<< 26-04-2016 >>
00:01:12*pregressive joined #nim
00:04:57*fredrik92 quit (Quit: Shutting down...)
00:10:51*bozaloshtsh quit (Quit: leaving)
00:12:18*krux02 quit (Remote host closed the connection)
00:14:16*enthus1ast quit (Read error: Connection reset by peer)
00:14:51*enthus1ast joined #nim
00:20:42*space-wi_ joined #nim
00:23:21*space-wizard quit (Ping timeout: 276 seconds)
00:25:56*bozaloshtsh joined #nim
00:26:11bozaloshtshDemon_Fox: peg isn't a superset of regex
00:32:20*gokr quit (Ping timeout: 250 seconds)
00:54:23Demon_FoxIt would appear so
00:54:37Demon_FoxIt appears to be incompatible
00:56:31*nsf quit (Quit: WeeChat 1.4)
01:04:16*nsf joined #nim
01:06:45*brson quit (Quit: leaving)
01:07:52*brson joined #nim
01:33:22*brson quit (Quit: leaving)
01:54:38*bozaloshtsh quit (Quit: leaving)
01:55:58*bozaloshtsh joined #nim
03:04:00*PMunch quit (Ping timeout: 250 seconds)
03:20:49*silven quit (Read error: Connection reset by peer)
03:22:48*silven joined #nim
03:27:33*pregressive quit (Ping timeout: 244 seconds)
03:32:18*space-wi_ quit (Quit: My Mac has gone to sleep. ZZZzzz…)
04:52:17*enthus1ast quit (Ping timeout: 250 seconds)
05:05:27*kingofoz quit (Ping timeout: 260 seconds)
05:06:44*kingofoz joined #nim
05:09:42*Sembei quit (Read error: Connection reset by peer)
05:10:50*Sembei joined #nim
05:15:20*desophos quit (Read error: Connection reset by peer)
05:21:40*yglukhov joined #nim
05:25:08*pregressive joined #nim
05:28:39*rusua joined #nim
05:29:44*pregressive quit (Ping timeout: 260 seconds)
05:34:56*castlelore quit (Quit: WeeChat 1.4)
05:35:22*castlelore joined #nim
05:39:05*silven quit (Ping timeout: 250 seconds)
05:39:47*silven joined #nim
05:42:33*castlelore quit (Ping timeout: 246 seconds)
05:49:21*castlelore joined #nim
05:49:45*space-wizard joined #nim
05:49:49*s4 joined #nim
05:50:20*space-wizard quit (Max SendQ exceeded)
05:51:00*space-wizard joined #nim
05:56:31*niv grumbles about the future
05:57:22nivcan i not clean()/complete() a futurevar multiple times?
05:58:47nivhttps://gist.github.com/niv/b1e0a3562a7a88c097018a861d9f56e5 what am i doing wrong?
06:00:33*space-wizard quit (Quit: My Mac has gone to sleep. ZZZzzz…)
06:03:14*Varriount quit (Read error: Connection reset by peer)
06:03:49*Varriount joined #nim
06:10:36*Varriount quit (Read error: Connection reset by peer)
06:10:50*Varriount joined #nim
06:14:14*fredrik92 joined #nim
06:27:39*yglukhov quit (Remote host closed the connection)
06:47:45*MyMind joined #nim
06:49:52*Sembei quit (Ping timeout: 260 seconds)
06:51:35*kingofoz quit (Ping timeout: 276 seconds)
06:52:40*kingofoz joined #nim
06:54:42*gokr joined #nim
06:54:55*zama quit (Ping timeout: 250 seconds)
06:55:39*zama joined #nim
07:01:55*pregressive joined #nim
07:07:22*pregressive quit (Ping timeout: 260 seconds)
07:10:23*Arrrr joined #nim
07:10:23*Arrrr quit (Changing host)
07:10:23*Arrrr joined #nim
07:21:19*fredrik92 quit (Quit: Leaving)
07:36:35*Pisuke joined #nim
07:39:10*MyMind quit (Ping timeout: 244 seconds)
07:42:11*Sembei joined #nim
07:43:53*Pisuke quit (Ping timeout: 250 seconds)
07:44:45*nsf quit (Ping timeout: 250 seconds)
07:49:19*nsf joined #nim
07:50:29*yglukhov joined #nim
08:03:33*pregressive joined #nim
08:08:09*pregressive quit (Ping timeout: 250 seconds)
08:15:06*Trustable joined #nim
08:24:02*endragor joined #nim
08:28:38*endragor_ joined #nim
08:31:21*endragor quit (Ping timeout: 244 seconds)
08:45:28*dorei joined #nim
08:51:26*endragor_ quit (Remote host closed the connection)
08:51:37*kingofoz quit (Read error: Connection reset by peer)
08:52:00*endragor joined #nim
08:52:39*Demon_Fox quit (Remote host closed the connection)
09:01:50*endragor quit (Remote host closed the connection)
09:04:20*rok joined #nim
09:28:03*Heartmender quit (Ping timeout: 264 seconds)
09:29:43*Guest72720 joined #nim
09:34:45*ephja joined #nim
09:36:52*Guest72720 quit (Ping timeout: 268 seconds)
09:46:43*Heartmen- joined #nim
09:51:27*Heartmen- quit (Quit: EliteBNC free bnc service - http://elitebnc.org - be a part of the Elite!)
09:58:00*izi quit (Quit: Leaving)
09:58:13*Heartmen- joined #nim
10:02:33*Heartmen- quit (Ping timeout: 250 seconds)
10:05:29*pregressive joined #nim
10:06:18*dorei quit (Ping timeout: 250 seconds)
10:06:53*dorei joined #nim
10:09:58*pregressive quit (Ping timeout: 250 seconds)
10:10:30nivdom96: can i bother you for a moment?
10:11:14dom96niv: sure :)
10:11:32nivdom96: cool. is there a way to reset a future?
10:11:43nivi tried this: https://gist.github.com/niv/b1e0a3562a7a88c097018a861d9f56e5
10:12:53dom96why are you using a FutureVar?
10:13:32nivno idea. i tried Future too, with the same result :)
10:13:45nivim trying to use it as a cheap mutex
10:14:37nivmaybe i should just recreate it instead of resetting it, but i suspect then other awaiters will fail
10:15:46dom96hrm
10:16:12nivyeah
10:17:11nivim attempting to use it to basically make an async proc atomic. it can be awaited upon (and it in itself awaits on other things) but it can only be run once at a time
10:17:13*Heartmen- joined #nim
10:18:05dom96the reason that happens is because 'await' sets a callback on 'fut'
10:18:12dom96'clean' does not reset that callback
10:18:13dom96https://gist.github.com/dom96/4046cf5ee677cbae1c069bc734b8cca6
10:18:14dom96that works
10:18:34nivfunny
10:18:46nivis that a bug with clean() then?
10:18:47dom96Question is, should `clean` do that?
10:18:55dom96indeed, that is the question heh
10:18:59nivi dunno. is resetting futures something that is supported at all?
10:19:10nivits not exactly the official usecase for them, the way I do it
10:20:04dom96'clean' is used here: https://github.com/nim-lang/Nim/blob/devel/lib/pure/asynchttpserver.nim#L176
10:20:41dom96so it gets lucky and the 'await' sets the callback again
10:20:54dom96It makes sense to reset the future completely I think
10:20:58dom96wanna make a PR to fix this? :)
10:21:55*Heartmen- quit (Quit: EliteBNC free bnc service - http://elitebnc.org - be a part of the Elite!)
10:22:13*kingofoz joined #nim
10:23:08*rok quit (Quit: rok)
10:24:38nivi'll look into it, but first i need to find out why this stuff isnt working either
10:26:02nivhttps://gist.github.com/niv/5e50fef3a33ba52cdfa6654822e80c7e got a tip for me? apparently, code beyond the await is running twice - but there is only one call to it.
10:26:43*Guest50721 joined #nim
10:27:55nivnever mind, i was stupid. accidentally dropped the cb reset
10:30:20*yglukhov_ joined #nim
10:32:42*yglukhov quit (Ping timeout: 246 seconds)
10:33:13*Guest50721 quit (Quit: EliteBNC free bnc service - http://elitebnc.org - be a part of the Elite!)
10:40:43*Heartmen- joined #nim
10:45:30*Heartmen- quit (Ping timeout: 250 seconds)
11:03:56kingofozhello
11:04:10kingofozI am trying to build urhonimo
11:04:21kingofozPlease see this sentence: You can then copy the resulting .lib file from the lib directory into Urhonimo's lib directory.
11:04:40kingofozno lib filder in urhonimo
11:04:55*rusua quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
11:05:36dom96kingofoz: sorry, I can't help. But maybe gokr or Araq_ can?
11:05:59gokrmmm
11:06:13*Heartmen- joined #nim
11:06:31kingofozsee this: On Windows you will need both a .dll as well as a .lib file. The DLL can be downloaded from Urho3D's website.
11:06:49kingofozurho3d doesn't mention a dll
11:06:56kingofozso I didn't get it
11:06:58gokrone sec
11:09:23gokrRegarding "lib directory", just make one in Urhonimo.
11:09:29gokrThat's a doc buglet.
11:09:59yglukhov_Araq: how does nim decide whether to put frame info into a generated C func or not?
11:11:39gokrkingofoz: Regarding download (don't remember the details) I think it's here: https://sourceforge.net/projects/urho3d/files/Urho3D/
11:11:40*Heartmen- quit (Quit: EliteBNC free bnc service - http://elitebnc.org - be a part of the Elite!)
11:12:26kingofozwhat is the name of the dll?
11:17:43gokrI think its the libUrho3D.dll.a file in the SHARED blabla downloads. Although... not sure.
11:17:48gokrLimited time to help right now
11:18:43*Heartmen- joined #nim
11:19:33gokrkingofoz: I also don't recollect that about needing a dll, wonder if that is really true.
11:19:53kingofozok
11:20:01kingofozplease see this error:LINK : fatal error LNK1181: cannot open input file 'd:\labs\urhonimo\examples\ni
11:20:02kingofozmcache\stdlib_os.obj'
11:20:50kingofozand there are a lot of this error: C:\Nim\lib\nimbase.h(412): error C2118: negative subscript
11:23:25gokrNo idea, punting to Araq.
11:23:36*Heartmen- quit (Quit: EliteBNC free bnc service - http://elitebnc.org - be a part of the Elite!)
11:24:11kingofozAraq_, we need you
11:24:13kingofoz:-)
11:29:35gokrIf I were you I would start by following the instructions to the letter (same version of Nim, same version of VS, same version of Urho3D etc).
11:29:44gokrAnd when that works, I would try deviating.
11:30:27gokrThe positive side here is that the demos are pretty darn cool - so hopefully it will give you a good taste.
11:31:43*Heartmender joined #nim
11:31:44*Heartmender is now known as Guest13017
11:35:43Araq_kingofoz: it means your visual studio and Nim disagree on the bitsize of a word
11:36:44Araq_gokr: well ... I need to update the instructions :-)
11:36:49kingofozhow to fix it?
11:36:56kingofozdo you see the fatal error?
11:36:56*Guest13017 quit (Ping timeout: 276 seconds)
11:37:13kingofozI use vs 2015 and nim 0.13
11:37:26Araq_what does nim --version say?
11:38:13kingofozfatal error LNK1181: cannot open input file 'd:\labs\urhonimo\examples\ni
11:38:13kingofoz<kingofoz> mcache\stdlib_os.obj'
11:38:20kingofozah sorry
11:38:30kingofozNim Compiler Version 0.13.0 (2016-01-19) [Windows: amd64]
11:38:30kingofozCopyright (c) 2006-2015 by Andreas Rumpf
11:38:41kingofozmaybe I should try 32bit nim?
11:39:01Araq_yup
11:40:11kingofozdo we really need a dll?
11:42:19gokrAraq_: Instructions at Urhonimo talks about a Urho3d dll file needed for Windows. I don't recall if that's ... correct.
11:43:47*Heartmen- joined #nim
11:45:27kingofozok, now it works, 32bit nim
11:45:36kingofozanother question, it needs d3dcompiler_47.dll
11:45:39kingofozto run
11:46:05kingofozum... from the name, seems this dll should not be needed?
11:46:17Araq_gokr: nope, it links against the lib file
11:46:36Araq_kingofoz: most likely it is needed since it's the shader compiler or something
11:46:51kingofozok
11:47:39kingofozthat dll is not needed, right?
11:47:47kingofozI mean, the dll in Instructions
11:49:31Araq_aye
11:50:05kingofozok
11:50:23kingofozhello.nim does not work and exit automatically
11:50:30kingofozjust a black screen
11:54:27*Heartmen- quit (Quit: EliteBNC free bnc service - http://elitebnc.org - be a part of the Elite!)
11:54:40kingofozbelow are some outputs:
11:54:41kingofoz[Tue Apr 26 19:52:41 2016] DEBUG: Loading resource Fonts/BlueHighway.ttf
11:54:41kingofoz[Tue Apr 26 19:52:41 2016] DEBUG: Font face BlueHighway (42pt) has 395 glyphs
11:54:41kingofoz[Tue Apr 26 19:52:41 2016] DEBUG: Reloading shaders
11:54:41kingofoz[Tue Apr 26 19:52:41 2016] DEBUG: Loading resource Shaders/HLSL/Basic.hlsl
11:54:41kingofoz[Tue Apr 26 19:52:41 2016] DEBUG: Loaded cached vertex shader Basic(DIFFMAP VERT
11:54:43kingofozEXCOLOR)
11:54:45kingofoz[Tue Apr 26 19:52:41 2016] DEBUG: Loaded cached pixel shader Basic(ALPHAMAP VERT
11:54:45*Arrrr_ joined #nim
11:54:47kingofozEXCOLOR)
11:55:37Araq_give it the urho data stuff like the instructions tell you
11:55:42*Parashurama joined #nim
11:56:32*krux02 joined #nim
11:57:33*Arrrr quit (Ping timeout: 240 seconds)
11:58:30kingofozgiven
11:59:20*krux02 quit (Client Quit)
11:59:35kingofozCoreData and Data, right?
11:59:38kingofozcopied
12:00:14*Arrrr_ quit (Quit: WeeChat 1.4)
12:01:50kingofozwhen black screen shown, if I press any key, it will exit
12:06:27*RGeisel joined #nim
12:07:04*pregressive joined #nim
12:07:26*RGeisel left #nim (#nim)
12:11:58*pregressive quit (Ping timeout: 244 seconds)
12:12:43*Heartmen- joined #nim
12:14:37*arnetheduck joined #nim
12:14:39yglukhov_Araq_: please take a look at https://github.com/nim-lang/Nim/pull/4115
12:16:45*Heartmen- quit (Client Quit)
12:18:33nivi think i found a bug in the gc. but i cant repro it. https://gist.github.com/niv/abdca03f7954880171e2db9f06e27d2c
12:18:43nivit just happened one-off in a tight loop, now it doesnt happen again
12:21:06*BitPuffin joined #nim
12:23:43*Heartmen- joined #nim
12:27:57*Heartmen- quit (Client Quit)
12:31:43Araq_yglukhov_: why doesn't it run the tests for this PR?
12:32:43yglukhov_no idea. i'll try to bump it.
12:33:40yglukhov_ok, tests started
12:34:16*Heartmender joined #nim
12:34:24ParashuramaHey is it desired behaviour to forbid same module name in different folder inside single module.
12:34:31*Heartmender is now known as Guest68809
12:34:58Araq_Parashurama: inside single package you mean? if so, yes.
12:35:04Parashuramaex: foo.module.nim and blah.module.nim
12:35:29Parashuramayes, exactly they generate same file inside nimcache
12:35:35Parashuramaand crash the C compiler
12:35:55Parashuramawith missing symbols (with TCC)
12:38:26Araq_yup, the compiler should report that as an error properly.
12:38:28nivAraq_: inside an async proc, s there a reason why try/finally: <xx> would run code once, but defer: <xx> would run <xx> twice?
12:38:58Araq_no.
12:39:10*Guest68809 quit (Quit: EliteBNC free bnc service - http://elitebnc.org - be a part of the Elite!)
12:39:15ParashuramaDo you want me to create a new issue about that, with test files?
12:39:20nivi suspect it's something to do with the async macro, but i really have no idea
12:39:43cheatfateParashurama, try to do same on regualar proc
12:40:50Parashuramacheatfate: I not sure what you meant
12:41:01cheatfateParashurama, sorry
12:41:43cheatfateniv, did you use "## * Can't await in a ``except`` body" ?
12:41:55nivno, in a finally block
12:43:29nivcorrection, not using await at all in any try/finally/defer
12:43:34nivjust inside the try
12:43:43*Heartmen- joined #nim
12:46:14cheatfateAraq_, about https://github.com/nim-lang/Nim/pull/4107, i dont understand "This is wrong"
12:46:56Araq_cheatfate: it's a ref that you alloc0
12:47:08Araq_it's wrong.
12:47:29cheatfateAraq_, ok, how i can `new` with size?
12:47:46Araq_unsafeNew
12:47:47*Heartmen- quit (Quit: EliteBNC free bnc service - http://elitebnc.org - be a part of the Elite!)
12:47:57cheatfatethanks i will check
12:47:59Araq_but why is that necessary?
12:48:08Araq_the size is known at compile-time
12:48:53Araq_oh wait, ugh.
12:48:58Araq_that's gonna be messy.
12:49:08Araq_better use a 'seq' for the single threaded case
12:49:50cheatfateAraq_, i dont know why but `seq`'s is 2x times slowly than simple array
12:50:23Araq_I don't know either. benchmark it.
12:51:36cheatfateAraq_, i have already made benchmarks...
12:52:50cheatfateok i will do some more without memory allocations just for push/pop on same size
12:55:19yglukhov_Araq_: tests complete
13:00:56kingofozAraq_, any clue on hello.nim's issue?
13:01:20Araq_kingofoz: try the particles and character demos
13:01:35Araq_iirc hello.nim might indeed be buggy
13:03:14dom96niv: yes, the try/except/finally stmt transformation is faulty.
13:03:29nivalready made an issue, for better or worse
13:03:41dom96niv: you're better off checking manually whether a future failed
13:03:55kingofozparticles and character works vell well
13:04:30nivdom96: how would i do that, and still benefit from "await"?
13:04:48dom96niv: var fut = asyncProc(); await fut; if fut.failed: # handle error
13:05:22nivdom96: this seems to work: https://gist.github.com/niv/9d4ad9fff35c57d36454bb799e83eaf3 - am i doing things wrong?
13:06:25dom96not sure, you might be getting lucky with the transformation
13:06:37dom96only way to know for sure is to look at what the macro generates
13:07:01nivi dont so much care about the error, i just want to make sure the future completes
13:07:02dom96Araq_: is there a way to see what the compiler produces after macro/template expansion?
13:07:13*Heartmen- joined #nim
13:07:39*rusua joined #nim
13:08:30Araq_seriously?
13:08:36Araq_echo repr result
13:08:58*filcuc joined #nim
13:09:59kingofozAraq_, can you find the bug?
13:10:59federico3in "not a in 1..3" the not evaluates before the "in", is that expected?
13:11:16*Heartmen- quit (Client Quit)
13:11:23dom96Araq_: ...without modifying the source code, I know how to get the expansion of a single macro but I want to see what everything expands to.
13:11:41dom96(So that I don't need to tell niv to modify asyncdispatch.nim in order to see what the macro produces)
13:12:18arnetheduckAraq_, ping
13:15:18Araq_"what everything expands to". yeah good luck with that. even != is a template expansion in Nim. Welcome to Nim. :-)
13:15:50Araq_what your async macro should have is:
13:16:09Araq_when defined(showAsyncExpansion): echo repr result
13:16:27Araq_and then you tell niv to compile with -d:showAsyncExpansion
13:17:04arnetheduckwhen you have a moment, https://github.com/nim-lang/Nim/pull/4002
13:17:18Araq_or perhaps we can build that into the compiler. --show:async
13:17:55Araq_kingofoz: don't have time plus I don't consider it important. the real examples work. ;-)
13:18:42Araq_arnetheduck: looks good
13:20:33arnetheduckAraq_, great.. ever considered having the compiler pass currently allocated size to realloc/dealloc? it either knows it or can compute it
13:21:10Araq_yeah but never did it. would be a much nicer solution.
13:21:27dom96Araq_: Even though there is a LOT of expansions, it would still be interesting to see the source code of the project file being compiled after the expansion
13:21:31kingofozum....
13:22:08Araq_arnetheduck: now I have "This branch has conflicts that must be resolved" :-)
13:22:15kingofozactually I want to wraite some texts on a window in my game
13:22:27kingofozthat is why I care about this demo so much
13:22:31kingofoz:-D
13:22:47Araq_so do that and complain if *that* doesn't work :P
13:23:12Araq_my bet is that it is some initialization problem that is gone with real world examples.
13:23:30kingofozreal world examples?
13:23:36kingofozdo you mean the others?
13:23:38arnetheduckAraq_, trivial, or should I update it? I'm guessing news
13:23:56Araq_update it please, I like pressing github buttons
13:24:04Araq_kingofoz: yes
13:24:30kingofozwhen you have time, please have a look
13:24:46kingofozI suspect if we can write text in a real game
13:25:13Araq_come on, give me a real bug report, not some vague fear
13:26:09kingofoz:D
13:26:35arnetheduckAraq_, there
13:27:05Araq_arnetheduck: well thanks but now I want the better fix. :-)
13:27:15Araq_patch the compiler to pass the old size.
13:27:36arnetheduckAraq_, yeah sure. I'll do that if you fix gc support for nlvm
13:27:53Araq_what's there to fix?
13:28:29Araq_nlvm should generate the same write barriers that the C backend does
13:30:13arnetheduckAraq_, no idea ;) the gc code in the c generator is.. er, .. well.. mature? and a bit hard to follow.. with the OnStack/OnHeap being set all over the place
13:30:36cheatfateAraq_, i think dom96 is right and we need compiler feature to see generated nim code after all templates expanded :)
13:32:01*Heartmender joined #nim
13:32:05federico3can I do something like "let b = try: a except: continue" ?
13:32:17*Heartmender is now known as Guest44724
13:34:20*cheatfate_ joined #nim
13:34:30arnetheduckAraq_, also, the Nim version I used to compile nlvm was crashing all the time so I had to switch to mark&sweep just to compile anything larger than a simple test case.. might have improved since then, but the
13:37:39*cheatfate quit (Ping timeout: 276 seconds)
13:39:57arnetheduckthen it was hard to figure out where the bugs were (nlvm or Nim)
13:46:21Araq_arnetheduck: can explain it later. you don't have to replicate this logic, there are easier ways to accomplish the same
13:50:54*rok joined #nim
13:53:26*Sonderblade quit (Ping timeout: 276 seconds)
13:55:28*pregressive joined #nim
14:05:56*Sonderblade joined #nim
14:17:14*s4 quit (Quit: Konversation terminated!)
14:38:42cheatfate_Araq_, why you warn me about unsafeNew(), i like it :)
14:39:50cheatfate_Araq_, there is only way to beat your queues.nim where no alloc/realloc
14:40:34*Parashurama quit (Quit: ChatZilla 0.9.92 [Firefox 45.0.1/20160325004906])
14:42:14cheatfate_Araq_, i got 9% faster where no alloc/realloc and 63% faster with alloc/realloc
14:44:18*Motan joined #nim
14:48:05Araq_cheatfate_: it's not correct with unsafeNew if T is something that contains GC'ed memory.
14:48:32Araq_for MT this is "not" a problem since these don't work properly for other reasons. but the original queue worked with them.
14:54:43Araq_arnetheduck: merged it until a better patch from you arrives ;-)
14:58:06arnetheduckAraq_, my gut feeling would be that it's not too hard, unless you want it backwards compatible, in which case it's pointless (ie if one can break the realloc/dealloc api, one can reap the benefits of not having to stored alloced size)
14:58:45arnetheduckas far as the compiler goes, afair it only reallocs seqs and strings, so it's trivial
14:59:18Araq_it's not too hard but it's also sad that by 2016 Ansi C doesn't give access to the internal length.
14:59:35Araq_it's not like you can write an allocator which doesn't track the size in some way.
14:59:39arnetheduckthat's because likely, it doesn't store the internal length
15:00:19Araq_there is no allocator out there which cannot give you the length. 99% of them can even provide it in O(1)
15:00:22arnetheduckyou do, actually.. you store a rounded size, and then you use the freed up bits for extra info
15:00:42Araq_rounded size is good enough.
15:02:28arnetheduckthen you need to zero out the rounded size on allocation, which violates the api of malloc in a different way (by writing past requested size)
15:07:16Araq_you can always write past the 'requested' size if malloc itself told you it actually allocated more than the requested size.
15:08:06Araq_for valgrind like checks you can always return the requested size, not the real size with some overhead.
15:11:45*dorei quit (Quit: Page closed)
15:12:42*gokr quit (Ping timeout: 246 seconds)
15:13:24*boop quit (Ping timeout: 246 seconds)
15:14:11*boop joined #nim
15:17:34*PMunch joined #nim
15:20:17arnetheduckon the topic of memory and gc, if I do let a = "hello", why does nim make a copy of the constant string global?
15:21:05arnetheduckcan't change it through a anyway, so it seems like one could delay the copying and let a point to the constant?
15:33:38arnetheducknevermind, I guess it's to handle the generic let a = b case where b might be a var?
15:44:42nivdom96: got a sec?
15:44:52nivdom96: did you write the nim redis client that's on github?
15:46:23*filcuc quit (Ping timeout: 244 seconds)
15:51:42*fredrik92 joined #nim
15:53:54*arnetheduck quit (Quit: Leaving)
15:59:23*space-wizard joined #nim
16:00:29*Parashurama joined #nim
16:05:47*yglukhov_ quit (Ping timeout: 260 seconds)
16:06:33Araq_niv: indeed he did.
16:07:30nivAraq_: thanks! i'm hacking away at a redis client of my own, and I was wondering why dom96 used BiggestInt instead of int64 for the redis datatype
16:07:40*fredrik92 left #nim ("Leaving channel")
16:07:58nivredis integers always are 64bit wide after all, so this flummoxes me a bit
16:08:34Araq_I don't think there is a real reason. it's unlikely BiggestInt will become int128 anytime soon though.
16:08:55nivare there nim compilers in existence somewhere that dont support 64bit?
16:09:30Araq_no, even Nim+Tiny C supports int64
16:09:51Araq_well actually. embedded CPUs might not support it, yeah.
16:10:36Araq_so yeah, forget it, I didn't think, BiggestInt could be way smaller than 64 bits.
16:10:47nivokay then. never seen one of those alive myself :) is there someone using them or is it just theoretical? can you program an atmel or avr with nim?
16:11:12Araq_avr is semi-officially supported even.
16:11:18nivnice!
16:11:27nivi'll have to grab one just to play with it
16:12:10Araq_people claim it's pointless since you cannot use Nim's GC etc. but that's wrong. the meta programming, the saner type system and the meta programming makes it still worthwhile.
16:12:24Araq_IMHO.
16:13:08nivnim is a lovely language that is much more productive than plain C. but i never tried turning off the GC. i assume normal stack stuff still works as it does now?
16:13:09Araq_lol I listed the meta programming twice.
16:13:16nivyes, yes you did. :)
16:13:44Araq_you can use --gc:stack which kind of works, but needs to be documented.
16:14:16Araq_with it you can use the whole stdlib and deal with memory semi-automatically.
16:14:35Araq_but it still uses the heap so for tiny devices it doesn't gain much.
16:14:58nivthat's pretty cool still. I'll have to test it out sometime
16:15:06Araq_--gc:none is pretty restrictive, so eventually --gc:stack will replace it.
16:16:10Araq_oh and we need a better name. --gc:obstack ? (it copied GCC's obstacks ideas)
16:16:37nivdont ask me. im not that versed in how compilers work and what their naming patterns are. --gc:workdamnit?
16:17:20Araq_I think I like --gc:excuse
16:17:31nivhaha, yeah
16:17:34Araq_or --gc:poorman
16:17:44niv--gc:sunday
16:20:01*rusua quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:21:55Araq_--gc:insane
16:22:30niv--gc:placebo
16:25:28Motannewbie question, can't seem to figure out how to get the return value to honor the type without casting http://pastebin.com/dtjzV5NV
16:26:33nivodd O.o
16:27:50nivTry parens around the ().Neighbours() call chain? Other than that, no idea
16:29:30def-Motan: i've seen this before, happens sometimes, should be reported on github as a bug
16:29:41def-Motan: you can use an object instead of a tuple and it should work
16:29:48Motanok, cool
16:36:22ParashuramaAraq_: can you see https://github.com/nim-lang/Nim/issues/4117 about JSON locale
16:36:30Motanhaving trouble finding the issue on github, do you want me to report the issue? or you reasonably certain it's already there?
16:36:47nivuhm, isn't json always utf-8 by spec?
16:37:16nivoh, yeah. my bad! of course that looks like a bug
16:37:46Parashuramayup a big that tripped me up for a good half hour
16:38:23Parashuramai couldn't figure out why my texcoords were 0.0 and 1.0
16:41:45nivi can imagine that must have been very frustrating
16:42:13Motanbtw, creating a proc prototype and moving the neighbors call down it fixed the issue: http://pastebin.com/nxkY4wgb
16:42:40def-Motan: if it's not reported, would be nice if you could do so
16:42:59Motansounds good
16:48:27Motanreported here https://github.com/nim-lang/Nim/issues/4118
17:12:42cheatfate_Araq_, do i need to fill an issue on this compiler bug?
17:12:44cheatfate_https://gist.github.com/cheatfate/620616e092be9c4a6fa24a423f00a124
17:14:50cheatfate_this is debug version of compiler, release version just exiting with SIGSEGV
17:16:45Araq_cheatfate_: yup, that's a new one.
17:16:57Araq_Motan: same for you, unknown bug. yummy.
17:17:51cheatfate_Araq_, i know that source i've used is wrong, but you can use it to reproduce error
17:18:00Motani'd try to fix it, but alas my nim is not good enough yet
17:18:01Araq_Parashurama: that shouldn't be a problem, we use a patched version of strtod or whatever. I wonder why this still is a problem.
17:21:56Araq_see lib/system/sysstr.nim nimParseBiggestFloat
17:24:04Araq_and nimFloatToStr
17:34:51*ozra_ joined #nim
17:37:01*ozra_ left #nim (#nim)
17:37:47*yglukhov joined #nim
17:43:25ParashuramaAraq_: I had actually already found tah
17:43:51Parashuramathat function but i wonder why we don't implement ourselfves strtod in pure nim?
17:44:19Parashuramait is complex, but not *that* complex.
17:48:14Parashuramaor I might be wrong. it seems some implementation uses GMP for corner cases, huge or very small floats
17:54:01*yglukhov quit (Remote host closed the connection)
18:06:02*yglukhov joined #nim
18:10:32*yglukhov quit (Ping timeout: 244 seconds)
18:22:32*yglukhov joined #nim
18:39:42*jonasac joined #nim
18:40:11*jonasac quit (Client Quit)
18:49:21*Parashurama quit (Quit: ChatZilla 0.9.92 [Firefox 45.0.1/20160325004906])
18:52:59*brson joined #nim
18:54:31*Demos_ joined #nim
18:57:17*Demos quit (Ping timeout: 250 seconds)
19:07:18*gokr joined #nim
19:08:26*BitPuffin quit (Read error: Connection reset by peer)
19:31:39*desophos joined #nim
19:37:20*rok quit (Ping timeout: 244 seconds)
19:37:35*rok joined #nim
19:42:20*Jesin quit (Quit: Leaving)
19:42:26*brson quit (Ping timeout: 268 seconds)
19:44:11*Jesin joined #nim
19:48:46*izi joined #nim
19:56:42*desophos_ joined #nim
19:56:59dom96Really tempted to get some Nim magnets https://www.stickermule.com/p/d466c59d
19:57:38*desophos quit (Disconnected by services)
19:57:40*desophos_ is now known as desophos
19:58:32*mahlon quit (Ping timeout: 260 seconds)
20:08:20*Ven joined #nim
20:15:38*yglukhov quit (Remote host closed the connection)
20:19:05*brson joined #nim
20:20:57*yglukhov joined #nim
20:21:22*castlelore quit (Quit: WeeChat 1.4)
20:28:33*mahlon joined #nim
20:28:37*gunn joined #nim
20:31:16*gunn_ quit (Ping timeout: 252 seconds)
20:35:00*novavis joined #nim
20:50:56*Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:55:25*brson_ joined #nim
20:56:04*brson_ quit (Client Quit)
20:56:15*novavis quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
20:56:23*brson_ joined #nim
20:56:27*novavis joined #nim
20:57:22*rok quit (Ping timeout: 250 seconds)
20:57:28*yglukhov quit (Remote host closed the connection)
20:58:09*brson quit (Ping timeout: 246 seconds)
21:01:31*yglukhov joined #nim
21:01:47*novavis quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
21:02:35*novavis joined #nim
21:02:48*novavis quit (Client Quit)
21:06:30*novavis joined #nim
21:08:39novavisHi, I am installing nim. Before, I have to install minGW-W64. The problem is that I don't know wich threads should I select for installation: posix or win32?
21:09:11Araq_novavis: the Nim installer comes with a mingw that's usable and doesn't make you make this decision
21:09:39Araq_but you should select win32 if you don't like the mingw the Nim installer provides.
21:10:33novavisThanks, I didn't know it
21:14:06*Demon_Fox joined #nim
21:24:20*Trustable quit (Quit: Leaving)
21:26:57*yglukhov quit (Remote host closed the connection)
21:27:39*yglukhov joined #nim
21:32:02*yglukhov quit (Ping timeout: 250 seconds)
21:52:06*yglukhov joined #nim
21:55:42*castlelore joined #nim
21:56:02*Varriount quit (Read error: Connection reset by peer)
21:56:15*yglukhov quit (Ping timeout: 246 seconds)
21:56:34*Varriount joined #nim
22:18:32*izi quit (Quit: Leaving)
22:28:10*yglukhov joined #nim
22:28:57*brson_ quit (Quit: leaving)
22:29:15*brson joined #nim
22:33:15*yglukhov quit (Ping timeout: 268 seconds)
22:52:36*yglukhov joined #nim
22:57:24*yglukhov quit (Ping timeout: 260 seconds)
23:17:20*castlelore quit (Quit: WeeChat 1.4)
23:17:37*castlelore joined #nim
23:28:43*yglukhov joined #nim
23:33:53*yglukhov quit (Ping timeout: 276 seconds)
23:39:20*pregressive quit (Remote host closed the connection)
23:39:58*pregressive joined #nim
23:45:25*pregressive quit (Ping timeout: 276 seconds)
23:53:08*yglukhov joined #nim
23:57:56*yglukhov quit (Ping timeout: 276 seconds)
23:58:04*ephja quit (Ping timeout: 260 seconds)