<< 09-08-2017 >>
00:03:16FromGitter<krux02> ok good luck, I go offline
00:03:43FromGitter<k0pernicus> Thanks! See you soon :-)
00:21:36*Serenit0r joined #nim
00:25:05*Serenitor quit (Ping timeout: 240 seconds)
00:47:32*endragor joined #nim
00:52:19*endragor quit (Ping timeout: 268 seconds)
00:59:40*Xe quit (Ping timeout: 255 seconds)
01:01:51*Xe joined #nim
01:03:29*snowcrshd joined #nim
01:05:53snowcrshdhey there! just stumbled upon Nim and I'm curious: is the original compiler (before bootstrap) available somewhere? I had a look at https://github.com/nim-lang/csources, but these appear to be automatically generated
01:22:20*mahmudov joined #nim
01:29:23*vivus quit (Quit: Leaving)
01:32:06*sakalli quit (Ping timeout: 240 seconds)
01:32:27*xet7 quit (Ping timeout: 240 seconds)
01:33:21*sakalli joined #nim
01:33:30*xet7 joined #nim
01:41:26def-pri-pubHow do I convience my coworkers (and boss) to let me implement something in Nim at work instead of C/C++?
01:43:27ftsfdef-pri-pub, get everyone there to learn it so it doesn't become a big tech debt when you leave
02:01:43*chemist69 quit (Ping timeout: 255 seconds)
02:06:14*skrylar joined #nim
02:10:07*snowcrshd quit (Remote host closed the connection)
02:15:29*chemist69 joined #nim
02:36:19*endragor joined #nim
02:41:20*skrylar quit (Quit: My iMac has gone to sleep. ZZZzzz…)
02:52:44*skrylar joined #nim
03:05:17ehmrydef-pri-pub: throw in some calls to C/C++ or some exports to C
03:06:32*skrylar quit (Quit: My iMac has gone to sleep. ZZZzzz…)
03:07:07ehmryfor me it was networking, its not hard to argue that raw Nim networking is better than raw C networking
03:08:49*pilne quit (Quit: Quitting!)
03:28:39*Jesin joined #nim
03:35:46*Jesin quit (Ping timeout: 255 seconds)
03:48:58*Jesin joined #nim
03:53:05*yglukhov joined #nim
03:57:27*yglukhov quit (Ping timeout: 240 seconds)
04:11:39*def-pri-pub quit (Quit: leaving)
05:32:28*dankrad quit (Ping timeout: 240 seconds)
05:41:09*tdc joined #nim
05:48:37*rauss quit (Quit: WeeChat 1.9)
05:53:41*Serenit0r quit (Quit: Leaving)
05:55:45*yglukhov joined #nim
05:59:57*yglukhov quit (Ping timeout: 240 seconds)
06:02:39*Vladar joined #nim
06:21:20*tankfeeder joined #nim
06:33:17*nsf joined #nim
06:42:36*Sentreen quit (Ping timeout: 240 seconds)
06:55:36*Sentreen joined #nim
07:06:25*Arrrr joined #nim
07:06:25*Arrrr quit (Changing host)
07:06:25*Arrrr joined #nim
07:15:55*scriptum joined #nim
07:31:56*yglukhov joined #nim
07:52:03*Andris_zbx joined #nim
08:08:32*yeeve joined #nim
08:22:57*cspar_ quit (Ping timeout: 248 seconds)
08:24:20*gokr joined #nim
08:26:02*dom96|w joined #nim
08:33:56FromGitter<TiberiumN> snowcrshd: yes
08:34:22FromGitter<TiberiumN> https://github.com/nim-lang/nim
08:47:16*yglukhov quit (*.net *.split)
08:47:17*EastByte quit (*.net *.split)
08:47:17*Amun_Ra quit (*.net *.split)
08:47:17*bodie_ quit (*.net *.split)
08:47:17*insomniac quit (*.net *.split)
08:47:18*joebo quit (*.net *.split)
08:47:18*myp quit (*.net *.split)
08:47:18*heinrich5991 quit (*.net *.split)
08:47:19*dom96 quit (*.net *.split)
08:49:37*mahmudov quit (Ping timeout: 258 seconds)
08:49:37*Araq quit (Ping timeout: 258 seconds)
08:49:37*gmpreussner quit (Ping timeout: 258 seconds)
08:50:08*Araq joined #nim
08:50:47*flyx quit (Ping timeout: 260 seconds)
08:52:33*flyx joined #nim
08:52:46*gmpreussner joined #nim
08:55:13*dom96|w quit (Quit: My Mac has gone to sleep. ZZZzzz…)
09:03:08*dom96|w joined #nim
09:04:03*jinshil quit (Quit: Good-bye!)
09:19:56*nattefrost joined #nim
09:30:25*dom96|w quit (Quit: My Mac has gone to sleep. ZZZzzz…)
09:31:14*myp joined #nim
09:31:16*insomniac joined #nim
09:31:21*joebo joined #nim
09:31:36*yglukhov joined #nim
09:31:50*Amun_Ra joined #nim
09:32:37*EastByte joined #nim
09:32:42*dom96 joined #nim
09:35:40*bodie_ joined #nim
09:37:48*heinrich5991 joined #nim
09:40:37*yglukhov_ joined #nim
09:42:48*yglukhov quit (Ping timeout: 240 seconds)
09:46:40*rokups joined #nim
09:54:17FromGitter<TiberiumN> I don't know how he didn't found Nim source code :D
09:58:11*dom96|w joined #nim
09:58:17*dom96|w quit (Client Quit)
10:06:22*insomniac quit (Changing host)
10:06:22*insomniac joined #nim
10:11:18*haha_ joined #nim
10:18:51*krux02 joined #nim
10:20:52*haha_ quit (Quit: haha_)
10:21:42*haha_ joined #nim
10:55:55*mahtov2 quit (Ping timeout: 255 seconds)
11:09:15*couven92 joined #nim
11:11:11*mahtov joined #nim
11:17:43*Arrrr quit (Read error: Connection reset by peer)
11:38:10*sakalli quit (Ping timeout: 255 seconds)
11:39:26*krux02 quit (Remote host closed the connection)
11:54:58*BitPuffin|osx joined #nim
11:59:27*Ven joined #nim
11:59:50*Ven is now known as Guest88211
12:16:26*tdc quit (Quit: Leaving)
12:16:56*tdc joined #nim
12:23:41*yglukhov joined #nim
12:25:47*yglukhov_ quit (Ping timeout: 255 seconds)
12:25:52FromGitter<cooldome> Hi,
12:27:58*yglukhov_ joined #nim
12:30:06*yglukhov quit (Ping timeout: 240 seconds)
12:32:28*rokups quit (Quit: Connection closed for inactivity)
12:42:45*ibutra joined #nim
12:56:00*adeohluwa joined #nim
12:57:05*Guest88211 quit (Ping timeout: 248 seconds)
12:57:37Araqhi
12:58:53*rokups joined #nim
13:23:23*rauss joined #nim
13:35:34*yglukhov joined #nim
13:37:40*yglukhov_ quit (Ping timeout: 260 seconds)
13:58:01*arnetheduck quit (Remote host closed the connection)
14:00:49*chaosdav joined #nim
14:03:24*yglukhov_ joined #nim
14:06:52*yglukhov quit (Ping timeout: 276 seconds)
14:07:51*arnetheduck joined #nim
14:13:03tankfeederhttps://www.reddit.com/r/nim/comments/6slkqw/where_can_i_get_the_original_nim_compiler_pascal/?ref=share&ref_source=link
14:13:08tankfeederquestion on reddt
14:14:59*ibutra quit (Read error: Connection reset by peer)
14:21:04*nsf quit (Quit: WeeChat 1.9)
14:34:46AraqI don't know
14:40:12tankfeeder:)
14:41:31cremCompilers are a bit special, they don't look like average complex programs.
14:41:52*nattefrost quit (Remote host closed the connection)
14:45:14Araqno, they are the only complex programs, everything else is easy :P
14:48:00AraqI might have the original Pascal sources somewhere but it can only compile Nim v 0.6
14:48:12Araqand we're at version 0.17
14:48:57tankfeederAraq: make it public /
14:48:58tankfeeder?
14:49:05Araqwhy?
14:49:34Araqit used to be part of the distribution
14:49:52cremSo that people who learn pascal could learn from example of complex program. :)
14:50:09Araqpeople shouldn't learn Pascal, they should learn Nim instead
14:50:26tankfeederok
14:51:18cremI doubt. :) Nim is a nice "fun language" but I cannot imagine using it in large team. For now. :)
14:51:41Araqand you can imagine to use Pascal for that?
14:52:50cremHm, not sure. I guess it's easier to imagine, pascal has constructors. :)
14:53:41Araqsuccessful software development in a large team: you fire people until it's a small team. Then you can use a language where you can program instead of play the bullshit bingo game
14:53:42cremLast time I touched pascal was in previous century though.
14:54:22Araq;-)
14:55:37Araqconstructors are required for complex programs? that's news to me, how does that work out?
14:56:01*endragor quit (Remote host closed the connection)
14:56:30cremOk, that's not true, in Go they also don't have constructors and somehow manage to write large systems.
14:58:35cremAnyway, I wrote <100 lines in nim so far (and got ~10 SIGSEGVs). I'll update my opinion as I progress. :)
14:59:17Araqthat's not the lack of destructors but the lack of a sane default value for strings/seqs, I bet
14:59:57cremyes
15:00:16Araqit's also only a mild annoyance, these are not bugs that take months to hunt down
15:00:25*endragor_ joined #nim
15:00:52cremI wonder why aren't they implemented as C++'s string/vector. It's no allocation for empty ones.
15:02:04cremAlso why are they built in into language (are they?) rather than being a part of standard library.
15:02:13Araqoh not hat again
15:02:23AraqI remember explaining these things to you
15:02:36cremThat? I don't remember that.
15:02:40cremSo probably it wasn't me.
15:03:06cremBut I can look up in the forum or something.
15:03:11*Matthias247 joined #nim
15:03:26euantorNot implemented as C++'s strings/vectors because the language doesn't target C++ all of the time - most commonly it compiles to C. Makes sense to have a standard form across backend targets
15:03:58euantorAs for why they're built into the language, it makes sense to me but can't remember seeing an official reason
15:04:36*endragor_ quit (Ping timeout: 240 seconds)
15:04:37cremI'm not saying about being compiled into strings/vectors, just trying to understand the decision.
15:05:17*dom96|w joined #nim
15:05:23cremI only ranted about unicode strings not being a separate type, but I'm now silent about that. So I don't raise the same topic again!
15:05:59Araqok, fine, here is the reason once again:
15:06:13cremAlso I don't oppose (or even disagree), but rather asking the reasoning.
15:06:22euantorstrings are basically just a bag of bytes which is why things like the net module use strings rather than some byte view or byte arrays
15:07:16*endragor joined #nim
15:07:21euantorThe way strings work in Nim is probably one of the things I like most about them, though I have pestered Araq with questions in the past related to misunderstanding how slicing works
15:09:02Araqwhen you have a tracing GC, or even want the possibility of a tracing GC, you want the GC to trace the seq in its range 0..<s.len, not 0..<s.capacity
15:09:31Araqwhen you build seqs on top of that as a library, the GC only knows about the capacity though (if you're lucky, that is)
15:10:10Araqso the runtime needs to understand that 'len' is a special field that reflects the length and that pretty much means you want them as builtins in your language
15:10:14cremOk, clear about seq. :)
15:11:22cremThanks, that makes sense.
15:11:26euantorstrings are basically `seq[char]`
15:11:39euantoras far as I understand things anyway
15:11:43cremOk, then it also makes sense.
15:11:55*endragor quit (Ping timeout: 255 seconds)
15:12:03Araqnow your other question is why is seq a pointer to a struct { len, cap; data[unknownSize] } rather than struct { len; pointer to data[unknownSize]; }
15:15:10Araqbecause then you only pass a single pointer around instead of a struct with 2-3 words in it and an empty seq takes up 1 word, not 2-3. maybe that was a bad tradeoff but we can change the implementation
15:19:03FromGitter<aboisvert> Showing my ignorance here but why doesn't zeroing the extra capacity in the seq not work well (for tracing GC) ?
15:25:03FromGitter<krux02> Araq: I think the implementation of seq as a struct with a pointer to the data could be faster, because then the length field is on the stack
15:25:39FromGitter<krux02> for passing it down to functions it could be done like with any other object type, is is passed by a hidden pointer
15:29:45*Trustable joined #nim
15:34:19*chriswakare joined #nim
15:36:38*chriswakare quit (Client Quit)
15:37:13subsetparkdom96: you around?
15:41:51*Ven joined #nim
15:42:14*Ven is now known as Guest36538
15:46:56*haha_ quit (Quit: haha_)
15:50:00Araqaboisvert: then you have subsequence full of 'nil' values, ok that would work, but it's rather inelegant and slower
15:51:14Araqkrux02: small objects are passed by value in Nim because we assume it's faster than the pointer indirection
15:51:37Araqfor seqs however, we need a single indirection anyway so the situation is a bit different.
15:52:18Araqthat said, if you duplicate then length field you risk it becoming out of date with the real length, for example:
15:52:27Araqlet old = myseq
15:52:34Araqmyseq.setLen 0
15:52:58Araqif 0 < old.len: echo old[i] # cannot fail, right? ... wrong!
15:53:10Araqif 0 < old.len: echo old[0] # cannot fail, right? ... wrong!
15:54:01Araqbut ok, the existing implementation has similar problems too
15:54:08Araqso maybe it doesn't matter
15:58:34dom96|wsubsetpark: sort of, why?
15:58:43*Andris_zbx quit (Remote host closed the connection)
15:58:58*mahmudov joined #nim
16:04:48*krux02 joined #nim
16:05:46*adeohluwa quit (Quit: Connection closed for inactivity)
16:09:46subsetparkdom96|w: just wanted to follow up on the async/spawn interaction ... but ignore me for now.
16:10:09dom96|wjust say what you found, i'll read the logs later.
16:11:04subsetparkYeah, I mean I'm still poking around. Nothing conclusive. Thought I encountered an issue where active requests stopped at 8, but can't reproduce it
16:11:48*Parashurama joined #nim
16:12:17*Matthias247 quit (Read error: Connection reset by peer)
16:16:37ParashuramaHey.
16:16:38ParashuramaAraq, dom96: I'm looking into traceback errors, where lineno/procname doesn't point to the failing line, the right proc or even sometime in the right module.
16:16:40ParashuramaDoes anyone, has some short code samples that show that behaviour.
16:16:41Parashuramapreferably on 'gist'/github or pastebin so that I can use it easily.
16:17:20AraqParashurama: template invokations are ambiguous
16:17:30Araqt(a, b)
16:17:37dom96|wsubsetpark: so it is working asynchronously? :)
16:18:04subsetparkseems like it...
16:18:10Araqwhen it fails in 'a' or 'b' the traceback is wrong, when it fails in the first line of the template, it is correct, iirc
16:19:28Araqsimilar problems arise due to the inlining of iterators
16:19:55Araqthe root cause is that we emit the line tracking on the statement level, not expression level
16:20:06Araqfixing it could be difficult :-)
16:20:20ParashuramaAraq: ah, okay. where do you recommand I start. It's a very annoying bug in nested code.
16:20:50*dom96|w quit (Read error: Connection reset by peer)
16:22:44Araqcgen.nim, ccgexprs.nim, ccgstmts.nim
16:23:27*couven92 quit (Quit: Client disconnecting)
16:26:16*dankrad joined #nim
16:27:28FromGitter<krux02> when I run a test with ./koch test run /tests/.../test.nim it fails, when I then execute the exact same executable on the command line it just runs
16:28:14FromGitter<krux02> segfault when run in the test environment, normal exit when run nurmally
16:28:18FromGitter<krux02> what could that be
16:28:33*tdc quit (Read error: Connection reset by peer)
16:28:37*dom96|w joined #nim
16:29:27*tdc joined #nim
16:30:48*Arrrr joined #nim
16:31:13FromGitter<krux02> I just have a segmentation fault, no stack trace available
16:31:31FromGitter<krux02> and when I want to run with gdb afterwards, yea no error anymore
16:31:40FromGitter<krux02> that is a true Heisenbug
16:32:04FromGitter<krux02> the test is tuple_with_nil
16:32:11*nsf joined #nim
16:34:19*dom96|w quit (Quit: My Mac has gone to sleep. ZZZzzz…)
16:36:22FromGitter<brentp> hi, any advice on how to advice on how to side-step this: https://github.com/nim-lang/c2nim/issues/94 ?
16:37:01*Guest36538 quit (Ping timeout: 276 seconds)
16:37:28FromGitter<krux02> well you can change the source for c2nim
16:38:19FromGitter<krux02> the pattern you see in the C version is just for convenience so that you don't need to call the name of the struct always with the prefix struct
16:38:31FromGitter<krux02> that is something that does not need to be wrapped or reproduced in any way
16:38:48FromGitter<krux02> so either delete the additional types in the nim file or in the C file
16:39:53FromGitter<brentp> aye. that does it `typedef struct {} bam_plp_t;`
16:39:56FromGitter<brentp> thank you.
16:48:31*nhywyll joined #nim
16:53:38*cspar_ joined #nim
16:54:58*dankrad quit (Ping timeout: 255 seconds)
16:55:16*dankrad joined #nim
16:57:00*Ven joined #nim
16:57:23*Ven is now known as Guest39777
16:57:54*haha_ joined #nim
16:59:29*ofelas joined #nim
17:16:05*sakalli joined #nim
17:16:22*nhywyll quit (Quit: nhywyll)
17:22:41*willprice joined #nim
17:30:50*arnetheduck quit (Ping timeout: 240 seconds)
17:32:40*djellemah_ quit (Remote host closed the connection)
17:36:06*BitPuffin|osx quit (Ping timeout: 240 seconds)
17:40:04*dankrad quit (Ping timeout: 276 seconds)
17:40:21*dankrad joined #nim
17:40:38*Tiberium joined #nim
17:41:58*Tiberium quit (Client Quit)
17:43:51*yglukhov_ quit (Remote host closed the connection)
17:46:38*BitPuffin|osx joined #nim
17:47:59*krux02 quit (Remote host closed the connection)
17:52:10*haha_ quit (Quit: haha_)
17:55:47*yglukhov joined #nim
17:59:43*couven92 joined #nim
18:00:16*yglukhov quit (Ping timeout: 255 seconds)
18:02:30*PMunch joined #nim
18:03:30*dddddd joined #nim
18:03:56*dom96|w joined #nim
18:05:14*dom96|w quit (Client Quit)
18:05:48*nsf quit (Quit: WeeChat 1.9)
18:07:26*Etheco quit (Read error: Connection reset by peer)
18:17:20*Tiberium joined #nim
18:17:38*Tiberium quit (Remote host closed the connection)
18:17:43*nhywyll joined #nim
18:19:10*Guest39777 quit (Ping timeout: 240 seconds)
18:19:13subsetparkdom96: I can confirm that with the right httperf invocation, the form that I submitted on the jester repo works concurrently. However, when I translate my application into that form... It's sequential D:
18:19:24subsetparkMaybe when you've got time we could go over my implementation?
18:19:55*Tiberium joined #nim
18:25:41*gangstacat joined #nim
18:28:25*yglukhov joined #nim
18:29:23*tdc quit (Ping timeout: 255 seconds)
18:29:37*Ven joined #nim
18:30:02*Ven is now known as Guest3761
18:33:04*yglukhov quit (Ping timeout: 260 seconds)
18:48:02dom96subsetpark: sure
18:48:07dom96Let's do it
18:48:17subsetparkalright i'll msg you
18:50:31*yglukhov joined #nim
18:53:27*Trustable quit (Remote host closed the connection)
18:54:26*Trustable joined #nim
18:54:35dom96I will have to eat soon so better hurry :)
18:54:38dom96subsetpark: ^
18:58:08subsetparkAraq: I am in need of your threadpool wisdom
18:58:40*Arrrr quit (Read error: Connection reset by peer)
18:59:53dom96Araq: I think subsetpark's issue is that `spawn` is blocking (because threadpool only ever launches a finite amount of threads, right?)
19:00:11subsetparkSpecifically - (# cores) + 1
19:00:34subsetparkI wonder how to spawn more threads, and have them compete for CPU time
19:02:28*rokups quit (Quit: Connection closed for inactivity)
19:05:37*haha_ joined #nim
19:11:46*Vladar quit (Quit: Leaving)
19:14:13subsetparkOr if that's the new threadpool from yglukhov
19:21:12yglukhovsubsetpark: yeah, you could try my impl...
19:21:23yglukhovfeedback is welcome
19:22:09subsetparkyglukhov: how do I get to it?
19:22:36yglukhovsubsetpark: https://github.com/yglukhov/threadpools/blob/master/threadpool_simple.nim
19:23:04yglukhovit's in early access now =)
19:24:23yglukhovline 251 and below is compatibility layer between current nim threadpools. should work as a drop-in replacement. but you're encouraged to not use those.
19:24:36*Matthias247 joined #nim
19:25:00subsetparkyglukhov: what's the difference between simple and complex?
19:25:50*pilne joined #nim
19:26:01yglukhovcomplex is an attempt to make work stealing. but from my trials simple is always more robust. also simple is a lot simpler in implementation
19:26:29subsetparkhow does simple go past (n+1) without work stealing, then?
19:27:34subsetparkor do the threads just get created and wait until a core is free?
19:28:12yglukhovthe threads are created and wait until there is some job on the channel. there is a single channel for all threads.
19:28:45subsetparkgot it
19:28:55subsetparkbut they allow the original call site to not have to block
19:29:42yglukhovcall site blocking depends on maxMessages parameter. grep it.
19:30:06*dankrad quit (Ping timeout: 240 seconds)
19:30:41yglukhovbasically if the channel has more messages than maxMessages, call site will wait
19:30:54yglukhovyou can set maxMessages to 0 to never block.
19:31:11*dankrad joined #nim
19:31:19subsetparkGot it, seems pretty straightforward
19:33:06*Sentreen quit (Read error: Connection reset by peer)
19:37:25*Sentreen joined #nim
19:38:43subsetparkyglukhov: do I need to do any magic to get that module to compile? it looks like Thread and Channel are not defined there
19:38:57yglukhov--threads:on?
19:39:28yglukhovjust like you would with existing threadpools
19:39:39*Sentreen quit (Read error: Connection reset by peer)
19:39:47subsetparkoh, i see - sorry, i misunderstood
19:39:59subsetparkmy linter doesn't know about --threads even though my application does :)
19:40:12*Sentreen joined #nim
19:40:27yglukhovah, yeah, i've got the same issue =)
19:45:17*Sentreen quit (Ping timeout: 260 seconds)
19:46:41*Guest3761 quit (Ping timeout: 248 seconds)
19:47:10subsetparkdo i need to set locks around the threadpool when spawning?
19:47:44yglukhovnope, why?
19:48:46subsetparkbecause jester complains by default if i put a threadpool in global scope and then spawn within a handler
19:49:44yglukhoverr... that's probably because your handlers get gcunsafe.
19:50:17yglukhovif your handlers are always on main thread, just declare your global threadpool as {.threadvar.} and thats it
19:50:58subsetparkyep, roger that
19:51:37subsetparkhuh, a thread var cannot be initialized explicitly...
19:52:50yglukhovyup. create a myThreadPool(): ThreadPool proc that will init it lazily
19:53:48yglukhovor use old api (spawn, etc) that already does this under the hoos
19:53:51yglukhov*hood
19:55:07yglukhovbut those will be bound by maxMessages
19:56:06yglukhovbtw if you're spawning from jester handlers, how are you going to get the result back?
19:56:50subsetparkhttps://www.irccloud.com/pastebin/aePIpdxx/
19:57:37yglukhovno, not like that.
19:57:54subsetparkyglukhov: I get it back using the method that dom96 uses in the book for the chat app: in a while(true), if flowVar.isReady return - otherwise await sleepAsync
19:57:56yglukhovinitThreadPool should init the global var, and return it
19:58:51subsetparkah, ok- with the same isNil check?
19:59:01yglukhovyup
19:59:02FromGitter<gokr> Hmmm, is the coro module used by anyone? Any thoughts on it?
19:59:20*Trustable quit (Remote host closed the connection)
19:59:30yglukhovwhile(true) - that would surely work, but looks a bit naive.
19:59:48yglukhovi'd rather look at pipes or smth.
20:00:10subsetparkhm, any thoughts to that dom96 ?
20:01:01yglukhovi think he proposed that solution for the sake of simplicity.
20:03:20yglukhovhrm.. it just came to me that my threadpool will not work in such way (
20:03:52yglukhovi mean in `while(true)` way.
20:03:59subsetparkaw man... why not?
20:05:45yglukhovbecause old threadpools set the result of flowvars from bg threads, while my threadpool has to select on the result channel to read the results...
20:06:00yglukhovbut i think, there's a simple fix for that...
20:06:56subsetparki'm all ears
20:08:14yglukhovno, i mean, from my side. to make my threadpool look as it behaves in the old way...
20:08:35yglukhovbut you have to wait a bit...
20:08:44yglukhovan hour maybe..
20:09:07yglukhovmeanwhile you could try the pipes solution, that would definitely work and looks less hacky.
20:10:29subsetparkyou don't mean unix pipes do you?
20:11:19subsetparkor, i should say - OS pipes as opposed to some specific version of channels
20:11:29yglukhovyup, those
20:11:57*haha_ quit (Quit: haha_)
20:12:13subsetparkhuh, ok
20:15:29*enthus1a1t quit (Read error: Connection reset by peer)
20:20:57*couven92 quit (Ping timeout: 240 seconds)
20:22:28yglukhovsubsetpark: ok, done. isReady should work in your case now.
20:22:36subsetparkquick!
20:24:16yglukhov:)
20:25:06*nsf joined #nim
20:26:23subsetparkwhoa, it works!
20:28:20dom96Awesome :)
20:28:39dom96Any plans to merge this threadpool into Nim's stdlib?
20:29:05Araqyes that is indeed the plan
20:34:50FromGitter<TiberiumN> I didn't knew that Nim has almost 2,400 merged PR's, just wow
20:36:18FromGitter<TiberiumN> crystal-lang has less PR's :)
20:41:04FromGitter<TiberiumN> http://githubstats.com/nim-lang/Nim ⏎ very interesting stuff
20:41:25FromGitter<TiberiumN> (be warned - slow loading because it makes API requests to githu)
20:42:00*itseris quit (Quit: Konversation terminated!)
20:44:45FromGitter<TiberiumN> maybe this can be a bad decision for someone, but I don't want to switch to other languages until nim has a big community :) ⏎ because libraries that I would write in Nim would help someone in the future, rather than writing a library in some mainstream language which can be replaced by others
20:47:33FromGitter<TiberiumN> and I would have an opportunity to say to someone in the future: "hey, I've used Nim when it was less popular than rust"
20:48:39*itseris joined #nim
20:48:55yglukhovTiberiumN: btw, what about another habr or smth?
20:49:20FromGitter<TiberiumN> well I definitely need to write something, maybe about FFI or macros
20:50:25yglukhovsure
20:51:07FromGitter<TiberiumN> and in this schoolyear I'll need to prepare for USE ("ЕГЭ" in russian as you may know)
20:51:13*Tiberium quit (Remote host closed the connection)
20:54:25yglukhovit's been a while since i had to know what that means =)
20:56:14yglukhovso which side are you? student or teacher? =)
20:56:21*rauss quit (Quit: WeeChat 1.9)
20:56:34dom96TiberiumN: That's awesome!
20:56:38dom96(The website)
20:56:42dom96Nice to see these graphs
20:57:41yglukhovdom96: so what do you think about the pr to nimble?
20:58:30yglukhovwe've switched to the fork in our prod environment, and there were no outofmems ever since
21:02:18*onionhammer quit (Read error: Connection reset by peer)
21:02:45dom96I dislike the complexity that this adds :\
21:03:25FromGitter<TiberiumN> yglukhov: student of course
21:05:12dom96Maybe a closure iterator could be used for the recursive case?
21:05:18yglukhovTiberiumN: good job!
21:05:50*dankrad quit (Ping timeout: 240 seconds)
21:05:56yglukhovdom96: that sounds too obvious for me not to try it ;)
21:06:22dom96does that mean you haven't tried it? :P
21:06:34yglukhovi have
21:07:15dom96Araq: Is this the best we can do? https://github.com/nim-lang/nimble/pull/385
21:07:54*dankrad joined #nim
21:09:20*ofelas quit (Quit: shutdown -h now)
21:10:41*Jipok[m] joined #nim
21:15:33yglukhovAraq: it would be cool if closure iters could be recursive. why can't they now?
21:15:47dom96what error did you get?
21:16:21yglukhovsmth about recursion not supported, dont remember exact wording
21:19:02dom96hehe, apparently it's a thing https://github.com/nim-lang/Nim/issues/555
21:19:31dom96I did manage to get around it for async though it seems
21:21:43Araqhow often do I have to explain the difference between iterators/generators and coroutines here?
21:22:07Jipok[m]Excuse me, I do not understand something from the manual. Can someone say what output must be here
21:22:07Jipok[m]https://pastebin.com/TXNw9mgB
21:24:52*dom96 hides
21:25:23dom96Araq: Apparently every 4 years :P
21:25:57Araqmaybe you should write a book about it
21:26:14FromGitter<TiberiumN> Jipok - 110
21:26:20*onionhammer joined #nim
21:26:30FromGitter<TiberiumN> but template will not run iirc
21:27:00*couven92 joined #nim
21:27:18dom96Araq: Maybe /you/ should?
21:27:55*Jipok[m] sent a long message: Jipok[m]_2017-08-09_21:27:55.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/bdGmrZkwUiCJBUWEYkMupcjT>
21:28:11yglukhovhrmmm. so there is a way to call closure iter from itself...
21:29:37FromGitter<TiberiumN> ah yes
21:29:53FromGitter<TiberiumN> f() well execute two times
21:29:59FromGitter<TiberiumN> *will
21:30:10FromGitter<TiberiumN> and echo "side effect" two times
21:32:29FromGitter<TiberiumN> well, I don't know why it's executed two times :)
21:33:38Jipok[m]But why? After all, I have noSideEffect pragma
21:34:20Araqregression :P we changed the way how .noSideEffect is computed
21:34:31*PMunch quit (Quit: leaving)
21:34:32Araqused to work, report it as a bug please
21:36:07*gokr quit (Ping timeout: 260 seconds)
21:38:51*Jesin quit (Quit: Leaving)
21:40:32yglukhovhm... recursive closure iters cause invalid c code...
21:41:11*Jesin joined #nim
21:42:25Jipok[m]https://github.com/nim-lang/Nim/issues/6217
21:47:31*BitPuffin|osx quit (Ping timeout: 255 seconds)
21:50:42*mahmudov quit (Ping timeout: 260 seconds)
21:58:54FromGitter<TiberiumN> btw, is there any plans on 0.17.2? or there are issues which must be fixed before it?
21:59:27*Parashurama quit (Ping timeout: 260 seconds)
21:59:43*rauss joined #nim
22:01:14*def-pri-pub joined #nim
22:01:37dom96Araq: Shall we release this weekend?
22:01:53dom96I should have time to help
22:02:10dom96btw, you guys think choosenim is ready to be suggested as the recommended way to install Nim on nim-lang.org
22:02:10dom96?
22:02:44Jipok[m]+
22:03:59FromGitter<TiberiumN> yes, +1, but maybe some way to not-redownload devel and csources every time?
22:04:02Jipok[m]Good tool. It was already proposed to merge it with nimble?
22:04:14FromGitter<TiberiumN> why merge?
22:04:27Jipok[m]" but maybe some way to not-redownload devel and csources every time" +1
22:04:50Jipok[m]why not?
22:05:25Jipok[m]It is convenient to have one tool for updating
22:05:34FromGitter<TiberiumN> they are different tools. ⏎ maybe you mean "add it to nimble packages"?
22:05:50FromGitter<TiberiumN> then i agree
22:05:54Jipok[m]+
22:05:55Jipok[m]yes
22:06:03dom96Yeah, I don't think it should be merged into Nimble :)
22:06:08*couven92 quit (Remote host closed the connection)
22:06:22Jipok[m]sry, google translate(
22:06:39dom96We can add it to Nimble's package list though
22:06:48*onionhammer quit (Ping timeout: 260 seconds)
22:07:02FromGitter<TiberiumN> Are you from Russia, jipok?
22:07:14Jipok[m]yes
22:08:11FromGitter<TiberiumN> Well I can help you with nim if you have some simple questions (but not here, maybe in VK or gitter pm)
22:09:55*skrylar joined #nim
22:10:41FromGitter<TiberiumN> And help you translate your questions ;)
22:10:50*nhywyll quit (Quit: nhywyll)
22:11:41Jipok[m]Спасибо за предложение, но думаю, с простыми вопросами лучше разбираться самому
22:12:25skrylarnot sure if zachs around but i finally got around to fixing skeasing to use SomeReal, and pushed it to nimble
22:13:19FromGitter<TiberiumN> Ok, but if you need, you can find me here - https://vk.com/tiberium_1111
22:13:54Jipok[m]TiberiumN, я всего пару раз сюда писал. и всё было связано с багами(или тем что я считал багами). в вк не зареган, гиттер не использю. Но за предложение спасибо.
22:13:57dom96skrylar: see my comment on your PR
22:14:32skrylari haven't gotten a notification about it but i'll go manually check @dom96
22:14:44FromGitter<TiberiumN> Jipok: ok, understandable
22:15:13dom96We're past the 1k issue mark again D:
22:15:34FromGitter<TiberiumN> Yah
22:15:36FromGitter<TiberiumN> Yeah
22:16:08FromGitter<TiberiumN> I'll maybe find some already solved issues tomorrow (whose can be closed)
22:16:12skrylaroh i saw what happened
22:16:34FromGitter<TiberiumN> *which
22:16:54skrylardom96, there was one but it hadn't synced with github
22:17:02*skrylar re-synced it with github
22:17:42dom96TiberiumN: thx
22:19:13dom96skrylar: thx
22:19:36FromGitter<TiberiumN> Hmm, maybe I should write a tool in Nim which would take code from the issues and try to compile/run them :P
22:22:25skrylarmm.
22:22:31skrylarwonder if i ever put diascias code somewhere
22:22:42skrylaron the note of automatic debugging i did write a delta debugger
22:23:19skrylarthey don't work too well with significant whitespace languages unfortunately
22:23:58*Matthias247 quit (Read error: Connection reset by peer)
22:24:08skrylarif we have the parser as an api like go does then that can be worked around
22:24:57skrylarguess it could also be hacked around with some heuristics and converting indentation blocks in to indent/dedent tokens
22:25:11skrylarTiberiumN but yea those are nice for minimizing test reports
22:28:46dom96TiberiumN: Do it! :D
22:33:40*onionhammer joined #nim
22:35:56FromGitter<TiberiumN> Well, already found two solved issues (but not yet posted on second one)
22:37:43*nsf quit (Quit: WeeChat 1.9)
22:40:22dom96nice
22:42:38dom96not gonna close that one yet :)
22:44:27*willprice quit (Ping timeout: 240 seconds)
22:45:08dom96you could help though
22:53:31TheManiacHi all - I have a ~500 line script that causes the compiler to crash when I uncomment 4 lines (trying to make a type a variant type). Sadly I've failed to create a minimal example. Is it worth opening an issue, or is that going to be too hard to chase down?
22:54:11dom96TheManiac: It's always worth creating an issue. Even if the script is 100k lines.
23:04:30TheManiachttps://github.com/nim-lang/Nim/issues/6220 <-- pity, as I'd hoped to first my code to the world when it worked, not when it caused a compiler crash :(
23:07:59TheManiacs/first my/first reveal my/
23:08:08skrylarWell ideally you would use a minimizer first
23:08:43skrylarBut as I said earlier, nim's whitespace magic borks those so.
23:08:50*skrylar shrugs
23:09:38dom96TheManiac: wow, a segfault
23:09:59TheManiac- yeah
23:10:40dom96Oh, okay, so the reason is because your `Node` type is an `object`
23:10:52TheManiacI've tried to use inheritance rather than variant types, but that doesn't work either, though I'm less convinced that it's a compiler error
23:10:56dom96simply change to `ref object`
23:11:17TheManiacok, but why?
23:12:22TheManiacconfirm - that adding `ref` stops the compiler crashing, though it changes the semantics of the program
23:12:59dom96because you cannot have a recursive value type
23:13:35TheManiacthings I did not know #507
23:14:50dom96:)
23:15:34TheManiachmm - manual says I can't have a recursive tuple, but I don't think it says I can't have a recursive value type
23:21:23TheManiacappreciate the assist - was about to go all sad  as I got completely stumped by a nimbug :(
23:21:46TheManiacNow I can go back to writing my own bugs
23:22:56*yglukhov quit (Remote host closed the connection)
23:23:27TheManiacIs that because in the value type it has to reserve space for itself (in the recursive field), which has to reserve enough space to store itself... etc
23:24:12dom96yep
23:24:36dom96whereas for a reference it's just reserving space for a pointer
23:25:22TheManiacIf you want a really unintelligible error message, try putting the ref on the pointer to the recursive field...
23:25:34FromGitter<krux02> TheManiac you cannot acces global variables from macros,because macros are evaluated at compile time and global variables technically only exist at runtime
23:25:57FromGitter<krux02> but you can acces global variables when they are in a static block
23:26:12FromGitter<krux02> but then they are only existent during compilation, but not during runtime
23:26:23TheManiacyou've lost me. The rest of the code works fine
23:26:51TheManiacI don't think this is a problem with global variables, unless I'm missing something...
23:27:14FromGitter<TiberiumN> @krux02 he didn't want to link this nim issue :)
23:28:01FromGitter<krux02> the issue is see above is not an issue to me it is just how things should behave
23:29:10FromGitter<TiberiumN> He didn't mean to link this issue, he doesn't understand what are you talking about :)
23:29:38TheManiacAh yes, that wasn't intended to be a link :)
23:30:31FromGitter<krux02> well then, ok
23:34:30FromGitter<zacharycarter> o/
23:35:22dom96'night guys!
23:36:34FromGitter<zacharycarter> night dom
23:37:47gangstacatI know it's certainly stupid but if you save your file as true.nim and try to use the true boolean, the compiler will say "Error: ambiguous identifier: 'true' --use unknown.true or bool.true"
23:37:55gangstacatbut bool.true is wrong, though system.true works
23:51:22*smt_ joined #nim