00:01:01 | * | boydgreenfield quit (Quit: boydgreenfield) |
00:01:09 | * | brson quit (Ping timeout: 248 seconds) |
00:02:21 | BitPuffin | zahary: 3G ftw watcha talkin bout |
00:03:34 | zahary | I feel like in 1996 when the first 14kbps modem ISP appeared in Bulgaria |
00:07:25 | gradha | zahary: I've heard good things about Bulgaria cybercafe bandwitdh, are you in the woods? |
00:08:49 | zahary | there used to be a site that let you compare prices and quality of life metrics around the world - I managed to rank Bulgaria as #1 by choosing internet speed + price of beer |
00:09:03 | * | brson joined #nimrod |
00:09:30 | Araq | XD |
00:09:31 | zahary | so yes, we have good internet connection at home, but I'm in the country-side now |
00:10:09 | EXetoC | well those criterias are pretty important |
00:11:02 | zahary | could you think of anything more important :P |
00:11:48 | EXetoC | the price of bacon maybe |
00:13:27 | OrionPKM | man idetools doesnt work on osx at all |
00:13:55 | zahary | I'm using "go to definition" all the time |
00:13:59 | gradha | OrionPKM: maybe you are just unlucky on your queries, I use it pretty often |
00:14:11 | OrionPKM | o? maybe... |
00:14:56 | OrionPKM | i'm getting "arguments can only be given if the '--run' option is selected" |
00:16:33 | BitPuffin | goodnight! |
00:16:42 | * | BitPuffin quit (Quit: WeeChat 0.4.2) |
00:17:20 | Araq | OrionPKM: that's a regression I think |
00:17:40 | OrionPKM | mm, date range? |
00:18:00 | Varriount | How does one echo a TWinChar? |
00:18:04 | Araq | last couple of days, quoteIfContainsWhite was changed |
00:18:10 | OrionPKM | ah |
00:18:27 | OrionPKM | gradha you running latest? |
00:19:04 | gradha | latest of what? |
00:19:13 | OrionPKM | nimrod |
00:19:13 | gradha | Araq: see https://gist.github.com/gradha/7883627#file-betterobjc-nim-L176 for my wip, I think it's nicer this way |
00:19:15 | OrionPKM | idetools |
00:19:16 | OrionPKM | osx |
00:19:22 | gradha | OrionPKM: should be |
00:19:31 | OrionPKM | within the last 2 days? |
00:20:05 | gradha | OrionPKM: there hasn't been much changes in the last 2 days, though maybe zahary's recent commits broke something |
00:20:20 | OrionPKM | gradha look what araq just said |
00:20:39 | gradha | I'm running with that, presumably |
00:20:57 | gradha | ah, no, I'm not |
00:22:17 | EXetoC | Varriount: no stringifier for it? try repr then |
00:22:31 | gradha | with the quote thingy the koch web fails pretty quickly |
00:22:57 | gradha | for me it's dying instead on actors.nim |
00:23:07 | EXetoC | Varriount: but it's just a char |
00:23:30 | gradha | OrionPKM: try to do "git checkout -b temp_fix; git revert 5dd5c78fdabfd4fb7c0a170b3f0ee87bf569fa29" and use that for the time being |
00:25:09 | Araq | gradha: please revert that quoteIfContainsWhite thing already |
00:25:31 | EXetoC | Varriount: well, not if unicode support is specified. then you might have to convert to its base type which is int16, and maybe to TRune after that and call unicode.toUTF8 :p |
00:26:03 | EXetoC | unless you know it's in the ASCII range or you just want the numeric value |
00:26:16 | gradha | Araq: that's no fun |
00:26:36 | gradha | Araq: git versions should be unstable and bite you an arm off whenever you use them |
00:26:52 | Araq | gradha: oh wait there is a pull request from zielinksi already |
00:27:06 | gradha | well, good night, honey badgers |
00:27:13 | * | gradha is saved by the bell |
00:27:16 | * | gradha quit (Quit: bbl, need to watch http://www.youtube.com/watch?v=hcDEWiH-ciw again) |
00:27:51 | * | PortablePuffin quit (Ping timeout: 260 seconds) |
00:38:52 | * | boydgreenfield joined #nimrod |
00:41:46 | * | PortablePuffin joined #nimrod |
00:46:06 | * | fowl quit (Ping timeout: 250 seconds) |
00:49:07 | Varriount | Araq, I just found another bug with deleting files (and this one seems pretty common among languages and utilities) |
00:49:33 | Varriount | Araq, eraseFile cannot erase files with the R attributes |
00:50:03 | Araq | so fix your OS instead |
00:50:06 | * | Araq sighs |
00:50:15 | Varriount | Araq, I would. |
00:50:25 | Varriount | If I didn't have a research paper to write. |
00:50:32 | Varriount | And a resume to build. |
00:52:43 | * | fowl joined #nimrod |
00:53:31 | * | boydgreenfield quit (Ping timeout: 272 seconds) |
00:55:48 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
01:06:45 | * | PortablePuffin quit (Ping timeout: 248 seconds) |
01:20:26 | Araq | Varriount: well fix it, good night |
01:23:09 | EXetoC | yeah fix it anyway ya lazy twat :p |
01:25:18 | * | boydgreenfield joined #nimrod |
01:35:01 | * | TylerE joined #nimrod |
01:35:55 | * | TylerE_ joined #nimrod |
01:35:57 | TylerE_ | test |
01:36:19 | * | OrionPKM quit (Remote host closed the connection) |
01:36:33 | TylerE_ | If I have a working recent install, doing a git pull and then a koch boot is enouhg, right? I don't need to bootstrap from c again? |
01:37:31 | * | OrionPKM joined #nimrod |
01:39:25 | * | TylerE quit (Ping timeout: 250 seconds) |
01:40:19 | TylerE_ | unsigned really really sucks |
01:40:20 | TylerE_ | I just have to say that |
01:40:53 | * | PortablePuffin joined #nimrod |
01:41:59 | TylerE_ | uint upcasting seems to be broken. if a:uint16 < b:uint32 fails to compile |
01:42:04 | TylerE_ | when I see no reason why it shouldn'ed |
01:42:13 | TylerE_ | according to dock uint16 should implicit to uint32 |
01:43:35 | OrionPKM | are you importing unsigned? |
01:44:22 | TylerE_ | yes |
01:44:50 | TylerE_ | https://gist.github.com/tylereaves/7884506 |
01:44:55 | TylerE_ | errors on line 32 |
01:46:00 | TylerE_ | grr some extra crap in the gist |
01:46:28 | TylerE_ | it's the a.byteVal <= length line |
01:47:39 | * | PortablePuffin quit (Ping timeout: 260 seconds) |
01:51:04 | * | DAddYE quit (Remote host closed the connection) |
01:51:38 | * | DAddYE joined #nimrod |
01:56:03 | * | DAddYE quit (Ping timeout: 260 seconds) |
02:01:49 | * | viteqqq_ joined #nimrod |
02:01:49 | * | viteqqq quit (Read error: Connection reset by peer) |
02:03:07 | TylerE_ | I stand by my statement that unsigned is a huge wart, though |
02:03:15 | TylerE_ | it either should be in system |
02:03:28 | TylerE_ | or you should need to import unsigned to even use the types |
02:03:57 | OrionPKM | araq is racist against unsigned numbers |
02:07:26 | * | xenagi joined #nimrod |
02:12:00 | fowl | TylerE_, im sure he would accept fixes |
02:14:05 | * | Varriount_ joined #nimrod |
02:15:22 | * | XAMPP quit (Read error: Connection reset by peer) |
02:16:37 | * | Varriount quit (Ping timeout: 248 seconds) |
02:28:05 | * | viteqqq_ quit (Read error: Connection reset by peer) |
02:31:42 | * | PortablePuffin joined #nimrod |
02:35:38 | * | ics joined #nimrod |
02:46:53 | * | PortablePuffin quit (Ping timeout: 272 seconds) |
02:50:27 | * | boydgreenfield quit (Quit: boydgreenfield) |
02:52:16 | * | DAddYE joined #nimrod |
02:57:17 | * | DAddYE quit (Ping timeout: 272 seconds) |
02:58:48 | * | boydgreenfield joined #nimrod |
03:05:20 | TylerE_ | heh, it's alive |
03:05:29 | TylerE_ | only 2 hours in and I'm capable of reading in the data files |
03:05:49 | TylerE_ | * - for about the slackest possible definition of reading the data files |
03:06:56 | OrionPKM | cool.. which data files? |
03:08:38 | * | xenagi quit (Read error: Connection reset by peer) |
03:16:16 | * | Ogion quit (Ping timeout: 260 seconds) |
03:18:04 | * | Ogion joined #nimrod |
03:18:10 | * | DAddYE joined #nimrod |
03:18:22 | * | DAddYE quit (Remote host closed the connection) |
03:18:30 | * | DAddYE_ joined #nimrod |
03:28:14 | * | TylerE_ quit (Quit: Page closed) |
03:37:18 | * | PortablePuffin joined #nimrod |
03:45:36 | * | DAddYE_ quit (Remote host closed the connection) |
03:46:03 | * | DAddYE joined #nimrod |
03:50:29 | * | DAddYE quit (Ping timeout: 248 seconds) |
04:20:53 | * | brson quit (Ping timeout: 272 seconds) |
04:46:56 | * | DAddYE joined #nimrod |
04:51:39 | * | DAddYE quit (Ping timeout: 272 seconds) |
04:56:05 | * | PortablePuffin quit (Ping timeout: 248 seconds) |
04:58:45 | * | noam_ quit (Ping timeout: 245 seconds) |
05:05:29 | * | boydgreenfield quit (Quit: boydgreenfield) |
05:36:12 | * | boydgreenfield joined #nimrod |
05:47:29 | * | boydgreenfield quit (Quit: boydgreenfield) |
05:48:25 | * | PortablePuffin joined #nimrod |
05:48:26 | * | DAddYE joined #nimrod |
05:51:43 | Varriount_ | On Linux, does marking a file with the read-only attribute prevent it from being deleted? |
05:53:21 | * | DAddYE quit (Ping timeout: 272 seconds) |
05:58:12 | * | Varriount_ is now known as Varriount |
05:58:25 | * | PortablePuffin quit (Ping timeout: 272 seconds) |
05:58:29 | Varriount | Araq, fixed the removeFile proc. See pull request |
05:59:30 | * | boydgreenfield joined #nimrod |
06:17:03 | joelmo | I get this when using the caas with pipes: Error: unhandled exception: EOF reached [EIO] |
06:17:32 | joelmo | and --server.type:stdin |
06:32:31 | Varriount | CAAS? |
06:32:54 | joelmo | compiler as a service |
06:33:07 | Varriount | joelmo, is this for vim? |
06:33:38 | joelmo | no, http://build.nimrod-lang.org/docs/idetools.html |
06:33:58 | Varriount | No, I mean, are you trying to use ide tools for vim? |
06:34:55 | joelmo | Varriount: yes, but im trying to work on a solution that wont use python for it, using mkfifo instead |
06:36:01 | joelmo | don't know if it will work at all |
06:36:20 | fowl | joelmo, you'll have to catch zahary or Araq to ask them, or post your problem on the forums |
06:36:39 | Varriount | Unfortunately, I run Windows, and don't use idetools |
06:37:02 | Varriount | I do know that it is one of the areas of the codebase that needs some love |
06:37:22 | joelmo | when is zah and Araq usually online? |
06:39:18 | joelmo | but this may be from the strutils and readLine? |
06:39:42 | Varriount | joelmo, possibly. I'd have to see your code before I could make any judgements. |
06:40:10 | Varriount | And unfortunately, to do that, I would have to stay awake for another hour, which is doubtful. |
06:40:33 | fowl | Varriount, https://www.youtube.com/watch?v=bemgJDD75ng |
06:40:35 | Varriount | It's 1 in the morning here, and about 7 in the morning where araq lives. |
06:41:09 | fowl | joelmo, ~5-6 hours |
06:41:57 | Varriount | fowl, is that blood on the window? |
06:43:28 | fowl | no i think its sauce |
06:43:40 | joelmo | she didnt get her nuggets |
06:45:40 | joelmo | I use something like this: mkfifo /tmp/nimrod.in && nimrod serve --server.type:stdin < /tmp/nimrod.in, then echo 'cmd' > /tmp/nimrod.in |
06:47:09 | * | PortablePuffin joined #nimrod |
06:47:49 | * | radsoc joined #nimrod |
06:49:18 | * | DAddYE joined #nimrod |
06:53:26 | * | DAddYE quit (Ping timeout: 240 seconds) |
07:04:10 | * | boydgreenfield quit (Quit: boydgreenfield) |
07:08:25 | * | DAddYE joined #nimrod |
07:08:35 | * | DAddYE quit (Remote host closed the connection) |
07:08:41 | * | DAddYE_ joined #nimrod |
07:13:31 | * | Varriount quit (Ping timeout: 246 seconds) |
07:15:06 | joelmo | got help in #linux: while true; do cat /tmp/myfifo.in; done | nimrod serve --server.type:stdin |
07:55:52 | * | PortablePuffin quit (Ping timeout: 246 seconds) |
08:19:39 | * | radsoc quit (Ping timeout: 272 seconds) |
08:23:11 | * | zahary quit (Read error: Connection reset by peer) |
08:35:14 | * | DAddYE_ quit (Remote host closed the connection) |
08:35:42 | * | DAddYE joined #nimrod |
08:39:47 | * | DAddYE quit (Ping timeout: 240 seconds) |
08:47:22 | * | PortablePuffin joined #nimrod |
08:54:51 | * | PortablePuffin quit (Ping timeout: 272 seconds) |
09:29:17 | * | fntzr joined #nimrod |
09:35:35 | * | CarpNet joined #nimrod |
09:42:29 | * | achim joined #nimrod |
10:28:03 | * | PortablePuffin joined #nimrod |
10:38:39 | * | DAddYE joined #nimrod |
10:43:25 | * | DAddYE quit (Ping timeout: 272 seconds) |
10:51:32 | * | BitPuffin joined #nimrod |
11:08:35 | * | PortableEXetoC2 quit (Ping timeout: 260 seconds) |
11:15:01 | * | PortablePuffin quit (Ping timeout: 246 seconds) |
11:24:50 | * | radsoc joined #nimrod |
11:32:08 | Araq | hi radsoc, tried a crit bit tree? |
11:39:25 | * | DAddYE joined #nimrod |
11:39:48 | radsoc | hi Araq, no, I'm very pleased with the CountTable performance (especially since I switched from silence mode to performance mode on my laptop...). But do you think the crit bit tree could perform better ? |
11:40:19 | Araq | I think it's worth trying, though my guess is memory usage would go up |
11:40:38 | Araq | depends on how similar your short strings are iirc |
11:42:16 | * | Icefoz quit (Ping timeout: 240 seconds) |
11:42:17 | * | Icefoz joined #nimrod |
11:44:59 | * | DAddYE quit (Ping timeout: 260 seconds) |
11:55:09 | radsoc | Araq: I'll certainly try. Have you ever heard about this tree algorithm? http://www3.in.tum.de/~leis/papers/ART.pdf I tried this implementation in C before discovering Nimrod https://github.com/armon/libart The performance was slighty better than with a Count Table (before the different optimizations). I would like to C2nim it but I'm a litlle reluctant to go into that process. |
12:13:54 | Araq | radsoc: at first sight ART looks rather similar to a crit bit tree |
12:23:30 | radsoc | Araq: maybe. I also have to try the Free Lock Hash table. I didn't mean to test all tree and hash algorithms available on earth but I'm heading that way. |
12:23:57 | radsoc | bye |
12:24:54 | Araq | alright, good point |
12:24:57 | Araq | bye |
12:28:34 | * | radsoc quit (Ping timeout: 272 seconds) |
12:41:31 | * | DAddYE joined #nimrod |
12:45:50 | * | DAddYE quit (Ping timeout: 240 seconds) |
13:10:12 | * | PortablePuffin joined #nimrod |
13:15:57 | * | PortablePuffin quit (Read error: Operation timed out) |
13:22:33 | * | fundamental quit (Ping timeout: 252 seconds) |
13:23:28 | * | fundamental joined #nimrod |
13:30:49 | * | fundamental quit (Ping timeout: 246 seconds) |
13:42:15 | * | DAddYE joined #nimrod |
13:43:00 | * | fundamental joined #nimrod |
13:47:02 | * | DAddYE quit (Ping timeout: 240 seconds) |
14:02:23 | * | fundamental quit (Read error: Connection reset by peer) |
14:03:31 | * | fundamental joined #nimrod |
14:10:45 | * | fowl quit (Ping timeout: 246 seconds) |
14:11:08 | * | fowl joined #nimrod |
14:21:06 | * | PortableEXetoC2 joined #nimrod |
14:40:07 | * | PortablePuffin joined #nimrod |
14:44:27 | * | DAddYE joined #nimrod |
14:45:42 | * | Mat3 joined #nimrod |
14:45:46 | Mat3 | hi all |
14:46:01 | fowl | hey |
14:46:08 | Mat3 | hi fowl |
14:46:26 | Mat3 | how's work going ? |
14:46:30 | fowl | are you still working on native code generator |
14:46:34 | fowl | heh im not working |
14:46:56 | Mat3 | sorry, wrong terminology - yes, still working on it |
14:48:38 | * | DAddYE quit (Ping timeout: 240 seconds) |
14:54:45 | * | PortablePuffin quit (Read error: Operation timed out) |
14:56:46 | Mat3 | succeeded someone here in compiling Nimrod on the Raspberri Pi (Version A, Rasperian) ? |
14:57:17 | OrionPKM | is that a question? |
14:57:24 | Mat3 | yes |
14:57:26 | OrionPKM | I've got nimrod running on my RBPI |
14:57:42 | OrionPKM | w/ raspbian |
14:58:05 | Mat3 | the 256 mB or 512 mB version ? |
14:58:09 | OrionPKM | 512 I believe |
14:58:21 | Mat3 | ok, how do you compile it ? |
14:58:43 | OrionPKM | nimrod c koch, koch boot -d:release |
14:58:47 | OrionPKM | didnt have any issues |
15:00:20 | Mat3 | hmm, I see. My first problem is: I can't compile Nimrod from the C sources so 'nimrod c koch' would not work |
15:00:50 | OrionPKM | hm, mine compiled fine |
15:01:07 | Mat3 | seem to be a problem with to much, temporary memory usage |
15:01:17 | Mat3 | (I have the 256 mB version) |
15:02:15 | OrionPKM | ah |
15:03:05 | OrionPKM | are you trying to fix it or are you just trying to get it working? |
15:03:45 | Mat3 | just want to get it working |
15:04:51 | * | radsoc joined #nimrod |
15:05:19 | OrionPKM | can take out your sd-card and cross compile from a diff machine |
15:06:17 | dom96 | Mat3: I had to set up a swap partition on my sd card to compile it. |
15:06:30 | Mat3 | thanks dom96 |
15:08:40 | Mat3 | OrionPKM: thanks, I'm now trying compiling it per emulation with debian6 (including a dynamic swap file) |
15:09:40 | BitPuffin | nested procs are legal right? |
15:10:41 | OrionPKM | yes |
15:11:03 | BitPuffin | good |
15:12:15 | BitPuffin | OrionPKM: and they can access parent proc variables? |
15:12:56 | OrionPKM | not sure, make it a closure maybe |
15:13:28 | BitPuffin | we'll see I guess |
15:14:57 | Mat3 | last time I tried, accessing local variables within nested procs resulted in runtime errors |
15:15:24 | Mat3 | however, the bug can be fixed now |
15:16:32 | EXetoC | at runtime? odd |
15:21:11 | * | Mat3 compiling Nimrod on the emulated Raspberri Pi system with 512 mB worked fine |
15:25:15 | Mat3 | EXetoC: yes, compiling nested procs which do not access local variables of there parent worked fine however |
15:26:20 | BitPuffin | Mat3: but then there is nearly no point to inner procs lol |
15:27:20 | EXetoC | if it's a bug then I assume that it was a crash, rather than some exception |
15:28:33 | EXetoC | I've been able to access outer vars at least once before |
15:29:16 | EXetoC | I wonder if it's possible to avoid the additional context in that case, because then it's still useful as a way of encapsulating the proc |
15:29:25 | Mat3 | BitPuffin: you can't think of all reasons one want |
15:29:45 | Mat3 | EXetoC: as written, can be fixed now |
15:36:39 | * | PortableEXetoC2 quit (Ping timeout: 272 seconds) |
15:45:16 | * | DAddYE joined #nimrod |
15:49:57 | * | DAddYE quit (Ping timeout: 248 seconds) |
15:50:01 | * | Varriount joined #nimrod |
15:50:15 | Varriount | Good morning! |
15:51:19 | Mat3 | hello Varriount |
15:51:42 | Varriount | It's snowing wher I live. All my classes got cancelled. |
15:51:45 | Varriount | *where |
15:55:26 | EXetoC | awesome |
16:03:34 | * | PortableEXetoC2 joined #nimrod |
16:04:39 | * | shodan45 quit (Quit: Konversation terminated!) |
16:06:34 | * | gradha joined #nimrod |
16:08:37 | Varriount | Hello gradha |
16:08:41 | * | radsoc quit (Ping timeout: 272 seconds) |
16:09:14 | gradha | Hello Varriount |
16:09:25 | Mat3 | hi gradha |
16:10:00 | gradha | mi Mat3 |
16:10:11 | gradha | or hi |
16:17:45 | * | gradha is confused, after downloading a girls' torrent there are boygroups here |
16:20:55 | * | PortableEXetoC2 quit (Ping timeout: 246 seconds) |
16:26:54 | * | PortablePuffin joined #nimrod |
16:29:04 | * | PortableEXetoC2 joined #nimrod |
16:31:17 | brihat | gradha: i wanna download that torrent too. care to share? |
16:31:30 | gradha | brihat: you into kpop? |
16:31:46 | brihat | korean pop? |
16:31:50 | gradha | yes |
16:31:51 | brihat | go ahead |
16:32:54 | gradha | this one http://kpop24hrs.com/131210-arirangtv-simply-kpop/ |
16:33:06 | gradha | don't recommend it, it's low quality |
16:33:25 | brihat | am not really into it, but can have a look at it |
16:33:33 | brihat | it's free, so why ignore :P |
16:33:38 | gradha | arirangtv wouldn't know what fullhd is even if it hit them |
16:34:24 | EXetoC | 144p ought to be good enough for everybody |
16:34:25 | gradha | brihat: then you may "enjoy" http://kpop24hrs.com/rania-dr-feel-good-live-collection/ more |
16:34:50 | gradha | EXetoC: do you know japanese still make telecined blurays? |
16:35:00 | gradha | EXetoC: it's like spitting in your face |
16:36:51 | gradha | I'm sure when 4k arrives TV stations will find a way to botch it in some way or another anyway to be lower quality than youtube |
16:37:26 | EXetoC | wut |
16:39:50 | Araq | hi gradha |
16:39:58 | gradha | hi Araq |
16:40:07 | gradha | looks like today is greeting day? |
16:40:34 | Araq | I checked the pull request and it's meh ... so please revert that change to quoteIfContainsWhite |
16:40:38 | Mat3 | hi Araq |
16:41:22 | gradha | Araq: ok |
16:43:18 | Araq | hi Mat3 you keep getting better |
16:43:55 | * | radsoc joined #nimrod |
16:45:08 | gradha | Araq: in objc 2.0 (hah!) there are https://en.wikipedia.org/wiki/Objective-C#Properties |
16:45:30 | gradha | Araq: I want to create a macro for that, is there any example of "creating" similar syntax? |
16:45:51 | gradha | Araq: I tried yesterday putting random words separated by commas and looking at the AST with treedump but didn't understand the rules |
16:46:35 | * | DAddYE joined #nimrod |
16:46:45 | gradha | so to emulate "@property(copy) NSString *name;" I was trying things like "property Greeter, g(readonly, atom)" since atomic is a keyword |
16:50:38 | * | DAddYE quit (Ping timeout: 240 seconds) |
16:50:46 | Araq | "By default, properties are considered atomic, which results in a lock preventing multiple threads from accessing them at the same time. A property can be declared as "nonatomic", which removes this lock." er .. what? |
16:51:34 | gradha | when a property is atomic the compiler inserts mutexes and serious stuff to make your code technically thread safe but still incorrect |
16:51:48 | gradha | so everybody uses nonatomic because that gives you the same safety without the overhead |
16:51:50 | Varriount | *cough*like java*cough* |
16:52:29 | gradha | the fact that "atomic" is the default speaks a lot about the stupidity of objc designers/implementors |
16:53:07 | gradha | Araq: but that's not relevant, I just want you to tell me what could approach that syntax so I can parse it in the macro and generate the setter/getters myself |
16:54:04 | Araq | I'm not sure you can use macros for that, you need to influence the codegen |
16:54:08 | NimBot | Araq/Nimrod master 3dccdd4 Grzegorz Adam Hankiewicz [+0 ±2 -0]: Reverts "Make quoteIfContainsWhite quote…". Refs #702.... 3 more lines |
16:54:08 | NimBot | Araq/Nimrod master 5b96890 Grzegorz Adam Hankiewicz [+0 ±2 -0]: Merge pull request #732 from gradha/pr_reverts_quoting_changes... 2 more lines |
16:54:39 | Araq | so that it generates x.foo instead of foo(x) or [foo stupidName: x] |
16:55:03 | gradha | oh, I'm not talking about that, that's already done |
16:56:14 | Araq | alright well I don't understand your question then |
16:56:22 | gradha | Araq: see the example at https://github.com/fenekku/commandeer |
16:56:36 | gradha | there's a statement macro "commandLine:" |
16:56:44 | gradha | then, inside you write "argument number, int" |
16:56:46 | fntzr | Hi. Is it possible in nimrod call function by string name ? |
16:57:04 | gradha | so that part has to be valid nimrod syntax, I guess |
16:57:07 | Araq | fntzr: only if you know the string at compile time |
16:57:23 | Araq | or if you create the string->function dispatching table yourself with a macro |
16:57:24 | fntzr | yes, i know string in compile time |
16:57:40 | Araq | then yes, it's possible with a macro |
16:58:04 | fntzr | How? |
16:58:26 | gradha | meh, I'll go with commas for the time being |
16:58:55 | fntzr | How to get all arguments for function? I'm trying to implement `alias` method. |
16:58:56 | Araq | gradha: yes that has to be in nimrod syntax |
16:59:33 | Araq | fntzr: that's harder and I think still not possible as we lack the type API for that |
16:59:33 | Varriount | fntzr, you can use a macro to inspect the ast tree |
17:00:24 | fntzr | Araq, ok. |
17:00:33 | Araq | macros.emit("myfunction()") works in 0.9.2 but has recently been broken, fntzr |
17:01:14 | gradha | wouldn't it be the same to return what parseStmt does on a string? |
17:01:15 | fntzr | Yes, it's broken in 0.9.3 |
17:01:18 | Araq | template myalias(a, b, c: expr): expr = foo(a, b, c) |
17:01:26 | Araq | it not to bad, is it? |
17:02:16 | Araq | gradha: yeah but you need to do it a macro context; that's how eval/emit worked |
17:02:17 | fntzr | yes |
17:03:25 | gradha | fntzr: yesterday I wrote myself a macro to loop over the parameter names/types of a procdef https://gist.github.com/gradha/7883627#file-betterobjc-nim-L64 maybe that's of any use |
17:03:44 | Varriount | Araq, any particular reason why a literal int shouldn't be implicitly converted to a uint64? |
17:04:42 | fntzr | gradha, ou thanks. |
17:04:43 | Varriount | As in, pow(5'u64, 2) |
17:06:45 | Araq | Varriount: I guess not |
17:07:24 | Varriount | Araq, ok, where is the code for implicit literal conversion? |
17:08:33 | Araq | compiler/sigmatch.nim |
17:08:42 | Varriount | Danke |
17:08:52 | Araq | bittesehr |
17:09:20 | Varriount | Finally, my miniscule knowledge of the German language comes in handy. :D |
17:10:10 | Araq | I need to go now, see you later |
17:10:34 | Varriount | Bye! |
17:12:16 | gradha | should have answered "biss später" |
17:12:49 | Varriount | gradha, I said "miniscule" |
17:15:28 | gradha | and I should have used a single s |
17:17:20 | * | zielmicha joined #nimrod |
17:18:26 | OrionPKM | später for short :p |
17:18:38 | OrionPKM | später alligator |
17:26:48 | * | hoverbear joined #nimrod |
17:46:22 | Mat3 | ciao |
17:46:24 | * | PortablePuffin quit (Ping timeout: 240 seconds) |
17:46:30 | * | Mat3 quit (Quit: Verlassend) |
17:46:31 | gradha | bye |
17:51:43 | * | boydgreenfield joined #nimrod |
17:52:35 | * | boydgreenfield quit (Client Quit) |
17:53:20 | * | DAddYE joined #nimrod |
17:53:36 | * | DAddYE quit (Remote host closed the connection) |
17:53:49 | * | DAddYE joined #nimrod |
18:00:10 | * | brson joined #nimrod |
18:02:43 | * | brson quit (Client Quit) |
18:02:56 | * | brson joined #nimrod |
18:13:05 | * | PortablePuffin joined #nimrod |
18:16:35 | reactormonk | now it's rolling O.o |
18:17:31 | Varriount | Grr. |
18:17:38 | dom96 | Rawr |
18:17:55 | gradha | rolling? |
18:18:19 | Varriount | I can't find out where nimrod handle's type conversions like var x = 4'u64;x += 5 |
18:19:24 | EXetoC | meow |
18:32:06 | * | radsoc quit (Ping timeout: 272 seconds) |
18:41:33 | Araq | ping zielmicha |
18:44:57 | * | PortablePuffin quit (Ping timeout: 252 seconds) |
19:00:37 | * | brson quit (Ping timeout: 265 seconds) |
19:01:13 | * | fntzr quit (Quit: Leaving) |
19:10:37 | zielmicha | Araq: ack |
19:10:56 | Araq | I don't like your PR sorry |
19:11:19 | zielmicha | what's wrong? |
19:11:20 | Araq | parseopt is disliked by everybody anyway, so we can deprecate that module |
19:11:29 | zielmicha | it's used by compiler |
19:11:50 | Araq | yes and so your changes can break things in a subtle way again |
19:12:29 | Araq | it's used by quite some tools in fact |
19:12:48 | Araq | which may rely on the undocumented weird parsing rules |
19:13:58 | Araq | so lets deprecate the module instead instead of "fixing" it and breaking clients silently |
19:14:52 | zielmicha | do we have working parseopt? (in babel for example) |
19:15:20 | Araq | not sure, there is a new argument parsing module in babel |
19:15:31 | dom96 | does it not depend on parseopt? |
19:15:32 | Araq | but I don't know if it's based on parseopt |
19:16:54 | zielmicha | So maybe parseopt2 or something like this. |
19:17:03 | Araq | yeah |
19:17:08 | zielmicha | So you could quickly make your code correct just by changing number. |
19:17:18 | gradha | no parseopt in sight https://github.com/fenekku/commandeer/blob/master/commandeer.nim |
19:17:53 | Araq | ok, I like parseopt2 |
19:18:04 | gradha | parseopt2.0 is catchier |
19:18:24 | Araq | that's not a valid module name though, gradha :p |
19:18:48 | OrionPKM | numbering modules at all is bleh |
19:19:17 | zielmicha | so "git mv parseopt.nim parseopt2.nim", restore old "parseopt.nim" and PR? Or put parseopt2 in babel? |
19:19:19 | OrionPKM | import parseopt -> user comes to #nimrod and complains -> try parseopt2 |
19:19:28 | gradha | OrionPKM: somehow parseopt5b96890181638aaca4583c32d60e49c92ec52a35 doesn't feel the same |
19:19:53 | gradha | make it superparseopt then |
19:20:02 | Araq | OrionPKM: there is {.deprecated.} for modules |
19:20:05 | gradha | nobody will want to use the normal version having the super available |
19:20:19 | zielmicha | than still compiler needs to be fixed, so idetools work correctly |
19:20:21 | dom96 | I think commandeer should be in the stdlib |
19:20:34 | zielmicha | dom96: maybe with saner name |
19:20:55 | OrionPKM | araq yeah, so they'll get a warning they'll probably ignore.. |
19:21:02 | dom96 | using parseopt is a bit... low-level. Especially when the language has macros which allow for cool things like what commandeer does |
19:21:28 | OrionPKM | you'll have "well you should read the output" on your side, but that doesnt necessarily prevent complaints/confusion |
19:21:32 | dom96 | zielmicha: name it argparse or something |
19:22:11 | Araq | OrionPKM: what's your solution then? |
19:22:16 | Araq | complaining is cheap |
19:22:49 | OrionPKM | Araq not sure I have any good ideas right now.. maybe versioning of modules to prefer later versions or something |
19:23:04 | zielmicha | (btw deprecated should accept error message) |
19:23:09 | OrionPKM | "import parseopts < 1.0" or something |
19:23:27 | Araq | yeah versioning hell is surely preferable |
19:23:31 | OrionPKM | :P |
19:23:41 | Araq | has that ever worked in practice btw? |
19:23:49 | OrionPKM | it was just a spitball idea |
19:24:12 | gradha | Araq: works for me using git and submodules, you get a version, and it never changes |
19:24:21 | OrionPKM | "oh your code broke and you dont want to fix it? change your imports to explicitly import the old version" |
19:24:31 | * | PortablePuffin joined #nimrod |
19:24:59 | gradha | OrionPKM: dom96 wants to hear your versioning ideas for babel |
19:25:08 | Araq | .NET regularly complains that I have the wrong log4net dll version |
19:25:24 | OrionPKM | thats a restriction that the developer put in place |
19:25:27 | zielmicha | should compiler use old parseopt or new parseopt? |
19:25:30 | Araq | guess what? I couldn't care less, any version for logging is fine |
19:25:38 | Araq | but no |
19:25:41 | zielmicha | if it'll use old, path in arguments still won't work |
19:25:46 | Araq | that would not be "correct" |
19:25:53 | zielmicha | if it'll use new, tools using it will be subtly broken |
19:25:57 | OrionPKM | Araq they explicitly set it |
19:26:29 | zielmicha | s/ arguments still won't work/ with spaces still won't work/ |
19:26:40 | Araq | in .NET I regularly spent time working around the misguided notions of correctness that plague the modern developer |
19:27:04 | OrionPKM | maybe you should switch to a dynamic language :p |
19:27:06 | Araq | no, toString(3.4) should NOT produce "3,4" for the german locale |
19:27:26 | OrionPKM | oh i hate that |
19:27:27 | Araq | yes, I know how to i18n my code, thank you |
19:27:53 | OrionPKM | I had issues parsing XML with my portuguese friend :p |
19:28:45 | Araq | zielmicha: the compiler can use parseopt2 if you test it |
19:28:56 | zielmicha | aghr |
19:29:18 | Araq | that's the point really |
19:29:26 | zielmicha | do we have buildbot or something? |
19:29:29 | Araq | you change parseopt to parseopt2 and test again |
19:29:53 | gradha | zielmicha: there is http://build.nimrod-lang.org |
19:29:54 | Araq | zielmicha: we have a build farm |
19:30:18 | zielmicha | yeah, I know - but what does it do? |
19:30:28 | gradha | it crashes a lot |
19:30:33 | Araq | runs the bootrapping and the test suite |
19:30:38 | gradha | see https://github.com/nimrod-code/nimbuild |
19:30:48 | Araq | gradha: I'm working on it |
19:31:09 | gradha | Araq: wat? |
19:32:39 | OrionPKM | I've got a lot of ideas for babel |
19:33:02 | gradha | btw, I was running manually "nimrod check" and it used to sigsev, but only after checking files, has anybody had this behaviour? |
19:33:06 | OrionPKM | I might work on it after the sublimetext stuff, if dom agrees with what I want to add |
19:33:20 | Araq | gradha: I think I fixed that |
19:36:07 | * | brson joined #nimrod |
19:36:36 | gradha | http://pastebin.com/CDqt9HCB |
19:36:52 | gradha | bbl |
19:37:08 | Araq | "nimrod check" used to work pretty well but you know ... regressions really plaque us |
19:49:40 | zielmicha | https://github.com/Araq/Nimrod/pull/730 now: |
19:49:51 | zielmicha | 1. adds parseopt2 module |
19:50:09 | gradha | I had imagined the check command is like compile but without invoking the compiler or generating files |
19:50:15 | zielmicha | 2. deprecates old one |
19:51:34 | Araq | gradha: "check" aggregates all errors |
19:51:56 | Araq | so the first error tends to produce a 'nil' somewhere and then the rest of the compiler ain't used to that |
19:53:20 | gradha | sounds like a scenario for a cool random fuzzy input generator |
19:54:02 | NimBot | Araq/Nimrod master 49ea51f Michał Zieliński [+0 ±2 -0]: Merge branch 'master' of github.com:zielmicha/Nimrod |
19:54:02 | NimBot | Araq/Nimrod master 396cf6e Michał Zieliński [+0 ±1 -0]: Normalize whitespace in os.nim.... 3 more lines |
19:54:02 | NimBot | Araq/Nimrod master 97d0b6b Michał Zieliński [+0 ±1 -0]: Add commandLineParams to os.nim.... 2 more lines |
19:54:02 | NimBot | Araq/Nimrod master 518c4a7 Michał Zieliński [+1 ±2 -0]: Reimplement parseopt which parses arguments given as a sequence of strings, not single string. |
19:54:02 | NimBot | 7 more commits. |
19:54:17 | zielmicha | whoa! |
19:54:52 | gradha | uh oh |
19:54:58 | Araq | zielmicha: that's NimBot. NimBot: that's zielmicha |
20:12:42 | gradha | ah, I thought that "proc `@l`()" could be called like @l, but quoting is necessary |
20:15:03 | * | PortablePuffin quit (Ping timeout: 272 seconds) |
20:25:47 | OrionPKM | araq idetools executes static: blocks? |
20:29:44 | Araq | it should |
20:31:17 | OrionPKM | mmk |
20:31:24 | * | PortablePuffin joined #nimrod |
20:43:53 | * | boydgreenfield joined #nimrod |
20:54:15 | * | achim quit (Quit: Computer has gone to sleep.) |
21:05:44 | * | boydgreenfield quit (Quit: boydgreenfield) |
21:06:12 | * | boydgreenfield joined #nimrod |
21:11:54 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
21:18:16 | * | ics joined #nimrod |
21:27:43 | zielmicha | is it possible to cheat about exported symbols? In order to write unit tests, for example. |
21:28:20 | Araq | no |
21:28:21 | gradha | you could try to include a file |
21:28:35 | Araq | oh yeah that works |
21:30:52 | zielmicha | maybe buildbot could check if module in stdlib contains "when isMainModule" and add it as test (if it already doesn't) |
21:31:53 | zielmicha | or something else, like "when isTestingLib" |
21:31:56 | gradha | I wonder if macro + slurp could allow you to build dummy nim files which autoexport everything, and you can import those dummy instead |
21:32:30 | gradha | zielmicha: some of those when isMainModule are not really serious, or don't work any more |
21:34:21 | zielmicha | quick testing written after proc with something like "when isTesting:" would surely help fighting regressions |
21:34:52 | zielmicha | but I'm not sure if the would not decrease readibility, as *.nim files in stdlib are already quite long |
21:36:36 | Araq | imho a long 'when isMainModule' section with tests is irrelevant for readability |
21:36:52 | * | vendethiel joined #nimrod |
21:37:02 | Araq | hi vendethiel welcome |
21:37:12 | vendethiel | hi Araq |
21:37:22 | joelmo | Do anyone know how I can do to read a fifo, from stdin? I get an error once it has red one message |
21:37:27 | Araq | gradha: which are "not serious"? these should be fixed |
21:38:06 | gradha | Araq: lib/pure/times.nim |
21:38:38 | Araq | then please fix it |
21:38:52 | gradha | I asked dom96 about it but got nothing |
21:39:11 | gradha | the tests are about times in the future, but the year range is quite limited |
21:39:49 | gradha | maybe those tests work in js? |
21:40:12 | Araq | they should be in a when defined(js) section then |
21:40:55 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
21:40:59 | gradha | the year range is -/+ 10_000, but the test expects 30143 |
21:41:38 | Araq | well we have to support year 40K for warhammer |
21:42:36 | gradha | the change to add the range had the commit "changed integer promotion rules; breaks bootstrapping and lots of code" |
21:42:51 | zielmicha | yeah, land rides will be programmed in Nimrod |
21:42:54 | zielmicha | What `extern: "nosp$1"` does in osproc.nim pragmas? I don't thing extern pragma is even mentioned in manual. |
21:43:32 | Araq | the manual doesn't know about specific user defined pragmas |
21:43:51 | Araq | or maybe it's too new lol |
21:44:20 | zielmicha | I don't see definition (grep fails me) |
21:44:28 | Araq | yeah looks like it's the latter |
21:44:58 | Araq | well obviously it only affect name mangling, without the "import" part of "importc" |
21:45:27 | Araq | we tell the compiler which name to generate for DLL support |
21:46:01 | zielmicha | and why is it needed? |
21:46:28 | Araq | for DLL support |
21:46:43 | Araq | usually that's enough of a reason for everybody |
21:47:27 | Araq | "what the...? -- bbbzzzt. DLL support!" |
21:47:35 | Araq | you could turn that into a comic strip |
21:47:41 | zielmicha | I just want to add public proc to osproc (quoteShell), and I don't know what to do. |
21:48:18 | zielmicha | why some are called nosp/npo/nt? |
21:48:27 | zielmicha | a some don't have this prefix? |
21:49:31 | Araq | well just do what the other exported os procs do |
21:50:17 | Araq | the prefixes are rather arbitrary |
21:51:48 | * | PortablePuffin quit (Remote host closed the connection) |
21:51:50 | zielmicha | ok, they seem to be made of letters taken from module name. |
21:52:22 | zielmicha | just noticed |
21:53:03 | * | DAddYE_ joined #nimrod |
21:53:47 | BitPuffin | oh yeah Varriount the thing wasn't updated because I couldn't figure out how to reproduce the bug, so it may as well be closed because I'm not gonna bother more with it |
21:56:11 | EXetoC | but wasn't the bug present in the gist where you did "4". .....? the only issue was that no instantiation info was printed IIRC |
21:56:43 | * | DAddYE quit (Ping timeout: 252 seconds) |
21:57:05 | EXetoC | or is this not that template bug? |
21:57:57 | BitPuffin | EXetoC: well the bug was that it didn't tell me that I couldn't have a comment below or above or whatever it was |
21:58:02 | BitPuffin | but then when I tried it it worked |
21:58:03 | BitPuffin | ugh |
21:59:31 | EXetoC | I told you yesterday that it might've been in a proc initially, and that the end result might not be the same in a template |
22:00:30 | BitPuffin | EXetoC: something like that |
22:00:39 | BitPuffin | not to keen on investigating it right now haha :) |
22:00:47 | BitPuffin | gotta apply for jobs because fuck AF |
22:01:42 | EXetoC | they won't let you? or you expect them to just send cash your way? :p |
22:07:05 | * | zielmicha quit (Ping timeout: 250 seconds) |
22:13:40 | gradha | good night, honey badgers |
22:13:43 | * | gradha quit (Quit: bbl, need to watch http://www.youtube.com/watch?v=hcDEWiH-ciw again) |
22:18:20 | * | DAddYE_ quit (Ping timeout: 245 seconds) |
22:18:24 | * | DAddYE joined #nimrod |
22:19:07 | * | DAddYE quit (Remote host closed the connection) |
22:19:44 | * | DAddYE joined #nimrod |
22:21:32 | EXetoC | BitPuffin: how will you load images? I've been using sdl_image, but I think I might go with stb_image instead |
22:23:25 | BitPuffin | EXetoC: I won't |
22:23:41 | BitPuffin | EXetoC: But I'd go with either stb_image or devil |
22:24:23 | EXetoC | so pure procedural? |
22:34:29 | * | ics joined #nimrod |
22:34:45 | EXetoC | I'll work on nim-portaudio first then |
22:35:06 | EXetoC | BitPuffin: you know you can't rely on me, but tell me if you're more in need of TTF rendering :> |
22:35:31 | BitPuffin | EXetoC: well you've been fairly reliable :P |
22:35:58 | EXetoC | c(:) |
22:36:03 | * | brihat left #nimrod (#nimrod) |
23:07:04 | joelmo | can i reopen stdin? https://gist.github.com/41e7c7b8e3c5afbb054c im trying to read continously from a fifo |
23:07:33 | joelmo | but i get stuck at EOF :) |
23:08:56 | BitPuffin | EXetoC: I can never see what that smiley should be lol |
23:09:15 | BitPuffin | joelmo: maybe you should ask about stderr instead. It's Araq's favorite topic |
23:09:37 | OrionPKM | I assumed it was a swedish smiley, but i guess not |
23:09:42 | EXetoC | c(:)-< what about this? |
23:09:56 | joelmo | its reddit |
23:10:03 | BitPuffin | I always think it's supposed to be a hat |
23:10:08 | joelmo | without arms, a swedish smiley? |
23:10:20 | BitPuffin | but it looks like he doesn't have a mouth or an end of the head |
23:10:34 | BitPuffin | c(:])-<-< makes more sense |
23:10:49 | joelmo | maybe if i get to know how to reopen stderr as stderr, i suppose thats fine too |
23:12:43 | Araq | joelmo: which OS? |
23:12:58 | EXetoC | that's like an ugly dude with a massive overbite |
23:13:02 | joelmo | Araq: Mac X |
23:13:38 | Araq | what code do you use? while not eof(stdin): readline ? |
23:13:45 | EXetoC | *underbite |
23:13:59 | joelmo | Araq: I used this https://gist.github.com/41e7c7b8e3c5afbb054c |
23:15:00 | joelmo | Araq: works the first time when i write to the fifo, but second time its just stuck in the end forever |
23:15:51 | joelmo | I have seen the tail implementations use safe_read, I dont know if this would matter |
23:16:58 | Araq | well I have no idea whether it's caused by nimrod's stdlib or the underlying C library or the OS |
23:17:10 | Araq | does it work in python/C/whatever? |
23:18:17 | joelmo | Araq: I have only tried with tail, so i wont know, i can try the same on linux |
23:19:44 | Araq | I never tried reopening of stdin |
23:20:18 | Araq | can't you just read in from proper files like everybody else? ;-) |
23:23:52 | Araq | joelmo: try to close(stdin) before you reopen it: http://stackoverflow.com/questions/9084099/re-opening-stdout-and-stdin-file-descriptors-after-closing-them |
23:24:26 | Araq | plus perhaps you want to use Posix's IO layer instead of Nimrod's (which is the same as C's) |
23:26:46 | joelmo | Araq: i get the same thing, alright i will try that :) |
23:27:18 | Araq | have fun, posix doesn't know how to read a line iirc |
23:27:38 | Araq | say hello to your own buffer handling |