00:00:24 | * | lubos_cz quit (Ping timeout: 244 seconds) |
00:03:11 | * | yglukhov joined #nim |
00:06:09 | cheatfate | and how your propose to run async proces? |
00:06:14 | cheatfate | procs? |
00:07:21 | * | yglukhov quit (Ping timeout: 246 seconds) |
00:27:45 | * | yglukhov joined #nim |
00:31:55 | * | yglukhov quit (Ping timeout: 244 seconds) |
00:44:19 | * | brson joined #nim |
01:03:50 | * | yglukhov joined #nim |
01:08:05 | * | yglukhov quit (Ping timeout: 244 seconds) |
01:12:48 | * | kseg joined #nim |
01:28:16 | * | yglukhov joined #nim |
01:32:24 | * | yglukhov quit (Ping timeout: 246 seconds) |
01:42:04 | * | brson quit (Quit: leaving) |
02:04:15 | * | yglukhov joined #nim |
02:08:41 | * | yglukhov quit (Ping timeout: 265 seconds) |
02:28:46 | * | yglukhov joined #nim |
02:33:32 | * | yglukhov quit (Ping timeout: 260 seconds) |
03:05:10 | * | yglukhov joined #nim |
03:09:57 | * | yglukhov quit (Ping timeout: 276 seconds) |
03:41:26 | * | yglukhov joined #nim |
03:44:44 | IcyFoxy | dom96: Happen to have a link? Searching without luck in finding this. Not currently listed in nimble's packages.json either. |
03:45:52 | * | yglukhov quit (Ping timeout: 260 seconds) |
03:55:05 | IcyFoxy | Nvm. Github's own search sufficed |
04:10:16 | * | sarlalian quit (Ping timeout: 252 seconds) |
04:13:20 | * | sarlalian joined #nim |
04:17:29 | * | yglukhov joined #nim |
04:21:48 | * | yglukhov quit (Ping timeout: 246 seconds) |
04:26:54 | * | endragor joined #nim |
04:41:54 | * | yglukhov joined #nim |
04:46:32 | * | yglukhov quit (Ping timeout: 260 seconds) |
05:18:02 | * | yglukhov joined #nim |
05:23:09 | * | yglukhov_ joined #nim |
05:23:12 | * | yglukhov quit (Ping timeout: 276 seconds) |
05:23:37 | * | endragor quit (Remote host closed the connection) |
05:24:00 | * | endragor joined #nim |
05:26:02 | * | yglukhov_ quit (Remote host closed the connection) |
05:36:08 | * | rok joined #nim |
05:39:03 | * | themagician quit (Ping timeout: 240 seconds) |
05:44:41 | * | themagician joined #nim |
05:54:46 | * | sarlalian quit (Ping timeout: 252 seconds) |
05:56:45 | * | sarlalian joined #nim |
06:16:44 | * | endragor_ joined #nim |
06:20:03 | * | endragor quit (Ping timeout: 240 seconds) |
06:22:02 | * | yglukhov joined #nim |
06:32:07 | * | endragor_ quit (Remote host closed the connection) |
06:32:35 | * | endragor joined #nim |
06:35:26 | * | kingofoz quit (Read error: Connection timed out) |
06:35:51 | * | kingofoz joined #nim |
07:06:33 | * | themagician quit (Ping timeout: 240 seconds) |
07:10:59 | * | themagician joined #nim |
07:13:04 | * | br3w5 joined #nim |
07:16:01 | * | br3w5 quit (Client Quit) |
07:25:58 | * | br3w5 joined #nim |
07:33:50 | * | br3w5 quit (Quit: br3w5) |
07:40:00 | * | gokr joined #nim |
07:40:04 | * | endragor quit (Remote host closed the connection) |
07:46:21 | * | rok quit (Quit: rok) |
07:53:41 | * | Matthias247 joined #nim |
07:56:48 | gokr | dom96: gitter is quite fine compared to slack IMHO. We already have gitter. |
07:58:34 | gokr | dom96: Also, startssl offers one cert for free IIRC. |
08:00:37 | * | Arrrr joined #nim |
08:00:37 | * | Arrrr quit (Changing host) |
08:00:37 | * | Arrrr joined #nim |
08:12:54 | * | kulelu88 joined #nim |
08:17:02 | * | tankfeeder joined #nim |
08:17:15 | * | endragor joined #nim |
08:27:59 | * | GangstaCat quit (Ping timeout: 260 seconds) |
08:43:09 | * | Arrrr quit (Ping timeout: 260 seconds) |
08:50:05 | * | yglukhov quit (Ping timeout: 276 seconds) |
08:55:31 | * | GangstaCat joined #nim |
09:19:05 | * | yglukhov joined #nim |
09:19:47 | * | yglukhov quit (Client Quit) |
09:25:00 | * | fastrom joined #nim |
09:25:46 | * | kseg quit (Quit: kseg) |
09:33:14 | * | fredrik92 joined #nim |
09:35:09 | * | PMunch joined #nim |
09:43:51 | * | der-landgraf quit (Ping timeout: 276 seconds) |
09:44:43 | * | gokr quit (Quit: Leaving.) |
09:44:47 | * | gokr1 joined #nim |
09:45:43 | * | fastrom quit (Quit: Leaving.) |
09:53:12 | * | GangstaCat quit (Quit: Leaving) |
09:58:07 | dom96 | gokr1: once again. The idea is to make this channel more accessible to users who already have Slack installed and are accustomed to it. |
10:00:48 | gokr1 | Sure, sorry :) |
10:01:11 | gokr1 | I configed Slack for Evothings, but... it was a bit of a pain to setup the invitation app that you need etc. |
10:01:29 | gokr1 | (people can't just join a Slack channel willy nilly) |
10:11:49 | endragor | afaik Gitter recently added auth via Twitter which helps people access it without having GitHub account |
10:27:04 | * | GangstaCat joined #nim |
10:32:13 | * | der-landgraf joined #nim |
10:36:09 | * | GangstaCat quit (Quit: Leaving) |
10:36:27 | * | GangstaCat joined #nim |
10:44:08 | * | elrood joined #nim |
10:48:03 | * | nchambers quit (Quit: Killed (Sigyn (Being awesome is too on-topic for freenode))) |
10:49:04 | * | nsf quit (Quit: WeeChat 1.4) |
10:49:28 | * | nchambers joined #nim |
10:51:01 | * | tankfeeder left #nim ("Leaving") |
10:54:51 | * | PMunch quit (Ping timeout: 246 seconds) |
11:00:40 | cheatfate | looks like i can't use literals as arguments for templates? |
11:13:28 | * | _stowa quit (Read error: Connection reset by peer) |
11:15:10 | gokr1 | dom96: It was also this article that got me moving from slack to gitter for Evothings: https://medium.freecodecamp.com/so-yeah-we-tried-slack-and-we-deeply-regretted-it-391bcc714c81#.x5g74dtj3 |
11:15:32 | gokr1 | dom96: Apart from the annoying invitation app thingy. |
11:24:49 | * | fredrik92 quit (Read error: Connection reset by peer) |
11:25:17 | * | fredrik92 joined #nim |
11:34:21 | * | Trustable joined #nim |
11:35:04 | * | PMunch joined #nim |
11:41:59 | * | der-landgraf quit (Quit: WeeChat 1.5) |
11:42:21 | * | der-landgraf joined #nim |
11:47:37 | elrood | any ideas why Xe considered slack harmful? |
11:48:02 | dom96 | gokr1: that indeed looks worrying, but I in no way want to make Slack the default form of communication for us. |
11:48:36 | dom96 | I just want to make a Slack front-end for this IRC channel |
11:48:42 | gokr1 | dom96: Sure! |
11:48:47 | dom96 | we can create the same thing for Gitter and anything else |
11:57:44 | dom96 | Some HN people seem to really dislike compilation to C https://news.ycombinator.com/item?id=11701200 |
12:00:08 | * | kulelu88 quit (Quit: Leaving) |
12:04:35 | elrood | who cares, as long as their worries remain largely theoretical and don't have any severe practical consequences |
12:04:44 | gokr1 | dom96: Hehe, yeah. Well, as usual people miss all the "real world" aspects of this and almost exclusively talk about technical details. |
12:07:24 | gokr1 | I already made Nim work on a Linkit ONE dev board, without the C/C++ backend that would have been a complete no go. |
12:07:47 | gokr1 | And without the C++ backend of Nim it would have been an insane task to create Urhonimo. |
12:11:45 | tautologico | C is a bad choice for a target compilation language for many source languages |
12:13:27 | tautologico | because despite what people say, C is not "high-level assembly", it imposes abstractions and a semantic model |
12:14:20 | tautologico | many functional language implementations were started by compiling to C and it didn't work, one of the main issues is tail call optimization |
12:14:38 | tautologico | but the case with Nim is different |
12:14:47 | * | nsf joined #nim |
12:15:10 | tautologico | Nim was/is designed to compile to C, so it takes the C semantic model as a starting point |
12:15:48 | elrood | to be fair, eg. clojure on the jvm does work quite well, while the jvm doesn't support tail call optimizations |
12:16:15 | tautologico | the JVM is a good example |
12:16:32 | tautologico | basically all languages that compile to the JVM have to acquire some of the semantics of Java |
12:17:10 | tautologico | the design of Scala has oddities that were imposed by the JVM |
12:17:22 | gokr1 | tautologico: IIRC Chicken has a fun take on that, right? |
12:17:30 | gokr1 | Chicken Scheme that is. |
12:18:15 | tautologico | gokr1: how's that? I don't know Chicken very well |
12:18:56 | gokr1 | IIRC it does some cool trick with the C stack. |
12:19:44 | tautologico | I may have heard about it sometime ago |
12:20:02 | tautologico | there are ways to get tail calls in C |
12:20:25 | tautologico | e.g. use continuation passing style |
12:20:38 | gokr1 | https://wiki.call-cc.org/chicken-compilation-process |
12:21:33 | tautologico | cool, it's CPS alright |
12:22:01 | gokr1 | right |
12:23:11 | elrood | on the other hand nim's strong bonds with c do sometimes make me worried how modular its design is and how feasible it would be to separate front- and backend and, say, have an alternative llvm-based nim implementation. the js backend does mitigate those worries only partially |
12:26:40 | * | Demon_Fox quit (Remote host closed the connection) |
12:27:10 | tautologico | I guess a llvm backend wouldn't be too difficult, but I don't know the nim compiler well yet |
12:27:12 | gokr1 | elrood: There is already an LLVM backend brewing. |
12:29:09 | elrood | interesting. really curious how well that works out and whether the early ties to a c backend impose any problems or limitations |
12:32:12 | * | gokr1 quit (Ping timeout: 276 seconds) |
12:33:30 | * | PMunch quit (Ping timeout: 276 seconds) |
12:47:03 | * | bamorim joined #nim |
12:51:06 | arnetheduck | tautologico, https://github.com/arnetheduck/nlvm .. can now create executables and covers maybe 90% of test suite |
12:51:16 | * | gokr joined #nim |
12:51:33 | arnetheduck | it can even compile itself |
12:52:38 | tautologico | arnetheduck: cool, will take a look |
12:59:52 | arnetheduck | elrood, by far the biggest problem is the reliance on c headers in the standard library, accounts for maybe 90% of the test failures |
13:07:05 | elrood | yup, assumed as much. really nice project though |
13:10:10 | tautologico | how does the JS backend solve this? |
13:21:35 | arnetheduck | it doesn't, mostly.. for a few specific cases there are js-specific hacks in the std lib |
13:24:19 | * | libman joined #nim |
13:29:41 | dom96 | arnetheduck: I think we will need to check for the LLVM backend and fix those cases that way |
13:29:56 | dom96 | Impressive that it works so well already |
13:30:36 | arnetheduck | dom96, I think that's a bad idea - it'll litter the std lib with even more of those ugly ifdef equivalents |
13:30:53 | dom96 | arnetheduck: what do you suggest we do instead? |
13:31:08 | arnetheduck | c2nim the whole bunch |
13:32:25 | arnetheduck | remove all includes, remove posix.nim and the like (which is broken anyway).. then create a libc in wrappers that wraps the c library like any other, providing nim-compatible definitions of all functions present in the local c library |
13:34:12 | arnetheduck | that way, all of the local c library will be available and ABI-compatible with nim code |
13:34:59 | cheatfate | arnetheduck, but windows dont have standart c library... |
13:35:08 | arnetheduck | of course it does |
13:35:20 | arnetheduck | what do you think is in all those msvcrt dlls? |
13:35:49 | arnetheduck | similarily, create a windows library that wraps windows functions in an abi-compatible way |
13:35:58 | cheatfate | arnetheduck, you need to check compatibility of c stdlib and msvcrt... you will be disappointed |
13:36:55 | arnetheduck | cheatfate, sure, but that is orthogonal to what I'm proposing |
13:37:56 | * | Parashurama joined #nim |
13:38:33 | arnetheduck | the point is to have a wrapper library that offers up a c library based on what is available on each platform.. then, other nim code can use these wrappers to provide a nim-level api that abstracts the differences (ie CreateFile vs open) |
13:38:36 | dom96 | cheatfate: Regarding https://github.com/nim-lang/Nim/issues/4160, I think it will require a call to poll() |
13:38:47 | dom96 | so we should continue with the callSoon changes |
13:39:25 | dom96 | Wanna create a PR for that? |
13:39:28 | Araq_ | I propose const C_Stuff {.importc.} instead which uses staticExec under the hood to determine the values |
13:40:14 | Parashurama | dom96: could you look at https://github.com/nim-lang/packages/pull/354? The problem should be corrected. |
13:40:27 | cheatfate | dom96, how do you want to insert poll() in #4160? |
13:40:59 | dom96 | cheatfate: replacing 'asyncCheck' with 'waitFor' would work |
13:41:13 | dom96 | Parashurama: could you rebase it? |
13:41:31 | dom96 | (we really need a bot that does it for us :\) |
13:43:21 | arnetheduck | to take a silly example, in posix, there's an equivalent for struct stat (of sys/stat.h fame) for file stuff.. except the order, quantity and type of fields doesn't match the native c libraries.. this works in nim because it casts everything to int eventually and looks up fields by name, but for something like nlvm, it's a source of horrible hacks in the compiler |
13:44:24 | Parashurama | dom96: OK, didn't know if it was needed. |
13:45:00 | arnetheduck | actually, the names don't match either, they're from some old, obsolete posix standard, and the c headers contain a macro to provide a backwards compatibility workaround ;) |
13:46:03 | * | gokr quit (Read error: Connection reset by peer) |
13:46:25 | * | fredrik92 left #nim ("Leaving channel") |
13:51:09 | * | bamorim quit (Ping timeout: 260 seconds) |
13:57:16 | cheatfate | dom96, so you want me to update async tests too? |
13:57:30 | dom96 | cheatfate: which ones? |
13:57:48 | cheatfate | tasyncdiscard.nim is what i remember |
13:58:38 | dom96 | sure |
13:59:12 | * | saml joined #nim |
14:00:03 | cheatfate | and how it must to be made to avoid bugs with automatic test run of PR? |
14:03:27 | dom96 | not sure I understand |
14:08:10 | * | saml quit (Remote host closed the connection) |
14:08:39 | cheatfate | dom96, simple replacing `asyncCheck` to `waitFor` not working because there no sockets/timers registered... so i got `Error: unhandled exception: No handles or timers registered in dispatcher. [ValueError]` |
14:09:34 | dom96 | cheatfate: fix that error so that it checks whether there are any queued callbacks |
14:10:05 | cheatfate | dom96, to avoid this error i need to create at least one asyncSocket |
14:10:15 | Parashurama | dom96: Should be good now. |
14:10:23 | cheatfate | dom96, ahh i understand |
14:11:00 | dom96 | Parashurama: oh sorry, could you pull master into your branch? |
14:11:07 | dom96 | and resolve the conflicts |
14:11:18 | * | saml joined #nim |
14:16:00 | * | mal`` quit (Ping timeout: 244 seconds) |
14:16:42 | cheatfate | dom96, one more problem from tasynctry.nim |
14:18:05 | dom96 | yes? |
14:18:52 | * | mal`` joined #nim |
14:28:11 | Parashurama | dom96: Done. This shows I'm not quite as comfortable with git I want to be :) |
14:29:30 | dom96 | Parashurama: Thank you. Good opportunity to get more comfortable with it :) |
14:29:41 | dom96 | merged |
14:29:54 | cheatfate | dom96, tasynctry.nim: [Error: unhandled exception: Future still in progress. [ValueError]] |
14:32:39 | Parashurama | dom96: I mean i have used git for ~2 years on a regular basis but its when you merge conflicts on several branches that you realize how *much* you know about version control (and git especially). |
14:33:52 | elrood | Parashurama, for the sake of diversity, you could alternatively get comfortable with mercurial and hg-git instead ;) |
14:38:29 | Parashurama | dom96: How often http://irclogs.nim-lang.org/packages.json is updated? |
14:39:10 | dom96 | Every 6 hours https://github.com/nim-lang/nimbot/blob/master/src/nimbot.nim#L62 |
14:41:47 | Parashurama | elrood: I have used hg in the past, but once i re-discovered git, I actually never tried it again. Not because i disliked it, but it *is* easier to only use a single VCS at the same time. |
14:42:04 | Parashurama | dom96: Ok thanks. |
14:45:19 | cheatfate | dom96, i have problems with this tests https://github.com/nim-lang/Nim/blob/devel/tests/async/tasynctry.nim#L94 |
14:45:59 | dom96 | cheatfate: can you show me the stack trace? |
14:46:36 | Parashurama | Question: Are methods intended to be used with concepts? because i have some UseBase warnings if i don't use the pragma, and an error if I do. |
14:46:54 | * | boop quit (Ping timeout: 246 seconds) |
14:46:57 | cheatfate | dom96: https://gist.github.com/cheatfate/1c3eca89e534ea5c029cc20598fe83d6 |
14:47:54 | * | boop joined #nim |
14:49:02 | dom96 | cheatfate: argh, that's annoying |
14:49:39 | cheatfate | dom96, yep, a little, but this is last test |
14:50:02 | dom96 | cheatfate: replace 'read' with 'waitFor' |
15:00:07 | Parashurama | dom96: Are methods intended to be used with concepts? because i have some UseBase warnings if i don't use the pragma, and an error if I do. |
15:00:55 | dom96 | Parashurama: I think they are, but concepts are still buggy. |
15:00:58 | dom96 | Araq_: ^ |
15:02:07 | Araq_ | sure, why use one type of polymorphism when you can use all at the same time. |
15:03:48 | Araq_ | Parashurama: generic methods don't work well and concepts always introduce generics |
15:07:26 | Parashurama | Araq_: I understand the idea: concepts generate a proc per object type matching the concept and with inheritance... I can see where its bugs. |
15:08:24 | Parashurama | I suppose I can use a template makeWhateverInterface() and generate the procs for the types passed as arguments |
15:20:05 | * | StarBrilliant quit (Ping timeout: 276 seconds) |
15:22:52 | arnetheduck | Araq_, home come a+1 generate a nkChckRange node but inc(a) doesn't? |
15:23:04 | arnetheduck | how |
15:23:59 | Araq_ | not sure but it has to generate an overflow check at least |
15:24:44 | * | StarBrilliant joined #nim |
15:26:35 | arnetheduck | well, for +, the overflow check is in nkchckrange, for inc it's part of the inc impl... |
15:32:07 | arnetheduck | so effectively, in the code gen, one needs to generate overflow checks in two places, one of which should be redundant if the ast made up its mind |
15:37:44 | Araq_ | *shrug* you can always transform the AST before codegen |
15:38:16 | Araq_ | and you need to introduce AST transformations soon enough once you add support for the GC |
15:40:50 | arnetheduck | sounds like such a transformation would be useful for all code gens.. or maybe even desugaring inc->add.. |
15:41:00 | arnetheduck | why do I need ast trasforms for gc? |
15:41:08 | arnetheduck | haven |
15:41:12 | arnetheduck | t seen any in c gen |
15:42:23 | arnetheduck | funny, you can inc a uint and uint64 but not a uint32 if I read it correctly.. also, succ/pred are not defined for unsigned types it seems |
15:43:17 | * | Senketsu quit (Quit: Leaving) |
15:43:53 | cheatfate | dom96, something wrong happens with Travis CI https://travis-ci.org/nim-lang/Nim/builds/130593926 |
15:47:46 | Araq_ | cheatfate: humm? where does it fail? |
15:48:11 | cheatfate | Araq_, i dont know... |
15:48:18 | cheatfate | Araq_, it just stopped |
15:48:23 | Araq_ | arnetheduck: the type traversion procs that are generated for the GC are painful to generate in C |
15:48:35 | Araq_ | and I suspect they are *horrible* for LLVM |
15:49:01 | cheatfate | Araq_, looks like it stopped here twrong_setconstr.nim |
15:49:13 | cheatfate | my windows tests also stopped on this test |
15:50:51 | arnetheduck | the nimtype stuff? |
15:51:10 | Araq_ | arnetheduck: yes |
15:51:17 | Araq_ | ccgtrav.nim |
15:51:37 | Araq_ | cheatfate: I'll be on Windows soon to test my GC fixes extensively |
15:51:49 | Araq_ | I'll look into this issue as well then |
15:51:55 | * | libman quit (Remote host closed the connection) |
15:52:34 | cheatfate | so do i need to close my pr? |
15:52:49 | arnetheduck | is high(uint) meant to work? |
15:53:47 | Araq_ | arnetheduck: for the 100th time. no. |
15:53:51 | Araq_ | cheatfate: nah |
15:53:51 | * | fastrom joined #nim |
15:54:04 | arnetheduck | documented somewhere? |
15:54:06 | Araq_ | cheatfate: try the stack overflow issue on the prim-gc branch please |
15:54:12 | Araq_ | should be gone. |
15:54:29 | Araq_ | I think so |
15:54:32 | Araq_ | bbl |
16:08:51 | cheatfate | Araq_, looks like you successfuly resolved #4160 but we still have a problem with #3190 |
16:09:03 | cheatfate | Araq_, https://gist.github.com/cheatfate/7a9b0cd45957dc928d3792fb17fa3684 |
16:14:02 | * | arnetheduck quit (Ping timeout: 276 seconds) |
16:16:43 | cheatfate | but looks like this is another problem |
16:17:10 | cheatfate | i think something wrong with closure environment |
16:28:51 | * | arnetheduck joined #nim |
16:31:58 | * | arnetheduck quit (Remote host closed the connection) |
16:34:32 | * | fastrom quit (Quit: Leaving.) |
16:36:04 | * | gokr joined #nim |
16:50:56 | Araq_ | cheatfate: how to reproduce? |
16:51:37 | cheatfate | Araq_, compile asynchttpserver.nim with "nim c asynchttpserver.nim" |
16:52:03 | cheatfate | and then you need to run "wrk http://xxx.xxx.xxx.xxx:5555" |
16:52:13 | cheatfate | asynchttpserver must be run on windows |
16:52:26 | cheatfate | wrk you can compile only on bsd/linux |
16:55:08 | cheatfate | or you can use another tool which can stress test http protocol |
16:59:23 | * | fastrom joined #nim |
17:02:31 | * | Parashurama quit (Remote host closed the connection) |
17:04:33 | * | gokr quit (Ping timeout: 276 seconds) |
17:05:50 | * | brson joined #nim |
17:15:03 | * | fastrom quit (Quit: Leaving.) |
17:30:44 | * | brson quit (Quit: leaving) |
17:31:03 | * | brson joined #nim |
17:42:27 | * | bozaloshtsh quit (Changing host) |
17:42:27 | * | bozaloshtsh joined #nim |
18:09:19 | * | gokr joined #nim |
18:25:01 | * | bozaloshtsh quit (Ping timeout: 265 seconds) |
18:40:45 | * | fastrom joined #nim |
19:24:20 | * | fastrom quit (Quit: Leaving.) |
19:30:29 | federico3 | what's the best way to allocate a string of a given size? |
19:31:31 | federico3 | newString(n) I guess |
19:31:39 | dom96 | yep |
19:32:07 | * | fastrom joined #nim |
19:43:42 | * | Jesin quit (Quit: Leaving) |
19:45:37 | * | Jesin joined #nim |
19:47:33 | * | PMunch joined #nim |
19:50:11 | * | Jesin quit (Client Quit) |
19:56:55 | federico3 | actually newString is returning zeroed contents even with d:release |
19:58:05 | * | Jesin joined #nim |
20:09:36 | * | Ven joined #nim |
20:12:34 | * | Ven quit (Read error: Connection reset by peer) |
20:25:07 | * | bozaloshtsh joined #nim |
20:45:35 | * | fastrom quit (Quit: Leaving.) |
20:58:23 | fowl | federico3, newStringOfCap |
21:02:31 | * | libman joined #nim |
21:09:45 | * | endragor_ joined #nim |
21:13:18 | dyce_ | i wrote a little webserver with jester + nim. https://glot.io/snippets/eeqrvf60o2 i noticed that ram increased from 900kb to around a peak of 5MB. (after running curl with a for loop). given the app's simplicity, are there any tweaks to improve ram usage? |
21:13:49 | * | endragor quit (Ping timeout: 252 seconds) |
21:14:22 | * | endragor_ quit (Ping timeout: 252 seconds) |
21:17:28 | * | elrood quit (Quit: Leaving) |
21:39:42 | dom96 | dyce_: try compiling with --gc:markandsweep, there is still one or two bugs left with the compiler which causes small leaks like that when using async. |
21:39:56 | cheatfate | dom96, asynchttpserver not leaking... |
21:40:07 | cheatfate | asyncdispatch too |
21:44:02 | cheatfate | dyce_, what os you are using? |
21:44:15 | dyce_ | osx |
21:45:31 | cheatfate | hmm |
21:47:04 | dom96 | cheatfate: What makes you so sure? |
21:47:15 | cheatfate | dom96, so many tests... |
21:47:38 | cheatfate | dom96, i will run one more test in a minute |
21:47:41 | dom96 | cheatfate: the forum and NimBot both leak unless compiled with --gc:markandsweep |
21:48:35 | cheatfate | dom96, i'm using ./wrk so it burst to maximum memory usage in a seconds and there no continuous memory leaking any more |
21:49:00 | dom96 | cheatfate: it happens over multiple days |
21:49:18 | dyce_ | with markandsweep it peaks around 4mb |
21:52:22 | cheatfate | dom96, 5 runs of wrk 170k requests |
21:52:27 | dyce_ | ah but it uses the gc faster? |
21:52:37 | cheatfate | no leaks on freebsd |
21:52:59 | dyce_ | but still the memory allocated goes from 700KB to 2.4MB for a simple resp "hi" app |
21:53:02 | cheatfate | 5*170-220k requests = near 1 million requests |
21:53:21 | dyce_ | peaks at 3.9MB |
21:53:23 | cheatfate | and no leaks |
21:53:39 | cheatfate | maybe jester? :)\ |
21:54:58 | cheatfate | Araq_, how is progress on your really great prim-gc? |
22:00:29 | dom96 | cheatfate: that's easy to work out, try jester then asynchttpserver on its own :) |
22:01:12 | * | yglukhov joined #nim |
22:03:49 | dom96 | https://twitter.com/pcwalton/status/732329324481634304 |
22:03:58 | dom96 | Must. Not. Reply. |
22:04:16 | Xe | dom96: what can I do to help out with https://github.com/dom96/jester/pull/67? |
22:05:35 | dom96 | Xe: See if there is a way to make it work without creating a global 'jester' var |
22:06:40 | Xe | dom96: it looks like that is referring to the jester module itself |
22:07:23 | dom96 | Xe: I'm referring to this https://github.com/dom96/jester/pull/67/files#diff-03ee768e621c7de115a1c9956eb8f201R85 |
22:07:54 | Xe | hmm |
22:08:06 | Xe | i don't know how you'd do it without breaking api |
22:09:14 | Xe | dom96: you already do make a global jester var |
22:09:16 | Xe | https://github.com/dom96/jester/pull/67/files#diff-03ee768e621c7de115a1c9956eb8f201L322 |
22:10:08 | dom96 | Xe: Do I? I think that's under the 'serve' proc? |
22:10:40 | Xe | dom96: it looks like it's being lifted to a package level mutable state so that other instances of `routes` can add to it |
22:11:00 | Xe | unless you extend `routes` to allow you to pass your own jester instance that you build up by hand |
22:14:32 | dom96 | yeah :\ |
22:14:48 | Xe | i mean |
22:14:54 | Xe | unless you have a better idea :/ |
22:14:54 | dom96 | Araq_: We still can't have compile-time vars can we? |
22:25:39 | * | GangstaCat quit (Ping timeout: 260 seconds) |
22:34:06 | * | gokr quit (Ping timeout: 276 seconds) |
22:36:36 | * | Demon_Fox joined #nim |
22:51:49 | * | brson quit (Quit: leaving) |
22:52:28 | * | brson joined #nim |
23:00:56 | * | Trustable quit (Remote host closed the connection) |
23:14:04 | Araq_ | dom96: what makes you say that? |
23:14:33 | * | Matthias247 quit (Read error: Connection reset by peer) |
23:43:11 | * | bozaloshtsh quit (Ping timeout: 276 seconds) |