<< 13-05-2016 >>
00:03:47*yglukhov joined #nim
00:08:00*yglukhov quit (Ping timeout: 246 seconds)
00:12:28*Jesin quit (Quit: Leaving)
00:28:18*PMunch quit (Ping timeout: 250 seconds)
00:29:02*brson quit (Ping timeout: 276 seconds)
00:29:29*brson joined #nim
00:38:33*Roin quit (Ping timeout: 240 seconds)
00:39:21*Roin joined #nim
00:53:49*libman quit (Remote host closed the connection)
01:13:24*brson quit (Ping timeout: 244 seconds)
01:17:16*enthus1ast quit (Read error: Connection reset by peer)
01:19:42*brson joined #nim
01:25:32*yglukhov joined #nim
01:27:03*brson quit (Ping timeout: 240 seconds)
01:31:54*yglukhov quit (Ping timeout: 260 seconds)
02:01:20*brson joined #nim
02:30:35*brson quit (Ping timeout: 276 seconds)
02:31:51*brson joined #nim
02:53:47*brson quit (Ping timeout: 260 seconds)
03:06:08*brson joined #nim
03:29:05*yglukhov joined #nim
03:33:27*yglukhov quit (Ping timeout: 260 seconds)
03:55:07*brson quit (Ping timeout: 244 seconds)
04:02:59*notfowl is now known as fowl
04:09:35*ludocode quit (Ping timeout: 244 seconds)
04:50:50*yglukhov joined #nim
04:55:03*yglukhov quit (Ping timeout: 240 seconds)
05:43:18*kseg joined #nim
05:52:22ksegHow can I turn a pointer (say, from http://nim-lang.org/docs/sqlite3.html#column_blob,Pstmt,int32) into something usable? Was hoping p = cast[ptr byte](pointer) would work, but p[1] doesn’t (p[] gives me the first value though)
06:00:17*ludocode joined #nim
06:02:47*endragor joined #nim
06:14:32*yglukhov joined #nim
06:16:06ksegtype BArray {.unchecked.} = array[0..0, byte]
06:16:21ksegcast[ptr ByteArray](pointer)
06:16:22ksegseems to work
06:19:07*yglukhov quit (Ping timeout: 260 seconds)
06:20:23*endragor_ joined #nim
06:24:26*endragor quit (Ping timeout: 244 seconds)
06:29:21*endragor_ quit (Remote host closed the connection)
06:29:50*endragor joined #nim
06:33:22*fastrom joined #nim
06:59:45*gokr joined #nim
07:01:11*kseg quit (Quit: kseg)
07:12:49*kseg joined #nim
08:06:26*Demon_Fox quit (Quit: Leaving)
08:13:09*moigagoo joined #nim
08:16:20moigagooHi! Just a quick silly question. Any idea on when Nim 0.14 will be released?
08:16:44moigagooAlso, haven't you thought about switching from IRC to Gitter? :-)
08:16:48*Arrrr joined #nim
08:30:02gokrmoigagoo: IRC is still home for a LOT of people. It's also "free". Gitter is great, we use it a lot at Evothings, but its still a commercial entity. Personally I find both have their respective merits.
08:31:58*kseg quit (Quit: kseg)
08:45:22*kseg joined #nim
08:49:11*zodiak_ joined #nim
08:52:08*zodiak quit (Ping timeout: 276 seconds)
08:56:16*yglukhov joined #nim
08:57:07yglukhovdom96: can you merge, https://github.com/nim-lang/Nim/pull/4150
09:00:09*fastrom quit (Quit: Leaving.)
09:02:23*Arrrr_ joined #nim
09:02:37*Arrrr_ quit (Client Quit)
09:04:24*Arrrr quit (Ping timeout: 250 seconds)
09:05:57*Salewski joined #nim
09:09:34SalewskiCurrently I can not remember the Nim way to ensure cleanup when the program terminates. For example, I start a new process, how can i ensure that this process is always terminated when my main program terminates?
09:10:36Salewski(My main program may terminate regular, or maybe by an exception)
09:15:28*moigagoo quit (Ping timeout: 250 seconds)
09:15:42SalewskiDo we use try/finally or defer for that? Have not seen an example yet, but I think so.
09:16:49Araq_Salewski: yeah but also addQuitProc is useful for that
09:17:27SalewskiAh, thanks!
09:20:42SalewskiAraq_ Is http://forum.nim-lang.org/t/2258 a bug that I should report, or may the return of all the templates definitions for a sug query really be intended?
09:30:42Araq_it's intended indeed, sorry wanted to answer
09:31:00Araq_since float matches expr, all the templates are candidates
09:35:47Araq_and there is little we can do about it
09:36:38SalewskiOK, I indeed guessed that. But I can not imagine for what that is useful. When I import glib, I get hundred of such templates, makes no sense to display them to user for selection, so I will just filter all out.
09:37:46SalewskiBye.
09:37:49*Salewski quit ()
09:41:00yglukhovdom96, cheatfate. regarding this deep recursion problem. I think there's an easy fix for that. in future.complete() check for current stack size, and if it exceeds threshold, defer callback to selector and wake it up. selector will unconditionally call deferred callbacks after every iteration.
09:46:33*nsf quit (Ping timeout: 240 seconds)
09:49:55*PMunch joined #nim
10:01:30*kulelu88 quit (Quit: Leaving)
10:18:58*kseg quit (Quit: kseg)
10:26:06*br3w5 joined #nim
10:37:39*PMunch quit (Ping timeout: 246 seconds)
10:48:47*Trustable joined #nim
10:59:27*Trustable quit (Quit: Leaving)
11:03:54*gokr quit (Ping timeout: 276 seconds)
11:06:38*gokr joined #nim
11:33:38*tankfeeder joined #nim
11:35:56*elrood joined #nim
12:16:42*yglukhov quit (Ping timeout: 260 seconds)
12:24:44*gokr quit (Quit: Leaving.)
12:24:47*gokr1 joined #nim
12:28:15dom96yglukhov: interesting idea. I think it would work pretty well.
12:29:01dom96explicitly deferring a callback might be better though
12:29:23dom96otherwise async becomes even more unpredictable
12:30:13*arnetheduck joined #nim
12:34:56dom96yglukhov: merged
12:35:23cheatfatedom96, i cannot agree, because we are not fall to "deep recursion" fast we are going to it step by step... and after when we reach position stackSize - 1 we will always run only one callback per pool
12:35:42cheatfateper pool() call
12:35:51dom96cheatfate: so you think we should do what yglykhov suggests?
12:36:09cheatfatedom96, nope we need to stay with our old plan of callSoon
12:36:18cheatfatedom96, this is the best variant
12:36:51dom96hrm okay.
12:39:07cheatfatedom96, you know yesterday i have tested GetQueuedCompletionStatusEx() which can receive not one result like GetQueuedCompletionStatus() but an array of results... and for some reason this new function not give asyncdispatch any speed increase...
12:39:47cheatfate0.01ms...
12:42:35dom96btw, just in case, I re-added these sanity checks https://github.com/nim-lang/Nim/commit/299989f3aa72b4bb0558ce5dbe7043dc83a4d2a5
12:46:17*zaquest joined #nim
12:49:11*lubos_cz joined #nim
12:58:16*gokr1 quit (Ping timeout: 265 seconds)
12:59:37*gokr joined #nim
13:13:53*yglukhov joined #nim
13:21:25*lubos_cz_ joined #nim
13:22:05*lubos_cz_ quit (Remote host closed the connection)
13:22:39*lubos_cz quit (Quit: Leaving)
13:23:04*lubos_cz joined #nim
14:02:16*pregressive joined #nim
14:02:39yglukhovcheatfate: do you mean that callSoon should now be called instead of future.complete? or inside futureComplete?
14:04:50yglukhovusing callsoon unconditionally will make every completion deferred. isn't that less efficient?
14:06:17yglukhovwith my suggestion (which actually still requires callSoon), we can complete more futures immediately under normal load. under heavy load we will fallback to callsoon.
14:06:51yglukhovalso we can define a min/max threshold. e.g. if stack > max: callSoon until stack < min
14:07:00yglukhovping dom96 also
14:08:22dom96yglukhov: I think the plan with callSoon is that it's a part of the API and we only use it in certain places
14:08:43dom96basically any time the future completes immediately
14:09:14*pregressive quit (Remote host closed the connection)
14:09:55yglukhovah, that makes sense. nevermind what i said
14:10:58yglukhovcallSoon sounds like dead easy to implement. will you do it soon? :)
14:11:36yglukhovdo i understand correclty that it's like no more than 5 lines of code total?
14:13:14*BitPuffin joined #nim
14:15:42yglukhovAraq_: can i cast a ref to anything to ref RootObj and hope that GC will not mess it up?
14:17:16Araq_yglukhov: yeah that sounds about right
14:17:47yglukhovok thanks
14:20:21yglukhovAraq_, also if i cast int or smth small to ref RootObj, am i in trouble?
14:20:35Araq_yep
14:21:06Araq_then you are in big trouble and need to patch the GC so that every != nil check checks for ptr >% PageSize or something
14:21:27Araq_which doesn't seem wise for bug preventions
14:22:01Araq_otherwise I would have done it years ago since it has no cost and makes it a bit more flexible
14:22:02yglukhovok thanks again
14:23:15yglukhovdoes gc somehow check object variants in this context?
14:23:36yglukhovAraq_
14:24:07Araq_sure, it's precise for object variants too
14:24:21Araq_don't use them as an unsafe union
14:24:30yglukhovok
14:28:14*tautologico quit ()
14:35:08*nsf joined #nim
14:35:56arnetheduckhey Araq_, what's the motivation behind skirting the dynamic loader and loading dynlibs with dlopen/equivalents?
14:37:50Araq_so that I don't need braindead -dev packages which contain some shitty libs that I link statically against that then call the stuff in the dynamic lib anyway
14:38:44*Arrrr joined #nim
14:38:53*Arrrr quit (Changing host)
14:38:53*Arrrr joined #nim
14:39:10Araq_it makes no sense at all and the scripting languages all use dlopen anyway so the "dependency walkers" are all completely unreliable
14:40:37Araq_not too mention that the command line order in the linking step is still relevant. In 2016.
14:42:36*tankfeeder quit (Quit: Leaving)
14:45:30*zahary joined #nim
14:47:24*kulelu88 joined #nim
14:47:24*kulelu88 quit (Changing host)
14:47:24*kulelu88 joined #nim
14:56:46*pregressive joined #nim
15:03:33*BitPuffin quit (Ping timeout: 240 seconds)
15:05:42*gokr quit (Ping timeout: 276 seconds)
15:15:17reactormonkAraq_, is there a windows-equivalent of the mac automator?
15:19:21Araq_no idea. does COM/ActiveX count?
15:19:47Araq_speaking of which, why does Nim still lack COM support?
15:20:22Araq_disphelper ain't that hard to port to Nim and then you can script Excel/Word etc with Nim.
15:20:45reactormonkAraq_, does that have a GUI? :-)
15:22:17*nsf quit (Ping timeout: 244 seconds)
15:22:32Araq_http://www.webdomination.de/2010/10/actions-das-automater-pendant-fuer-windows/
15:23:29reactormonkNice.
15:23:37Araq_funny it's a Java App
15:24:36*fastrom joined #nim
15:25:09Araq_this seems to be way more useful though: https://www.autoitscript.com/site/autoit/
15:25:20Araq_since it emulates mouse events
15:28:37reactormonkThe automator would be the equivalent of the command line in power - somewhat of.
15:37:12*nsf joined #nim
15:47:53Araq_blasphemy! ;-)
15:57:38*pandada8_ joined #nim
15:57:49*pandada8_ quit (Client Quit)
15:59:18*pandada8 joined #nim
16:05:10*arnetheduck quit (Ping timeout: 244 seconds)
16:19:10yglukhovAraq_: is there some magic flag which asserts nim upon compilation error/warning so that it's easier to debug nim?
16:19:43Araq_hmm? -d:useSysAssert -d:useGcAssert turns on even more memory checks
16:20:40yglukhovno. e.g. error: cannot evaluate 'sizeof(Foo[int])'. it looks like nim bug. i want to know the stacktrace of nim that produces this error. stacktrace of the nim compiler itself.
16:21:54yglukhov.e.g $ nim c --assertOnErrors test.nim
16:22:03yglukhovand nim will crash with stacktrace
16:22:39*Jesin joined #nim
16:23:21yglukhovbecause otherwise i have to patch compiler/msgs.nim to doAssert(false)
16:27:09*endragor quit (Remote host closed the connection)
16:27:14Araq_koch temp c -d:debug foo.nim
16:27:28Araq_or --verbosity:3 instead of -d:debug
16:28:00Araq_it's not a bug though, the compiler cannot evaluate complex sizeof() expressions, it passes them to C
16:29:36yglukhovoh, really...
16:32:53yglukhovok then
16:39:12*Arrrr quit (Ping timeout: 246 seconds)
16:44:56*libman joined #nim
16:50:36*kulelu88 quit (Quit: Leaving)
16:59:49yglukhovAraq_: i want to add a note to sizeof doc: "If used within nim VM context ``sizeof`` will only work for scalar types." does it sound right?
17:04:31*brson joined #nim
17:06:44Araq_yup
17:07:34*libman quit (Ping timeout: 250 seconds)
17:18:06*libman joined #nim
17:23:02cheatfateyglukhov, about `callSoon` we want to add https://github.com/nim-lang/Nim/blob/devel/lib/pure/asyncdispatch.nim#L260 callSoon(future.cb) which enqueue future.cb and dequeue it after this line https://github.com/nim-lang/Nim/blob/devel/lib/pure/asyncdispatch.nim#L471
17:23:34cheatfateand run all callbacks there... queue data structure must be placed in globalDispatcher
17:24:12cheatfatei have already made it, but it causes very very strange warnings and errors... I dont understand it so i ask dom96 to make it
17:25:05yglukhovcheatfate: sounds reasonable. got a gist?
17:27:28cheatfateyglukhov, ok give me some time to make it again... could not find it
17:28:00*endragor joined #nim
17:28:57*brson quit (Quit: leaving)
17:29:49*brson joined #nim
17:31:52yglukhovok, bbl
17:32:47*endragor quit (Ping timeout: 276 seconds)
17:37:34*libman quit (Remote host closed the connection)
17:37:48*yglukhov quit (Ping timeout: 276 seconds)
17:41:49*br3w5 quit (Quit: br3w5)
17:58:07cheatfateyglukhov: dom96: this is my proposal of `callSoon` https://gist.github.com/cheatfate/ea85f5f8fb8f26ba79ff253541b526dc/revisions
17:59:25cheatfatebut for some reason it got an error
17:59:41cheatfateerror are in the comments
18:06:42*endragor joined #nim
18:09:38dom96cheatfate: have you tried to mark that proc with {.gcsafe.}?
18:09:57dom96cheatfate: now that I'm looking at the diff, maybe we could just reuse the timers for this?
18:10:23cheatfatedom96, but we will kill timers when we got hardware timers...
18:11:15dom96cheatfate: even if the timers are implemented in hardware it will still be possible to use them this way
18:11:36*endragor quit (Ping timeout: 276 seconds)
18:11:38cheatfatedom96, for what reason?
18:11:57dom96cheatfate: simpler code?
18:12:04cheatfatedom96, but insane slowdown
18:12:27dom96I don't think so
18:12:43cheatfatedom96, i have already tested old timers and i have an issue on that
18:13:32cheatfatedom96, https://github.com/nim-lang/Nim/issues/3909
18:13:45cheatfateit makes asynchttpserver 2x times slower...
18:13:50cheatfatethere was old timers
18:14:04dom96I think yglukhov fixed that
18:14:57Xedoes the async macro rewrite code with await to callback-ify it?
18:15:12dom96Xe: it rewrites it into a coroutine
18:15:27cheatfatedom96, you want me to make tests again?
18:15:29dom96(kind of, Nim's closure iterators aren't really coroutines)
18:15:37dom96cheatfate: if you want
18:15:53Xei should look at rewriting the time library
18:16:05cheatfatedom96, i dont because i have already tested hardware timers and there only 2-5% speed decrease if you use hardware timer
18:16:07Xebecause for the love of god that needs cleansing
18:16:28Araq_Xe: please start with fixing the open bugs :P
18:18:17dom96Xe: PRs are always warmly welcome :)
18:18:39XeAraq_: like the one I reported that was basically "this doesn't work"?
18:19:27Araq_do you really think I know every bug in detail?
18:19:37Araq_we have 700 of these
18:21:08cheatfatedom96, please check gist for my last comment, there was a bunch of warnings if i add {.gcsafe.}...
18:21:45dom96Xe: which one is that? (Can't remember your GH username)
18:21:51XeXe
18:22:24Xetimetotimeinfo has been causing me hell
18:22:46*Salewski joined #nim
18:22:47Xei think that it should be removed as well as the time object made private
18:22:49dom96Xe: oh, Github didn't show it in the completions so I assumed that wasn't it.
18:23:04*yglukhov joined #nim
18:24:36dom96Xe: I think we deprecated that
18:25:19Salewskisug skProc system.toFloat proc (i: int): float{.noSideEffect.} /home/stefan/Nim/lib/system.nim 1534 5 "" 100 # Araq, what is the 100 (last value result) when nimsuggest is launced with --v2 ? Priority?
18:26:07dom96confidence perhaps?
18:26:57SalewskiYes, maybe. Seems to be always 100, so some percentage maybe?
18:27:08dom96Xe: in fact, your issue might be fixed now?
18:27:31Araq_Salewski: yup, it's a "matching quality"
18:27:42*yglukhov quit (Ping timeout: 260 seconds)
18:27:42Araq_currently I might only use 100 and 0, but hey
18:27:43SalewskiOK, thanks!
18:27:51Araq_it can scale.
18:28:13SalewskiBye.
18:28:16*Salewski quit ()
18:30:08cheatfatedom96, did you saw warnings?
18:30:45dom96cheatfate: yes, I'm not sure what to do about them. Maybe Araq_ can help.
18:34:12cheatfatedom96, its because callSoon using queue which are not gcsafe
18:34:41cheatfatebut i dont understand why first error wants {.closure,gcsafe.}
18:34:43*yglukhov joined #nim
18:35:31cheatfatedom96, i even dont understand why first error appeared
18:48:09cheatfatedom96, i can make queue to be gcsafe...
18:54:29*aziz joined #nim
18:58:55yglukhovcheatfate: your gist works ok for me
18:59:17cheatfateyglukhov, you can compile it without error?
18:59:18yglukhovif callSoon is {.gcsafe.}
18:59:21yglukhovyup
18:59:24yglukhovbut im on mac
18:59:39cheatfateyglukhov you made callSoon gcsafe but it not gcsafe
18:59:49yglukhovit is gcsafe on mac
18:59:52cheatfateit uses queues.nim
18:59:53yglukhovprobably =)
19:00:19cheatfateits just because you marked callSoon proc with {.gcsafe.} i have marked callback with {.gcsafe.}
19:03:39cheatfateyglukhov, and in your case it can cause memory leaks i think...
19:03:52*brson quit (Ping timeout: 260 seconds)
19:04:55yglukhovcheatfate: im not sure i understand you.
19:05:35cheatfatecallSoon using queue from queues... so enqueue() operation is not {.gcsafe.} but you have marked whole proc with {.gcsafe.}
19:06:10yglukhovwhy enqueue is not gcsafe?
19:07:30yglukhovit doesnt use globals as far as i can see
19:07:53cheatfateyglukhov, yeah you are right, but queue stored in global variable
19:07:59cheatfategetGlobalDispatcher
19:08:26cheatfatequeue stored here https://gist.github.com/cheatfate/ea85f5f8fb8f26ba79ff253541b526dc#file-asyncdispatch_norecurse-nim-L416
19:08:57yglukhovglobalDispatcher is gcsafe because its in tls
19:09:19yglukhovcan you show your errors if you mark callSoon gcsafe?
19:11:42yglukhovalso you should callSoon in future.complete, shouldnt you?
19:13:20cheatfateyglukhov, nope callSoon is in right place
19:13:21*libman joined #nim
19:16:07cheatfateyglukhov, i was forgot about initalizing queue... and i have added {.gcsafe.} to callSoon declaration... and now it compiled without warnings and errors
19:16:09cheatfatehttps://gist.github.com/cheatfate/ea85f5f8fb8f26ba79ff253541b526dc
19:16:42*Gonzih quit (Ping timeout: 250 seconds)
19:17:04*pecan left #nim ("WeeChat 1.5")
19:17:21yglukhovcheatfate: great! could you please define callSoon not in the windows section, but further in the shared section?
19:18:07cheatfateyglukhov, ok lets try
19:19:21yglukhovshouldnt call soon wake selector up?
19:19:52yglukhovoh, nevermind.
19:19:52cheatfateyglukhov, the problem is that callSoon uses getGlobalDispatcher() to obtain pointer for queue
19:20:28cheatfatebut in shared section there still no getGlobalDispatcher() declaration
19:20:54yglukhovjust move it lower
19:21:03yglukhovafter both windows and unix sections end
19:22:18yglukhovbefore proc sleepAsync
19:24:10yglukhovoh and i think that processPendingCallbacks should be called before select as well as after select
19:24:34yglukhovbecause otherwise you might stall in select for some time
19:25:30cheatfatehttps://gist.github.com/cheatfate/ea85f5f8fb8f26ba79ff253541b526dc/revisions
19:27:12cheatfatewhy you think processPendingCallbacks must be called twice? just because it can break your timers?
19:29:11cheatfatecurrently until it used privately it can't break timers because for unix we have only 1 place where future can be returned already finished
19:29:41yglukhovon the other hand.... you're right. processPendingCallbacks at the end should be enough
19:30:08yglukhovyour gist works smoothly btw
19:31:30cheatfateyglukhov, https://gist.github.com/cheatfate/ea85f5f8fb8f26ba79ff253541b526dc#gistcomment-1777128
19:32:16cheatfateyglukhov, and i dont this Araq_ will accept this gist as PR :)
19:34:40*Gonzih joined #nim
19:43:07*brson joined #nim
19:54:24*aziz quit (Quit: Ex-Chat)
19:55:29*lcm337 joined #nim
20:08:08zodiak_re library is deprecated ?!
20:08:20zodiak_according to http://nim-lang.org/docs/lib.html it's the one to use :'(
20:08:59zodiak_oh, I see, clicking into the doc tells me to use nre or pegs
20:09:03Araq_zodiak_: there is 'nre' but I use 're' for my new projects so ...
20:09:13Araq_I might de-deprecate it ...
20:09:13zodiak_(thumbsup)
20:09:35zodiak_yeah.. I think (personally speaking) coming from python/perl.. re is 'the one true namespace' for regex ;)
20:10:00Araq_oh ok but we could remove 're' and make 're' an alias for 'nre'
20:10:08zodiak_oh
20:10:10zodiak_*laughs*
20:10:16zodiak_yeah, that would work (duh on me :)
20:10:27Araq_but at some point I will introduce Araq's lib
20:11:26Araq_the "old stdlib"
20:13:36Araq_cheatfate: last time I checked dom96 needs to accept stdlib PRs
20:13:39Araq_not me.
20:22:40cheatfatedom96, so we have Araq_ opinion and do you accept my gist as PR? with this latest `hidden` warnings? https://gist.github.com/cheatfate/ea85f5f8fb8f26ba79ff253541b526dc
20:22:43yglukhovcheatfate: these warnings existed before your changes
20:22:50yglukhovstash and try
20:23:56cheatfateyglukhov, yeah you are right just lost in this big amount of warnings...
20:24:09yglukhovso youre free to go i guess
20:26:20*bozaloshtsh quit (Ping timeout: 276 seconds)
20:34:14dom96cheatfate: make a PR please so that I can see the full diff
20:36:40cheatfatedom96, https://github.com/nim-lang/Nim/pull/4156 waiting for tests to be completed
20:40:28*gokr joined #nim
20:57:34*yglukhov quit (Remote host closed the connection)
21:00:18*libman quit (Remote host closed the connection)
21:01:13*elrood quit (Quit: Leaving)
21:07:53dom96cheatfate: looks like you broke tests
21:08:12dom96https://travis-ci.org/nim-lang/Nim/builds/130101013#L2301
21:16:47cheatfatedom96, yeah working on it
21:17:22cheatfateits just because yglukhov ask me to add callSoon to shared branch... and i have not tested it on unix yet... will made pr later
21:20:05*yglukhov joined #nim
21:20:20*gokr quit (Ping timeout: 244 seconds)
21:23:08*Matthias247 joined #nim
21:25:13*pregressive quit (Remote host closed the connection)
21:25:59*yglukhov quit (Ping timeout: 260 seconds)
21:33:38*saml quit (Remote host closed the connection)
21:43:08*saml joined #nim
21:43:21*tautologico joined #nim
21:43:47*bozaloshtsh joined #nim
21:44:42tautologicoI just tried to register on the forums, but my email won't fit in the text field... very small limit
21:44:50*saml quit (Remote host closed the connection)
21:46:35cheatfatedom96, made new PR https://github.com/nim-lang/Nim/pull/4159, tested in linux/windows/freebsd
21:47:08dom96tautologico: really? I don't recall adding any limits for that.
21:47:12dom96tautologico: Are you getting an error?
21:47:32tautologicono, no error
21:47:45tautologicothe browser suggested the autocomplete with my address
21:48:09tautologicobut then I noticed it said the confirmation email was sent to [email protected]
21:48:12tautologicothe m was cut out
21:49:03tautologicowhen I try to put the m back the form won't let me
21:50:10tautologicolimit seems to be 30 characters
21:50:51dom96tautologico: oh, looks like it's a limit in the html.
21:52:56dom96tautologico: I can change the email address for you if you'd like
21:59:46dom96tautologico: added the 'm'
22:04:41cheatfatedom96, please could you remember how to run particulare async tests with koch
22:05:22*yglukhov joined #nim
22:09:36*yglukhov quit (Ping timeout: 246 seconds)
22:10:13Araq_cheatfate: tests/testament/tester cat async
22:10:25cheatfateAraq_, thank you
22:10:36Araq_not sure what the koch alias is. 'koch test cat async' ?
22:12:39*fastrom quit (Quit: Leaving.)
22:13:03cheatfatekoch test c async working good
22:14:29*Matthias247 quit (Read error: Connection reset by peer)
22:14:56cheatfatelooks like my pr seriously break tests...
22:16:57*Matthias247 joined #nim
22:23:18cheatfateand looks like method to dequeue callbacks in pool() not works, because not all async code use poll()
22:29:14*yglukhov joined #nim
22:30:18*KYKYLLIKA joined #nim
22:30:45KYKYLLIKAAnyone know of a lib that implements guids?
22:33:19dom96KYKYLLIKA: haven't used these personally but might be close enough: https://github.com/wheineman/nim-only-uuid https://github.com/idlewan/nim-uuid http://nim-lang.org/docs/oids.html
22:33:42*yglukhov quit (Ping timeout: 244 seconds)
22:34:29KYKYLLIKAdom96: Thanks, I already found the oids, but uuids should be interesting to look at.
22:36:52cheatfatedom96, looks like dequing callback would be tough task
22:43:20*Demon_Fox joined #nim
22:45:27cheatfateand now i even dont know how we can resolve this "deep recursion" bug
22:53:35*yglukhov joined #nim
22:58:04*yglukhov quit (Ping timeout: 265 seconds)
23:00:15*Phoenixbl4 joined #nim
23:02:33*KYKYLLIKA quit (Ping timeout: 240 seconds)
23:05:09*Phoenixbl4 quit (Ping timeout: 260 seconds)
23:30:05*yglukhov joined #nim
23:34:50*yglukhov quit (Ping timeout: 276 seconds)
23:53:59*yglukhov joined #nim
23:58:26*yglukhov quit (Ping timeout: 244 seconds)