<< 31-10-2014 >>
00:00:07flaviuAlso, can we ban trailing whitespace in the source tree?
00:22:46*superfunc_ joined #nimrod
00:34:29*darkf_ joined #nimrod
00:38:07*darkf quit (Ping timeout: 272 seconds)
00:38:57*darkf_ is now known as darkf
00:49:28VarriountAww... is the party over?
00:49:53flaviuVarriount: And I wasn't invited? :/
00:50:33Varriountflaviu: You are right that uint32's would be more appropriate for unicode.
00:52:23flaviuI'm concerned that it may be totally broken on arch's that have 16 bit words
00:52:37*superfunc quit (Quit: Connection closed for inactivity)
00:52:42*Joe_knock left #nimrod ("Leaving")
00:53:07*mko quit (Quit: Bye.)
00:54:53Varriountflaviu: Someone needs to get skryler's unicode stuff into the stdlib
00:59:43BitPuffinyeah
00:59:45BitPuffinSkryler
00:59:48BitPuffinremember that guy
01:00:12BitPuffin:D
01:01:40flaviuAnyone remember his Github name?
01:05:11Varriountflaviu: Same as his irc name
01:05:13Varriounthttps://github.com/Skrylar/Skylight
01:06:01flaviuOops, I misspelled it. Ok.
01:09:44flaviuVarriount: It's incomplete
01:10:11flaviuI think just going over the current version adding a bunch of tests and cleaning up is sufficient.
01:11:43*superfunc_ quit (Ping timeout: 246 seconds)
01:13:19*Jehan_ quit (Quit: Leaving)
01:21:04*rpag quit (Ping timeout: 245 seconds)
01:25:56*Hakaslak quit (Quit: TODO: Generate 'Computer Sleep Quit Message')
01:49:52*fowlmouth joined #nimrod
01:50:53*fowl quit (Ping timeout: 255 seconds)
01:57:22*q66[lap]_ quit (Changing host)
01:57:23*q66[lap]_ joined #nimrod
02:13:17*saml_ joined #nimrod
02:16:57*brson quit (Quit: leaving)
02:17:23*brson joined #nimrod
02:21:29*wan quit (Ping timeout: 255 seconds)
02:22:27*wan joined #nimrod
02:42:07*Trustable quit (Quit: Leaving)
02:48:28*Boscop joined #nimrod
02:48:28*Boscop quit (Changing host)
02:48:28*Boscop joined #nimrod
02:50:39*brson quit (Quit: leaving)
02:50:53*brson joined #nimrod
02:51:23*flaviu quit (Ping timeout: 240 seconds)
03:19:23*AFKMorpork is now known as AMorpork
03:21:11*bjz quit (Ping timeout: 265 seconds)
03:29:53*rpag joined #nimrod
03:44:31*ARCADIVS joined #nimrod
03:52:35*vendethiel- joined #nimrod
03:53:59*vendethiel quit (Ping timeout: 245 seconds)
04:03:09*vendethiel- quit (Ping timeout: 245 seconds)
04:19:59*kemet joined #nimrod
04:22:28*saml_ quit (Quit: Leaving)
04:49:57*xenagi quit (Read error: Connection reset by peer)
04:59:25*Hakaslak joined #nimrod
05:01:34*Hakaslak quit (Max SendQ exceeded)
05:02:13*Hakaslak joined #nimrod
05:12:38*kemet quit (Remote host closed the connection)
05:18:36*Demos_ quit (Read error: Connection reset by peer)
05:24:45*Hakaslak quit (Quit: TODO: Generate 'Computer Sleep Quit Message')
05:37:26*AMorpork quit (Quit: to actually disconnect)
05:37:44*AMorpork joined #nimrod
05:38:52*edayo joined #nimrod
05:49:50*khmm joined #nimrod
05:53:29*BitPuffin quit (Ping timeout: 258 seconds)
06:52:53*johnsoft quit (Ping timeout: 265 seconds)
06:53:43*johnsoft joined #nimrod
06:54:19*Hakaslak joined #nimrod
06:54:35*gokr_ joined #nimrod
06:56:29*gokr quit (Ping timeout: 245 seconds)
06:56:32*Hakaslak quit (Max SendQ exceeded)
06:57:12*Hakaslak joined #nimrod
06:57:31*vendethiel joined #nimrod
07:00:19*vendethiel quit (Client Quit)
07:09:25*Hakaslak quit (Quit: TODO: Generate 'Computer Sleep Quit Message')
07:10:27*Hakaslak joined #nimrod
07:13:35*johnsoft quit (Ping timeout: 244 seconds)
07:15:33*johnsoft joined #nimrod
07:20:17*brson quit (Quit: leaving)
07:20:36*johnsoft quit (Ping timeout: 244 seconds)
07:30:35*edayo_ joined #nimrod
07:33:21*gokr joined #nimrod
07:33:29*edayo quit (Ping timeout: 265 seconds)
07:34:10*edayo joined #nimrod
07:35:04*edayo_ quit (Ping timeout: 244 seconds)
07:36:29*gokr_ quit (Ping timeout: 245 seconds)
07:49:01*Matthias247 joined #nimrod
07:58:08*khmm quit (Ping timeout: 265 seconds)
08:03:38*khmm joined #nimrod
08:04:56*f0wl joined #nimrod
08:07:34*Hakaslak quit (Quit: TODO: Generate 'Computer Sleep Quit Message')
08:16:28*Matthias247 quit (Quit: Matthias247)
08:21:20*f0wl quit (Ping timeout: 265 seconds)
08:22:15*johnsoft joined #nimrod
08:22:25*gokr_ joined #nimrod
08:25:11*gokr quit (Ping timeout: 244 seconds)
08:36:29*Francisco quit (Ping timeout: 264 seconds)
08:37:28Araqflaviu: trailing whitespace is irrelevant for any tool not written by a Neanderthal. If git doesn't like it, add some option to ignore it.
08:38:49*Francisco joined #nimrod
08:42:22Araqoh wait, this option seems to be missing. so let's instead be religious about it: http://codeimpossible.com/2012/04/02/Trailing-whitespace-is-evil-Don-t-commit-evil-into-your-repo-/
08:42:59*gokr joined #nimrod
08:43:07Araqtypical unix mentality. don't fix broken tools. blame somebody else instead.
08:43:13*MyMind quit (Read error: Connection reset by peer)
08:43:55*Pisuke joined #nimrod
08:46:04*gokr_ quit (Ping timeout: 245 seconds)
08:49:41*khmm quit (Ping timeout: 244 seconds)
08:52:49*khmm joined #nimrod
08:57:19gokr1Araq: I guess this solution is the "reasonable way" in Nim for the super call problem using procs? http://goran.krampe.se/2014/10/31/nim-and-oo-part-ii/
08:58:03gokr1I also think that was the proposed solution mentioned in the forum somewhere when this was brought up.
08:59:22Araqno. generics are not necessary
08:59:26Araqin this case
08:59:48Araqyou can simply use a non-generic helper proc that uses the base type in its signature
09:00:38Araqone macro based solution is to transform 'method m' to 'proc mBase' and 'method m' that calls mBase
09:00:54Araqand then you can transform 'super m' to 'mBase'
09:04:49Araqgotta go, see you later
09:07:40*irrequietus joined #nimrod
09:08:17*wan quit (Ping timeout: 264 seconds)
09:08:41*wan joined #nimrod
09:11:02*Jesin quit (Read error: Connection reset by peer)
09:17:49gokr1Hmmm, ok!
09:18:28gokr1Btw, this is a fairly interesting little dialog with Alan Kay on OO: http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
09:20:36gokr1Araq: Aren't you missing the fact (that I write fairly detailed about) that the "helper proc" then wrongly will resolve self calls to Fruit and not Banana?
09:25:17gokr1As soon as you call a proc with an explicit base type - then any subsequent "self calls" from that proc will resolve to Fruit only and "miss" overrides.
09:26:40*bjz joined #nimrod
09:49:55*johnsoft quit (Ping timeout: 244 seconds)
09:50:46*BlaXpirit joined #nimrod
09:50:54*johnsoft joined #nimrod
09:53:00*BlaXpirit quit (Client Quit)
09:55:30dom96Not even a thank you for fixing nimbuild? :(
09:59:04*Araq0 joined #nimrod
10:00:53Araq0dom96_: thank you
10:01:13Araq0gokr: why would the proc only call procs and not other methods?
10:01:26Araq0I don't see the problem, it "just works"
10:01:53dom96_Araq0: No problem
10:02:38Araq0gokr: btw please don't use proc p(a, b, c) (without explicit types)
10:03:12Araq0I'll ban all these experimental features for 1.0 under a switch --experimental or something
10:04:07Araq0bbl
10:04:10*Araq0 quit (Quit: Page closed)
10:14:52*vezzy joined #nimrod
10:15:21*quasinoxen quit (Ping timeout: 260 seconds)
10:40:28gokr1Isn't "proc p(a)" equivalent to "proc p[T](a: T)"?
10:42:09gokr1"why would the proc only call procs and not other methods?" - not sure I follow, did I say something along those lines?
10:58:45*johnsoft quit (Ping timeout: 260 seconds)
10:59:00*johnsoft joined #nimrod
10:59:44*edayo_ joined #nimrod
11:02:35*edayo quit (Ping timeout: 255 seconds)
11:21:55*BlaXpirit joined #nimrod
11:25:28*Araq0 joined #nimrod
11:25:32*untitaker_ quit (Ping timeout: 256 seconds)
11:26:36Araq0gokr: "Aren't you missing the fact (that I write fairly detailed about) that the "helper proc" then wrongly will resolve self calls to Fruit and not Banana?" if the helper proc calls a method on Fruit, it will be resolved to Banana if that's what the fruit is
11:27:23Araq0it's quite like private vs public calls in Java. private methods are bound statically, but can invoke public methods which are bound dynamically
11:30:40gokr1Yes, a method will work. But not procs.
11:31:01gokr1Wait...
11:32:41*untitaker joined #nimrod
11:32:59gokr1So I have one fruit.nim using only procs and generics. If I change the type of that base proc to "Fruit" then it will of course fail when I do "self.reduction()" because self is then a Fruit and it will call the Fruit reduction always.
11:33:10gokr1Now, again - this is trying to use procs only.
11:33:28gokr1But... the second sentence above you wrote - not sure what that means.
11:40:52gokr1Hmmm, I am benching both the "methods only" fruits - and the "procs and generics only fruits". With a heterogenous seq - 30 million fruits - for the procs only fruits I need to cast before calling calcPrice - but... the funny thing is that both variants run just as fast.
11:41:52gokr1So... while I am perhaps doing something wrong - it seems method lookup is... very fast. No obvious need to bother here at least.
11:45:49*bjz quit (Ping timeout: 264 seconds)
11:49:37gokr1Araq0: But yes, good point there - for private methods (non *) we can relatively easy move to procs/generics since we control all calls to them. I just did a mixed variant of my method based fruit.nim - and... it works, as long as I don't have public methods in Fruit (with self: Fruit) because again, then it fails.
11:49:44*bjz joined #nimrod
11:49:48gokr1Too bad I can't see any speed improvement though :)
12:03:45*hg joined #nimrod
12:03:48Araq0well method dispatching has been optimized and can be faster than how c++ does it
12:10:01*edayo joined #nimrod
12:12:29*edayo_ quit (Ping timeout: 264 seconds)
12:12:44*hg quit (Quit: Page closed)
12:17:44*Trustable joined #nimrod
12:22:56*edayo_ joined #nimrod
12:23:04*edayo quit (Ping timeout: 244 seconds)
12:27:07*irrequietus quit (Ping timeout: 255 seconds)
12:36:03*quasinoxen joined #nimrod
12:36:29*vezzy quit (Ping timeout: 245 seconds)
12:39:46Araq0gokr1: the major reason why we don't use methods in the stdlib is that they don't play well with the effect system and our dead code elimination optimization
12:40:27Araq0and these are inherent problems with dynamic binding
12:42:08gokr1Got it
12:42:36gokr1But I was amazed that I couldn't see any difference in speed - so methods must be... very optimized. Of course, I don't have many kinds of Fruit :)
12:43:38gokr1So I guess I will write a part III too - to sum up the findings. I can add these facts there.
12:43:59Araq0beware micro benchmarks. they are often completely misleading
12:44:06*dom96_ quit (Ping timeout: 256 seconds)
12:44:09gokr1Btw... if I do "type(x)" I get a typedesc - right? But I can't do like "type(x) == Banana", right?
12:44:11gokr1Yeah, I know.
12:44:59Araq0you can compute 12 square roots in the time a cache miss takes. or something like that.
12:45:32Araq0right, there is no == for typedescs, but you can use 'is'
12:45:43gokr1But is ... is compile time, right?
12:45:57Araq0'is' is compile-time, 'of' is run-time
12:46:08gokr1So I can't do "type(x) is Banana", right?
12:46:24Araq0you can do "x of Banana"
12:46:35gokr1And "of" is like #isKindOf: in Smalltalk, it will be true for all subtypes too.
12:46:49Araq0yes
12:46:57gokr1I made a silly if/elif/elif using of - but ... had to make sure to test leafs first :)
12:47:49gokr1You wrote don't leave out types - but... isn't "fn(self)" equal to "fn[T](self:T)"?
12:48:00gokr1Or some subtle difference? Or just clarity you mean?
12:48:08Araq0it is, but I consider it sloppy
12:48:16*edayo joined #nimrod
12:48:41gokr1Well... perhaps. It does make less "line noise" though for my eyes.
12:49:07gokr1Oh well, so far so good :)
12:49:29gokr1It seems to me that... OO is very doable, unless I missed something.
12:50:03Araq0it is. except for the 'super' feature. but that's like 5 lines of code to add to the compiler ;-)
12:50:16Araq0will do it for the next version
12:50:22gokr1Right! Did you decide to do a "next best call" like the others?
12:50:35gokr1(others being Dylan, CLOS etc)
12:50:43Araq0I think 'static_call' is less confusing
12:50:44gokr1I am not sure if there is another technique to consider.
12:50:58Araq0what does "next best call" mean, anyway?
12:51:19Araq0'static_call' fits the language
12:51:29*edayo_ quit (Ping timeout: 264 seconds)
12:51:32gokr1AFAICT from reading up on Julia etc - you simply call the next method that matches.
12:51:57gokr1And "best" using some precedence rule of course.
12:52:01Araq0yes, but it's not obvious what "next method" means
12:52:27Araq0is there some chain of methods? and if so, how does it look like?
12:52:37gokr1I think most seem to go left to right on args etc.
12:52:41gokr1I haven
12:52:46gokr1't used any of those langs though.
12:53:13Araq0well I have some trust in my design capabilities. so it's static_call. ;-)
12:53:29gokr1And... sorry - but what did it do now again? :)
12:54:06gokr1(and I do agree that the "next method" feels ... slightly gotcha-prone)
12:54:17Araq0it uses the method that overloading resolution determines to use
12:54:36Araq0static_call m(Banana(b), Fly(x))
12:55:07gokr1Ah, so you use type conversions but to call methods instead of procs?
12:55:35Araq0yes
12:55:36gokr1So "static_call" in contrast to "dynamic call" that methods normally would use.
12:55:42Araq0exactly
12:55:42*darkf quit (Quit: Leaving)
12:55:43gokr1Ah, right. Yeah, cleaner.
12:55:58gokr1And it fits what you would do with procs.
12:56:25gokr1super duper then :)
12:57:11gokr1Btw... I am also trying to... learn how to use Twitter. The hash tag is #nimlang - and there is also an account @nimrodlang
12:57:34Araq0the nice thing with Nim's syntax is that it allows static_call m(a,b) without making static_call a keyword
12:57:56Araq0it's just yet another builtin
12:58:01gokr1Oh, so static_call would be a macro?
12:58:13gokr1Or a magic proc.
12:58:28Araq0there is no difference really in this case
12:58:41*flyx joined #nimrod
12:58:42Araq0but likely a magic proc
12:59:07gokr1I do agree that not requiring () opens up more extendability.
12:59:23gokr1I presume you agree with ... Steele on growing a language? :)
12:59:31Araq0yup
12:59:49*AMorpork is now known as AFKMorpork
13:00:20gokr1Ok... think I need to bang my head against Urho a bit.
13:00:54gokr1Thanks for all answers btw.
13:01:07Araq0you're welcome
13:01:38gokr1I know n00bs can be ... annoying sometimes, but I do try to read in the manuals etc first :)
13:03:14Araq0nah n00bs are fine, but you're not a n00b anyway
13:04:47gokr1But I really appreciate the friendly atmosphere here. Much like in Smalltalk. :) And many newbie questions turn into very interesting discussions.
13:05:04gokr1Ok, gotta go pick up a car. Later.
13:06:36*ARCADIVS quit (Quit: ARCADIVS)
13:11:19*gokr_ joined #nimrod
13:13:22*AFKMorpork is now known as AMorpork
13:14:31*gokr quit (Ping timeout: 244 seconds)
13:14:49*Araq0 quit (Quit: Page closed)
13:19:26*khmm quit (Ping timeout: 256 seconds)
13:40:12*gokr joined #nimrod
13:40:23*mbenadda joined #nimrod
13:43:59*gokr_ quit (Ping timeout: 245 seconds)
13:47:53*johnsoft quit (Ping timeout: 264 seconds)
13:48:11*johnsoft joined #nimrod
13:58:49*irrequietus joined #nimrod
14:09:16*edayo_ joined #nimrod
14:11:53*edayo quit (Ping timeout: 264 seconds)
14:12:18*gokr1 quit (Ping timeout: 265 seconds)
14:14:43*fowl joined #nimrod
14:17:53*gokr_ joined #nimrod
14:19:37*gokr quit (Ping timeout: 244 seconds)
14:33:03*AMorpork is now known as FrankenMorpork
14:45:16*BitPuffin joined #nimrod
14:45:17*gokr joined #nimrod
15:02:53*johnsoft quit (Ping timeout: 264 seconds)
15:03:14*johnsoft joined #nimrod
15:08:58*rpag quit (Remote host closed the connection)
15:09:38*irrequietus quit ()
15:11:55*rpag joined #nimrod
15:19:39*Joe_knock joined #nimrod
15:27:19gokrSilly question, is there a trivial way to run a lambda over a collection and sum up? Like you would do using #inject:into: in Smalltalk.
15:31:15Joe_knockgokr: Were you the 1 who wrote a blog post "I missed nim" ?
15:31:22gokryeah
15:31:54Joe_knockYour posts were interesting. Running a work-horse laptop too.
15:33:00*Hakaslak joined #nimrod
15:35:15*Hakaslak quit (Max SendQ exceeded)
15:35:55*Hakaslak joined #nimrod
15:38:08*Hakaslak quit (Max SendQ exceeded)
15:39:04*Hakaslak joined #nimrod
15:40:05*Hakaslak quit (Max SendQ exceeded)
15:40:42*Hakaslak joined #nimrod
15:45:20NimBotnimrod-code/nimforum new_async b5f6d8f Dominik Picheta [+1 ±3 -0]: Implemented new design for thread view.
15:47:40*Demos joined #nimrod
15:49:06*Hakaslak quit (Quit: TODO: Generate 'Computer Sleep Quit Message')
15:49:18Demoshas anyone here watched JOnathan Blow's language design videos?
15:58:47*Hakaslak joined #nimrod
16:01:55*FrankenMorpork is now known as AFKMorpork
16:02:46Joe_knockis async compatible with 0.9.6?
16:05:33*dom96_ joined #nimrod
16:06:15dom96_Joe_knock: Not really. The new stuff I introduced and the many bugs I fixed did not make it into 0.9.6.
16:06:25dom96_You're better off using big break at this point anyway though.
16:06:49*superfunc joined #nimrod
16:07:14*Hakaslak quit (Ping timeout: 272 seconds)
16:07:14*gokr_ quit (Read error: Connection reset by peer)
16:07:23*gokr_ joined #nimrod
16:07:58Joe_knockdom96_: I know you're busy, but it would be awesome if you could write a to-do like app using the new stuff as a tutorial.
16:10:10dom96_You mean like a web app?
16:11:38Joe_knocka tiny one. Like the to-do apps
16:12:11dom96_I can give it a shot.
16:12:26dom96_Still working on the new design for the forum though.
16:15:29Joe_knockI suppose all the "killer" frameworks got a start with those simple tutorials and people just built on top of that.
16:30:01*Hakaslak joined #nimrod
16:35:18*rpag quit (Ping timeout: 265 seconds)
16:42:01*dom96_ quit (Ping timeout: 246 seconds)
16:47:04*mbenadda quit (Quit: Be back later ...)
16:49:06*Hakaslak quit (Quit: TODO: Generate 'Computer Sleep Quit Message')
16:53:41*Hakaslak joined #nimrod
16:54:46*Hakaslak quit (Max SendQ exceeded)
16:55:21*Hakaslak joined #nimrod
16:58:19dom96Joe_knock: true
16:58:30dom96jester does still need some polishing though
17:02:53*dom96_ joined #nimrod
17:04:42gokrhttp://goran.krampe.se/2014/10/31/nim-and-oo-part-iii
17:07:58*EastByte_ is now known as EastByte____
17:12:39*irrequietus joined #nimrod
17:13:49*superfunc_ joined #nimrod
17:18:38*AFKMorpork is now known as AMorpork
17:18:45*AMorpork is now known as FrankenMorpork
17:31:04*gokr_ quit (Read error: Connection reset by peer)
17:31:28*gokr_ joined #nimrod
17:32:44*gokr quit (Ping timeout: 256 seconds)
17:33:34*Hakaslak quit (Remote host closed the connection)
17:34:09*Hakaslak joined #nimrod
17:35:13*superfunc quit (Ping timeout: 246 seconds)
17:35:14*superfunc_ is now known as superfunc
17:36:23*Hakaslak quit (Max SendQ exceeded)
17:37:12*Hakaslak joined #nimrod
17:39:27*Hakaslak quit (Max SendQ exceeded)
17:40:24*Hakaslak joined #nimrod
17:41:35*Hakaslak quit (Max SendQ exceeded)
17:42:20*Hakaslak joined #nimrod
17:44:35*Hakaslak quit (Max SendQ exceeded)
17:45:16*Hakaslak joined #nimrod
17:46:21*Hakaslak quit (Max SendQ exceeded)
17:47:04*Hakaslak joined #nimrod
17:47:52*Jehan_ joined #nimrod
17:48:13*Hakaslak quit (Max SendQ exceeded)
17:49:05*Hakaslak joined #nimrod
17:50:20*Hakaslak quit (Max SendQ exceeded)
17:51:08*Hakaslak joined #nimrod
17:53:29*Hakaslak quit (Max SendQ exceeded)
17:54:21*Hakaslak joined #nimrod
17:54:24*gokr_ quit (Read error: Connection reset by peer)
17:55:00*gokr_ joined #nimrod
17:56:47*Hakaslak quit (Max SendQ exceeded)
17:57:44*Hakaslak joined #nimrod
17:59:47*Hakaslak quit (Client Quit)
18:00:04*edayo joined #nimrod
18:02:53*edayo_ quit (Ping timeout: 240 seconds)
18:03:46*Hakaslak joined #nimrod
18:03:59*irrequietus quit ()
18:04:45*Matthias247 joined #nimrod
18:05:54*Hakaslak quit (Client Quit)
18:07:06*Hakaslak joined #nimrod
18:08:05*Hakaslak quit (Client Quit)
18:10:00*Hakaslak joined #nimrod
18:12:45*xenagi joined #nimrod
18:15:18*Hakaslak quit (Quit: TODO: Generate 'Computer Sleep Quit Message')
18:22:25*Hakaslak joined #nimrod
18:23:36*Hakaslak quit (Max SendQ exceeded)
18:24:15*Hakaslak joined #nimrod
18:24:45*BlaXpirit quit (Quit: Quit Konversation)
18:25:28*Hakaslak quit (Max SendQ exceeded)
18:26:09*Hakaslak joined #nimrod
18:26:22*BlaXpirit joined #nimrod
18:30:43*Hakaslak quit (Ping timeout: 255 seconds)
18:35:50wanHey dom96, I want to update nim to 0.9.6 for techempower's bench (tfb), is jester fine with it?
18:36:11dom96nah, you'll need bigbreak
18:36:35wanoh, I'll take it to nimbreak then
18:36:42wan*bigbreak
18:37:10wanby the way, could you take a look at my pull on nim-zmq when you have the time?
18:37:45wanI'm finally using babel/nimble for nawak
18:53:01*Matthias247 quit (Read error: Connection reset by peer)
19:06:40dom96sure
19:08:01dom96merged
19:09:59*gokr joined #nimrod
19:11:37*Jesin joined #nimrod
19:13:02*irrequietus joined #nimrod
19:13:46*superfunc_ joined #nimrod
19:20:26wanthanks!
19:25:32*brson joined #nimrod
19:27:56Araqso dom96 ... should we release 0.9.8 that only contains a couple of fixes but includes nimble?
19:28:13Araqor should we go for 0.10.0
19:28:26dom96the latter
19:28:44AraqVarriount: ping
19:29:46*brson quit (Client Quit)
19:29:55*brson joined #nimrod
19:36:27Joe_knockis dom96 the co-chair of the Nim foundation? :P
19:37:53AraqJoe_knock: power comes from contributing
19:38:38Joe_knockand long-term commitment
19:39:21Araqwrite something like Nim's networking layer and I will ask you about your opinion of release schedules too ;-)
19:41:10Joe_knockWell I can't do the deep tech stuff, but I am going to write the equivalent of numpy for Nim.
19:41:53*BitPuffin quit (Ping timeout: 264 seconds)
19:44:21Araq:O
19:44:39*Joe_knock cracks knuckles and grins evilly
19:47:02Jehan_ /popcorn
19:53:25*flaviu joined #nimrod
19:53:49dom96Joe_knock: If you do that then I will worship you.
19:54:40Jehan_dom96: I think he's not quite serious. :)
19:54:47Joe_knockdom96: It is something we all can use, instead of python + pypi
19:55:10Jehan_Not that I wouldn't love it, but a numpy-equivalent is a truckload of work.
19:55:28Jehan_I don't have enough spare cycles lying around to even think about implementing a fraction of it.
19:55:49Araqfirst step: revive nimborg and ensure it works with numpy
19:56:45Joe_knockJehan_: What about starting with basic statistics toolset?
19:57:09Jehan_Joe_knock: The big time eater is all the mathematical algorithms you'll need.
19:57:27*Araq is sure the 80/20 rule also applies to numpy
19:57:33*flaviu quit (Read error: No route to host)
19:57:44Jehan_Yeah, but even individual algorithms are time eaters.
19:58:15Joe_knockDo you guys think nim will blow pypi/cython + numpy out of the water?
19:58:36*flaviu joined #nimrod
19:58:38Jehan_I remember that the Sage people asked one of the Magma guys (I think) how he had implemented Quaternion Algebras.
19:58:55Jehan_His answer was something along the lines of him having essentially spent a decade working on it.
19:59:15Jehan_Joe_knock: Depends on what you're looking at.
19:59:36Jehan_I can tell you right now that feature completeness is a LOT more important for a lot of scientists than raw speed.
19:59:52Joe_knockagreed
20:00:33Jehan_A program that runs a couple of hours longer but saves you having to spend a week implementing non-trivial stuff is still better for the average researcher.
20:00:49Araqspeaking of which ... does anybody think the python people will see the light and drop python3 ?
20:01:12Joe_knockdrop it for ...? Araq
20:01:12Jehan_I'm seeing it in Computer Algebra, where you either spend a huge amount of money for one of the commercial Ma systems (Magma, Maple, Mathematica) or use an interpreted system (GAP, Singular, Macauley2) etc.
20:01:17Jehan_Araq: No.
20:01:35Jehan_There's too much time invested in Python3, especially some internal rearchitecting.
20:01:51Jehan_I expect that Python 2 and 3 will continue to coexist for quite some time.
20:01:56AraqJoe_knock: for python 2.
20:02:07Jehan_And if they stop supporting Python 2, then Red Hat or other vendors will keep it going.
20:02:16Jehan_Too many people depending on Python 2 compatibility.
20:02:16Joe_knockthey're dropping support for 2 next year...
20:02:18Araqpython 2 still has all the modules and frameworks
20:02:39AraqJoe_knock: nope, it's supported until 2020 afaik
20:02:44Jehan_I don't expect a fork, but I expect Python 2 to be maintained indefinitely.
20:03:13AraqI like python 2 better fwiw
20:03:39Jehan_I don't see the benefits of Python 3.
20:03:53Jehan_I believe the serious benefits are largely if you're doing Unicode-dependent stuff.
20:03:55Joe_knockmy user group gently nudged us to consider 3.
20:04:28Araqunicode is a pita with python 3
20:04:47Jehan_Araq: Dunno, it's nothing that affects me.
20:04:50Araqit enforces "correctness" where no such thing exists really.
20:05:05Araqunicode is a moving standard and really *complex*
20:05:14Jehan_Which is also why, for better or worse, Python 3 doesn't really buy me anything, one way or the other.
20:05:15*irrequietus quit (Ping timeout: 258 seconds)
20:05:28Jehan_Araq: Agreed. One of the things I like about Nim is that strings are encoding-agnostic.
20:05:50*edayo quit (Quit: WeeChat 1.1-dev)
20:05:59Araq'print' as a statement is also nicer for debugging
20:06:02Jehan_Which also means that it works for Shift-JIS or EUC-JP or EUC-KR (mostly).
20:06:28Jehan_The parentheses don't bother me much, I just think that was an unnecessary incompatibility.
20:06:40Jehan_It's not like print as a keyword hurt anyone.
20:06:45Araqindeed.
20:07:09Jehan_That seemed more like a clean-up to meet some theoretical ideal, not a practical need.
20:07:43Araqwell the theoretical ideal IMHO would have been to make () optional for calls, like Nim does it.
20:07:54Araqbut then religion kicks in and says
20:07:58Jehan_But the whole Python 2/3 thing has driven me to pretty much use Ruby for my scripting needs.
20:08:08Araq"no no no, there should be one way to do things"
20:08:14Jehan_Araq: Hmm, there are downsides for that, such as parsing ambiguities.
20:08:39Jehan_That's not just "one way", but also keeping the implementation simple.
20:09:05Jehan_Ruby right now has some serious advantages over Python for me, as far as scripting is concerned.
20:09:09Araqthe implementation is not hard at all.
20:09:46Jehan_More concern about compatibility (sometimes incompatibilities are introduced, but usually more gently) and easier interfacing with C.
20:09:46Araqbut then python even has problems with multi-line lambdas ...
20:10:34AraqRuby has a 'case' statement. That alone makes it far superior.
20:10:44Jehan_In the end, I'm pretty much using Pythin only in two places still: SCons scripting and Mercurial extensions.
20:10:53Joe_knockIsn't Puppet in Ruby?
20:11:12Jehan_Joe_knock: Dunno. I don't do web stuff (and I haven't ever even looked at Rails).
20:12:18Jehan_When I say scripting, I mean pretty much that.
20:12:22Joe_knockI don't see python losing any users any time soon though. Massive projects are running on it now.
20:12:30Jehan_I like Ruby for doing small scripts and fast prototyping.
20:12:37*superfunc quit (Quit: Connection closed for inactivity)
20:13:01Jehan_Joe_knock: Correct. Which is why I think Python2 will continue to exist almost indefinitely, no matter what the Python core team thinks.
20:13:49Joe_knockdidn't Ruby have a breaking version as well? Jehan_
20:14:19Jehan_Joe_knock: Yup, it did have compatibility breaks. But they were much more gentle, as I said.
20:14:37*FrankenMorpork is now known as AFKMorpork
20:14:58Jehan_I have a 14-year old piece of code that I recently tried to run and which still worked, other than having to replace id with object_id, I think.
20:15:25Jehan_Fixing the generated C code because of incompatibilities in gcc was more work. :)
20:16:16Jehan_Oh, and that was non-trivial code: The Ruby program was an Eiffel compiler, with a parser written in PCCTS (i.e., using C).
20:17:10Jehan_I'm also a bit concerned about Scala migrating to the JVM 8.
20:17:15Jehan_I understand why they're doing it.
20:17:44Jehan_They want to get the new features (such as more efficient anonymous functions) and they don't have the manpower to support multiple backends.
20:17:53*fowl quit (Ping timeout: 244 seconds)
20:18:25Joe_knockThere's a ton of languages out there now.
20:18:36Jehan_But I'm worried that the tools to convert JVM 8 bytecode to an earlier version that they intend to use for backwards compability may not be enough.
20:19:26Jehan_Joe_knock: Yeah. But lots of them without much support, limited tooling, or stuff that goes away when their author finishes his or her degree.
20:20:02Jehan_That's one of the reasons why I'm using Nim, to be honest.
20:20:42Jehan_While I would have designed the language different in quite a few places, that's nothing compared to having a reasonably mature, stable environment.
20:21:52Jehan_Plus, there are only a few other languages in the same space, and all of them don't meet my needs in one way or another, even though they're interesting on their own.
20:22:34Joe_knock"write something like Nim's networking layer and I will ask you about your opinion of release schedules too ;-)" Maybe Araq will allow 1 or 2 design changes if you build that
20:23:42Jehan_In Rust, GCed memory is a second-class citizen, which makes it largely useless for me (even though I understand that this is a critical feature for the niche they're aiming for). Go has a lot of fascinating ideas, but the limitations of the type system get in my way (though, again, I understand what their goal is and can appreciate it – it's just not what I need).
20:25:13Jehan_D is probably the closest language to Nim in intent, and I'd actually written quite a bit of code in D before I ran into Nim. My main problem with D is that the GC still needs major improvement and they seem to be shifting more and more to a Rust-like approach, where the GC is an optional thing; that worries me.
20:25:37Jehan_Subjectively, I also like Pascal and Python-style syntax more than C syntax, but that's not a killer feature one way or the other.
20:25:43flaviuRust is pretty cool. But compilation speed @_@
20:25:55Jehan_And as for release schedules, meh, I don't care about those. :)
20:26:16Joe_knockwhen there is a code-bloat of 80LoC, I think that is where syntax matters.
20:26:17Jehan_Usually, if I find a bug that breaks my code, I fix it myself.
20:26:36Joe_knock80K
20:26:43Joe_knock*80k :-/
20:27:29ldleworkJehan_: isn't Nim's GC optional..?
20:27:33Jehan_flaviu: Compilation speed I can live with. But it's really the odd obsession that too many people have with avoiding GC that's my problem.
20:27:57Jehan_ldlework: In theory, you can disable it, but … the language isn't designed to make it optional.
20:28:08Jehan_Rather, the language is designed to minimize its impact.
20:28:23ldleworkJehan_: a lack of GC is required for lots of programming and types of applications that you're probably not used to doing yourself
20:28:59ldleworkIts not an obsession its a requirement
20:29:01Jehan_Araq basically smartly recognized that a single-threaded GC is a hell of a lot easier to write and make fast than a multi-threaded GC, even if it comes at the expense of some flexibility.
20:29:19Jehan_ldlework: I know, but those domains are really few and far between.
20:29:25ldleworkJehan_: not really
20:29:44ldleworkExposure bias isn't a good justification for your comment about GC obsession.
20:29:54ldleworkI'm not making a serious argument, I'm just pointing it out
20:30:34Jehan_ldlework: Let me put it this way. As I said, I totally appreciate the need for having a GC-free language. It's just that there's also a need for languages that aren't weighed down by that consideration.
20:30:54ldleworkJehan_: what exactly about rust is weighed down by a lack of GC
20:31:01Jehan_Making a GC optional or unnecessary leaves a footprint on the language and the code you write.
20:31:07gokrAnyone know of any current usage of Nim where they consciously avoid ref and GC?
20:31:08ldleworkLike?
20:31:52Jehan_ldlework: The *necessity* to track ownership and the syntactical noise that it creates, for starters.
20:32:12ldleworkJehan_: do you think Rust does this in a way that adds a bunch of syntactical noise?
20:32:13ldleworkI mean really?
20:32:14Jehan_Plus, the much bigger noise when you actually want GC.
20:32:35Jehan_The problems with ownership and closures.
20:32:48ldleworkWhich problem
20:33:06flaviuJehan_: GC in mobile isn't very good. And it also has issues with mandatory runtimes and such, its harder to use a library that uses GC in a language that doesn't support it.
20:34:10Jehan_flaviu: It depends on the GC, honestly.
20:34:11ldleworkflaviu: you're just obsessed
20:34:28Jehan_For the mobile part, I mean.
20:34:52Jehan_And yes, I know about the issues with combining libraries with different approaches to memory management.
20:34:55flaviuldlework: hmm? I'm not against GC, but there are some valid criticisms.
20:35:18ldleworkJehan_: good thing they are few and far between, amirite?
20:35:39flaviuldlework: Are you actually serious, or are you just trolling?
20:35:40ldleworkflaviu: I was being facetious, I don't think you're obsessed
20:35:45Jehan_ldlework: Hmm?
20:35:52ldleworkJehan_: Hmm? what?
20:36:12Jehan_ldlework: Not sure about your last comment.
20:36:22Jehan_What you were trying to say, I mean.
20:36:41ldleworkJehan_: I was using your own argument as to why the reasons for needing no-GC are few and far between
20:36:55ldleworkAnd that the kinds of applications that require no-GC
20:37:09Jehan_The problem with closures and borrowing, by the way, is that they often violate the stack's LIFO policy.
20:37:17*Dispatch joined #nimrod
20:37:26ldleworkJehan_: can you link to anything about that?
20:37:37Jehan_ldlework: That is not helped by having no GC.
20:37:47Jehan_It's a problem with ANY memory management strategy.
20:37:51ldleworkThen why bring it up at all?
20:38:06*irrequietus joined #nimrod
20:38:22Jehan_ldlework: I acknowledged that there was a problem?
20:38:44ldleworkBut its an equivalency.
20:39:00Jehan_Well, any memory management strategy outside of doing all memory management manually.
20:39:22ldleworkIt doesn't distinguish. So I'm not sure why its relevant to the position that people and languages that push for non-GC are obsessed
20:39:26ldlework(instead of you know, just having reasons)
20:39:42flaviuWell, just allocate stuff. Deallocating is for scrubs
20:39:43Jehan_ldlework: The problem is not when they need GC for their own purposes.
20:40:02Jehan_But when they want to impose a GC-less environment on *everything*.
20:40:52Jehan_Look, I'm writing enough close-to-the-metal stuff where a GC gets in the way. I totally appreciate where it's a problem.
20:41:26ldlework"The basic idea is to remove garbage collection from the core language and relegate it to the standard library, with a minimal set of language hooks in place to allow for flexible, pluggable automatic memory management."
20:41:31Jehan_But there's a point where insisting on GC-freedom for everything because, I dunno, it *may* have a couple of percent overhead does not make any sense anymore.
20:41:33ldleworkThis sounds so horrible!
20:41:46flaviuldlework: How is that horrible? That's about ideal
20:42:00flaviuThe language shouldn't force decisions like that on the programmer
20:42:06ldleworkflaviu: again, I'm being overtly sarcastic and facetious to demonstrate how untennable Jehan_'s generalizing position is
20:42:34Jehan_ldlework: The problem is that automatic memory management is not a local concern that CAN be packaged in a library.
20:42:45ldleworkJehan_: it is with a language like Rust
20:42:54ldleworkJehan_: have you used it?
20:43:20ldlework"with a minimal set of language hooks in place"
20:43:42Jehan_ldlework: Simple example. Garbage collection requires that you scan the stack. How do you do that without having language support (other than the hacks that the Boehm GC does)?
20:44:11Jehan_Second, any GC with reasonable performance requires either a write or read barrier of some form.
20:44:15ldleworkJehan_: he's literally suggesting that they utilize meta-programming to implement implicit management
20:44:19Jehan_This means that code generation has to produce them.
20:44:24ldleworkAnd relegate the implementation to the library
20:44:49ldleworkI don't see your concern where this is fundamentally impossible
20:45:59ldleworkAnd the problem isn't that a language doesn't allow you to escape from the GC for some specific thing, but uses it for everything else
20:46:03ldleworkThat isn't the problem at all
20:46:12ldleworkPeople want -no GC- for several completely justified reasons
20:46:22Jehan_ldlework: Did I say otherwise?
20:46:39ldleworkYes, you said that languages that allow you to escape it for this or that, are fine
20:46:45ldleworkbut languages that force no GC are a problem
20:46:54ldleworkBut actually for lots of people, no GC is exactly what is desired
20:47:07ldleworkIt isn't about managing some specific resource that people want no GC for
20:47:26ldleworkIn some cases any GC at all is unacceptable
20:47:48ldleworkEven in the simple case of Mobile where GC stops the world for trivially large heap sizes
20:48:08Jehan_ldlework: That only tells me that you don't know how GCs work.
20:48:34ldleworkJehan_: I don't know what you mean. I haven't said anything untrue.
20:48:53ldleworkYou can demonstrate easily if I have made a mistake instead of accusing :)
20:49:17Jehan_Because we have known how not to stop the world for GC for, umm, a few decades now?
20:49:44Jehan_If you still think stop-the-world is an actual issue with a quality GC, I don't know what to say.
20:49:50ldleworkuhhhhh
20:49:51Jehan_Go read up on GC implementation.
20:49:52ldleworkhaha
20:49:54flaviuJehan_: Java has a state of the art GC. Now look at minecraft.
20:50:11Jehan_flaviu: They make the mistake of having a global shared heap.
20:50:12flaviuApparently minecraft's central issue these days *is* gc pauses
20:50:14ldleworkJehan_: both the JVM and the CLR have stop-the-world collections when running conurrently
20:50:26Jehan_Which, with multiple threads, is a hell of a lot more difficult.
20:50:41Jehan_Look at OCaml's GC for an actual example of something that doesn't have these issues.
20:50:51ldleworkJehan_: oh so now you're putting constraints on the kind of software I can write
20:50:55*Joe_knock finally appreciates mention of something familiar... minecraft
20:50:56Jehan_flaviu: The issue is that they allocate too much stuff. That would be a problem even without GC.
20:51:02Jehan_ldlework: No.
20:51:07ldleworkJehan_: but you just did
20:51:12flaviuNo it wouldn't. They could just stick it on the stack
20:51:34Jehan_flaviu: The nursery in OCaml is essentially a stack, for what it's worth.
20:51:49Jehan_Arguably, Chicken Scheme also, but that's an oddball implementation.
20:52:02Jehan_ldlework: No.
20:52:15ldleworkJehan_: name a production GC right now that doesn't stop the world with normal heapsizes on mobile
20:52:24Jehan_ldlework: OCaml's.
20:52:36ldleworkJehan_: yeah I forgot about all that OCaml code on mobile right now
20:52:37Jehan_Nim's, actually. Assuming you don't introduce cycles.
20:52:40*ldlework smacks his forhead.
20:53:35Joe_knockCan you use GC as a testing output after building your project and then going back to your code and implementing the stuff manually?
20:53:35Jehan_ldlework: My point is that the GC technology is there. Not that for some reason it didn't get deployed on mobile platforms.
20:54:00Jehan_Joe_knock: It's generally more helpful to use GC as a detector for leaks and early deallocations.
20:54:07Jehan_I.e. the other way round.
20:54:44Joe_knockSo as much as you can, you should try to do trivial GC manually?
20:55:06Jehan_Joe_knock: Not sure what you mean?
20:55:50Joe_knockJehan_: Instead of letting some automated process do GC for everything, for smaller parts of code where you're aware of de-allocation, you do it yourself.
20:55:59ldlework"The marking process can take a long time to run over the complete major heap and has to pause the main application while it's active."
20:56:20ldleworkJehan_: the truth is that for every GC you can point to that says "Oh this problem is solved" you leave out "In the very specific conditions X"
20:56:35ldleworkYour generalization simply isn't useful to anyone.
20:56:51Jehan_ldlework: Read the next sentence: "It therefore runs incrementally by marking the heap in slices."
20:57:12ldleworkJehan_: it doesn't say that it doesn't stop the process
20:57:49ldleworkIt even gives you the ability to manualy control slice collections. Why would you need to do that if the GC had no impact on your application's performance.
20:57:59ldleworkI mean, this argument isn't even interesting it is so trivially untrue.
20:58:00Jehan_ldlework: I say, because I've actually looked at the code. You are just googling in an attempt to win a debate, but don't actually understand what you're reading.
20:58:19Jehan_In any event, I've got work to do and can't waste more time arguing with an ignoramus. Night.
20:58:20*Jehan_ quit (Quit: Leaving)
20:58:21ldleworkJehan_: yeah because I'm not familiar with a specific GC you mentioned to be the holy grail I know nothing.
20:59:19gokrMaking a 32 bit .so on a 64 bit Linux - do you think I need to set up a virtual 32 bit Linux instead?
21:01:39*Dispatch quit (Quit: Page closed)
21:01:44Demosbiggest issue with java is not GC quality but the fact that even trivial objects are allocated on heap, if you did that in C perf would probably be /worse/
21:06:36*gokr solved it
21:06:58gokr(--cpu:i386 --passC:"-m32" --passL:"-m32" seemed to do the trick.
21:07:55Araqldlework: aicas a hard real-time concurrent and parallel GC for Java. minimum RAM requirements in practice 20MB. it's a commercial product though.
21:08:31Araqit scales to several GB of memory too
21:08:54Araqnote that hard real-time means provably no pauses.
21:10:57Araqthat surely is good enough for your phone...
21:11:08ldleworkAraq: and there are no downsides?
21:12:26Araqthe overhead is nicely spread out, but it's not zero. That would be your downside, I guess.
21:13:01Demoswait, how do people do hard real-time manual memory management?
21:13:21flaviuI'm not too convinced, the demand for that on Android is immense. There has to be some catch
21:13:55Araqyeah because the android technology stack is so good already ... er ... wait
21:14:36DemosI dobut it would work if you are allocating as much as a typical java program
21:15:27Araq*shrug* the fact is that most people who talk about GCs have no idea about GCs and have only touched some absurdly primitive GCs
21:16:44Demosyeah, I think languages should not use having a GC as an excuse to allocated everything on the heap
21:16:51Demosthen people would not hate them so much
21:17:14Araqthe "omg I can't use a heap" argument is also naive btw
21:17:34AraqO(1) alloc/dealloc is a solved problem, for instance
21:18:20flaviuAraq: O(1) isn't particularly essential. Constant factor is what really matters
21:19:12Araqflaviu: Thttp://www.gii.upv.es/tlsf/
21:19:28Araq"Fast. Additionally to a bounded cost, the allocator has to be efficient and fast enough. TLSF executes a maximum of 168 processor instructions in a x86 architecture. Depending on the compiler version and optimisation flags, it can be slightly lower or higher. "
21:20:03flaviuoh, I see how aicas works. It has a few essential threads that cannot be interrupted. To make such a realtime thread, you cannot use memory managed by GC.
21:20:28flaviu"For realtime threads not to be affected by garbage collector activity, these threads need to use memory areas that are not under the control of the garbage collector"
21:20:38Araqflaviu: er no
21:20:47Araqthat's just the general RTSJ spec
21:21:01Araqaicas doesn't require that at all
21:21:27flaviuAraq: It sounds like you have experience here. How does it do it then?
21:22:28Araqthe essential invariant is that everything reachable from the stack is also reachable via some heap based root. so no stop the world for stack marking is required.
21:23:21Araqnote that stacks are the only real problem for pauseless GCs to work.
21:28:41NimBotAraq/Nimrod bigbreak 4b61592 Araq [+0 ±1 -0]: minor bugfix for notFoundError
21:28:41NimBotAraq/Nimrod bigbreak 860a288 Araq [+0 ±1 -0]: fixes #1595
21:28:41NimBotAraq/Nimrod bigbreak 590461d Araq [+3 ±0 -0]: updated the test
21:28:41NimBotAraq/Nimrod bigbreak bbb1671 Araq [+0 ±3 -0]: Merge branch 'bigbreak' of https://github.com/Araq/Nimrod into bigbreak
21:30:20AraqDemos: one essential missing piece for CTE is 'os.changed'
21:30:38Araqthat returns true if some file changed since the last run
21:31:06Demoscan it be implemented at compile time with like a getDate function, I guess not
21:31:07Araqhowever "since the last run" is not clearly defined
21:31:09flaviuAraq: Actually, it looks like TLSF is one of the worse alligators: http://webkit.sed.hu/blog/20100324/war-allocators-tlsf-action
21:31:12Demosyeah
21:31:41flaviu"alligators" :P
21:32:40Araqflaviu: well "hard real-time" does not mean "fast", but "fast enough with provable worst case execution times"
21:33:18flaviuMost people don't care about though. "Fast enough" is what people care about
21:34:12Araqmost people argue for minimal jitter
21:34:19Demosright, so a GC without a massive deltas in the graph is good
21:34:28Araqthey simply don't even know what they argue for
21:34:47flaviuI sure hope that a single, slightly slower allocation won't push you over your time budget
21:35:15flaviuThere is an order of magnitude difference between GC freezes and possible malloc freezes
21:35:28Araqthese things are all blown out of proportion anyway
21:35:55flaviuAraq: No. I've had issues playing minecraft because of that jitter. And mobile games...
21:36:15Demosflaviu, because minecraft allocates a MASSIVE amount of memory each frame
21:36:24Demoslike 200+ MB/s
21:36:35flaviuDemos: Yep, but that's a recent increase
21:36:58flaviuThey're using boxed Vector2Ds now :/
21:37:06Demosyes. That was my point
21:37:11Araqyeah and I love it
21:37:23Demosallocating everything as a heap object is gunna be a problem
21:37:31Araqproves that these FP advices wrt immutable data is simply bullshit
21:37:43flaviuAraq: Immutable data on the stack :D
21:38:17Araqoh really? who does that? Haskell certainly does not.
21:38:28Araqwhich is the crown of everything
21:38:50flaviuhttps://stackoverflow.com/questions/5132350/how-do-haskell-compilers-decide-whether-to-allocate-on-the-heap-or-the-stack
21:39:06DemosAraq, don't I lot of persistent data structures require a lot of dynamic allocations?
21:40:03AraqDemos: persistent data structures are ultimately against the hardware works. on multiple levels.
21:40:41Araqimmutability really only works for scalars or when you don't have lots of data
21:41:48Araqand you only trade one set of bugs for another set of bugs anyway
21:45:14ldleworkAraq: what you're talking about right now is fascinating
21:45:17ldleworkand you should write a bit about it
21:46:36Araqyeah I know I should really write a book ... :-/
21:46:42DemosI think the nimrod compiler is him writing about it
21:47:01*Jesin quit (Quit: Leaving)
21:47:10Araq"everything you think you know about programming is wrong" ;-)
21:47:29Araqwould be the book title
21:47:38flaviuAraq: Just summarize it in a blog post
21:50:46AraqDemos: usually I program a 'changed' and a 'submit' which use checksums
21:51:10Araqbut it's a bit tedious
21:51:20ldleworkAraq: yeah just summarize your thoughts into an article, because then we can use that to seek out more information
21:52:01Araqldlework: there often is not more information easily available
21:52:19flaviuAraq: also, we can post it on reddit; they love linkbait titles
21:54:59ldleworkflaviu: who doesn't!?
21:55:31AraqDemos: any idea? can we somehow avoid 'submit'?
21:58:23Araqflaviu: we can first submit ldlework's article to reddit ...
21:58:34Araqor one of gokr_ 's ...
21:58:35ldleworkAraq: is it any good?
21:58:46AraqI like it
21:58:47ldleworkI haven't received any feedback
21:58:48flaviuCan someone post it?
21:58:51ldleworkWell that's good
21:58:55flaviuHere, I mean
21:59:06ldleworkhttp://blog.ldlework.com/a-cursory-look-at-meta-programming-in-nim/
22:00:35Araqwell you need to update at least one thing
22:00:44Araq"some work done to implicitly 'demote' a macro to its immediate form when you call it with undeclared arguments. "
22:01:12Araqthis is not how it works. you should say that it is possbile to unify immediate with non-immediate macros
22:01:22Araqand Nim is on its way in doing so
22:01:38Araqalso you should perhaps show off "currying a la Nim"
22:02:06ldleworkI think I did express that the need to tag was just a detail of on-going development?
22:02:19ldleworkAraq: or maybe we save the defect
22:02:20Araqthat was the only feature that I remember right now that has been discovered and not designed
22:02:23ldleworkso you can come in and correct me
22:02:28ldleworkpossibly spurring discourse?
22:02:48ldleworkwhatever you want
22:03:06Araqmeh, fine
22:03:16Araqpoke me until I do that
22:09:57Araqcan somebody compile babelpkglist.nim with 0.9.4 and the JS codegen and diff it against what 0.9.6 produces?
22:16:28*flaviu quit (Ping timeout: 250 seconds)
22:19:25*superfunc_ quit (Ping timeout: 246 seconds)
22:37:39*irrequietus quit ()
22:43:38VarriountAraq: Pong
22:44:57AraqVarriount: still some complaints about the installer
22:45:25Araqhttp://forum.nimrod-lang.org/t/604
22:45:40Araqthough I don't think we generate a link to the docs, do we?
22:46:04Araqand I don't think we really need to
22:46:52Araqoh wait we do
22:46:59Araqand it works for me?
22:49:10Araqhey
22:49:17Araqyou removed that feature
22:49:44VarriountI did?
22:50:48Araqyeah
22:50:58Araqoverview.html has no link anymore
22:51:30Demoswhere is the part in ldlework's article about currying?
22:51:44Araqit's completely missing :P
22:52:19Demosis there a link to them? I don't know about em
22:52:46Araqit's in system/excpt.nim
22:54:15ldleworkIs currying synonymous for function partials?
22:54:23ldleworkwait
22:54:27ldleworkI can't believe I just asked that
22:54:36*ldlework goes home and gets drunk.
22:55:10DemosI dont see it, just exception code with no comments to point me to where currying is used
22:55:22Demoswait found it
22:55:45Araqwell it's not "currying"
22:55:56Araqbut it reminded me of currying
22:56:30Demosyeah it is a template.... people who want currying will be disapoint
22:56:48Demosalthough currying should not be that hard to do, would need some special annotation (a function or operator)
23:12:03Araqwell strictly speaking currying is simply f_a(b) = f(a, b) iirc
23:12:15Araqit doesn't need special syntax
23:12:28Araqyou get the feature for free when you have proper closures
23:16:00Demosyeah
23:16:10Demosbut special syntax is what makes it deserve a name
23:18:04Araqnah, the idea behind is brilliant but simple
23:18:15Araqthat's why it deserves a name
23:18:18Joe_knockDemos: You shall be allowed to add your own specially flavoured currying if you can re-write Pandas in Nim
23:19:38*Boscop_ joined #nimrod
23:23:44*Boscop quit (Ping timeout: 255 seconds)
23:30:15*Jesin joined #nimrod
23:31:23*Jehan_ joined #nimrod
23:32:18ldleworkWell
23:32:28ldleworkI've pitched Docker on Nim
23:32:46ldleworkOr rather, I announced the existence of Nim to Dockerfolk and pointed them to my blog
23:32:53Joe_knockI'm pitching Jester to the guys at OpenShift
23:33:11ldleworkDocker is Golang to the core
23:33:20ldleworkAnd many peope here have cultish tendencies regarding it
23:33:25ldleworkSo we'll see how the response is :P
23:33:34*biscarch joined #nimrod
23:33:40Joe_knockDoesn't Docker pre-date Go?
23:33:57ldleworkJoe_knock: definitely not
23:36:09Joe_knockThe info about Docker is that it started in like 05/06/07 as something else
23:37:18ldleworkJoe_knock: the company used to be Dotcloud a paas
23:37:28ldleworkThe paas has internal technology to manage the paas's containers
23:37:42ldleworkThey pivoted and made that internal Python tech into Docker
23:37:51ldleworkwhich was ported to Golang
23:37:53Joe_knockinternal python?
23:37:55Joe_knockaah
23:38:36Araqhi biscarch welcome
23:38:53*Mat3 joined #nimrod
23:38:56Mat3hello
23:40:09biscarchAraq: hello
23:40:13Jehan_Araq: system.compiles seems to emit error messages when the argument doesn't compile? Is there a way to suppress it?
23:40:46AraqJehan_: I think that's a regression
23:41:00Jehan_Gotcha.
23:43:16ldleworkAraq: do you want me to post the article or is it better taste if someone else does?
23:45:04Araqldlework: dunno. let's ask skyfex to do it.
23:46:19*Jesin quit (Quit: Leaving)
23:47:43Joe_knockldlework: Are you pro-Python in your stack?
23:47:57ldleworkJoe_knock: I'm not sure exactly what you're asking
23:48:16Joe_knockldlework: Is that your preferred choice of language for most tasks?
23:48:22ldleworkOh definitely.
23:48:35*Jesin joined #nimrod
23:48:48ldleworkJoe_knock: I'm a DRY fetishist
23:49:00ldleworkPython gives me the ability to be overtly DRY for better or worse
23:49:07ldleworkUsing Golang makes me fucking insane
23:49:27Joe_knockI see your python interests go as far as Salt too.
23:49:56ldleworkJoe_knock: are you doxxing me right now?
23:49:57ldleworkhaha
23:55:00Araqldlework: congratulations. most programmers never make it to the thought "DRY taking seriously means a macro system"
23:57:25VarriountAraq: So, I'm making some progress setting up a buildbot for nim.
23:57:40VarriountIt's interesting, because the 'config' file is actually just a python script.
23:58:23VarriountIt would be nice (one day) if regular nimrod programs could make use of the compiler's VM, to do something like that.
23:58:36*Joe_knock doxxs ldlework
23:58:56ldleworkJoe_knock: :)
23:59:48Mat3ldlework: Does that mean you are impressed by golang ?
23:59:50*ARCADIVS joined #nimrod
23:59:59Jehan_Varriount: Have you considered executing an external Nim program that communicates via marshal.nim?