00:53:25 | * | Trix[a]r_za is now known as Trixar_za |
01:07:43 | * | q66 quit (Remote host closed the connection) |
01:57:22 | * | Trixar_za is now known as Trix[a]r_za |
02:02:29 | * | dom96 joined #nimrod |
02:02:29 | * | Araq joined #nimrod |
02:37:50 | * | fowl_ quit (Ping timeout: 256 seconds) |
04:54:31 | * | fowl joined #nimrod |
09:50:12 | * | zahary1 joined #nimrod |
10:09:21 | * | zahary1 quit (Quit: Leaving.) |
10:10:20 | * | Trix[a]r_za is now known as Trixar_za |
10:21:19 | * | q66 joined #nimrod |
10:43:15 | * | zahary1 joined #nimrod |
10:54:05 | * | zahary1 quit (Quit: Leaving.) |
10:59:00 | * | zahary1 joined #nimrod |
11:09:48 | * | zahary1 quit (Quit: Leaving.) |
11:26:18 | * | Trixar_za is now known as Trix[a]r_za |
12:36:53 | * | fowl quit (Ping timeout: 248 seconds) |
12:50:17 | * | fowl joined #nimrod |
13:57:43 | * | ack006 joined #nimrod |
14:36:28 | * | Mathnerd626 quit (Read error: Connection reset by peer) |
15:00:19 | * | zahary1 joined #nimrod |
15:00:45 | * | zahary1 quit (Client Quit) |
15:01:06 | * | zahary1 joined #nimrod |
15:01:11 | * | zahary1 quit (Client Quit) |
15:01:31 | * | zahary1 joined #nimrod |
15:06:32 | * | zahary1 quit (Quit: Leaving.) |
15:06:43 | * | zahary1 joined #nimrod |
15:14:23 | * | Mathnerd626 joined #nimrod |
16:17:58 | * | fowl quit (Ping timeout: 258 seconds) |
16:19:45 | * | fowl joined #nimrod |
16:51:32 | * | fowl quit (Ping timeout: 256 seconds) |
17:10:28 | dom96 | So, currently some modules which are "async" are not in fact fully async. |
17:11:12 | dom96 | The request closures get a TSocket client when they should get a PAsyncSocket. |
17:12:20 | dom96 | This however poses a problem because any operation on an async socket will not block, so data which is required in the next line of code is not there yet. |
17:13:25 | dom96 | We can either use extra callbacks to get around this, or use iterator closures and yield out of the iterator when there is not yet any data available. |
17:14:41 | dom96 | The dispatcher can then go back into the iterator once some specified event occurs (the yield can specify what event it wants to wait for, in most cases this will be a "data is available" event). |
17:16:29 | dom96 | What do you guys think is the best way to handle this? I'm leaning towards iterators. |
17:18:02 | Araq | iterators ftw |
17:18:47 | Araq | that's exactly what first class iterators have been designed for :-) |
17:19:23 | * | fowl joined #nimrod |
17:21:42 | dom96 | Araq: cool. Should this mechanism be simply contained to asyncio then? |
17:21:57 | Araq | sure thing |
17:22:01 | dom96 | or are you willing to provide language support for this? |
17:23:23 | dom96 | It would be pretty sexy if we could do: proc (..) {.async.} or something :P |
17:23:42 | dom96 | but I suppose I can implement it and we can always make it nicer. |
17:24:20 | Araq | dude, async is a simple macro |
17:25:32 | dom96 | can I transform a proc (..) {.async.} into some sort of iterator automagically? |
17:25:41 | Araq | yes |
17:25:51 | dom96 | Would need to be in a block though wouldn't it...? |
17:25:58 | Araq | hell no |
17:26:11 | dom96 | can macros be executed based on a pragma that is used? |
17:26:25 | Araq | proc p {.m.} |
17:26:29 | Araq | is rewritten to: |
17:26:31 | Araq | m: |
17:26:33 | Araq | proc p |
17:26:44 | Araq | that's been implemented since forever |
17:26:56 | Araq | nothing needed on your part for that to work |
17:27:25 | Araq | I think it's even in the manual :P |
17:27:54 | dom96 | cool |
17:28:07 | dom96 | it is indeed. |
17:28:33 | dom96 | Well, this looks like fun :P |
17:28:56 | dom96 | And as always I don't have enough time. |
17:47:22 | fowl | i decide to write a macro for parseopt today |
17:49:56 | dom96 | Have you seen gradha's module? |
17:49:57 | dom96 | https://github.com/gradha/argument_parser |
17:51:08 | fowl | yea it looks clunky |
17:54:33 | fowl | the examples are huge, way too many lines for argument parsing |
17:55:03 | Araq | hey, gradha wanted it to be compatible to some C library iirc |
17:55:53 | Araq | I told him he couldn't match the stdlib's parseopt anyway and so he didn't try :P |
17:56:23 | fowl | my goal is to plug this parseOptions: on "-f", "--file": file = value into the standard parseopt example thats in the docs |
17:57:54 | dom96 | Well alternatives are always good. I must agree with fowl, gradha's module feels a bit heavy. |
17:58:43 | Araq | fowl: I can't follow |
17:59:42 | dom96 | perhaps we should consider including a nicer module on top of parseopt in the stdlib, maybe even fowl's module. |
18:00:21 | Araq | the only problem with the current parseopt is that it doesn't support --key val as opposed to --key:val easily |
18:01:15 | Araq | we can add some macro for "nicer" usage too of course but then it's only nicer if you're on some religious war against string case statements |
18:01:51 | dom96 | yeah. Many people are strong believers in writing as little code as possible :P |
18:07:31 | Araq | the macro can't save more then 1-2 lines of code though |
18:17:10 | fowl | hrm im getting an error i dont understant |
18:17:12 | fowl | d |
18:19:16 | Araq | well? |
18:20:01 | fowl | going to post the code hwne i can |
18:20:14 | fowl | im on my cell phone internet, terrible service |
18:20:24 | * | gradha joined #nimrod |
18:26:03 | * | fowl quit (Read error: Connection reset by peer) |
18:28:40 | * | fowl joined #nimrod |
18:28:47 | fowl | https://gist.github.com/fowlmouth/5327093 |
18:32:25 | Araq | fowl: maybe that's because you do !!"key" instead of !"key" |
18:33:00 | Araq | I'm not sure what your !! does though ;-) |
18:33:32 | fowl | !!(a:string) = newIdentNode(a) |
18:34:00 | Araq | oh |
18:34:09 | Araq | I thought it may be using bindSym |
18:34:19 | Araq | try bindSym then |
18:34:27 | fowl | could it be a problem that kind,key,value are syms and not idents |
18:34:37 | Araq | yeah that's the problem |
18:34:54 | Araq | 'quote' perhaps does not the proper thing |
18:36:45 | Araq | yeah ... it seems to perform some semantic checking :-/ |
18:37:32 | Araq | you have to use parseStmt""" code here """ I think :-/ |
18:37:39 | Araq | bbl |
18:37:44 | fowl | ok |
18:37:45 | fowl | thanks |
19:11:13 | dom96 | oh guys, I wrote a nimrod article for wikipedia and would love some feedback: http://en.wikipedia.org/wiki/User:Dom96/sandbox |
19:11:26 | dom96 | Also ideas for more examples. |
19:14:32 | gradha | is there any difference in that wrt the one you saw and inspired you to try nimrod? |
19:15:47 | dom96 | hrm, lets see. |
19:17:41 | * | dom96 should steal some things from the old article |
19:21:52 | * | dom96 is adding refs like crazy |
19:38:04 | gradha | do you remember why it was removed in first place? |
19:38:44 | dom96 | lack of references |
19:38:54 | dom96 | It wasn't "notable enough" |
19:38:57 | dom96 | as well |
19:39:41 | gradha | could you use nimrod's language visibility on github as an argument there? meaning that maybe other "worse" or less used languages have wikipedia entries |
19:39:57 | dom96 | yeah. |
19:40:07 | dom96 | We can argue with them if they try to delete it again |
19:40:22 | dom96 | the old article really had very few references |
19:40:23 | gradha | in fact, why not mention that it's notabilityless was due to a linguist bug? |
19:40:24 | dom96 | if any at all... |
19:40:40 | gradha | people love drama |
19:40:40 | fowl | i dont think this is necessary The following code examples are valid as of Nimrod 0.9.0. Syntax and semantics may change in subsequent versions. |
19:40:49 | fowl | at least until theres an example that actually could change |
19:41:06 | dom96 | fowl: That's what the rust wiki page says about its examples |
19:41:16 | gradha | but rust is far from 1.0 |
19:41:30 | fowl | yea but its not likely that nimrod's syntax or semantics will change that much before 1.0 |
19:42:10 | dom96 | well 'echo' will most certainly not change |
19:42:17 | dom96 | but I was hoping for a cooler example which might change |
19:42:21 | dom96 | something which uses macros perhaps |
19:42:58 | gradha | maybe you can show a benchmark of some code compared to rust/ruby on the wikipedia page |
19:43:36 | fowl | and link to rosettacode |
19:43:48 | dom96 | we could mention that nimrod shows comparable performance to pure C code, as there are some benchmarks which show that. |
19:44:16 | dom96 | although it seems quite obvious that it would show comparable performance since it does compile to C |
19:44:19 | fowl | dom96: i was thinking about writing a partial c-preprocessor for c2nim |
19:44:46 | gradha | as example for the wikipedia page? |
19:45:09 | fowl | the idea being to expand macros that alter syntax like #define BEGIN { but leave constant macros as they are for c2nim |
19:45:15 | fowl | gradha: no, just in general |
19:45:53 | dom96 | not entirely sure how that would be useful |
19:46:11 | dom96 | oh, I think I get what you mean. |
19:46:24 | dom96 | c2nim already does most of that does it not? |
19:47:28 | fowl | no it doesnt expand macros but it handles #define SOMECONST 42 |
19:48:12 | fowl | DLL_API int DLL_CALLCONV FreeImage_GetPageCount(FIMULTIBITMAP *bitmap); |
19:48:17 | fowl | guh |
19:49:53 | dom96 | http://build.nimrod-code.org/docs/c2nim.html#preprocessor-support |
19:50:32 | gradha | dom96: it would be useful to add to the wikipedia page the idetools/doc support already provided by the compiler |
19:51:32 | dom96 | Yeah, I was thinking about mentioning Aporia and the fact that the compiler cooperates with it to provide suggest functionality. |
19:51:38 | dom96 | Also other tools like c2nim. |
19:53:04 | gradha | if you want I can add that to your sandbox, if that's possible? |
19:53:36 | dom96 | I think it is yeah. |
19:53:40 | dom96 | Just let me save what I have here. |
19:55:31 | dom96 | hah, I just realised that i have been logged out on wikipedia |
19:55:42 | dom96 | So yeah, you can definitely edit it |
19:56:05 | gradha | I would change "group of volunteers" to "closely knit together core developers", it gives the idea of people being bound to threads, with all of us being puppets of destiny, lacking any freewill |
19:56:30 | fowl | lol |
19:57:28 | dom96 | 13 references :D |
19:57:40 | dom96 | I bet they will complain that they are all primary sources though |
19:57:49 | gradha | dom96: the "private" folder of babel can have any name or "private" is good enough for it? |
19:58:39 | dom96 | gradha: Currently this is not enforced in any way, just something that users will not import accidentally. It may be enforced in the future so sticking to 'private' may be a good idea. |
19:58:55 | dom96 | Babel may still change majorly though. |
19:59:16 | gradha | it's tempting to name the folder "toomanysecrets" |
20:00:07 | dom96 | lol |
20:00:10 | dom96 | what is this for? |
20:00:23 | gradha | that recycle proc for macosx |
20:00:30 | dom96 | Araq: Is it still possible to use {} thanks to filters? |
20:00:46 | dom96 | ahh, better go with 'private' be professional :P |
20:01:01 | fowl | better yet .private |
20:01:04 | fowl | (: |
20:01:07 | gradha | oh, don't worry, this module is going to be as unprofessional as possible |
20:01:22 | gradha | I'm actually aiming for the worst module ever |
20:04:19 | gradha | don't wikipedia language pages have a "mortal enemy of:" section in their sidebar? |
20:04:57 | gradha | you could add D there as a reference |
20:05:55 | dom96 | lol |
20:06:07 | dom96 | Every language is our mortal enemy though. |
20:06:17 | gradha | ruby is? |
20:06:22 | dom96 | of course |
20:06:36 | gradha | right, we should add a "this language mocks: xxx" section |
20:08:28 | dom96 | definitely |
20:09:07 | gradha | hyperlink Araq's facebook page too |
20:09:50 | dom96 | We should just make an article titled "The one and only programmer God" with Araq's picture there. |
20:11:06 | gradha | surely Araq would like a sense of profesionality, show a photo of him in a suit http://www.lenpascoe.com/Portals/0/icons/person-icon-contact.jpg |
20:14:18 | gradha | in order to check for the availability of a proc do I write "when not defined(procname):"? |
20:14:43 | dom96 | yeah, I think so. |
20:14:46 | dom96 | Test it to be sure :P |
20:15:19 | dom96 | Maybe Araq would be willing to take a photo of himself with a Guy Fawkes mask. |
20:15:33 | dom96 | Maybe we would get some support from Anonymous. |
20:15:49 | gradha | is the module path prefix required? I'm looking at your previous aporia code "when not defined(os.findExe):" |
20:17:00 | dom96 | if you want to target a function which is specifically in some module, then yeah. |
20:17:38 | dom96 | defined(findExe) will return true if findExe is defined in the current module, but defined(os.findExe) will not (as long as it's not defined in os) |
20:17:43 | dom96 | As far as I know. |
20:26:49 | gradha | looks like the "private" folder doesn't work with the compile pragma, so I'll leave the objc code lingering around at the root |
20:28:54 | dom96 | well I added some extra things to the wiki article |
20:28:59 | dom96 | 15 references now |
20:32:09 | gradha | ugh, the compile pragma not only breaks paths for babel, it doesn't work for nimrod code either, looks like I'll have to embed the source as a big emit |
20:33:04 | dom96 | bug report |
20:33:34 | gradha | oh, and I can't use emit directly, since that would not work with C code generation... |
20:34:10 | gradha | ok, let's add extra layers of indirection, that always works |
20:34:24 | dom96 | you simply need more macros |
20:36:10 | gradha | wait a sec, if I import a module, does nimrod read it's nimrod.cfg for additional paths? |
20:36:39 | dom96 | My gut feeling says: no |
20:36:52 | * | ack006 quit (Quit: Leaving) |
20:36:54 | gradha | in that case it won't work anyway |
20:37:42 | gradha | so how is a module suposed to use the private folder then? does import private/name? |
20:38:29 | dom96 | yeah: import "private/name" |
20:38:52 | dom96 | actually without quotes works too |
20:41:10 | dom96 | This is pretty awesome: http://www.firstmenonthemoon.com/ |
20:45:54 | Araq | fowl: wtf? you do know about c2nim's #def directive ... |
20:49:10 | gradha | ah, the compile pragma works, there was something wrong with the nimcache folders, started to work again when purged |
20:53:48 | gradha | yay, so relative works with compile pragma too, again the bad nimcache was the culprit |
20:54:08 | gradha | for some reason the .crc file was being generated but the .o file wasn't appearing |
20:59:13 | gradha | this is a real blunder http://species.wikimedia.org/w/index.php?search=zerg |
21:00:02 | dom96 | Araq: Is it still possible to use {} thanks to filters? |
21:00:25 | Araq | you mean within a .tmpl file? ... I don't think so ... |
21:02:01 | dom96 | Wasn't there a time when you implemented something which allowed {} to be used to delimit blocks? |
21:02:09 | dom96 | did you remove that feature? |
21:02:33 | Araq | no, it's been a planned feature since forever |
21:03:05 | Araq | but if anything I'd rather use () instead now |
21:03:25 | dom96 | i see. |
21:03:47 | * | q66 quit (Ping timeout: 256 seconds) |
21:04:22 | * | q66 joined #nimrod |
21:04:35 | dom96 | Araq: What do you think of the wiki article now? |
21:05:19 | Araq | have to reread it |
21:09:23 | dom96 | brb |
21:24:36 | dom96 | back |
21:25:54 | dom96 | Araq: reread it yet? |
21:26:05 | Araq | no |
21:37:50 | gradha | awesome, nimrod is at least 10 times faster than ruby and I have the numbers http://pastebin.com/svuy8Dgk |
21:39:14 | Araq | tried with -d:release? |
21:39:35 | gradha | that's with -d:release, will see without |
21:40:34 | gradha | bummer, takes 2 milliseconds longer |
21:41:09 | reactormonk | gradha, is that macruby? |
21:41:09 | Araq | most of the time is spent in the kernel I guess |
21:41:34 | gradha | reactormonk: yes, the osx-trash gem |
21:42:42 | reactormonk | gradha, which ruby do you run it on? |
21:43:04 | gradha | default? $ ruby --version |
21:43:04 | gradha | ruby 1.8.7 (2012-02-08 patchlevel 358) [universal-darwin12.0] |
21:43:18 | reactormonk | gradha, and the gem? |
21:43:35 | gradha | don't know much about ruby, how do you know about a gem's version? |
21:43:46 | reactormonk | hm, ok |
21:43:55 | gradha | I think it's http://www.dribin.org/dave/osx-trash/ |
21:44:01 | reactormonk | try with ruby 2.0.0 for starters, maybe macruby too |
21:44:16 | gradha | why would I want to do that? |
21:45:31 | reactormonk | because they're faster and up-to-date? |
21:45:42 | reactormonk | so it's actually a fair comparison :-P |
21:46:30 | gradha | I don't want to tinker with my ruby installation, I could break it and at the moment I depend on redmine working |
21:46:52 | dom96 | reactormonk: sshhhh, ruby is slower, just accept it. :P |
21:47:04 | gradha | btw, ports and macruby both use 1.9, shouldn't they be 2.0? |
21:47:31 | reactormonk | gradha, maybe, 2.0.0 is kinda new |
21:47:32 | Araq | most performance improvements came with 1.9, so it doesn't matter |
21:48:01 | reactormonk | yeah, but gradha uses 1.8.7 |
21:48:46 | gradha | for the record, this "trash" program is just a call to the objc recycle operation, so we are measuring ruby startup time vs nimrod startup time, not that much ruby/nimrod code is being run at all |
21:51:12 | gradha | reactormonk: do you know if a user can install ruby on his path locally without admin priviledges? |
21:52:52 | reactormonk | gradha, use homebrew |
21:53:11 | gradha | I'm installing 2.0 manually now |
21:53:35 | gradha | ah, ./configure, how much did I not miss you at all |
21:55:09 | reactormonk | ^^ |
21:56:47 | gradha | checking for broken memmem... yes |
21:57:34 | Araq | a generated 40K configure script is the security aware user's dream |
21:57:55 | gradha | huh? "CFLAGS = -O3 -fno-fast-math" no wonder ruby is so slow if they use slow math on purpose |
22:00:13 | gradha | does ruby come with gems or do I have to install that also? |
22:01:07 | reactormonk | should come with rubygems |
22:01:53 | gradha | I hope you don't mind Araq, since you said you won't be using my machine I'm satanizing your user account |
22:03:04 | gradha | aw, ruby can't compile due to some readline wrong api mismatch, and there ends my ruby trip |
22:03:10 | Araq | meh, fair enough |
22:03:23 | gradha | I believed configure should have taken care of that readline mismatch |
22:03:33 | gradha | guess not enough 40k lines were produced |
22:04:10 | reactormonk | gradha, use homebrew on mac, since they have no usable pkgmanager |
22:05:39 | Araq | gradha: the configure script checks that you have a CPU ... ;-) |
22:07:12 | gradha | reactormonk: homebrew doesn't guarantee software to work unless you install with admin priviledges on /usr/local, that sucks |
22:07:36 | gradha | will see how it goes for ruby |
22:25:07 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
23:42:07 | * | zahary1 quit (Ping timeout: 245 seconds) |
23:57:43 | apotheon | Araq: From what I've heard (though I haven't used 2.0 myself, let alone benchmarked it), Ruby 2.0 is supposed to be faster than 1.9. |
23:58:33 | apotheon | Araq: I think the 1.9 speedups were to some extent based on the approach to implementation, though, while those for 2.0 were mostly improvements to specific types of operations. |
23:59:18 | Araq | quite possible, it's pretty easy to speedup ruby as it's so slow :P |