<< 28-04-2016 >>
00:10:00*brson quit (Quit: leaving)
00:12:52*brson joined #nim
00:46:33*brson quit (Ping timeout: 240 seconds)
00:48:05*brson joined #nim
00:55:30*libman quit (Remote host closed the connection)
01:02:12*yglukhov joined #nim
01:06:24*yglukhov quit (Ping timeout: 244 seconds)
01:26:33*castlelore quit (Quit: WeeChat 1.4)
01:29:16*brson quit (Ping timeout: 252 seconds)
01:32:08*desophos quit (Remote host closed the connection)
01:32:50*desophos joined #nim
01:36:53*desophos quit (Ping timeout: 244 seconds)
01:55:08*bozaloshtsh joined #nim
02:18:14*desophos joined #nim
02:22:49*fredrik92 quit (Read error: Connection reset by peer)
02:33:55*kulelu88 quit (Quit: Leaving)
02:39:04*yglukhov joined #nim
02:43:31*yglukhov quit (Ping timeout: 250 seconds)
03:03:35*yglukhov joined #nim
03:08:47*yglukhov quit (Ping timeout: 276 seconds)
03:11:10*Varriount quit (Disconnected by services)
03:11:10*Varriount_ joined #nim
03:39:40*yglukhov joined #nim
03:44:32*yglukhov quit (Ping timeout: 276 seconds)
04:04:05*yglukhov joined #nim
04:09:03*yglukhov quit (Ping timeout: 276 seconds)
04:12:57*kingofoz quit (Ping timeout: 268 seconds)
04:13:42*kingofoz joined #nim
04:15:20*roarde joined #nim
04:18:03*roarde left #nim (#nim)
04:27:00*brson joined #nim
04:28:43*brson quit (Client Quit)
04:40:09*yglukhov joined #nim
04:44:57*yglukhov quit (Ping timeout: 260 seconds)
04:52:19*u0_a92 quit (Ping timeout: 260 seconds)
04:53:50*u0_a92 joined #nim
05:04:15*yglukhov joined #nim
05:09:15u0_a92exit
05:09:19*u0_a92 quit (Quit: leaving)
05:09:30*yglukhov quit (Ping timeout: 276 seconds)
05:26:32*s4 joined #nim
05:56:49*desophos quit (Read error: Connection reset by peer)
06:21:03*nsf quit (Ping timeout: 250 seconds)
06:23:47*gunn_ quit (Quit: My Mac has gone to sleep. ZZZzzz…)
06:30:18*vendethiel- quit (Ping timeout: 246 seconds)
06:32:45*arnetheduck quit (Ping timeout: 250 seconds)
06:44:51*space-wizard quit (Quit: My Mac has gone to sleep. ZZZzzz…)
06:51:33*Varriount_ quit (Ping timeout: 240 seconds)
06:52:00*gokr joined #nim
06:54:04*Varriount joined #nim
07:14:21*castlelore joined #nim
07:26:02*yglukhov joined #nim
07:30:33*yglukhov quit (Ping timeout: 240 seconds)
07:35:17*castlelore quit (Ping timeout: 276 seconds)
07:47:30*dorei joined #nim
07:49:36*castlelore joined #nim
08:07:43*yglukhov joined #nim
08:12:09*yglukhov quit (Ping timeout: 246 seconds)
08:20:03*Arrrr joined #nim
08:20:03*Arrrr quit (Changing host)
08:20:03*Arrrr joined #nim
08:34:41*Trustable joined #nim
08:35:42*yglukhov joined #nim
08:40:24*yglukhov quit (Ping timeout: 260 seconds)
08:55:42*yglukhov joined #nim
09:00:16*Demon_Fox quit (Quit: Leaving)
09:00:54*yglukhov quit (Ping timeout: 276 seconds)
09:15:50*yglukhov joined #nim
09:16:50*McSpiros joined #nim
09:20:35*yglukhov quit (Ping timeout: 276 seconds)
09:24:56*elrood joined #nim
09:35:58*yglukhov joined #nim
09:40:25*yglukhov quit (Ping timeout: 252 seconds)
09:56:11*yglukhov joined #nim
10:00:45*yglukhov quit (Ping timeout: 268 seconds)
10:03:13*Arrrr quit (Ping timeout: 268 seconds)
10:13:22*Amun_Ra quit (Ping timeout: 250 seconds)
10:15:05*Amun_Ra joined #nim
10:16:13*yglukhov joined #nim
10:19:57*Arrrr joined #nim
10:19:57*Arrrr quit (Changing host)
10:19:57*Arrrr joined #nim
10:20:47*yglukhov quit (Ping timeout: 244 seconds)
10:29:41dom96Maybe it's time we get rid of strong spaces from the manual? https://www.reddit.com/r/programming/comments/4gnehl/pied_piper_compression_code_shown_on_silicon/d2j5khk
10:34:45ArrrrNo wonder the person that came with that comment is a rustacian
10:36:26*yglukhov joined #nim
10:37:23elroodmight be a good idea. it's a constant source of ridicule
10:38:49dom96Indeed.
10:39:25dom96I'm writing a reply which will hopefully alleviate some people's first reactions.
10:40:40*yglukhov quit (Ping timeout: 250 seconds)
10:51:40*arnetheduck joined #nim
10:56:33*yglukhov joined #nim
11:00:59*yglukhov quit (Ping timeout: 250 seconds)
11:01:24nivthat whitespace precedence thing is really weird to look at
11:09:00federico3yep, please remove that
11:09:07*yglukhov joined #nim
11:14:02*yglukhov quit (Ping timeout: 260 seconds)
11:16:05ArrrrI don't see why is that so bad. Not that i use it, but won't affect me anyway
11:17:33elroodthe thing is, it's not that bad to actual or former users of the language. most are just surprised when they notice it's there, while it didn't affect them at all
11:19:07elroodon the other hand, to anybody considering nim as a new language it's like waving a red flag, saying the design decisions the language is based on might not be completely sane
11:19:30elroodfor a young language it's somewhat of the equivalent of shooting yourself in your little toe
11:19:31*enthus1ast joined #nim
11:20:51nivi think it looks adorable once you get used to it, but it's a really ugly thing to mess with established foundations
11:21:14nivnot worth the mental overhead, imo, since you're already used to parsing parens
11:23:12dom96well I replied
11:23:27ArrrrTHe comments there doesn't provide any insight of why is bad. The first poster said that the feature made nim, among others things, great (which i'm sure he actually thought the opposite), and the one that responded complained on the contributors, but nothing else.
11:26:06nivdom96: dont take it too hard. the internet is vicious and always paints everything in the darkest picture for extra drama points
11:26:21nivexperimental, random features or just incomplete stuff, bugs - it's all assumed to be malicious first
11:28:22federico3Arrrr: insight of why is bad? Strong spaces are difficult to read, opening the door to a lot of bugs
11:28:51flyxI hear there are people who write code with non-monospace fonts ^^
11:29:12federico3right, and for them it would be a mess
11:29:17*yglukhov joined #nim
11:29:33nivflyx: yes, there are many weird people in the world :)
11:29:35flyxbut it has been a long time since I saw that
11:29:46flyxit was in RealBasic afair
11:29:50nivthere are also people writing code without syntax highlighting
11:29:59nivor without indentation
11:30:01ArrrrYes, and you could argue that allowing unsafe features leads to bugs and makes code harder to read. Should nim ban those?
11:30:04dom96niv: Don't worry, i'm not. I like to think that even though Nim is painted in a bad light there, it's better than not being mentioned at all :)
11:30:29ArrrrOn the bright side, there is no such thing as bad publicity.
11:30:38dom96You could argue that you can configure your editor to show spaces as some special character
11:30:44nivpretty much. and its just one small feature. anyone interested will check it out regardless
11:30:47dom96Many people have their editor configured to do that
11:30:54nivyes, they're weird too
11:31:00cheatfateAraq_, hows is you work with GC? because current GC is annoying with deep recursions on linked lists
11:31:03nivCRAZY, I say
11:31:21elroodwell, even without drama points strong spaces are just not a good idea. they counteract everything one learned in basic maths, violate the principle of least surprise, open up a pandora's box for unexpected bugs with no good reason..
11:32:01ArrrrBut by that argument why should stick to c syntax
11:32:33nivits more than language syntax, its basic math conventions. bad thing to mess with those. imo.
11:32:43dom96To be fair, there is still A LOT of people who say that significant whitespace at all is a bad idea
11:32:47dom96and diss Python because of it
11:33:02dom96I can only imagine what people said when Python was first announced
11:33:10nivdom96: well whitespace is taste so that can be argued :) i personally used to hate it, but since using nim i wish other languages would do it too
11:33:19ArrrrYeah, once i thought python syntax was bad.
11:33:41nivi figure it's all just a case of getting used to things. adapting to new things is what humans are good at so perception skews a lot after a while
11:33:45nivand it doesnt matter in the end
11:33:46dom96Indeed. So imagine if you first learned programming with Nim (which had strong spaces by default).
11:33:52*yglukhov quit (Ping timeout: 260 seconds)
11:34:06dom96It would likely seem natural to you.
11:34:29nivyeeah, but i still think the point can be made that it's a more invasive change than indentation, especially if you have a math background (i.e. went to school :D)
11:34:33dom96I think Araq deserves props for trying something new
11:34:33federico3Python wasn't the first language with significant whitespace *for indentation*
11:34:36dom96i.e. actually innovating
11:34:43ArrrrYes, going against basic math conventions is, after all, going agains conventions.
11:35:11nivoh im not bashing it. i still think its cute. but i would never use it, especially if i want to bring in new people to the project that havent had worked with nim before
11:35:32dom96While it's innovative, I agree that I don't think it's the right way to go.
11:35:47nivgood chat, lets do that again soon
11:35:53dom96s/ that/,/
11:36:38ArrrrMeh, i dont agree. If increasing your popularity was the only or first concern, again, we would be using ancient syntax by now.
11:37:11ArrrrThere is always a new language that do things different. Some of them may be ugly and die in hell, but maybe one makes popular a new concept
11:37:28ArrrrBut at first, we dont know. Everything new will cause at first rejection
11:37:50elroodlet's politely disagree here. python's indentation is an entirely different matter, and nim's syntax for the most part is pleasant to read and work with. alienating every mathematicially affined person on the planet is playing in another league
11:38:18dom96To be fair, most of us (including myself) are just predicting the problems with strong spaces.
11:38:26dom96We haven't actually tried it yet
11:38:40elroodbecause nobody in their right state of mind would? ;)
11:39:20ArrrrBut that may be true when programming languages were used mainly but mathematicians.
11:39:29Arrrr*have been
11:39:40Araq_strong spaces again?
11:39:54Araq_should I remove #! strongSpaces to make this discussion stop?
11:40:02Araq_any new insights?
11:40:04federico3yes please :)
11:40:30Araq_#! strongSpaces right now are on par with trigraphs in C/C++.
11:40:50Araq_technically they exist, I know no code base that uses them.
11:41:12Araq_can I now spread FUD about C/C++ never going mainstream anytime soon?
11:41:20nivwhat's C++?
11:41:41nivnever heard of it. must be esoteric claptrap
11:41:52Xeniv: something some person made to justify their employment a long time ago and has roped people into using since
11:42:09nivhaha. yeah, there's a great many interpretations on it's purpose :D
11:42:49elroodto be frank, it's less about this discussion, we here probably don't mind all that badly. but if you want to help nim's adoption along it would perhaps be a good idea to get rid of strong spaces once and for all
11:43:04Xeya know
11:43:07nivyes, kill it before anyone actually starts using it :D
11:43:12Xei'll open a github issue
11:44:14ArrrrYou know what comes next
11:44:35dom96Style insensitivity? :P
11:44:45nivprogrammer insensitivity
11:46:04dom96In other news, it looks like the people want a Nim Slack https://twitter.com/nim_lang/status/725289411412414465
11:46:44nivi dont like slack :( its slow and clunky and always goes through a web interface
11:47:07Xefuck slack
11:47:34dom96What if I create a IRC #nim <-> Slack #nim bridge?
11:47:48nivhttps://get.slack.help/hc/en-us/articles/201727913-Connecting-to-Slack-over-IRC-and-XMPP
11:47:50Xewe already have gitter
11:47:53federico3with a bridge, ok
11:48:19flyxum, how can one view the results of this poll?
11:48:20nivpeople could still connect with their irc clients if they wanted to. but i never tried it
11:48:21dom96Xe: Yeah, but I'm already running Slack anyway.
11:48:28dom96flyx: need to vote on it I guess
11:48:32dom96I'll make a screenshot
11:48:42Xedom96: slack app eats up gigs of ram for me
11:48:46flyxdom96: I'd need a twitter account for that
11:48:52dom96Xe: same heh
11:49:11Araq_removing strong spaces altogether could be a strategic mistake though. Might be wiser to leave it in so that people have something easy and obvious to work off.
11:49:12nivi dont like the slack native app either. its just a web wrapper loading a full instance of chrome
11:49:46dom96flyx: http://i.imgur.com/Tw0Dd9z.png
11:50:01flyxXe: from how it looks I guess it could be made with electron, which would explain why it eats RAM
11:50:13flyxdom96: thanks
11:50:15Araq_dom96: yeah, IRC #nim <-> Slack #nim bridge!!!!
11:50:26Araq_isn't that even something for your book?
11:50:43nivbonus points for writing it in nim
11:51:00dom96Araq_: Writing a bridge in Nim? lol
11:51:11flyxah yes, they even link it at electron's website
11:51:13Araq_sure, what else?
11:51:14nivyes, NIH it
11:51:19nivignore all the existing ones :D
11:51:26*BitPuffin joined #nim
11:51:34Xedom96: Why not Matrix?
11:51:37dom96Araq_: Sure, it's not like I don't have enough projects to maintain :P
11:51:58dom96Xe: The main reason for Slack is because of how many people are already using it, and therefore have the client installed.
11:52:03elrooddom96, your poll is flawed, it only counts twitter users :P
11:52:18dom96elrood: true, wanna implement polling functionality in NimBot? ;)
11:52:22Xedom96: I don't approve of locking Nim into a walled chat garden
11:52:37elroodmicro$oft not trusting in slack enough to acquire the company is probably a strong point, though ;)
11:53:15dom96Xe: It's just an alternative though, if it's bridged you'll be able to use either IRC or Slack.
11:53:54elrooddom96, you don't really want to give me commit access to nimbot, i might use it ;)
11:54:35*McSpiros quit (Quit: Page closed)
11:55:40dom96elrood: not quite sure what you mean
11:56:02dom96Araq_: I think it's wiser to remove strong spaces.
11:57:03*BitPuffin quit (Ping timeout: 240 seconds)
11:58:56*BitPuffin joined #nim
11:59:29*yglukhov joined #nim
12:02:33*yglukhov quit (Remote host closed the connection)
12:04:26*yglukhov joined #nim
12:11:05dom96wow, mikra just contributed $200 https://salt.bountysource.com/teams/nim
12:15:01Arrrrthank you mikra
12:15:31*GangstaCat quit (Ping timeout: 250 seconds)
12:15:41dom96^^ :)
12:18:03dom96We're now 50% of the way towards our "One day per week" goal :D
12:19:33dom96It's really awesome to see that people are willing to part with their hard earned cash to help Nim.
12:22:29flyxI wonder why Crystal lang has so many backers. I had a look at it once, but I didn't see any unique features
12:22:38nivbecause ruby
12:22:55flyxI equally wonder about ruby ^^
12:23:37dom96I think many fans of Ruby see it as a compiled Ruby.
12:24:04ArrrrWe could ask BlaXpirit
12:24:13dom96There are a occasional people in #crystal-lang asking why something they do in Ruby doesn't work in Crystal.
12:24:27nivruby is etremely productive. rails is mindblowing for getting stuff done in as little time as possible
12:24:30nivthe lure is there
12:25:09dom96Another interesting thing to note is that they get $600 off some Anonymous person.
12:26:11dom96so that's already almost all of what we got so far.
12:26:50Araq_cheatfate: what do you mean with deep recursions? that's been fixed since quite some time on devel. I hope.
12:26:54*BitPuffin quit (Ping timeout: 268 seconds)
12:27:05nivi tried it briefly and it worked well but nim just feels .. more mature and more useful. dunno. purely subjective.
12:27:21dom96btw I will likely post a large portion of that money as a bounty on various issues, so if you guys have any suggestions for issues which deserve a bounty feel free to let me know :)
12:27:46nivasyncdispatch + threads and all the niggles with templates/try/etc :D
12:28:26nivi'd invest the money towards things that block 1.0. real bugs and issues that are unexpected but people run into and then dont know what to do
12:28:30federico3meanwhile, $megaco invest millions on the JVM
12:28:35*novavis joined #nim
12:28:53*GangstaCat joined #nim
12:29:50dom96federico3: and 95% of that is spent on employees who spend 60% of their working time on Reddit/YouTube (probably).
12:30:58dom96niv: that sounds like a good idea. But I would also like to put some of it towards "easy" issues to encourage newcomers to contribute.
12:31:45nivfair enough. hard to balance though unless you want to risk it that people just do small PRs to grab those 5 dollars and then never reappear
12:32:28yglukhovdom96: what do you think of https://github.com/nim-lang/Nim/pull/4122 ?
12:32:36flyxJVM is big in megacorps because they long ago failed to hire capable admins. so they invented JavaEE and application servers so that the developers can do the admin job because it's part of their product
12:32:51dom96yglukhov: oh thanks for reminding me. In like it in general :)
12:32:58nivflyx: isnt that what's called devops nowadays?
12:33:40dom96s/In/I/
12:34:31yglukhovdom96, ok, waiting for your comments/accept then =)
12:34:50flyxniv: devops is mostly the movement to get developers to learn real admin stuff instead of fucking with a loosy application server
12:34:55dom96Gah, need to run to Tesco first. Will review afterwards!
12:34:58dom96bbl
12:35:04federico3flyx: that and much more
12:35:07yglukhovok
12:37:17cheatfateAraq_, please take look on comment for https://gist.github.com/cheatfate/fa97356b397df46730ed6e20458f903c
12:37:32cheatfateAraq_, its about recursion in GC
12:38:52niv--gc:workdamnit
12:40:30Araq_cheatfate: linked list with 50_000_000 elements? ... ok... well with gc:v2 it will be gone.
12:41:33*novavis quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
12:41:55cheatfateAraq_, its not a 50_000_000 linked nodes... its just 781250 linked nodes
12:42:18*novavis joined #nim
12:42:28Araq_ouch.
12:43:08Araq_well I tried to fix it once but the algorithm is infested to the core and so it only produced more crashes
12:43:12nivAraq_: do you have any idea what this could be? https://gist.github.com/niv/abdca03f7954880171e2db9f06e27d2c it only happened once, at random. the code where it triggered was a weird place, creating a new tuple i think
12:44:07nivthe very same code ran just fine after that, for many many test runs
12:44:14Araq_thinking about it. I can fix it tonight, I hope.
12:44:45cheatfateyglukhov, usage of your timers as usage of sleepAsync() slowdown whole asyncdispatch... That is the problem
12:45:32Araq_niv: yeah I have some ideas.
12:45:37cheatfateyglukhov, its like you can process 150,000 requests per second without timeouts and only 10,000 requests with timeout
12:46:03nivAraq_: okay, just wanted to hand it over in case you can make use of it. looked like a GC bug to me what what do i know ..
12:46:25nivexecution context was a while true: loop polling events off asyncdispatch, creating a tuple for each event
12:49:05Araq_cheatfate: is that async's very poor timers implementation?
12:49:11Araq_or something else?
12:50:35cheatfateAraq_, its because we need to use hardware timers, RegisterWaitForSingleObject for windows, kqueue - EVFILT_ITMER for bsd/macos, timerfd - for linux...
12:52:11cheatfateAraq_, even usage of epochTime() slowdown the whole polling process
12:52:53yglukhovcheatfate: i call to epochTime() only if there are active timers present.
12:53:51yglukhovcheatfate: is there a better/faster function to get process time?
12:55:53nivepochtime is using gettimeofday underneath?
12:56:32cheatfateyglukhov, problem is not in epochTime() problem is handling timers in such way...
12:57:24yglukhovcheatfate: then i don't get your point. from such perspective my solution is no worse than it was
12:59:36cheatfateyglukhov, last 2 monthes i'm working on the hardware implementation of timers and another staff
12:59:37cheatfatehttps://gist.github.com/cheatfate/21799cf43e3af13d275dc1863d43b68e
12:59:48cheatfatethis is windows version of what i'm proposing to use
13:01:09cheatfateand this variant gives only 2-5% slowdown
13:06:22cheatfatei want to add to asyncdispatch - timers, processes, signals, user events and maybe in future filesystem events
13:06:48nivinotify support would be awesome
13:08:39cheatfateniv, its a problem just because all OS has very different mechanisms of filesystem notifications... (inotify - linux, bsd/macos - kqueue, windows - ReadDirectoryChangesW)
13:08:56nivyeah. i was just giving it as an example :)
13:09:02federico3niv: https://github.com/nim-lang/Nim/blob/devel/lib/pure/fsmonitor.nim
13:09:11Araq_yglukhov: the JS backend supports .varargs, right?
13:09:56cheatfatefederico3, this is only linux implementation
13:11:11federico3yep, but it's a beginning
13:14:14cheatfatefederico3, its even not starting... :) you need to check functionality of kqueue
13:15:27yglukhovAraq_: i think it should...
13:16:12cheatfateAraq_, do i need fill an issue on this bug to remind you?
13:18:05Araq_cheatfate: no.
13:21:22Araq_yglukhov: yeah never mind, works.
13:22:26*desophos joined #nim
13:26:33*desophos quit (Ping timeout: 240 seconds)
13:28:35*desophos joined #nim
13:33:14*desophos quit (Ping timeout: 260 seconds)
13:43:01cheatfateAraq_, i want to make PR with queue again but i dont want to replace your queue, just because it is not faster than yours on small amounts of memory (depends on arch and compiler)
13:43:25*s4 quit (Quit: Konversation terminated!)
13:43:46cheatfateAraq_, but it threading safe so we can use it in asyncdispatch
13:44:34Araq_cheatfate: idea: use the new queue privately in asyncdispatch not exposing it for now
13:47:57cheatfateAraq_, looks like you and dom96 not really wants to update asyncdispatch, or maybe you want to switch to reactor?
13:48:30Araq_what makes you say this?
13:49:00Araq_we long for your patches but it needs to be reasonably clean and stable.
13:50:26Araq_or let me put it this way: I know you're working on it and so I work on something else. ;-)
13:51:52reactormonkWhat's the proper way to do https://gist.github.com/reactormonk/cab00e6420d9f0074f39cd67bf908067 ?
13:53:00dom96cheatfate: yglukhov's patch is good enough for now
13:53:12dom96if you can implement hardware timers in a nice way then I will merge your changes
13:53:29nivdom96: have you checked out reactor.nim?
13:53:41dom96niv: not in much detail
13:54:04nivit's using libuv instead of kqueue/polling and apparently supports threadpools
13:54:26dom96pretty sure zielmicha said that it didn't support threadpools yet
13:54:37nivthe documentation claims otherwise
13:54:47nivhttps://networkos.net/nim/reactor.nim/doc/
13:56:26cheatfateniv, but libuv using kqueue/polling :)
13:56:41nivokay, fine
13:57:32dom96niv: you can easily spawn procedures and use asyncdispatch at the same time
13:58:37*enthus1ast1 joined #nim
13:59:05nivdom96: huh.
13:59:26Araq_proc zero[S](T: typedesc[seq]): S = @[]
13:59:29Araq_reactormonk:
13:59:52dom96niv: In fact, give me a second and I'll show you an example from my book.
14:00:01*enthus1ast quit (Ping timeout: 268 seconds)
14:00:03*dom96 needs to finally push some examples to github
14:00:30nivdom96: i never realised. i thought native threading and asyncdispatch was completely incompatible.
14:01:58cheatfateniv, it will be a problem if you start `await`ing in other threads...
14:02:35nivcheatfate: i figured as much, but i can still do cpu intensive stuff on different threads and await for those then?
14:02:56dom96yep, you can't run the event loop in other threads.
14:03:09dom96Also, 'await' doesn't support FlowVar[T]
14:03:20nivi need to read up on threading in nim
14:03:27dom96(It really should)
14:03:42dom96But Araq had his reasons for making it incompatible with Future[T] (even though they are basically the same things)
14:03:53reactormonkAraq_, do I need to change the multiply as well? https://gist.github.com/2f617e2a7fe27851ff8cea8e5da53872 gives me monoid.nim(17, 14) Error: type mismatch: got (int literal(3), int literal(3))
14:03:56nivthreadpool exports it's own await thing
14:05:05dom96niv: yeah, but it blocks the current thread
14:05:20nivdom96: much like pthread_join(), right?
14:05:41nivi'll go RTFM
14:05:52dom96kinda yes
14:06:16cheatfateAraq_, the problem is that you never accept PR which modifies more than 1 file... it would be long discussion after you will want to split it... but my way to split PRs on smaller chunks also not working... so maybe it would be better for me to make some kind of reactor...
14:10:39nivdom96: does it make sense to have one poll asyncdispatch thing per thread?
14:15:24dom96niv: https://github.com/dom96/nim-in-action-code/blob/master/Chapter3/ChatApp/src/client.nim
14:15:46dom96niv: nope, that is precisely what won't work
14:16:35*dorei quit (Quit: Page closed)
14:18:33*Varriount quit (Ping timeout: 240 seconds)
14:37:09Araq_cheatfate: not true, in fact IMHO I'm very forgiving when it comes to PRs. But as long as a PR is like "ok, only works on Windows for now" or "ok, but breaks existing code" it's hard to accept it.
14:38:15Araq_and breaking existing code is acceptable if there is a clear migration path and it's caught at compile-time.
14:39:57*Trustable quit (Remote host closed the connection)
14:41:12Araq_in fact, once a PR arrives that's like "ok, I started from scratch, it's much faster than the original, the API is incompatible but as flexible and it supports more features" you can count on me pushing it forward (=fighting with dom96? ;-)
14:42:37*Trustable joined #nim
14:44:15nivdom96: thanks for the example!
14:45:21cheatfateAraq_, ok, thanks, then i will continue
14:47:54*Trustable quit (Remote host closed the connection)
14:49:20*Trustable joined #nim
14:56:31dom96I don't see any reason why you would need to change the API.
14:56:44Araq_ha ha ha. good one, dom96.
14:57:08dom96?
14:58:41cheatfatedom96, is your question to me?
14:58:58dom96No, my question is to Araq.
15:00:06Araq_dom96: sockets are not streams, threadpools don't support async await, SSL support is tedious, etc etc. There is a reason for everything of course, but these are all reasons that warrant changing the API.
15:00:37Araq_s/warrant/justify
15:04:01cheatfatedom96, your declaration of epoll in posix/epoll.nim is made only for usage in selectors.nim... if i want to use 64bit value i need to redeclare all epoll functions/structures...
15:04:47cheatfateand i know why u made it in such way, just because you dont want to resolve "nim union bug" :)
15:05:36cheatfatebut you can at least declare it as 64bit value
15:05:52*Deavmi_mobile joined #nim
15:05:55Deavmi_mobileello.all
15:10:53dom96cheatfate: it is, yes.
15:11:30*Pisuke is now known as MyMind
15:12:30dom96Araq_: Threadpools + async are a problem, but you don't even know how to get it to work.
15:12:38dom96Even if you were to write it from scratch
15:12:50Araq_I'm not blaming you at all.
15:12:59dom96The rest is just silly. Sockets are indeed not streams, why would they be?
15:13:14dom96As for SSL, I have no idea in what way it is tedious?
15:13:19Araq_dunno, seems like they could be
15:13:58dom96then you can easily write a stream abstraction which makes use of the current API
15:15:41Araq_actually I can't for async sockets because the streams API is wrong.
15:15:51*deavmi_mobile2 joined #nim
15:16:05Araq_streams: proc read(buffer...) # after call buffer is filled.
15:16:20Araq_async: proc read(oncompletion: proc(data))
15:17:08dom96indeed
15:19:40dom96Araq_: Are you happy with yglukhov's heapqueue implementation? https://github.com/nim-lang/Nim/pull/4122
15:20:06Araq_SSL is tedious because of the dependency but yeah I suppose you're right and it's not an API problem
15:21:09dom96yep, so we're left with thread pools :)
15:21:34dom96And I still have no idea how they should work really.
15:23:16cheatfatedom96, they must work like poll() in every thread...
15:23:53dom96right, but then how do you run iterators in different threads?
15:24:00dom96that is the problem IMO
15:24:16Araq_dom96: I'm sorry for the asshole laughing but it's not inconceivable somebody comes up with a better API for async, is it?
15:25:05dom96Araq_: sure, it's not. But I don't want people coming up with a new API just because they don't feel like understanding the old one.
15:25:56dom96If there is a valid reason for API breakage then so be it
15:26:11dom96But if it's just a case of "Well, I just decided to rewrite it"
15:26:17dom96then I will not be happy
15:27:51dom96And yes, the laughing wasn't nice.
15:28:45dom96Araq_: Now, are you happy with heapqueue being in the stdlib? https://github.com/nim-lang/Nim/pull/4122/files
15:29:59*enthus1ast joined #nim
15:31:52cheatfatedom96, api breakage is the only way to improve asyncdispatch
15:32:14*enthus1ast1 quit (Ping timeout: 260 seconds)
15:32:16*brson joined #nim
15:32:36dom96cheatfate: why?
15:32:40cheatfatedom96, for example sleepAsync()
15:33:37cheatfatei dont know what are the goals of this function... but one of them is for implementing timeouts
15:33:48Araq_dom96: yup, generic collections in general cause no problem to be in the stdlib.
15:33:57cheatfatein `future or sleepAsync()`
15:34:14dom96yes, what is the problem with this function?
15:34:54cheatfatecurrently nobody cares about sleepAsync() future resources if real future completed first...
15:35:23cheatfatebut if i implement sleepAsync() with more system specific staff, i need to free system resources...
15:35:40cheatfateeven if it not used any more
15:35:50cheatfatenot used = not needed
15:37:01cheatfateso i need to implement something like this https://gist.github.com/cheatfate/21799cf43e3af13d275dc1863d43b68e
15:37:17cheatfateproc withTimeout*[T](fut: Future[T], timeout: int): Future[void] =
15:37:42cheatfateso i can free system resources even if `fut` completed first
15:38:47dom96Ahh, so the problem is that with `future or sleepAsync()` if `sleepAsync` completes first, then there is no way to cancel `future`?
15:40:04cheatfateif `future` completes first, there is no way to free resources allocated by `sleepAsync()` too
15:41:40cheatfateanother problem is a `kqueue` selectors problem, just because selectors.nim support only EVFILT_READ, EVFILT_WRITE, EVFILT_ERROR... so there no way to add os specific timers/signals/processes
15:41:50dom96Technically, `or` could free the resources I think
15:42:18dom96if future.finished: free sleepAsync(); result.complete
15:42:26dom96if sleepAsync().finished: free future;
15:42:29dom96result.complete
15:42:35dom96(Pseudo-code)
15:42:50dom96Don't you think that would work?
15:42:58cheatfatebut currently we dont have `free`
15:43:00dom96Araq_: Cool. Merging.
15:43:13dom96cheatfate: indeed. And I have been saying for a long time that it is on my todo list
15:43:21dom96cheatfate: It's an API addition
15:43:31dom96it doesn't need any API modifications
15:43:46dom96Araq_: Oh, I see you made comments.
15:44:16Araq_dom96: doesn't matter, we can change it later
15:44:52*gokr quit (Ping timeout: 250 seconds)
15:45:17dom96Araq_: Would be nice to get a test for this timer stuff too
15:45:25dom96but it's not fair to get yglukhov to make that :)
15:45:34dom96Merged
15:46:18cheatfatedom96, what about `kqueue` selectors problem?
15:46:51dom96cheatfate: I didn't personally write `kqueue` so I'm not sure
15:47:11dom96cheatfate: But selector's API isn't as important to keep the same as asyncdispatcher's
15:48:11cheatfatedom96, ok let me explain another one problem
15:48:14yglukhovdom96, Araq_, thanks!
15:49:44cheatfatedom96, for example i want to adopt postgresql/mysql or any other libraries to be async
15:50:09cheatfatedom96, some libraries like postgresql i can obtain os specific socket/file handle
15:50:35cheatfatedom96, but i can't use it in windows just because we using iocp staff for windows only
15:51:08cheatfatecheatfate, so its possible to adopt postgresql to linux/bsd/macos easily but not windows...
15:51:35dom96That's a tough one because I don't know how those libraries work under the hood
15:51:39dom96so I can't advise you here
15:52:03dom96Go ahead and show me what you would like to change in the API to support them and then I will likely be able to give you a better answer
15:52:05cheatfatedom96, libraries doesnt matter, we need to have posibility to extend asyncdispatch
15:52:36cheatfatelike i need to add library specific poller()
15:53:28dom96I'm sure that can be an additional feature which can be added without disrupting the current API
15:54:27*libman joined #nim
15:55:11cheatfatei'm just trying to say, that current api is not very flexible, current asyncdispatch is looks like Proof Of Concept not like production stable API
15:56:22cheatfateI can't even write windows benchmarking tool just because asyncdispatch connect() uses strings as address, and perform dns resolution at every call
15:57:41dom96Fair enough. All I'm trying to say is that you CAN make it more flexible by adding things to the current API
15:57:52dom96but without changing what is already there
15:59:43*SoulMelody joined #nim
15:59:54Araq_dom96: yeah but it's also a question of "how much does it break". for example the 'or sleepAsync()' always seemed like an overly clever idea. the underlying OS stuff tends to supports timeouts but how can you pass this information down to it when it's attached via 'or'?
16:01:01dom96Araq_: Okay. Again, I'm not sure how timeouts/timers (which is it?) work in epoll/kqueue/iocp.
16:01:24dom96I imagine that you tell it "Please notify me after x ms"
16:01:32dom96if that is the case then sleepAsync will be able to easily adopt it
16:02:02dom96sleepAsync(100) -> Please notify me after 100 ms -> sleepAsyncFuture.complete() # boom
16:02:47dom96if however, you need to pass it to the socket function, for example: recv(buffer, 1000, timeout = 100)
16:02:53dom96then it's an issue
16:03:12dom96but surely, epoll/kqueue/iocp support timers
16:03:39dom96indeed, it looks like it: http://man7.org/linux/man-pages/man2/timerfd_create.2.html
16:04:03*enthus1ast quit (Ping timeout: 276 seconds)
16:04:46*SoulMelody quit (Quit: Manjaro-KDE user leaving!)
16:06:16cheatfatesleepAsync() was just as example, the main api breakage can cause to make asyncdispatch extendable... to let people easily adopt other libraries, like postgres, mysql, mongo or any other staff
16:07:11dom96I think I refuted that though.
16:07:26cheatfatei know nobody likes to write any documentation, or RFC
16:08:00cheatfatebut it looks we need to make async api rfc
16:08:19cheatfateand doesn't matter if some of functions not implemented yet
16:08:46cheatfatebecause currently i dont understand how to adopt `process termination` to asyncdispatch
16:09:15cheatfateso i have already implemented it in code, but i dont understand how to make it as API
16:11:12cheatfateand this will be very usefull when you async talking with GDB for example
16:16:23cheatfatedom96, and this is not api breaks its api improvements but i think somebody (maybe you?) need to write rfc
16:19:06cheatfatedom96, we need something like this https://www.python.org/dev/peps/pep-3156/
16:19:20cheatfatenot so big but at least with core features enlisted
16:19:33dom96cheatfate: I know, it takes far too much time to write stuff like that though
16:20:28cheatfatedom96, then just make list of core features you want to make for asyncdispatch...
16:20:58dom96okay, i'll make an issue
16:21:06cheatfatedom96, then when somebody implement it you will not be so aggressive on PRs
16:21:28dom96hrm, am I agressive on PRs? :(
16:21:54cheatfatedom96, and also i'm pinging you on `callSoon`
16:22:53cheatfatedo you remember what i'm talking about?
16:23:01dom96of course
16:23:12dom96I've still got it in my Github notifications so that I don't forget :)
16:25:02cheatfatedom96, main problem is in "closure", "gcsafe" and other pragmas when you modify future.cb() to callSoon(future.cb)... for some reason windows OVERLAPPED callbacks declarations fall into errors
16:25:41dom96Got this so far: https://github.com/nim-lang/Nim/issues/4123
16:25:48dom96will add more as I remember/am reminded
16:28:26cheatfateput callSoon first! its much easy than everything else
16:29:07cheatfateand i have already implemented all timers...
16:29:08*space-wizard joined #nim
16:31:55cheatfatedom96, and could you please give some time intervals
16:31:57*yglukhov quit (Ping timeout: 260 seconds)
16:32:11dom96cheatfate: time intervals?
16:33:17cheatfatewhen can we expect completion of callsoon() at least?
16:35:21dom96I can't estimate that
16:35:31*desophos joined #nim
16:37:16dom96Anybody here who could sort this out? https://www.reddit.com/r/programming/comments/4gnehl/pied_piper_compression_code_shown_on_silicon/d2kkx9j
16:37:27dom96(math.gcd giving inconsistent results)
16:40:29cheatfatedom96, "I can't estimate that" looks weird
16:43:02dom96huh?
16:45:12cheatfatei think callSoon is just 1 hour of your attention...
16:50:35cheatfatedom96, its just a one hour :)
16:51:21dom96cheatfate: I bet it would take longer :)
16:51:36dom96I would do it now but I've got a test tomorrow and a University assignment to code unfortunately
16:54:24*gokr joined #nim
17:08:07*gokr quit (Ping timeout: 260 seconds)
17:16:05*yglukhov joined #nim
17:39:57*silven quit (Ping timeout: 244 seconds)
17:40:43*silven joined #nim
17:49:30*Guest54448 is now known as Vivek
17:49:34*Vivek quit (Changing host)
17:49:34*Vivek joined #nim
17:53:25*yglukhov quit (Remote host closed the connection)
17:58:23*yglukhov joined #nim
18:10:08*rektide joined #nim
18:25:52*Deavmi_mobile quit (Read error: No route to host)
18:25:54*deavmi_mobile2 quit (Read error: No route to host)
18:26:08*Deavmi_mobile joined #nim
18:27:17*deavmi_mobile2 joined #nim
18:48:28deavmi_mobile2dom69: good luck with thee assessment :) hope you do excellent!
18:50:53dom96deavmi_mobile2: thanks :)
18:51:36*pregressive quit (Remote host closed the connection)
18:52:13*pregressive joined #nim
18:56:33*pregressive quit (Ping timeout: 240 seconds)
18:57:16*deavmi_mobile2 quit (Read error: Connection reset by peer)
18:57:16*Deavmi_mobile quit (Read error: Connection reset by peer)
18:59:48*deavmi_mobile joined #nim
18:59:54*Deavmi_m1bile joined #nim
19:00:27*brson quit (Read error: Connection reset by peer)
19:06:17*desophos quit (Remote host closed the connection)
19:14:11*brson joined #nim
19:14:17*nsf joined #nim
19:19:50*Arrrr quit (Quit: WeeChat 1.4)
19:22:17*Deavmi_m2bile joined #nim
19:25:00*Deavmi_m1bile quit (Ping timeout: 250 seconds)
19:25:44*deavmi_mobile quit (Ping timeout: 276 seconds)
19:26:28*deavmi_mobile joined #nim
19:36:34*yglukhov quit (Remote host closed the connection)
19:40:28*brson quit (Ping timeout: 252 seconds)
19:42:30*gokr joined #nim
19:44:46*pregressive joined #nim
19:52:14*Ven joined #nim
19:54:55*yglukhov joined #nim
19:56:45*brson joined #nim
20:01:18gokrdom96: IMHO gitter is more fitting for open source projects. We messed with setting up a slack channel for Evothings, but ... then we just switched to gitter and didn't look back.
20:02:42gokrThe gitter desktop app (built with node webkit, almost the same as electron) is quite ok. We are moving our IDE from node webkit to electron btw.
20:06:53*desophos joined #nim
20:08:50*Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:11:45*desophos quit (Ping timeout: 246 seconds)
20:14:29*desophos joined #nim
20:15:26*vendethiel joined #nim
20:18:28*novavis quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
20:18:48*novavis joined #nim
20:20:13*enthus1ast joined #nim
20:24:05*novavis quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
20:25:15*novavis joined #nim
20:32:27*novavis quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
20:34:26*novavis joined #nim
20:35:44*novavis quit (Client Quit)
20:36:37*novavis joined #nim
21:10:19*Demon_Fox joined #nim
21:17:13*elrood quit (Quit: Leaving)
21:27:13*novavis quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
21:30:01*brson quit (Read error: Connection reset by peer)
21:35:18*brson joined #nim
21:53:56*onionhammer quit (Quit: WeeChat 1.0.1)
21:56:42*dmi0 joined #nim
22:01:26*onionhammer joined #nim
22:02:03*castlelore quit (Quit: WeeChat 1.4)
22:03:12*castlelore joined #nim
22:04:03*rinukkusu quit (Ping timeout: 240 seconds)
22:04:22*castlelore quit (Client Quit)
22:04:46*PMunch joined #nim
22:05:01*castlelore joined #nim
22:05:07*kier quit (Ping timeout: 252 seconds)
22:05:25*kier joined #nim
22:07:53*vendethiel quit (Ping timeout: 250 seconds)
22:07:57*rinukkusu joined #nim
22:08:00*Matthias247 joined #nim
22:08:03*heinrich5991 quit (Ping timeout: 276 seconds)
22:10:07*deavmi_mobile quit (Read error: Connection reset by peer)
22:10:07*Deavmi_m2bile quit (Read error: Connection reset by peer)
22:11:04*Deavmi_mobile joined #nim
22:13:30*vendethiel joined #nim
22:16:10*Matthias247 quit (Read error: Connection reset by peer)
22:20:26*heinrich5991 joined #nim
22:35:11*vendethiel quit (Ping timeout: 250 seconds)
22:36:31*gokr quit (Ping timeout: 244 seconds)
22:37:37*gokr joined #nim
22:40:37*pregress_ joined #nim
22:43:51*pregressive quit (Ping timeout: 250 seconds)
22:45:45libmanAnyone try Nim in WebAssembly yet?
22:46:27*derka joined #nim
22:46:44libmanElectron.JS would support it eventually, so I guess it's a GUI option for Nim... 3:)
22:46:53*dmi0 quit (Quit: Leaving)
22:47:49*dmi0 joined #nim
22:48:20*dmi0 quit (Client Quit)
22:53:00*derka quit (Ping timeout: 250 seconds)
22:58:34*Matthias247 joined #nim
23:00:51*derka joined #nim
23:03:46*yglukhov_ joined #nim
23:06:06*derka_ joined #nim
23:06:17*yglukhov quit (Ping timeout: 260 seconds)
23:06:23*derka quit (Ping timeout: 268 seconds)
23:06:23*derka_ is now known as derka
23:13:41Araq_libman: I'm developing something but don't like to say more for now.
23:14:08*Jesin quit (Quit: Leaving)
23:14:18*libman braces himself.
23:15:14libmanIt could be anything! nimBook? nimPhone? I'm gonna short Apple now just in case.
23:16:40*Jesin joined #nim
23:19:38*brson quit (Read error: Connection reset by peer)
23:19:57*brson joined #nim
23:20:41*brson quit (Client Quit)
23:21:57*brson joined #nim
23:22:51*derka quit (Quit: derka)
23:25:55*onionhammer quit (Quit: WeeChat 1.0.1)
23:29:14Araq_lol
23:31:19*Matthias247 quit (Read error: Connection reset by peer)
23:47:29*derka joined #nim
23:49:21*onionhammer joined #nim
23:58:11*derka quit (Quit: derka)
23:59:58*yglukhov_ quit (Remote host closed the connection)