00:28:33 | reactormonk | dom96, pong |
00:28:45 | Araq | too late |
00:28:46 | reactormonk | dom96, yes, I kicked the github people. |
00:28:55 | Araq | he is sleeping |
00:29:54 | reactormonk | Araq, any idea on how to implement https://github.com/Tass/Nimrod/blob/bc1b8f4ccb497f01b849f2136939d2861e2f94c3/tests/run/tfinally.nim ? |
00:30:41 | Araq | reactormonk: dunno what the similar JS code would do? |
00:30:51 | Araq | did you check it? |
00:31:01 | Araq | I could imagine JS behaves the same way |
00:31:02 | reactormonk | Araq, the problem is the echo and \n |
00:31:22 | reactormonk | the test works, but the test runner doesn't like the multiline |
00:31:29 | Araq | ah |
00:31:57 | Araq | well that means output capturing on node doesn't work? |
00:32:14 | Araq | are you sure it's the newline? |
00:32:22 | Araq | maybe it doesn't work at all ... |
00:32:35 | reactormonk | sure, it's the newline. |
00:32:40 | reactormonk | the test parser doesn't like it |
00:33:58 | Araq | so if a node test produces a single line the tester likes it? |
00:41:24 | * | q66 quit (Remote host closed the connection) |
00:43:05 | reactormonk | yep |
00:43:15 | reactormonk | no love for mutli-line |
00:43:23 | reactormonk | parsing problem |
00:45:06 | reactormonk | so should I define stdout for node? |
00:46:29 | Araq | dunno if that would help |
00:46:35 | Araq | pong Zor |
00:47:26 | reactormonk | Araq, well, I need single line. https://github.com/Tass/Nimrod/commit/bc1b8f4ccb497f01b849f2136939d2861e2f94c3 |
00:47:44 | reactormonk | lemme run it |
00:54:03 | Araq | btw your patch looks good |
00:54:18 | Araq | and if you want to you may get write access to the repo |
01:04:07 | reactormonk | Araq, http://sprunge.us/BIBg |
01:05:09 | Araq | reactormonk: for multiline output put it into ''' ... ''' (triple single quotes) |
01:05:28 | reactormonk | ohh |
01:05:44 | Araq | that's tester specific ;-) |
01:06:26 | reactormonk | good to know. |
01:14:55 | reactormonk | Araq, how do I run the node tests? |
02:43:48 | * | Trixar_za is now known as Trix[a]r_za |
05:50:56 | * | Trix[a]r_za quit (Ping timeout: 240 seconds) |
05:53:50 | * | Trix[a]r_za joined #nimrod |
07:23:12 | * | gour joined #nimrod |
07:38:08 | gour | morning |
07:39:15 | gour | dom96: based on that picture of language popularity, it looks as it is very hard to be lower :-) |
07:42:50 | gour | or, we can say Nimrod can only improve ;) |
08:06:03 | Araq | gour: linguist had a bug where it wouldn't recognize nimrod code |
08:06:10 | Araq | this screws the statistics |
08:06:51 | Araq | also zahary showed up here recently so the bus factor is 2 :P |
08:56:32 | dom96 | gour: heh, indeed. It can only go up now, and as Araq said the stats were a bit false because of a bug in github's language detection thingy, but it's fixed now! |
09:01:22 | gour | if oyu would use bitbucket, statistics would be better ;) |
09:01:41 | gour | Araq: when did zahary show up again? |
09:01:58 | dom96 | if we used bitbucket there would be no statistics |
09:02:08 | Araq | gour: why does it matter? |
09:02:37 | Araq | 3 days ago or something |
09:03:05 | gour | dom96: why no statistics @bitbucket? |
09:03:28 | Araq | and why is this so concerning to you anyway? we've been working on it for years it won't disappear over night |
09:03:40 | dom96 | gour: Ask them, as far as I can see they don't provide any statistics. |
09:03:53 | gour | Araq: you mean in regard to zahary? |
09:04:09 | Araq | yes |
09:04:48 | gour | well, as I wrote to gradha yesterday, it's a bit risky seeing project with bus-factor 1 |
09:05:20 | gour | e.g. i't a bit depressing seeing how long it takes wxwidgets to release 3.0 or, at least, 2.9.5... |
09:06:47 | gour | Araq: i know you're quite determined, but wonder what would happen to Nimrod if you, for some reason, stop working on it? |
09:08:40 | Araq | I'm quite sure zahary would take over completely |
09:09:12 | Araq | also comex knows quite a lot of the compiler and the GC iirc |
09:09:37 | Araq | and dom96 will get there soon enough too ;-) |
09:10:02 | Araq | not to forget reactormonk who's working on the JS backend |
09:10:47 | Araq | but then I don't really think you're fair ... what happens if Matz leaves Ruby? |
09:10:56 | Araq | what if Guido leaves Python? |
09:11:21 | Araq | these languages will of course survive but it'll damage them too |
09:17:56 | Araq | oh ... and once idetools works better it should be a lot easier to navigate through the compiler to figure out how it all works; it's not that hard :P |
09:18:40 | gour | i know it's catch-22 situation...of course absence of Matz & Guido would damage languages, but there is enough investment in those as well a big-enough user/dev base to replace them |
09:20:18 | gour | i'm glad to hear some folks here could continue working on Nimrod, although never heard from some like comex, but i'm not sure that, besides required skills, they feel the same passion as you for the language |
09:20:28 | gour | ...which is even more important ;) |
09:26:59 | Araq | *shrug* the plan is to finish most important missing features this year anyway |
09:27:19 | Araq | and then mostly bugfixes need to happen |
09:27:41 | Araq | no need for that much passion after 1.0 is out :P |
09:28:14 | gour | here you considered missing 'language features' or some parts of the ecosystem as well (libs, build system...)? |
09:32:40 | Araq | language features |
09:33:02 | Araq | the stdlib is done by dom96 already |
09:33:55 | Araq | in fact, many people are writing libraries for Nimrod already so I don't see your point |
09:34:58 | gour | any 'critical' language features are missing which would make migration from 0.9 --> 1.0 cumbersome? |
09:35:32 | gour | of course, i was thinking about GUI, e.g. claro and/or gtk3 etc. |
09:41:24 | Araq | hmm lets see ... we have ~100K loc at least in the distribution ... do you think we'll make migration cumbersome? |
09:56:30 | gour | Araq: for you, being very capable dev, (almost) nothing is cumbersome, plus you have design in you head already |
11:06:04 | * | q66 joined #nimrod |
11:21:45 | reactormonk | Araq, how do I run the node tests? |
11:58:44 | Araq | reactormonk: I don't know whether I completed them :P |
11:59:40 | Araq | reactormonk: "tester js" should do it |
12:07:08 | reactormonk | Araq, doesn't run the ones in special.nim |
12:08:11 | Araq | well look at tester.nim please |
12:08:29 | Araq | it calls runJsTests which is defined in specials.nim |
12:09:39 | Araq | oh and beware ... I plan to get hit by a bus this weekend and then nimrod will be dead ... :P |
12:47:39 | gour | king is dead...long live the king :_} |
12:57:03 | Araq | gour: your concerns would be more valid if you were to develop extremely long lived commercial software with nimrod |
12:57:28 | Araq | but afaik you plan to develop some open source software |
12:57:58 | Araq | targeting a niche of users :P |
13:00:29 | Araq | and yet you act like it's some Nasa project |
14:50:22 | * | Zerathul joined #nimrod |
14:51:26 | Zerathul | I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people? |
15:19:09 | * | Zerathul quit (Ping timeout: 256 seconds) |
15:35:35 | gour | Araq: don't understand...for me my project has the value despite being open-source and i'm going to invest my time into it...would you invest in writing software to be used daily for several years knowing you have to rewrite all what is written next year? |
15:36:34 | gour | it has to be useful for me even i'd be the only user |
15:55:26 | * | ccssnet quit (Quit: http://atccss.net) |
15:56:34 | * | ccssnet joined #nimrod |
16:10:13 | Araq | gour: stop being concerned then and start programming |
16:12:37 | dom96 | gour: I don't know what you want Araq to tell you, no one can guarantee that Nimrod will be developed forever, no one can guarantee that any language will be developed for ever. Sure, a large user base makes it more likely. If Nimrod's small user base is a problem to you then use another language or help us get more users. |
16:18:19 | gour | dom96: i do not expect any guarantee by Araq since that's not possible...otoh, i just express my, hopefully, valid concern - that's all |
16:20:32 | dom96 | It is a valid concern, and I am quite aware of it. But talking about excessively will not get us anywhere. |
16:20:40 | dom96 | *about it |
16:21:34 | gour | well, i simply take opportunity to speak about it while i do not have time working on the project atm... |
16:40:21 | NimBot | Araq/Nimrod 47aca27 Araq [+1 ±2 -0]: bugfix: 'indexOf' for tuple fields works |
16:40:21 | NimBot | Araq/Nimrod 6af5c4e Araq [+0 ±5 -0]: debugger improvements |
16:40:21 | NimBot | Araq/Nimrod b21a41c Araq [+1 ±3 -0]: fixes #358 |
16:45:14 | Araq | reactormonk: you've been given write access to the repo |
16:45:41 | NimBot | Araq/Nimrod bc1b8f4 Simon Hafner [+0 ±3 -0]: nestedTryStmts removed... 4 more lines |
16:45:41 | NimBot | Araq/Nimrod e3613d0 Simon Hafner [+0 ±1 -0]: hack to include hti correctly |
16:45:41 | NimBot | Araq/Nimrod ba74ccd Simon Hafner [+0 ±3 -0]: used correct syntax for multiline results in tests... 3 more lines |
16:45:41 | NimBot | Araq/Nimrod c193996 Araq [+0 ±5 -0]: Merge pull request #359 from Tass/master... 3 more lines |
16:46:31 | NimBot | Araq/Nimrod 27f2e47 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds newSeq documentation example. |
16:46:31 | NimBot | Araq/Nimrod 78a6aa7 Araq [+0 ±1 -0]: Merge pull request #357 from gradha/pr_adds_newseq_documentation_example... 3 more lines |
16:47:24 | NimBot | Araq/Nimrod b510570 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds left alignment example to strutils. |
16:47:24 | NimBot | Araq/Nimrod f4d4ed8 Araq [+0 ±1 -0]: Merge pull request #356 from gradha/pr_adds_left_alignment_example_to_strutils... 3 more lines |
16:48:05 | NimBot | Araq/Nimrod 12f3b9a Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds babel package manager link to library index. |
16:48:05 | NimBot | Araq/Nimrod b7f71d4 Araq [+0 ±1 -0]: Merge pull request #355 from gradha/pr_adds_babel_link_to_library_doc... 3 more lines |
16:48:33 | NimBot | Araq/Nimrod 9a12832 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Implements `$` proc for a sequence of TRunes. |
16:48:34 | NimBot | Araq/Nimrod 27aa557 Araq [+0 ±1 -0]: Merge pull request #354 from gradha/pr_adds_stringyfication_of_runes... 3 more lines |
16:55:04 | * | Trix[a]r_za is now known as Trixar_za |
16:58:30 | * | gradha joined #nimrod |
16:59:46 | reactormonk | Araq, cool. policy? no --force? |
17:03:50 | reactormonk | Araq, next thingy to work on? |
17:20:31 | Araq | reactormonk: what about #347, #343 ? |
17:21:00 | Araq | policy: js stuff is pretty much yours I trust you to test your changes of course |
17:21:27 | Araq | for other changes I'd like to see diffs before you push |
17:22:06 | Araq | oh and #334 should be easy to fix for you too |
17:24:14 | * | exhu joined #nimrod |
17:24:34 | exhu | Araq, thanks for fixing that "indexof" thing! ;) |
17:45:28 | Araq | well I hope it works now |
17:45:45 | Araq | I think it still has issues within a unit test |
17:46:25 | Araq | funny thing that "unittest" actually tests the compiler more than your own code |
17:48:30 | Araq | exhu: I still think you should use macros for your ORM |
17:52:49 | exhu | Araq, I will use macros when the api is advanced and stable and well documented. |
17:53:14 | Araq | that's not how it works :P |
17:53:42 | Araq | it's of low priority then |
17:54:09 | exhu | i don't care, when it's ready -) |
17:55:51 | exhu | i prefer several features to be a part of language and not a tool to create those features (macros) anyway. |
17:56:23 | Araq | but then it's an ever growing set of language features |
17:56:54 | exhu | e.g. they introduced smart pointers in c++ as templates while i think they must be a part of language after using them in a huge project. |
17:58:57 | exhu | Araq, i don't criticize nimrod in that way, i'm very satisfied with the feature set already present. |
18:01:22 | exhu | Araq, the more features to be implemented as a library the more it will be like c++ "boost" library, which boosts complexity and building time -) |
18:02:01 | Araq | we'll see about that :P |
18:02:15 | Araq | we have "perfect" incremental compilation implemented :P |
18:02:25 | Araq | except that it's broken right now ;-) |
18:02:59 | Araq | brb |
18:03:32 | exhu | Araq, that's why i am not so concerned about future compilation time problems of nimrod macro libraries, its syntax is way better than c++ |
18:09:58 | exhu | and i'm also sure that there's no such thing as an ideal programming language |
18:10:43 | gradha | defining ideal is already difficult enough |
18:10:54 | exhu | e.g. compile-time procs and templates make runtime dynamic linking a problem. |
18:12:07 | gradha | AFAIK the binary library concept of nimrod is compile to c and use C bindings, so yes, that's out of the question |
18:12:53 | gradha | but at the nimrod level you distribute the source, so you get the original macro/template, what is the problem there? |
18:13:41 | exhu | i keep to "use the right tool for the job" and "keep it simple" principles. |
18:16:03 | exhu | the problem with dynamic linking arises when you want to develop a system in nimrod and provide the way to write extension modules to that system. e.g. app and dynamically loadable plugins, with shared transparent code. |
18:17:20 | gradha | IIRC Araq was working on an eval proc, so maybe it would be possible to distribute macros/templates along for dynamic linking, which would really be runtime compilation of linked code? |
18:18:05 | gradha | you would still be forced to distribute source code, no opaque binaries |
18:19:04 | exhu | yes, probably that feature, but i prefer GNOME (glib, gobject) all binary api way and nimrod is not suitable for this due to its advanced template/compilation-time features. |
18:19:54 | gradha | you aren't force to use such features if they are a problem and still use nimrod as a better c/c++ |
18:20:00 | exhu | anyway if i were to write a close-source app i would still prefer nimrod and provide plugins interface via LUA scripts or luajit. |
18:22:15 | dom96 | IIRC GTK contains macros in its API, so glib/gobject probably does too. And indeed, you do not need to use these features, if you want to provide templates as part of your API then you will need to distribute some sources. |
18:23:26 | gradha | macros/defines are a problem for C/C++, so I see more and more libraries which provide runtime procs which return the constants, so newer versions of the library can change them and you don't need recompilation for stuff to keep working |
18:23:52 | exhu | freepascal/lazarus has the same problem, but they provide lazarus opensource so that if you want to add a plugin, you just recompile the whole ide. |
18:24:03 | gradha | directx sizeof(param_struct) is epic in this regard |
18:24:54 | exhu | i keep my eyes away from directx -) i'm happy apple and google use opengl for their devices. |
18:25:42 | gradha | me too, I was meaning epic as in you need the string will of a crusader to touch their api, full of struct sizeof() trickery |
18:25:53 | gradha | or at least it was in the pre 9 days |
18:26:34 | reactormonk | Araq, didn't you want to do ther copy by value personally? |
18:26:36 | exhu | the last time i used it there was directx 5 around -) |
18:27:05 | gradha | and Carmack still bashed it |
18:29:52 | * | Trixar_za is now known as Trix[a]r_za |
18:31:30 | exhu | as soon as i finish my database application in nimrod, i'll start imlpementing 2d scenegraph library (opengl backend) for gui and games. |
18:33:01 | dom96 | exhu: Is your database app open source? |
18:33:17 | exhu | has anyone used opengl bindings recently? |
18:33:20 | exhu | dom96, yes |
18:34:30 | exhu | dom96, i've posted a github link several times here, https://github.com/exhu/Palitsa/tree/master/nimrod |
18:34:35 | Araq | reactormonk: true, I forgot it was that bug ;-) |
18:35:16 | Araq | gradha: I will give you write access to the repo too if you like |
18:35:35 | gradha | Araq: would it make any difference? You would still have to apply patches |
18:35:38 | dom96 | exhu: I can't believe I didn't star it. |
18:36:11 | * | dom96 shouts at github for getting the language stats for that repo wrong |
18:37:58 | dom96 | But now I see that it's not just getting Nimrod wrong, there is Python code in the repo and apparently the repo is 98.4% Java with the rest being "Other" |
18:38:02 | exhu | dom96, that repo contains sources in many languages |
18:38:21 | Araq | gradha: well I suppose I should really continue to read your documentation improvements, so yeah it wouldn't make much of a difference |
18:38:30 | exhu | dom96, i tried some to feel which language is better for the job =) |
18:38:57 | dom96 | exhu: Settled on Nimrod then? :) |
18:39:46 | exhu | dom96, looks like 4 months ago |
18:40:16 | Araq | exhu: DLL support works already if you don't use 'of' and multi methods across DLLs; the GC works across DLL boundaries |
18:40:50 | Araq | the 'eval' features I have been working on amounts to a Nimrod interpreter |
18:42:14 | dom96 | Araq: speaking of those features, do you have an ETA? |
18:43:09 | exhu | Araq, C++ has problems with DLLs too, i remember a project where dynamic_cast<> worked only on windows and not on linux, because exe and dll did not share the same talbe for RTTI. This was gcc-specific, i guess. |
18:43:52 | gradha | I think "Error cannot be passed to a procvar" just wants to be my friend |
18:44:17 | Araq | dom96: not really anymore it's still lots of work |
18:44:40 | dom96 | Araq: What are you working on currently? |
18:44:58 | Araq | hacking together some API could be done in an evening but then people will moan endlessly about it I think |
18:45:30 | gradha | more than on the license? |
18:45:33 | Araq | gradha: it will be as soon as you add a default parameter to an exported proc of the stdlib ;-) |
18:47:08 | Araq | dom96: fixing bugs and getting destructors to a workable state; overloading of '=' is also high on my todo |
18:47:37 | dom96 | Araq: If there is anything you want me to help with I'm all ears. |
18:48:35 | Araq | dom96: the scgi bug is embarrassing ... |
18:48:47 | dom96 | true. |
18:49:05 | dom96 | It's also boring to fix :P |
18:49:21 | Araq | bugfixes are always boring |
18:49:31 | Araq | only new features are exciting |
18:51:09 | Araq | oh and we should perhaps add template `@`(field: expr): expr = self.field to the stdlib |
18:51:56 | Araq | could be a boost to nimrod's popularity (yay! ruby-like!) |
18:52:33 | dom96 | I want a: macro with(...) = ... |
18:56:13 | Araq | huh? what do you mean? |
18:58:43 | dom96 | with object: field = "blah" |
18:58:52 | dom96 | # -> object.field = "blah" |
18:59:02 | Araq | that's incredibly ambiguous |
18:59:09 | dom96 | But now that I think about it, with the new object constructor syntax there is no need for it. |
18:59:10 | Araq | and I hate that feature of Delphi |
18:59:27 | Araq | it makes code quite hard to follow imho |
19:00:10 | dom96 | fair enough |
19:00:19 | Araq | tried the new constructor syntax yet? |
19:00:40 | dom96 | Not yet no. |
19:08:50 | gradha | Araq: would you accept an iterator version of foldl/foldr for sequtils or you want the full recursive thingy? |
19:09:35 | Araq | why would I want a full recursive thingy? recursion is meh ... |
19:09:55 | Araq | it's nice when you otherwise would need a stack |
19:10:14 | Araq | it's a religious thing if you use it for anything else |
19:11:40 | Araq | gradha: actually I want them to be templates instead |
19:12:31 | gradha | like filterIt? |
19:12:48 | Araq | templates work much better with the effect system and the "procvar" issue ;-) |
19:12:55 | Araq | like filterIt, yeah |
19:13:41 | gradha | it sure gets rid of the lambda |
19:15:22 | NimBot | Araq/Nimrod 8dd1d3e Araq [+0 ±2 -0]: fixes #323 |
19:15:22 | NimBot | Araq/Nimrod 963bd9a Araq [+0 ±9 -0]: Merge branch 'master' of github.com:Araq/Nimrod |
19:16:35 | NimBot | Araq/Nimrod 561c250 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds example to instantiationInfo docstring. |
19:16:35 | NimBot | Araq/Nimrod 479bafe Araq [+0 ±1 -0]: Merge pull request #360 from gradha/pr_adds_example_to_instantiationinfo_docstring... 3 more lines |
19:18:49 | dom96 | Nimbuild certainly has a lot of work today. |
19:22:29 | dom96 | cool, newest member of our Nimrod family is someone who is involved with factor. |
19:24:04 | * | ack006 joined #nimrod |
19:24:30 | ack006 | dom96: hi, thanks for the invite :-) |
19:24:51 | dom96 | ack006: Awesome, i'm glad you accepted it :D |
19:24:54 | ack006 | i'm the archer who dared to send you that PKGBUILD ;-) |
19:25:29 | ack006 | nimrod is an absolutely awesome language, needs some more press to get people interested tho. |
19:25:43 | dom96 | Totally agree. |
19:25:59 | ack006 | they even dared to kick the nimrod page off of wikipedia, such a _shame_ |
19:26:03 | gradha | do you have a blog ack006? |
19:26:22 | dom96 | ack006: interesting, how long have you been following nimrod development? |
19:26:26 | ack006 | gradha: no, not yet, but willing to start one just to promote nimrod :-) |
19:26:47 | ack006 | tho i will not have many googlepoints yet when just starting hihi |
19:26:53 | dom96 | You should, i'm starting one just for Nimrod. |
19:27:25 | gradha | no problem, we will all link you from our non existing blogs to page rank you higher |
19:27:33 | dom96 | We could work as a team :D |
19:27:35 | ack006 | it really is the language i have been dreaming about for a long time. was about to seriously think about designing my own, luckily i found you! :-) |
19:27:53 | ack006 | saves me 10 years at least & lots of gray hairs :-) |
19:28:22 | ack006 | dom96: love to! |
19:28:48 | dom96 | We shall spam reddit with the tales of our great adventures with Nimrod! |
19:28:55 | ack006 | ha!!! |
19:29:00 | ack006 | yes! |
19:29:04 | dom96 | :) |
19:30:30 | Araq | hi ack006, welcome :-) |
19:31:11 | ack006 | Araq: thanks! thanks for this wonderful language |
19:31:27 | ack006 | i really really can't imagine why you're not better known |
19:31:41 | gradha | Araq doesn't post on facebook |
19:31:56 | ack006 | i searched all over, from lambdatheultimate to hackernews |
19:32:18 | ack006 | all pps go 'hm nice work, could be better tho, hmm will look at it sometime' |
19:32:32 | ack006 | you only need to spend about 5 minutes with nimrod to know it's awesome |
19:33:35 | ack006 | i think many people are so high on haskell (the time they put in to wrap their head around monads) that they're not willing to acknowledge anything else. |
19:33:38 | dom96 | yes, I don't get it either. Maybe once 0.9.2 is released and we put the new website up we will get some more interest. |
19:33:46 | dom96 | Everyone is a sucker for slick websites. |
19:34:11 | dom96 | hehe, I was once high on haskell, and then I found Nimrod :P |
19:34:24 | ack006 | new website? i already like the current one :-) |
19:34:32 | Araq | ha!!!! |
19:34:37 | Araq | see, dom96? |
19:34:50 | gradha | hmm... python doesn't seem to have a strong following on facebook https://www.facebook.com/pythonlang so we only need 70K+ likes to be better |
19:35:28 | ack006 | that's because secretly all facebook employees switched to python cause ruby is too slow ;-) |
19:35:51 | ack006 | and they don't want to admit using python (just joking!) |
19:36:06 | ack006 | soon they will be using Nimrod anyway! |
19:36:09 | gradha | well, maybe their php compiles to python |
19:36:26 | dom96 | Araq: Yes, I see. Lets just throw away filwit's design then yeah? :P |
19:36:27 | Araq | they compile their php to c++ |
19:36:33 | ack006 | well at least pascal compiles to nimrod. nice one, too! |
19:37:09 | Araq | except that there is no non-OO pascal left ;-) |
19:37:20 | ack006 | anyway, i really like the language, and as soon as i know more about it, i'd like to contribute. |
19:37:23 | Araq | it's nice to translate the pascal wrappers though |
19:37:46 | ack006 | and c too, i saw. |
19:38:08 | Araq | c2nim is much better than pas2nim now I think |
19:38:13 | ack006 | aha |
19:38:20 | Araq | because c2nim is maintained ;-) |
19:38:26 | ack006 | :-) |
19:39:59 | ack006 | too bad i couldn't bootstrap from git today, sadly install.sh mismatch again |
19:40:28 | ack006 | i would like to help out with that, only need to know why it's setup the way it currently is. |
19:41:11 | ack006 | yes, of course i can use Nimrod from within the tree, but i'm maintaining a local package too. |
19:41:41 | Araq | ah so you're that guy |
19:41:53 | Araq | well ... your solutions sounds good |
19:41:54 | ack006 | yup :-) |
19:42:24 | Araq | except that many people want us to remove the csource.zip from the git repo |
19:42:54 | Araq | as the repo is pretty large because of these binary files |
19:43:03 | ack006 | would be even better, i thought that there's some kind of download service on github too |
19:43:27 | ack006 | you could always put it in its own repo and ask people to get the zipball |
19:43:52 | Araq | well I have to prune history for it and it will break every fork |
19:44:03 | ack006 | yup, thought so. |
19:44:03 | Araq | that's why I haven't done it already |
19:44:45 | Araq | we can easily have a dummy file for nimbuild to trigger a rebuild |
19:45:06 | ack006 | ah nimbuild, a kind of build service? |
19:45:16 | ack006 | have you thought about travis? |
19:45:45 | Araq | we have our own CIS written in nimrod |
19:45:54 | ack006 | ah of course :-)) |
19:46:13 | ack006 | is there anything you don't have, warp drive or something ;-> |
19:48:20 | Araq | I've been working on a remote debugger written in nimrod ... |
19:48:34 | Araq | but decided there are more important things to do ;-) |
19:48:50 | dom96 | Sadly the only thing we don't really have is a bigger community. |
19:49:12 | Araq | (or commercial support ... *cough*) |
19:49:29 | dom96 | Yeah, true. |
19:49:39 | ack006 | Araq: may i ask how long have you been developing Nimrod? it already has such interesting features...must be quite some time. |
19:49:46 | ack006 | are you using it for business as well? |
19:49:47 | * | gour waves with the GUI lib transparent |
19:53:03 | Araq | ack006: it took from 2004 till 2008 to get it into bootstrapping stage iirc |
19:53:46 | Araq | or maybe from 2006 it's hard to tell as I always had code lying around dealing with ASTs and lexing |
19:54:07 | ack006 | wow :-) |
19:54:42 | ack006 | really really nice work. i'm getting more and more interested in compiler design, parsing, etc. as well |
19:55:25 | ack006 | began when i discovered factor, which also bootstraps itself, but from a pre-existing image like many smalltalk/squeak/some lisps etc. |
19:55:56 | Araq | factors is quite cool but dynamic typing is a show stopper for me |
19:56:02 | ack006 | the horror and nightmares thinking back to how we used to do this with lex/yacc at university. |
19:56:32 | ack006 | yep for me too, it is what kills its speed i think |
19:57:02 | ack006 | like the 'each' word having to deal with fried quotations, more quotations, etc. |
19:57:43 | ack006 | when i view the call stack it is bursting with quotations that i think need recompiled on every type change |
19:57:51 | ack006 | must be killing performance dead. |
19:58:27 | dom96 | Araq: we need to resolve on that sockets.recvLine vs asyncio.recvLine issue. Thought about how it should be solved? |
19:58:27 | ack006 | and using TYPED: for each and every word would turn it into a statically typed language anyway, except much more wordy. |
19:58:40 | dom96 | s/on// |
19:59:09 | Araq | ack006: that's Lisp's problem too |
19:59:13 | ack006 | dom96: you go about your lofty business, i'll drop in some time later :) |
19:59:41 | Araq | dom96: sockets.recvLine shouldn't be changed again I think |
20:00:01 | dom96 | ack006: hrm? Are you leaving? |
20:00:50 | ack006 | nonono! i'm just gonna be afk for just a bit |
20:01:41 | dom96 | oh alright. |
20:01:44 | ack006 | need to get some food into me :-) |
20:02:43 | dom96 | Araq: I think it should be. |
20:03:25 | Araq | dom96: we need some deprecation plan for sockets I think |
20:03:41 | Araq | that asyncio is an ever moving target can't be avoided |
20:04:07 | Araq | it needs to changed to make use of first class iterators |
20:04:21 | dom96 | For some reason it's quite hard to predict these practical issues. |
20:04:27 | Araq | once they got a bit more stable |
20:05:31 | dom96 | I don't think it's a good idea for recvLine to return false on error mainly because it seems so innocent. |
20:05:39 | Araq | maybe we should introduce 'fetchLine' and 'fetch' and deprecate 'recv' as a term |
20:06:11 | dom96 | I would prefer 'read' |
20:06:15 | dom96 | 'fetch' sounds very odd |
20:06:29 | Araq | *shrug* ok |
20:06:40 | dom96 | But I don't want to deprecate 'recv' |
20:06:57 | Araq | well only deprecate recvLine then |
20:07:28 | dom96 | and replace it with what? |
20:07:38 | Araq | readLine |
20:08:08 | Araq | I sometimes also use 'deprecated' to *mark* an upcoming change |
20:08:25 | Araq | and then change the signature and remove the 'deprecated' again ;-) |
20:08:54 | Araq | but I guess people dislike that |
20:11:49 | exhu | what are the first class iterators? |
20:13:31 | Araq | exhu: http://build.nimrod-code.org/docs/manual.html#first-class-iterators |
20:13:49 | Araq | have a look at the tasking example in this section |
20:14:02 | dom96 | I don't think it's a good idea to change the name of the proc. |
20:14:19 | dom96 | argh, but we can't deprecate based on return value. |
20:14:29 | Araq | exhu: C#'s await/async can be built with them too |
20:17:33 | Araq | dom96: what do you mean? you can deprecate a single overload |
20:18:14 | dom96 | I can't overload recvLine by creating the same proc but with 'void' as the return type though. |
20:18:16 | exhu | Araq, nice, it seems there have been added several features since the last time i looked into manual. |
20:18:44 | Araq | exhu: keep in mind it's the manual from nimbuild |
20:18:54 | Araq | 0.9.2 is still not out |
20:19:35 | exhu | Araq, about the recently fixed indexOf, the exception clause is not thrown further, the compiler displays only "can't evaluate 'indexof ..."" message. |
20:19:57 | exhu | Araq, in case of passing non-existing field name. |
20:20:37 | Araq | that's because it's a compiletime proc ... |
20:20:43 | exhu | Araq, it's not that important anyway |
20:21:00 | Araq | good, it's perhaps impossible to fix :P |
20:21:17 | Araq | the compiler evaluates the 'raise' at compile time too :P |
20:21:38 | Araq | or do you mean the error message is unhelpful? |
20:21:54 | exhu | Araq, the error message is meaningful anyway, so it's not a problem. |
20:30:18 | gradha | release builds don't check sequence out of index accesses, is that right? |
20:31:46 | Araq | gradha: correct |
20:39:55 | * | exhu quit (Quit: Ex-Chat) |
20:45:38 | dom96 | Araq: ugh, this scgi stuff is too much work. |
20:45:57 | Araq | dom96: why? :-/ |
20:46:37 | dom96 | Araq: Because I don't know how to implement it, which means I'd need to spend a considerable amount of brain power thinking about it. |
20:47:34 | Araq | well maybe you can start with explaining to me what the actual problem is |
20:50:11 | dom96 | Actually i'm not entirely sure it is a problem. |
20:50:32 | dom96 | Simultaneous file downloads from Nimbuild are possible, aren't they? |
20:50:49 | dom96 | I think nginx basically handles what needs to be done. |
20:50:56 | dom96 | Larger files may cause problems though. |
20:51:08 | dom96 | But ok, let me describe what happens. |
20:51:52 | dom96 | You request a file, a handleRequest proc is called, this handleRequest proc sees that you are requesting a file so you read the file requested into memory and send it on its way. |
20:51:56 | ack006 | i'm back :-) |
20:52:10 | dom96 | If the file is large of course then it will block. |
20:52:48 | ack006 | dom96: what's hard in scgi? it's supposed to be 'simple' :-) |
20:53:24 | ack006 | had to deal with it a bit for the julia web repl (julia = nice language too btw) |
20:55:33 | ack006 | dom96: here's one in python :-) : http://www.cherokee-project.com/download/pyscgi/ |
20:56:32 | ack006 | and no, it doesn't depend on half of cherokee to do the job, just socketserver & some standard libs |
20:57:24 | dom96 | ack006: The problem is designing it so that it works nicely with our current asyncio module. |
20:58:54 | ack006 | aha :) |
20:59:22 | ack006 | asyncio module anything like nodejs's? |
21:02:06 | dom96 | No idea. It's loosely based on Python's asyncore module |
21:02:16 | ack006 | ok |
21:03:37 | ack006 | this one maybe? http://pydoc.net/Python/wsgitools/0.2/wsgitools.scgi.asynchronous/ |
21:06:00 | dom96 | it's not scgi specific |
21:06:09 | ack006 | :( |
21:06:15 | dom96 | http://docs.python.org/2/library/asyncore.html |
21:06:27 | dom96 | Nimrod docs: http://build.nimrod-code.org/docs/asyncio.html |
21:06:48 | Araq | ack006: we already have an scgi module and it's used for nimbuild |
21:09:42 | ack006 | ok, got it :-) |
21:14:11 | Araq | dom96: we can use multi-threading |
21:14:25 | Araq | but that defeats much of the point of asyncio |
21:14:35 | dom96 | We could also somehow verify that everything that happens in your request handlers is asynchronous. |
21:14:40 | dom96 | perhaps with effects? |
21:14:44 | Araq | indeed |
21:15:07 | Araq | effects are made for these kind of things |
21:15:15 | dom96 | good |
21:15:59 | Araq | except FAsyncIO is a subtype of FIO so can't really work |
21:16:21 | Araq | but a better effects system is planned already ;-) |
21:16:30 | dom96 | oh? |
21:16:33 | reactormonk | Araq, so you have an object and an effect hierarchy? |
21:16:42 | Araq | reactormonk: yeah |
21:16:55 | Araq | but the effects system will be greatly improved |
21:17:40 | Araq | it's necessary for the concurrency modell too so this feature will get lots of love ;-) |
21:17:46 | reactormonk | Araq, why not use the object hierarchy? |
21:18:12 | Araq | reactormonk: because hierarchies suck |
21:18:57 | Araq | they are never expressive enough |
21:19:28 | reactormonk | Araq, graph? |
21:19:39 | Araq | (plus I always get the co-/contravariance wrong :P ) |
21:19:59 | Araq | (which means it's likely to be too complex for everybody else to grasp too :P ) |
21:20:31 | dom96 | The good thing is that we can use the PDispatcher object to contain all these async jobs. |
21:22:35 | dom96 | Araq: btw I don't think you ever fully helped me fix jester |
21:23:07 | Araq | dom96: I told you to insert 2 immediate pragmas which made it work for me |
21:23:29 | Araq | reactormonk: parametrization is the keyword |
21:23:32 | dom96 | yes, and I told you that I was getting weird conflicts between httpclient.request and jester.request. |
21:23:58 | Araq | well... I missed that part, dom96 |
21:24:21 | reactormonk | Araq, generics? |
21:24:23 | Araq | but I'm back at working on the template overloading anyway |
21:24:34 | Araq | reactormonk: yeah quite like generics |
21:24:41 | dom96 | Araq: no worries, please try adding 'import httpclient' to nimbuild/github.nim and then compiling it. |
21:25:36 | Araq | dom96: remind me later |
21:26:19 | * | gour quit (Disconnected by services) |
21:26:20 | * | gour_ joined #nimrod |
21:28:15 | gradha | when value is a sequence I'm using type(value[0]) to figure out the type of the contained objects, is that right or is there a better way? will that fail for zero length sequences (inside a template)? |
21:28:53 | dom96 | Araq: ok, but don't put it off too much. It's a showstopper for Nimbuild and nimforum. |
21:30:08 | gradha | ok, at least it compiles (makes sense) |
21:30:38 | gradha | still, rfc on the style of type(value[0]) |
21:37:56 | * | gour_ is now known as gour |
21:38:41 | Araq | gradha: type(value[0]) is fine |
21:57:19 | * | fowl joined #nimrod |
22:08:50 | Zor | Araq: btw, how do you lower your AST to C? |
22:08:53 | Zor | do you 'flatten' it first? |
22:11:01 | Araq | there are a couple of AST->AST transformations but it's not flattened |
22:11:44 | Araq | we use the same representation everywhere kind of like LLVM does |
22:12:18 | Zor | so do you just recursively translate your AST? |
22:15:30 | Araq | yes. I wouldn't say "just" though ... |
22:16:33 | Zor | why is there an executable text file in the nimrod repo o_O |
22:16:48 | gradha | IIRC there are lots o them |
22:17:17 | gradha | possibly due to using git on freedos |
22:17:43 | Araq | it's some windows<->linux migration issue, yeah |
22:18:32 | gradha | I wonder, does it make sense to mark build.bat as an executable? it is under windows, but not through the executable bit |
22:19:13 | Araq | fix it, I don't care |
22:23:00 | * | Trix[a]r_za is now known as Trixar_za |
22:26:45 | gradha | it seems you don't care about .gitignore either |
22:27:29 | Araq | true but what's wrong with the .gitignore? |
22:27:59 | gradha | it pollutes the output of git status after a build |
22:28:11 | gradha | well, the lack of it |
22:35:31 | dom96 | It's not easy to .gitignore all these binary files that the tester generates |
22:37:00 | Araq | it would be easy if unix used '.exe' extensions ... ;-) |
22:37:12 | gradha | nothing prevents you from doing so |
22:38:07 | ack006 | Araq: what are the parameters that you use when running ./cook csources? |
22:38:28 | ack006 | i'm working on the bootstrap stuff, need to know what to pass in |
22:39:14 | ack006 | koch ?! cook, i translated it, sorry :-) |
22:39:26 | gradha | don't worry |
22:39:40 | gradha | btw, do you happen to like gladiator films? |
22:39:50 | ack006 | how so? |
22:40:00 | gradha | benhur, spartacus... |
22:40:10 | ack006 | wow heavy :-) |
22:40:32 | gradha | just kidding, I often make the same mistake |
22:41:01 | ack006 | well, i'm more of the 'T'ai Ch'i Master' kind of guy. too much violence in todays movies |
22:42:43 | gradha | you don't like xml? |
22:42:44 | ack006 | i've got todays 'broken' bootstrap working by just adding "csource(args)" at the end of "boot(...)" in koch.nim. proves that it's possible |
22:42:57 | Araq | ack006: I use 'koch boot -d:release' |
22:43:13 | Araq | but many use 'koch boot -d:release -d:useGnuReadline' |
22:43:48 | ack006 | but how do you normally build the c sources? i need to know what to pass on to niminst, trying to make it generate only install.sh, nothing else. |
22:44:49 | Araq | 'koch csource -d:release' |
22:45:17 | Araq | gradha: that's actually not a bad idea for the testing |
22:45:23 | ack006 | ah ok, was worried you passed in more obscure vars i don't yet now about :-) |
22:47:42 | ack006 | then it would just be a matter of adding a new target like "niminst installscript" or something like that |
22:52:26 | Araq | well it's easy to do anyway |
22:53:35 | ack006 | i'm doing it already, could be nice first contribution i hope :-) |
22:53:46 | Araq | indeed |
22:56:19 | reactormonk | what do you use for DNS? |
22:57:38 | gradha | Araq: if you decide to break github history maybe it would be convenient to rename the current repo and create a new one, so at least the old history is not discarded for archeologists |
23:00:20 | * | gour quit (Quit: WeeChat 0.4.0) |
23:02:22 | Araq | reactormonk: what the OS provides? |
23:02:36 | Araq | gradha: hrm, what repo name would you suggest? |
23:03:24 | dom96 | Araq: how would you like the asyncio module to use first class iterators? |
23:03:46 | reactormonk | Araq, for hosting DNS |
23:04:40 | Araq | dom96: yeah |
23:04:58 | Araq | reactormonk: why is that important to you? |
23:05:06 | dom96 | Araq: How? |
23:05:35 | dom96 | reactormonk: why do you want to host your own DNS? |
23:05:40 | gradha | Araq: maybe thelanguageformerlyknownasnimrod and use the chance to rename nimrod to gamera |
23:06:09 | gradha | besides, the github guys are going to love new linguist patches for a rename |
23:06:37 | dom96 | if you get rid of the current repo you'll get rid of all the stargazers :( |
23:06:39 | reactormonk | dom96, nah, just an A record |
23:07:09 | dom96 | reactormonk: still, why? |
23:12:09 | Araq | dom96: ugh that's hard to explain |
23:12:19 | Araq | I need to find some link ... |
23:13:14 | reactormonk | dom96, for my current ip. owncloud. |
23:14:19 | ack006 | boot strapped, it worked :-) now i just need to sit and meditate on some sane names for the procs and all |
23:15:01 | ack006 | i h8te finding names for things, and refactoring ba and zillions of files, lucky me here it's only 2... |
23:15:19 | dom96 | ugh, I need to organise my Nimrod todo list better. |
23:16:01 | gradha | tip: if you finish your todos, you will also organise the list by keeping it empty |
23:19:07 | ack006 | isn't that the gtd mantra? or is it that other one about keeping your inbox empty? |
23:21:39 | gradha | not sure, I can easily delete my inbox without getting things done |
23:28:59 | dom96 | Write an app which deletes your inbox, then you only have to do some work once and let your app take care of the rest. |
23:29:34 | ack006 | gradha: :-D |
23:29:37 | gradha | you could use approved Knuth methods and get a secretary to deal with your mail |
23:30:20 | dom96 | Write an AI to deal with your mail, it's cheaper. |
23:30:47 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
23:32:46 | ack006 | Letter: "You've won the lottery! The prize is in bearer bonds, anyone can cash them". What's the AI going to do now? Turing test maybe? |
23:33:24 | dom96 | It will obviously send your credit card details. |
23:34:14 | ack006 | greedy(human). :- gimme(more). ? |
23:34:43 | ack006 | does not compute, infinite loop, bzzzzzz |
23:35:15 | Araq | wow prolog syntax, I'm impressed |
23:35:23 | ack006 | ;-) |
23:35:57 | ack006 | not too many people know it today, i once had a dream of convincing Linus he should use it to configure the kernel |
23:36:36 | ack006 | would have found those "select FEATURE" bugs years ago |
23:37:26 | ack006 | but since he f#$@ed off Eric S Raymond, I didn't even bother |
23:37:39 | Araq | I dreamed of a language that lets you distinguish between pointers pointing to kernel memory and pointer pointing to user level memory |
23:37:58 | Araq | nimrod's type system is almost there now ;-) |
23:38:20 | ack006 | keep up the good work! :-) |
23:39:01 | Araq | isn't fucking off raymond a good idea anyway? |
23:39:36 | ack006 | well, not if he tried to convince Linus by building an effing SAT solver to prove his point |
23:40:04 | ack006 | and the current kbuild is anything but sat, let alone solver |
23:40:32 | Araq | a SAT solver is not that much work, is it? |
23:40:54 | ack006 | well, this one is tristate, as the kernel config symbols are |
23:41:12 | Araq | map it to boolean logic first ;-) |
23:41:22 | ack006 | boolean SAT is difficult enough, imagine tristate |
23:41:38 | ack006 | and the "select" bug was exactly one such problem |
23:42:20 | ack006 | well, trivial to me, i saw it coming, i worked with the linux-media dvb drivers, where it was used to select tuners |
23:43:13 | ack006 | if your var's value is one of 'Y', 'M' or 'N', and you select another var, what should it's value be? |
23:44:42 | ack006 | easy enough, the 'minimum' of your var and the other var's 'maximum' |
23:45:08 | Araq | yeah |
23:45:18 | ack006 | took a whole lot of time for linux to catch up with that, fix was about two years ago. |
23:46:18 | ack006 | my guess is that a correct prolog ruleset would have found it in ~ a few millisec. |
23:46:57 | Araq | what about getting rid of memory overcommitting as the default and encouraging users to use posix_spawn? |
23:47:29 | ack006 | ah but today's kids want to do it in haskell and do it with fancy typeclasses and such. |
23:48:44 | ack006 | http://lwn.net/Articles/317814/ |
23:50:47 | Araq | already know that article |
23:50:54 | ack006 | :-) |
23:51:10 | Araq | ack006: do you know how to allocate memory on a 64K boundary with mmap portably? |