<< 17-03-2015 >>
00:03:11*bsoist joined #nim
00:03:48*bsoist left #nim ("Leaving")
00:05:43a5i#Debian
00:06:24Araqa5i: what's the point?
00:07:06a5iAraq, I sometimes, as a shortcut, use any available irc channel and input a channel name to go to it
00:07:11a5isince im using irccloud
00:07:13a5imy bad :/
00:07:23EXetoCprefer /join #channel
00:07:33Araqah, and I thought you're a spammer :-)
00:09:22Araqgood night
00:13:22fowlis there a symbol like __LINE__?
00:15:08EXetoCfowl: "proc instantiationInfo*(index = -1, fullPaths = false): tuple[filename: string, line: int] {. magic: "InstantiationInfo", noSideEffect.}"?
00:17:06*Matthias247 quit (Read error: Connection reset by peer)
00:17:14*jholland quit (Quit: Connection closed for inactivity)
00:31:37*davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
00:37:50*fizzbooze quit (Ping timeout: 256 seconds)
00:39:56*reem quit (Remote host closed the connection)
00:42:38*reem joined #nim
00:45:51*rzzz quit (Quit: leaving)
00:47:33*reem quit (Remote host closed the connection)
00:49:41*rzzz joined #nim
00:54:09*reem joined #nim
00:54:47*rzzz quit (Quit: Leaving.)
00:56:11*reem quit (Remote host closed the connection)
00:59:15*reem joined #nim
01:03:34*reem quit (Remote host closed the connection)
01:05:02*reem joined #nim
01:08:40*saml_ joined #nim
01:15:00*milosn quit (Read error: Connection reset by peer)
01:20:19*milosn joined #nim
01:29:42*brson quit (Quit: leaving)
01:44:14*Senketsu joined #nim
01:47:42*davidhq joined #nim
02:12:52*darkf joined #nim
02:17:05*brson joined #nim
02:21:26*davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
02:24:22*davidhq joined #nim
02:30:06*davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
02:36:00*reem quit (Remote host closed the connection)
02:37:38*reem joined #nim
02:40:57*chemist69 joined #nim
02:43:39*elbow_jason joined #nim
02:43:52*chemist69_ quit (Ping timeout: 240 seconds)
02:50:18*fizzbooze joined #nim
02:53:05*mwbrown quit (Ping timeout: 250 seconds)
02:53:19*rzzz joined #nim
02:59:09*elbow_jason quit (Quit: Leaving)
03:08:13*johnsoft quit (Ping timeout: 264 seconds)
03:08:35*johnsoft joined #nim
03:42:27*MyMind quit (Read error: Connection reset by peer)
03:42:42*Pisuke joined #nim
03:45:39*filwit quit (Quit: Leaving)
03:54:04*gsingh93 quit (Quit: WeeChat 1.1.1)
03:55:01*gsingh93 joined #nim
04:03:17*saml_ quit (Ping timeout: 250 seconds)
04:17:09*fizzbooze quit (Read error: Connection reset by peer)
04:21:57*Senketsu quit (Remote host closed the connection)
04:23:49*brson quit (Ping timeout: 264 seconds)
04:42:25*reem quit (Remote host closed the connection)
04:44:50*ChrisMAN quit (Ping timeout: 244 seconds)
04:46:12gmpreussner|workforum is getting spammed again
04:49:48*reem joined #nim
05:03:18*reem quit (Remote host closed the connection)
05:03:51*reem joined #nim
05:19:00*a5i quit (Quit: Connection closed for inactivity)
05:57:31*rzzz quit (Quit: Leaving.)
06:05:34*BlaXpirit joined #nim
06:10:09*Demos quit (Read error: Connection reset by peer)
06:15:14*Senketsu joined #nim
06:25:30*bjz joined #nim
06:45:49*Senketsu quit (Quit: Leaving)
06:51:04*wb quit (Ping timeout: 245 seconds)
07:07:02*xificurC joined #nim
07:08:32*k1i joined #nim
07:09:49k1iwhen working with nim C FFI, do I have to redeclare ALL types/identifiers, or can I somehow import these from C without a nim implementation?
07:11:28*reem quit (Remote host closed the connection)
07:14:52*bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
07:20:32*reem joined #nim
07:22:33*Pisuke quit (Read error: Connection reset by peer)
07:31:05*bjz joined #nim
07:36:38*MyMind joined #nim
07:37:01*bjz quit (Ping timeout: 264 seconds)
07:39:35*gsingh93 quit (Ping timeout: 246 seconds)
07:45:13gokrk1i: c2nim generates the nim code for you
07:46:03k1igokr: trying to wrap OSX system libs; didnt work - they use the ',' operator
07:46:09k1iamong other problems
07:46:33gokrI wrote an article shedding some light I guess: http://goran.krampe.se/2014/10/16/nim-wrapping-c/
07:46:39gokrDo you use c2nim or?
07:47:18k1ii tried to use c2nim and it didn't work
07:47:34gokrI think c2nim should be used with devel branch.
07:47:58k1inim devel branch?
07:48:00gokrSince Araq is improving it heavily these days since we use it at work for wrapping a big game engine.
07:48:21gokrYeah, when you do the bootstrap procedure - you use "-b devel" on both the git clone commands.
07:48:28k1iyeah i am running against the devel branch
07:48:31k1ic2nim wont run against 10.2
07:48:39gokrRight
07:48:44gokrNot surprising.
07:48:58ekarlsohttps://bpaste.net/show/9b919065a4b5 < anyone seen that before ?
07:49:11k1ithe problem is, running it against my OS X CoreServices header crashes
07:50:09gokrOk, if you got any info more than "crashes" Araq should be able to help.
07:50:24ekarlsogokr: u know ? ^
07:51:27k1igokr: correct usage should just be "c2nim path/to/header.h", correct?
07:52:54gokrk1i: Well, basically but you should check my article. Perhaps you need some extra option, I don't recall.
07:53:23gokrekarlso: No, dunno.
07:53:58ekarlso-,,- gokr :)
07:54:03ekarlsoI thought u where the nim expert : )
07:54:08gokrNo,no...
07:54:19gokrI'm a n00b
08:02:43*bjz joined #nim
08:20:24*BlaXpirit quit (Quit: Quit Konversation)
08:20:49*banister quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:25:18*BlaXpirit joined #nim
08:26:19*reem quit (Remote host closed the connection)
08:27:34*reem joined #nim
08:29:22*tmku quit (Ping timeout: 265 seconds)
08:32:13*reem quit (Ping timeout: 255 seconds)
08:38:33Araqk1i: correct usage should just be "c2nim path/to/header.h", correct? wrong.
08:39:03Araqunless you copied and modified the header file there is no way in hell to make this work
08:39:30Araqsystem header files use every single dirty trick and undocumented pragma that C offers
08:39:43Araqyou need to help c2nim
08:39:51ekarlsoAraq: u got a clue on my async error ? ^
08:40:32Araqekarlso: no. and I told you to use cgi anyway. ;-)
08:40:56ekarlsoAraq: pffft
08:40:57Araqyou can either listen to me or else live in a world of pain.
08:41:01ekarlsohahaha :p
08:41:04ekarlsoyou're evil!
08:41:19ekarlsothink i'll just write it using python instead :p
08:42:07*zahary quit (Read error: Connection reset by peer)
08:42:28*zahary joined #nim
08:43:08*gokr left #nim (#nim)
08:44:17Araqso ... how can I restore a recently closed tab in chrome?
08:44:51Araqthese shitty new UIs without any buttons. thank you apple.
08:45:51ekarlsoAraq: :D
08:45:54ekarlsowho needs buttons : P
08:45:57ekarlsoflat design ftw
08:46:32Araqnever mind, I found it -.-
09:33:01*BlaXpirit-UA joined #nim
09:34:49*BlaXpirit quit (Ping timeout: 245 seconds)
09:35:34*Aszarsha joined #nim
09:55:38*zahary quit (Read error: Connection reset by peer)
09:56:07*zahary joined #nim
09:56:29*zahary quit (Client Quit)
09:57:26*zahary joined #nim
10:06:36*chemist69 quit (Ping timeout: 246 seconds)
10:12:42*allan0_ quit (Quit: WeeChat 1.1.1)
10:21:52qwr!ilm
10:26:19*rkj-b joined #nim
10:27:40*a5i joined #nim
10:33:00*filwit joined #nim
10:38:32filwitdom96, Araq: when you have time, please review my PR: https://github.com/nim-lang/nimforum/pull/51
10:43:46filwithmm... i think i screwed that up and '.nimble' files where added accidentally..
10:44:12*Aszarsha quit (Ping timeout: 272 seconds)
10:46:31*Aszarsha joined #nim
10:51:12*allan0 joined #nim
10:51:43filwitfixed
10:53:37*gokr joined #nim
11:12:22*Senketsu joined #nim
11:44:37EXetoC"xfer: incoming file from HotBuns (0.0.0.0, irc.fn), name: STARTKEYLOGGER, 0 bytes (protocol: dcc)" oh really
11:45:59*banister joined #nim
11:49:01EXetoCit's some kind of exploit
12:01:41bw_its an oold exploit for some faulty AV software
12:11:19*wb joined #nim
12:12:11Araqhey filwit
12:12:22AraqI don't really like black on grey (forum)
12:14:31*rkj-b quit (Quit: ChatZilla 0.9.91.1 [Firefox 36.0.1/20150305021524])
12:18:34*Aszarsha quit (Ping timeout: 245 seconds)
12:23:10filwitAraq: That wasn't my doing. The black-on-grey was added before as a way to indicate visited links
12:23:38filwitAraq: i have to go for awhile now, but i'll be back later today to talk about it.
12:23:45filwitlater
12:23:47*filwit quit (Quit: Leaving)
12:25:26*davidhq joined #nim
12:25:37novistthis confirms my theory that good programmers are usually half-bind when it comes to making visual stuff
12:31:18EXetoCyou've gathered enough samples now? :p
12:34:30*banister quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:39:40*saml_ joined #nim
13:01:29*mpthrapp_ joined #nim
13:01:35*infrashortfoo joined #nim
13:03:35*banister joined #nim
13:03:39*banister quit (Max SendQ exceeded)
13:04:36*banister joined #nim
13:04:58*rzzz joined #nim
13:11:19*banister quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:14:50*mpthrapp quit (Quit: Konversation terminated!)
13:19:22*mpthrapp_ is now known as mpthrapp
13:23:59*TEttinger quit (Ping timeout: 246 seconds)
13:31:27*banister joined #nim
13:31:38*banister is now known as banisterfiend
13:39:11*saml_ quit (Ping timeout: 250 seconds)
13:49:10*jfchevrette joined #nim
14:01:01*tmku joined #nim
14:03:12*milosn quit (Ping timeout: 245 seconds)
14:04:09*Senketsu quit (Quit: Leaving)
14:06:04*Senketsu joined #nim
14:15:09*bcinman_ joined #nim
14:15:17*bcinman quit (Read error: Connection reset by peer)
14:26:27*darkf quit (Quit: Leaving)
14:35:09*Aszarsha joined #nim
14:37:41*drewsrem joined #nim
14:44:41k1iAraq: will c2nim wrap all references to dependencies present in a file? sorry if I am not understanding - having never used it before I don't know what the intended output is. (trying to wrap CoreFoundation on OSX)
14:45:24drewsremIt seems that there is currently no way to fseek from the current position with only 1 syscall, there is a proc that wraps fseek named setFilePos but it doesn't expose the "origin" Parameter and instead always calls it with 0, which is from the beginning of the file. - I suspect calling fseek with SEEK_CUR is performing better then getting the current position with getFilePos and then adding the offset by yourself. - Is this
14:45:24drewsremdeliberate?
14:49:27k1iah "c2nim is meant to translate fragments of C code and thus does not follow
14:49:33k1iinclude files"
14:51:08*ChrisMAN joined #nim
14:55:28EXetoCk1i: there's tools/cmerge.nim though. I don't know if it's being advertised anywhere
14:56:08EXetoCI don't know if any packages include it. I might include it in the arch package
14:58:06k1iEXetoC: it follows includes? - these OSX frameworks are really spread apart, use all their own primitive data types, etc (i've really only worked with linux)
15:01:01EXetoCk1i: http://goran.krampe.se/2014/10/16/nim-wrapping-c/
15:01:08EXetoCmaybe it requires some manual work then
15:01:34k1iyeah i had decent luck doing it manually - read that post last night
15:01:39k1iit was just really tedious/hard to be correct
15:01:40EXetoC"for infile in walkfiles(dir / "*.c"):" ... and then it follows includes
15:01:46EXetoCok
15:02:28EXetoCit takes some time to learn indeed
15:03:03k1iyeah - and this is probably a bad starting point :D
15:03:21EXetoCand then I end up doing things that require advanced text editing
15:06:34*Senketsu quit (Quit: Leaving)
15:08:02EXetoCyou reminded me of all the wrapping helpers I've been wanting to write
15:09:15k1iyeah - would be good :D
15:10:12k1i"typedef const struct CF_BRIDGED_TYPE(NSArray) __CFArray * CFArrayRef;
15:10:17k1ic2nim is getting tripped up on that line
15:10:32*a5i quit ()
15:10:57k1inone of the external defines are being pulled in
15:12:11gmpreussner|worki usually end up removing any macros in function declarations
15:12:21gmpreussner|workand types as well
15:12:43k1igood idea
15:12:49gmpreussner|workmost of the time they just inject some C++ compiler specific switches
15:12:53k1iyep
15:12:54k1ithere's a lot of that
15:12:59EXetoCgmpreussner|work: for dll exporting and so on? there's a better way
15:13:17*pregressive joined #nim
15:13:46gmpreussner|workEXetoC, yep
15:13:47EXetoC#ifdef c2nim ... #def MACRO ... #endif
15:14:31gmpreussner|workah cool, didn't know that
15:18:28drewsremAny pointers how I'd import a constant in a C header file?
15:18:44k1ifeels like this is the only c2nim output I get on success: "Error: unhandled exception: invalid format string [ValueError]"
15:19:17EXetoCdrewsrem: c2nim will pull in constants
15:19:22k1iexpanding the header w/ clang before running cn2im made it work quite nicely :D
15:19:31EXetoCit's best not to use the header pragma, so that approach is preferable
15:19:40drewsremEXetoC, I see, thanks
15:19:58k1igreat looking wrapper
15:20:09EXetoCk1i: I've been meaning to expand code, and it probably helps a lot
15:20:15k1iother than all of the system stdlib stuff in there
15:20:15k1iyeah
15:20:36k1ithis wrapper would almost be 100% usable out of the box
15:20:45k1iif the sys stuff weren't in there from clang expansion
15:24:09k1ionly other gotcha is that it feels like __attribute__ hints aren't being handled nicely by c2nim
15:27:44EXetoCjust keep merging things I guess, and take regular breaks in order to keep your sanity intact
15:27:58EXetoCk1i: what are the arguments?
15:28:45EXetoCI don't think it handles any kind of extensions
15:28:48k1iin /usr/include/math.h - inline __attribute__ ((__always_inline__)) int __inline_isfinitef(float);
15:28:51k1iyeah
15:28:52k1ithere's a lot of that
15:29:05k1imostly in the system files
15:33:15EXetoCI think it can be safely ignored. it might be possible to #def some of those things
15:33:46EXetoCit's best to have everything available in the case where you need to search/replace
15:35:31EXetoCthere was someone who tried to automate everything including search/replace, but if the lib or any of its dependencies don't change very often then it might not save any time
15:40:53*rzzz quit (Quit: Leaving.)
15:40:53*jholland joined #nim
15:41:52k1iEXetoC: yeah i am getting tripped up on every extension at the moment
15:44:03k1imostly just deprecation-related __attributes__
15:48:12Araqk1i: #def __attribute__(x)
15:49:04EXetoCok so it does accept arguments too
15:49:54Araqc2nim is not git, it's a complex tool with a manual that you need to read properly.
16:00:20*brson joined #nim
16:06:28Araqfowl: finger exercise for you: http://forum.nim-lang.org/t/1044
16:12:10k1ii am a clang noob and read the docs: is there a good way to tell the preprocessor to exclude builtins from its output (just assume they're always there)?
16:12:28Araqk1i: don't preprocess before c2nim
16:12:50*pregressive quit (Remote host closed the connection)
16:13:01Araqmerge the include files with whatever tool fits
16:13:14Araqand then tell c2nim via #def how to transform
16:14:01k1iyeah i am pretty close to having a working wrapper (did it for one of the smaller dependencies of CoreFoundation), just need to have an automated way to merge/remove cruft
16:15:05k1irecommended tool to do include merges?
16:21:04Araqtools/cmerge.nim ?
16:21:24k1iperfect, thank you
16:22:12Araqand yeah
16:22:29Araqc2nim should get this feature instead of reyling on some other tool
16:26:41*pregressive joined #nim
16:41:08*gsingh93 joined #nim
16:48:32*rzzz joined #nim
16:56:02*pregressive quit (Ping timeout: 252 seconds)
16:56:20*pregressive joined #nim
17:21:17*Aszarsha quit (Ping timeout: 246 seconds)
17:21:51*infrashortfoo quit ()
17:56:37*Matthias247 joined #nim
18:00:12*milosn joined #nim
18:02:23*Woflox joined #nim
18:07:32*filwit joined #nim
18:09:09filwitAraq, dom96: around to talk now.
18:10:34filwitAraq: might have misunderstood what you meant by "black on grey" this morning. I assumed you where referring to how visited links are black now.
18:20:26*dewdrop quit (Quit: Quit)
18:24:28*irrequietus joined #nim
18:31:30*UberLambda joined #nim
18:32:17*dewdrop joined #nim
18:38:49*wb quit (Ping timeout: 255 seconds)
18:42:53*drewsrem quit (Quit: Leaving)
18:45:38*wb joined #nim
19:35:35Araqfilwit: it's fine, turned out every link was already visited
19:35:41Araqso it was all black for me ;-)
19:40:40filwitah, i see
19:41:17filwitAraq: i just hosed the GC refcounts using parallel + auto-deference (experimental)
19:41:41filwitgoing to report unless this is a known issue
19:43:12*a5i joined #nim
19:44:19Araqno idea what you're talking about
19:44:21*banisterfiend quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:44:29AraqI fixed the bugs afaict
19:44:57filwitk, i'm just trying to fix up the code for an issue report now
19:45:43filwitwell here: https://gist.github.com/PhilipWitte/1ea2efa2e04096ba9005
19:48:46filwitbasically I sample the refcount of a list before running a parallel statement over it (which attempts to randomly mutate integer values), then do a refCount again and compare.. I'm only changing integer values, show technically the refCounts shouldn't be different (to my understanding) but they end up different
19:50:07filwitthis seems to work correctly (refCounts are the same) if i use 'ref object' instead of the experimental auto-deref
19:51:48WofloxHey all, wondering if anyone can help me. I'm having a problem trying to get audio working using the sdl2 wrapper
19:53:01WofloxI can get audio to play like in the example (with a callback), but when I do anything on the main thread after while it's playing it quickly crashes
19:53:30Wofloxwith Error: execution of an external program failed
19:53:38Wofloxand sometimes it gives me a SIGSEGV
19:54:16AraqWoflox: sounds more like a problem with your threading than with SDL
19:54:25Wofloxyes I think so
19:55:21Wofloxbut I'm not sure how to do it properly
19:55:38Wofloxsince the callback is coming from an external library
19:57:39Wofloxhere is a modified version of the sample that gives me the crash (I only added the for loop at the end): https://gist.github.com/Woflox/77b085e80fba408a460c
20:00:31*enquora joined #nim
20:04:04*jfchevrette quit (Quit: Textual IRC Client: www.textualapp.com)
20:05:59AraqWoflox: compile with --threads:on ?
20:06:01*UberLambda quit (Quit: Leaving the Matrix)
20:06:14Araqand perhaps stackTrace:off
20:07:39WofloxI tried with threads:on and it crashed as soon as it starts playing audio, instead of randomly later on... haven't tried stackTrace:off, I'll see what that does
20:08:19Araqalso you seem to use an old SDL wrapper
20:08:27Araqthat doesn't adhere to NEP-1
20:09:28WofloxI think only the example is outdated
20:09:40Wofloxactually with both those on it seems to work!
20:09:41def-indeed, gives off a few warnings
20:10:19def-Woflox: this doesn't crash for me at all, what do I need to do?
20:10:33def-(at least with --threads:on)
20:11:18Wofloxhuh. With threads:on it was crashing for me right after printing out the obtained spec
20:11:31def-without --threads:on i have random segfaults
20:11:42Wofloxyes that's what I see too
20:11:45def-you could try removing nimcache. what system are you on?
20:11:50Wofloxwith both threads:on and stacktrace off it works fine
20:12:48Wofloxwindows 8.1 64bit, I think the compiler is 32bit
20:13:19def-maybe something with stacktraces on windows, not necessary on linux
20:16:05Wofloxyeah, seems pretty weird. But thanks for your help guys!
20:16:59*matkuki joined #nim
20:17:47AraqWoflox: you use Nim 0.10.2 ?
20:17:57Wofloxyes
20:18:24Araqah yeah, thread local storage emulaton is active and wrong in 0.10.2
20:18:29Araqon windows
20:18:51Araqyou can also try to disable thread local storage emulation instead
20:21:07*bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
20:21:45Wofloxwith tlsEmulation:off but stacktrace/threads on it seems to still crash but it's delayed again
20:24:06Araqfilwit: weird, will look into it.
20:37:28*wb quit (Ping timeout: 256 seconds)
20:39:54*reem joined #nim
20:42:45*mpthrapp_ joined #nim
20:44:17*mpthrapp quit (Ping timeout: 244 seconds)
20:49:05*foodoo joined #nim
21:00:03*wb joined #nim
21:00:07*reem quit (Remote host closed the connection)
21:00:58*reem joined #nim
21:05:33*bcinman joined #nim
21:05:52*bcinman_ quit (Ping timeout: 240 seconds)
21:07:17*mpthrapp_ quit (Remote host closed the connection)
21:14:39foodoois there a way to tell readtable() that my columns are seperated by tab?
21:14:55foodoooh, wrong channel. sorry
21:21:11Araqdom96: it's up to you to apply def-'s async speedups
21:24:04*shalabh joined #nim
21:24:09*foodoo quit (Quit: leaving)
21:30:26Araqdef-: so ... how fast is it now? I see you made additional optimizations
21:30:54def-Araq: it's mostly getting slower by using more futures
21:31:57Araqhe he he, not surprising to me
21:34:30def-we're down to 37k requests/second from 52k again
21:34:35def-with the last few commits
21:35:00def-the string copying changes pushed it up to ~54k, nothing big in this case
21:35:49def-I guess I should look into multithreading instead at this point, but I'm not sure how that would work
21:37:00*Senketsu joined #nim
21:37:43shalabhdef-:this is a web app, right?
21:38:06def-shalabh: I'm trying to speed up Nim's asynchronous HTTP server: https://github.com/def-/nim-http-speedup
21:38:33shalabhdef-:you just need to share the socket across multiple threads
21:38:38shalabhnothing else needs to be shared
21:38:50shalabheach thread will have it's own even loop
21:38:50def-i know, that kind of seems to work and gets nice speedups
21:39:08def-but I've never done real multithreading in nim
21:39:33def-I'm wondering what happens if you have some datastructure allocated in one thread, and want to use it from others as well. Would that just be forbidden?
21:39:42shalabhah, well if you don't share anything (except the one socket) - it's unlikely you'll run into any issues
21:39:43Araqdef-: I cannot follow. why are we back at 37K requests per second?
21:39:48def-Araq: right
21:40:17shalabhdef-:right, if you need that you need thread safe data structures
21:40:28shalabhwhy are futures so expensive?
21:40:49def-because we allocate so many and they're on the heap, garbage collected
21:41:12def-Araq: at least with boehm, markandsweep is doing a bit better than boehm now with ~43k
21:41:19shalabhsounds like you need a custom allocator for these.
21:41:37shalabhwhat's the structure of a future?
21:41:49def-well, so far I just got rid of them altogether, but this isn't nice style it seems
21:42:07Araqno getting rid of them is the only way to do it
21:42:19Araqit's not just that they allocate
21:42:31Araqthey also transform the stack frame into a heap frame
21:42:35shalabhdoes getting rid of them make the code look uglier?
21:43:24def-It requires more templates instead of procs
21:44:58shalabhAraq:what do you mean transform stack frame to heap frame? they create closures?
21:45:12Araqshalabh: exactly
21:45:26def-shalabh: https://github.com/Araq/Nim/blob/devel/lib/pure/asyncdispatch.nim#L135-L146
21:50:15shalabhAraq:nim's gc has optimization for values on stack only - is that correct?
21:50:48shalabhthat would mean it's not just the copying of values onto the heap, it's also more gc overhead.
21:52:06*davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
21:52:48Matthias247def-: that's much more lightweight than .NET's Task<T>. Shouldn't cause allocation problems
21:52:51flaviushalabh: Things on the stack do not require garbage collection by definition.
21:53:20*davidhq joined #nim
21:53:50shalabhflaviu: what if you have a ref on the stack?
21:53:54*davidhq quit (Client Quit)
21:54:16shalabhflaviu:you can't deallocate when the stack frame goes away because there may be other refs to the same object
21:54:32*bjz joined #nim
21:54:36AraqMatthias247: it's not the size of the object, but the number of how often it's allocated
21:54:39shalabhflaviu:i'm wondering if heap values referenced from the stack *only* have some optimization in nim
21:54:50shalabhflaviu:i suppose I didn't frame it correctly
21:54:51flaviushalabh: Ah, I see.
21:55:07Araqshalabh: no, we don't have any form of escape analysis yet
21:55:29Matthias247Araq: yes, but I can allocate several 100k of Task<T>/s in a single .NET thread and also complete them and attach continuations
21:55:32Araqwhich wouldn't help anyway since everything *can* escape for async code
21:55:57flaviuMatthias247: Generational GC, I'd guess.
21:56:00*enquora quit (Quit: enquora)
21:56:06Matthias247Araq: and these are even synchronized - which nims futures are not
21:56:14shalabhAraq:I see. I thought I read something about deferred reference counting but can't find that doc. It seemed there was some benefit for short lived objects.
21:56:25Matthias247flaviu: yes, that might be a thing
21:56:38Araqshalabh: oh yes but that's a totally different optimization :-)
21:57:02Araqwe do deferred RC, yes
21:58:00shalabhbased on what Matthias247 said, maybe the futures implementation in nim can be optimized
21:58:10shalabhor the closure implementation..
21:58:34Matthias247I guess it's more about the IO implementation
21:58:54*bjz quit (Ping timeout: 252 seconds)
21:58:56*EXetoC quit (Read error: No route to host)
21:59:04Araqyeah sure. only costs months of development time. so no thanks. ;-)
21:59:37Araqhacking around this issue is by far the cheaper solution
22:00:17shalabhsure, if you have a specific short term requirement
22:00:24shalabheven 10k/s is pretty good for most applications
22:00:51shalabhI mean, most of the work might be in the actual logic of whatever the web request will do.
22:00:58shalabhdef-:have you tried profiling?
22:01:07Araqshalabh: the requirement is to do better in benchmarks
22:01:11Matthias247lots of webservers are running slow python, php and ruby ;)
22:01:45shalabhAraq:any specific published benchmark?
22:01:56Araqin the real world, you have things like databases, CPU sensitive workloads, or you need to use processes for other reasons anyway
22:02:29Matthias247netty uses pools for byte buffers and recycles the buffers after requests. That eases the pressure on the GC a lot
22:02:36*EXetoC joined #nim
22:02:51shalabhhonestly if you beat golang, it's already compelling.
22:02:54def-shalabh: yes
22:03:08shalabhwriting if also a balance of ease of coding vs performance
22:03:32shalabhif giving up futures means code is harder to write.. not necessarily the best
22:03:37gokrI still like good ole threaded servers :)
22:03:52def-shalabh: profiling revealed the usual: string allocations/copies and ref allocations (futures in this case)
22:03:56gokrDoesn't force every little thing to do the async dance.
22:04:17shalabhdef-:looked into custom allocators? does nim support this?
22:04:34shalabha bump allocator will be really cheap. also take that pressure off the g
22:04:36shalabh*gc
22:05:05shalabhgokr:coroutines are nicer :)
22:05:19shalabhgokr:sync style code but lighter weight than threads
22:05:30shalabhgokr:you dont do any async dance either.
22:05:32Araqshalabh: yep, you can do all these things but it's hard without changing the API
22:05:32def-shalabh: i wouldn't know how to do it in nim
22:05:38shalabhi don't like callbacks
22:05:47flaviushalabh: How would you determine when to free the allocated memory?
22:06:29shalabhflaviu:good question, dont know in this case, but in many cases it may be possible to know exactly when it's not needed anymore.
22:06:40Araqdef-: use an array of ptr Future[T] and ensure via GC_ref/GC_unref it's not collected
22:07:10Araqof course doing this in practice might be almost impossible
22:08:07gokrshalabh: Note that Nim has a threadpool implementation, so spawn etc is a bit "lighter"
22:08:07Araqand it's futile since it's much easier to hack the allocator to do bump pointer allocations per thread
22:09:06gokrshalabh: A little experiment I wrote a while back: http://goran.krampe.se/2014/10/25/nim-socketserver/
22:11:02*matkuki quit (Quit: ChatZilla 0.9.91.1 [Firefox 35.0.1/20150122214805])
22:12:44def-gokr: doesn't compile right now, does it? Error: expression 'handle(client)' has no type (or is ambiguous)
22:13:06gokrCould be, haven't played with it in a long time
22:13:22gokrLike since I wrote it :)
22:14:02*davidhq joined #nim
22:14:56shalabhgokr:thanks
22:15:36Araqdef-: wtf? it should compile afaict
22:15:57Araqneed to add that to the testsuite
22:15:58EXetoCthere are bugs still? :/
22:16:16def-Araq: looks fine to me too, no idea
22:16:54AraqEXetoC: no, there are *more* bugs since that's the nature of developing software at a rapid rate
22:16:59dom96I think that keeping a pool of futures may be worthwhile.
22:17:16Araqdom96: I think it's pointless.
22:17:20dom96Depends how much their allocation really affects the performance.
22:17:45dom96That said, we should stop worrying about performance and worry about stability more.
22:17:49shalabhbtw, better http feature support (and http 2.0) may be more compelling features at this point
22:18:04shalabhthat's what actual users really want, IMO
22:18:16dom96Stability is very bad at the minute.
22:18:42flaviushalabh: I think it's best if nginx is in front of the server for that
22:19:07dom96And it seems that there are leaks hiding in the code, which is why I don't want to accept exported async proc which take a 'ptr string' as a parameter.
22:19:47dom96As that will probably create even more.
22:21:43AraqI still think we should compile Jester to a low level state machine
22:22:05EXetoCI know of course. I keep up with the stats
22:22:06Araqand get rid of the intermediate layers completely
22:22:44Araqthis way this thing is setup is essentially a way to maximize the work for us
22:23:13EXetoCfor what purpose?
22:23:22Araqone point of a DSL is that enables optimizations that are otherwise infeasable
22:23:58Araqand what do we do with the DSL?
22:24:20Araqwe transform it to our hard to optimize stdlib stuff
22:24:32Araqthat's simply not smart.
22:24:40dom96yeah, let's just make it generate ASM.
22:24:50EXetoCok. I've just looked at them as shortcuts
22:25:08dom96Why have libraries when we can get every user to write hand optimised ASM generators.
22:25:46dom96Araq: Yes, it is work for us. But that's what we are doing, we are developing a programming language, a *general-purpose* programming language.
22:25:58EXetoCdom96: we're making people lazy :p
22:26:14dom96EXetoC: how?
22:26:42Araqdom96: there is not much *general purpose* here. it's being optimized for benchmarks.
22:26:57flaviuMaybe optimizing for benchmarks is a bad idea?
22:27:00EXetoCit was a joke
22:27:10flaviuWho cares if nim beats hand-optimized C?
22:28:32dom96nobody, but we should at least beat or match Go.
22:28:48EXetoCmost people do just fine with dynamic languages after all, and many simply want static typing, but if we have time to optimize the hell out of things then great
22:29:43EXetoCdom96: that seems like a fair goal
22:30:41flaviuyep, that sounds reasonable. Fix bugs first, then optimize though.
22:31:02EXetoCbut I'm not sure how much slower than C it tends to be
22:31:22Araqflaviu: meh that's what brought us in this situation in the first place though.
22:31:55EXetoCbut functionality first please
22:31:55Araqand the result is that it's quite slow and hard to optimize
22:32:07shalabhgolang has proper coroutines, but they don't copy the stack to heap and back.
22:32:33Araqshalabh: we're well aware of how Golang is implemented, thanks
22:33:04Araqhrm sorry that was too harsh
22:33:41shalabhnp
22:34:33*pregressive quit (Remote host closed the connection)
22:34:47shalabhstupid question - why does each await create a new callback? would it be possible to use exactly one closure for each function that can be suspended (sort of like closure iterators). each 'await' becomes an yield point.
22:36:07shalabhi understand i'm talking about major changes here, but curious if that's technically possible.
22:36:39dom96each 'await' is already a yield point
22:36:53*adu_ joined #nim
22:36:58dom96and each async proc creates just one Future
22:37:21shalabhok, i guess i'm just confused then
22:37:36shalabhi should probably look at it in more closely
22:40:08shalabhok, to phrase it differently, do closure iterators also end up copying a stack frame to a heap frame?
22:41:06*filwit quit (Quit: Leaving)
22:43:16*xificurC quit (Ping timeout: 252 seconds)
22:44:03Araqshalabh: no the frame is part of the closure but not copied over but directly constructed on the heap
22:44:21shalabhAraq:right - so why can't the same be done for these async procedures that can suspend?
22:44:52Araqasync procedures are mapped to closure iterators, so we do the same for them
22:45:05shalabhhmm ok.
22:45:26shalabhbut then what is the stack frame that gets copied to the heap?
22:45:49*fizzbooze joined #nim
22:45:55Araqwell that was just poorly phrased by me
22:47:05shalabhah ok. i think you said 'transform' but I understood that as copy
22:47:21*Trustable joined #nim
22:47:27shalabhso these start out as heap frames, that's fine.
22:47:48shalabhi have nothing to suggest then :)
22:49:34*brson quit (Quit: leaving)
22:51:31EXetoChe knows what he's doing in most cases :p
22:53:23*tstm joined #nim
22:53:57tstmSeems like a very nice language they've made.
22:54:23tstmFor fun, I just ported the benchmarksgame nbody simulation to nim
22:54:36tstmAnd compared the speed to the best C entry, http://benchmarksgame.alioth.debian.org/u32q/program.php?test=nbody&lang=gcc&id=4
22:54:52tstmhttp://tstm.info/kuvat/nbodytest.png
22:55:10tstmOn my mac, it beats the C implementation.
22:55:13def-tstm: https://github.com/def-/nim-benchmarksgame
22:55:30def-I'm collecting benchmarksgame programs in Nim if you want to contribute any
22:55:46shalabhtstm:that's fantastic
22:55:58tstmdef-: Heh, ok. I only wrote the nbody for now. =)
22:56:05def-flaviu: so much for beating hand-optimized C code!
22:57:48reactormonkSomeone got the link why unsigned is evil?
22:59:07def-reactormonk: I'm searching, it was some blog, but don't remember where
23:00:59tstmdef-: Mine is a touch faster, it seems. At least in my quick testing.
23:01:01tstmdef-: http://tstm.info/files/nbody.nim
23:01:13def-tstm: may I add it?
23:01:17tstmSure. =)
23:01:35flaviudef-: Major difference between optimizing a benchmark that you never have to look at again and optimizing an actual program with non-clearly-defined correctness criterea
23:01:37def-tstm: looks really compact and readable, nice work
23:02:10def-reactormonk: Was it this one?: http://www.eschertech.com/articles/items/art100407.html
23:02:24tstmOne thing I was wondering.. when iterating through arrays, isn't there a better way than 0..(array.len -1)
23:02:43def-tstm: for i in 0..bodies.high
23:02:56tstmAh, ok.
23:02:57Araqdef-: http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/
23:03:09def-tstm: for body in bodies: works as well
23:03:52tstmCool. That I didn't find in the intro docs, though..
23:03:55def-tstm: and if you need to assign to body "for body in bodies.mitems", also "for i, body" in bodies:" and "for i, body in bodies.mpairs"
23:05:26tstmI've never coded any nim before, so I just read the two tutorials which don't really go into such fancy things. =)
23:05:52Araqnever coded in nim before, beat hand optimized C.
23:06:01Araq:D
23:06:03def-also, when you have "px: float, py: float, pz: float" you can do "px, py, pz: float"
23:06:32tstmAh. I didn't realize you could use a shorthand there, too.
23:09:09def-tstm: if you have multiple types/let variables/... you can put them in a single block
23:14:20*girvo joined #nim
23:14:21tstmdef-: Thanks for the tips. I cleaned it up a little.
23:14:35tstmI'm starting to like this block syntax for declaring stuff.
23:14:35girvoHi all :3
23:15:24Araqhi girvo
23:15:32girvoI've lost my password for the nim forums, heh, would it be possible to get someone to reset it? (thats if we even can, I notice that password reset was added yesterday by dom?)
23:16:01EXetoCbeen there >.>
23:16:01Araqare you the guy that I made read several papers for me?
23:16:03EXetoCoh really?
23:16:11girvoYes I am :)
23:16:16Araqha!
23:16:44girvoI even started on some proof-of-concept stuff implementing some of the type system stuff in one of them, but life got in the way :(
23:17:19Araqwell I never got the TL;DR from you
23:17:20EXetoCpassword recovery where? has it not made it into production?
23:17:34flaviuAraq: Still got the list of papers? I'd like to read them.
23:17:35AraqEXetoC: dom96 can do it now.
23:17:52Araqflaviu: nope ...
23:18:27girvoAraq: I definitely wrote one up, let me see if it's in my email hold on
23:25:36tstmdef-: Porting to nim was fairly easy. Some time ago I did the same benchmark for swift, and it was considerably harder. And especially hard to run fast.
23:26:57EXetoCI couldn't help but mention Nim in #archlinux when people were discussing C++
23:27:19EXetoCdom96: can has new pw? exetoc2 takes too long to type
23:27:36def-tstm: nice to hear!
23:31:00tstmI'm not sure who's in charge of the nim tutorials though.. they really should mention that you ca iterate with for item in listItems
23:31:10tstmcan
23:31:28Araqtstm: the tutorials need a big update, yeah
23:31:30EXetoCthis guy claimed that C++ is almost as concise as python, which might be true in *some* cases
23:31:35def-It's on my todo list to try to write a new tutorial, but I'm not sure when I'll have time (and if I'm capable of that)
23:32:04Araqdef-: IMO you should simply add stuff to the existing one
23:32:09dom96EXetoC: girvo: send me the passwords you want and I can change it.
23:32:41*brson joined #nim
23:33:39EXetoC"mistakes are always repeated". how many mistakes have been repeated in Nim? Got any examples?
23:35:26AraqEXetoC: 'nil'? ;-)
23:36:28*irrequietus quit ()
23:37:15flaviuAlso, "grown, not designed"
23:42:49def-tstm: Added your program, also simplified it a bit more: https://github.com/def-/nim-benchmarksgame/commit/a301d6c0e48b919a2860863246f7cc472a1e0c38
23:44:04tstmLooks good. =)
23:44:20Araqflaviu: what?
23:44:41Araqyou think Nim has not been designed?
23:46:27tstmdef-: When compiling I get "Error: undeclared identifier: 'mpairs'"
23:46:42tstmShould I be running something less stable to compile it?-)
23:46:44def-tstm: oh right, that's not in 0.10.2, will be in the next release
23:46:56flaviuI get the feeling that the thought process throughout the design was "this seems cool, let's add it."
23:47:14def-tstm: yeah, the devel branch should work:
23:47:31flaviuWhen I think the correct processes would be to create a long spec with extensive specs, and create it without scope creep.
23:48:09flaviuAnd then a while for user testing, maybe finding some usability problems
23:49:17EXetoCflaviu: when was a document last added to nim-by-example?
23:49:32EXetoCnanoc doesn't work now for some reason, which is why I'm asking
23:51:00flaviuEXetoC: Don't worry about that not building, I don't. If something fails, I can fix it after the build bot tells me.
23:52:01*BlaXpirit-UA quit (Remote host closed the connection)
23:52:10EXetoCI've created a PR. better late than ever
23:52:24EXetoC*never
23:52:30Araqflaviu: there is no difference between a very detailed spec and an implementation. ;-)
23:52:37tstmdef-: I got it to compile, but the results are not right.
23:52:54def-tstm: oh, let me see
23:53:14EXetoCflaviu: I'll just introduce a section myself in a PR if it seems like a good idea
23:53:16flaviuAraq: Specs don't have bugs, and if you say "the implementation will not deviate from the spec", you won't get scope creep.
23:53:32*adu_ quit (Ping timeout: 256 seconds)
23:53:37Araqflaviu: on the contrary, specs have bugs all the time.
23:54:05*adu_ joined #nim
23:54:12*rzzz quit (Quit: Leaving.)
23:54:44flaviuThat's a different sort of error. It's not "XYZ causes a segfault if used with ABC", it's "XYZ is unclear"
23:55:26Araqso you're talking about a spec you cannot run
23:55:38Araqwell yes, programs you cannot run, cannot crash either.