| 00:02:40 | * | Raynes_ is now known as Raynes |
| 00:02:45 | * | Raynes quit (Changing host) |
| 00:02:45 | * | Raynes joined #nimrod |
| 00:03:33 | * | Associat0r joined #nimrod |
| 00:10:21 | * | NimWolf quit (Quit: Nettalk6 - www.ntalk.de) |
| 00:24:33 | * | wlhlm quit (Ping timeout: 252 seconds) |
| 00:34:28 | * | BrazPaul joined #nimrod |
| 00:34:51 | BrazPaul | Hi guys. |
| 00:35:09 | Araq | hi BrazPaul welcome |
| 00:35:51 | BrazPaul | the man himself, I'm honored. |
| 00:37:37 | Araq | well actually I'm sleeping ;-) |
| 00:38:07 | BrazPaul | not everyone can brag about having created a computer language and made hacker news first page a couple times. |
| 00:40:19 | Araq | thanks |
| 00:41:10 | BrazPaul | nimrod features are almost my entire wish list for a computer language. I hope you don't mind the flattery. |
| 00:44:11 | Araq | really? how come? we still lack row polymorphism ... ;-) |
| 00:46:35 | BrazPaul | I'm thinking about writing a DNS library. |
| 00:46:52 | BrazPaul | Any advice? |
| 00:47:18 | * | DAddYE quit (Remote host closed the connection) |
| 00:47:27 | Araq | I think there already is a DNS library somewhere, perhaps in Babel |
| 00:49:09 | Araq | hmm I think I'm wrong |
| 00:54:14 | Araq | any advice I can give is to check out the critbits.nim module, a crit bit tree is comparable to Patricia |
| 00:57:35 | BrazPaul | ok, thanks... |
| 00:58:31 | BrazPaul | github is not on its best. |
| 01:10:45 | Araq | good night |
| 01:20:32 | BrazPaul | good night |
| 01:27:02 | * | Varriount joined #nimrod |
| 01:27:30 | * | Varriount quit (Client Quit) |
| 01:33:58 | * | xenagi joined #nimrod |
| 01:40:36 | * | xenagi quit (Ping timeout: 245 seconds) |
| 01:44:09 | * | xenagi joined #nimrod |
| 01:50:21 | * | DAddYE joined #nimrod |
| 01:55:15 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 02:28:23 | * | BrazPaul left #nimrod (#nimrod) |
| 02:39:12 | * | dyu_ joined #nimrod |
| 02:51:45 | * | fowl quit (Quit: Leaving) |
| 02:59:45 | * | Varriount joined #nimrod |
| 03:07:28 | * | DAddYE joined #nimrod |
| 03:07:30 | * | DAddYE quit (Remote host closed the connection) |
| 03:07:38 | * | DAddYE joined #nimrod |
| 03:10:21 | Varriount | Anyone home? |
| 03:11:43 | OrionPK | yope |
| 03:14:55 | Varriount | OrionPK, I'm stuck in torturous maths |
| 03:15:15 | OrionPK | that sucks |
| 03:29:27 | OrionPK | i just finished my sha1 implementation in nimrod |
| 03:30:09 | * | brson quit (Ping timeout: 240 seconds) |
| 03:30:42 | xenagi | nice OrionPK |
| 03:30:53 | xenagi | did you do it from scratch? |
| 03:31:24 | OrionPK | no, it's a combination of a couple libraries I ported from C and C++ |
| 03:31:51 | xenagi | oh i see |
| 03:31:55 | xenagi | that makes sense |
| 03:32:02 | * | mflamer joined #nimrod |
| 04:02:12 | * | DAddYE quit (Remote host closed the connection) |
| 04:08:46 | * | Boscop joined #nimrod |
| 04:08:46 | * | Boscop quit (Changing host) |
| 04:08:46 | * | Boscop joined #nimrod |
| 04:21:07 | * | OrionPK quit (Quit: Leaving) |
| 04:47:37 | * | xenagi quit (Quit: Leaving) |
| 04:52:22 | * | mflamer quit (Ping timeout: 268 seconds) |
| 04:56:14 | * | Endeg joined #nimrod |
| 05:03:34 | * | DAddYE joined #nimrod |
| 05:07:41 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 05:19:40 | * | Endeg quit (Ping timeout: 246 seconds) |
| 05:52:48 | * | XAMPP_ quit (Read error: Connection reset by peer) |
| 06:04:26 | * | DAddYE joined #nimrod |
| 06:09:13 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 06:30:37 | * | Endeg joined #nimrod |
| 07:05:18 | * | DAddYE joined #nimrod |
| 07:09:35 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 07:37:50 | * | Jackneill joined #nimrod |
| 08:06:15 | * | DAddYE joined #nimrod |
| 08:10:28 | * | DAddYE quit (Ping timeout: 246 seconds) |
| 08:45:44 | * | XAMPP joined #nimrod |
| 09:02:15 | * | ics quit (Ping timeout: 260 seconds) |
| 09:04:38 | * | Endeg quit (Read error: Connection reset by peer) |
| 09:04:58 | * | ics joined #nimrod |
| 09:08:29 | * | wlhlm joined #nimrod |
| 09:33:12 | * | ics quit (Ping timeout: 246 seconds) |
| 09:34:44 | * | ics joined #nimrod |
| 09:44:39 | * | CarpNet joined #nimrod |
| 10:15:40 | BitPuffin | dom96: I should make the wm portable and you should improve the kernel and we'll make it all run in a full nimrod stack :P |
| 11:08:51 | * | DAddYE joined #nimrod |
| 11:13:51 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 11:32:35 | BitPuffin | Araq: one day (probably sometime next year) I wanna make an hpkg for nimrod :D |
| 11:35:53 | Araq | what's a hpkg? |
| 11:37:22 | BitPuffin | Araq: haiku's new package manager |
| 11:38:20 | Araq | ok yay |
| 11:38:23 | BitPuffin | it works in a pretty interesting way |
| 11:38:33 | BitPuffin | they are kind of file systems that are mounted |
| 11:39:35 | BitPuffin | so you don't have to keep track of where on the filesystem a package's files are |
| 11:39:52 | BitPuffin | and to remove a package you can just remove the hpkg manually if you so please |
| 11:43:53 | BitPuffin | anyways enough nerding about haiku |
| 11:44:06 | BitPuffin | I'm just gonna tidy up the houst and them I am gonna code on my site :D |
| 11:59:28 | wlhlm | BitPuffin: kind of like *.app directories in Mac OS? |
| 12:03:47 | wlhlm | BitPuffin: nevermind, you mean something different… |
| 12:06:38 | wlhlm | *ment |
| 12:06:51 | dom96 | hello |
| 12:07:02 | wlhlm | hi |
| 12:09:02 | * | faassen joined #nimrod |
| 12:09:45 | * | DAddYE joined #nimrod |
| 12:14:55 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 12:16:35 | BitPuffin | hey dom96! |
| 12:16:48 | dom96 | hello BitPuffin! |
| 12:16:53 | BitPuffin | dom96: wassup? |
| 12:17:01 | dom96 | nm, just woke up :P |
| 12:17:05 | BitPuffin | hehe :P |
| 12:17:35 | BitPuffin | dom96: the optimization of jester is not in jester itself right? Rather in the nimrod httpserver? |
| 12:17:52 | dom96 | yeah |
| 12:18:06 | BitPuffin | I see |
| 12:18:11 | dom96 | Will try to fix sockets today |
| 12:18:18 | BitPuffin | well I am not very worried about performance for this website |
| 12:18:29 | BitPuffin | but the next website I'll make is a bit more critical |
| 12:19:31 | dom96 | and I will make it set SO_REUSEADDR, so that it's not as annoying to test. |
| 12:20:22 | olahol | dom96: I'm about to submit a babel package (my first one) is it possible for you to check if it's well formated? https://github.com/olahol/nimrod-murmur |
| 12:20:46 | dom96 | olahol: Awesome! |
| 12:20:47 | * | dom96 checks |
| 12:21:24 | BitPuffin | dom96: nice! |
| 12:22:07 | BitPuffin | olahol: cool! never heard of that hash, what's the purpse of it? |
| 12:22:21 | dom96 | olahol: looks good. |
| 12:22:57 | olahol | BitPuffin: it's a fast hash that's good for implementing bloom filters and hash tables |
| 12:23:21 | olahol | dom96: ok, i'll submit a pull request to nimrod-code/packages :) |
| 12:23:24 | BitPuffin | olahol: what you probably should do though is to either put a license file in the project or license text in the source |
| 12:23:33 | BitPuffin | rather than just saying MIT in babel file |
| 12:23:36 | dom96 | olahol: oh, what would be nice is if you tag the commit as 'v0.1.0' |
| 12:24:04 | olahol | BitPuffin: ah, knew i forgot something |
| 12:24:06 | BitPuffin | olahol: are you swedish by any chance? |
| 12:24:15 | dom96 | so that when you update it later users can still install 0.1 specifically. |
| 12:24:20 | BitPuffin | since you have ö in your last name |
| 12:24:33 | olahol | BitPuffin: yep |
| 12:24:37 | BitPuffin | olahol: gött :D |
| 12:24:46 | olahol | dom96: ok will do |
| 12:24:48 | BitPuffin | one swede leaves, one swede comes |
| 12:25:05 | dom96 | I miss EXetoC, where is he!? |
| 12:25:11 | BitPuffin | I don't know |
| 12:25:16 | BitPuffin | he's been compromised |
| 12:25:50 | BitPuffin | dom96: Keep a buffer of a private chat with him open and we will be able to see if he's cheating on nimrod |
| 12:25:58 | BitPuffin | dom96: /query EXetoC |
| 12:26:15 | dom96 | BitPuffin: I don't think xchat tracks users like that :P |
| 12:26:28 | BitPuffin | dom96: it does say if they come online |
| 12:26:52 | BitPuffin | dom96: so if you are online and he comes online while you have him open in a buffer. It will say something like EXetoC came online etc |
| 12:26:57 | dom96 | In any case, /ns info EXetoC |
| 12:27:11 | dom96 | Really? I've never seen that happen. |
| 12:27:20 | BitPuffin | well |
| 12:27:23 | BitPuffin | I don't use xchat |
| 12:27:28 | BitPuffin | :P |
| 12:27:41 | dom96 | That's what I thought. |
| 12:27:54 | dom96 | NickServ says he's last seen on Oct 20th |
| 12:27:58 | dom96 | Which is when he was here. |
| 12:30:06 | BitPuffin | awh |
| 12:30:45 | BitPuffin | dom96: he does have a skype |
| 12:30:51 | BitPuffin | with a face! |
| 12:30:55 | BitPuffin | I KNOW HOW HE LOOKS |
| 12:31:00 | BitPuffin | </stalk> |
| 12:31:05 | dom96 | his gravatar also shows his face :P |
| 12:32:04 | BitPuffin | haha |
| 12:32:32 | BitPuffin | hmm |
| 12:32:38 | BitPuffin | well he lives in sthlm |
| 12:32:44 | BitPuffin | and I am not going there xD |
| 12:33:23 | BitPuffin | maybe his computer exploaded |
| 12:33:34 | BitPuffin | killing him in the process :( |
| 12:33:37 | * | BitPuffin is getting worried |
| 12:33:56 | dom96 | :( |
| 12:34:49 | BitPuffin | dom96: try emailing him. If he has an android phone he'll at least be able to check his gmail in case his computer is broken |
| 12:36:36 | dom96 | there, sent |
| 12:38:03 | BitPuffin | goodie |
| 12:39:51 | olahol | dom96: I've added the version tag and the license and sent a pull request to packages. |
| 12:40:54 | BitPuffin | cool! |
| 12:41:05 | BitPuffin | olahol: where in sweden do you live btw? |
| 12:41:16 | NimBot | nimrod-code/packages master 37989ac Ola Holmström [+0 ±1 -0]: added murmur |
| 12:41:16 | NimBot | nimrod-code/packages master c556138 Dominik Picheta [+0 ±1 -0]: Merge pull request #28 from olahol/master... 2 more lines |
| 12:41:22 | dom96 | olahol: Thank you :) |
| 12:41:22 | BitPuffin | wooo |
| 12:41:25 | BitPuffin | gbg! |
| 12:41:27 | olahol | BitPuffin: Göteborg |
| 12:41:48 | BitPuffin | olahol: me too :D |
| 12:42:21 | olahol | dom96: yay! my first nimrod module |
| 12:42:30 | dom96 | :D |
| 12:42:39 | olahol | BitPuffin: nice, we should start a nimrod meetup group |
| 12:42:40 | BitPuffin | olahol: keep it up :D |
| 12:42:48 | olahol | :) |
| 12:44:46 | BitPuffin | me and olahol can have a mini nimcon right here in sweden lol >.< |
| 12:45:11 | dom96 | Where are the Irish programmers :( |
| 12:45:37 | dom96 | I want a mini nimcon in Ireland. |
| 12:45:58 | BitPuffin | dom96: it's probably not expensive for you to come to gothenburg for a day :P |
| 12:50:29 | dom96 | £269 apparently |
| 12:50:36 | dom96 | with a 12h layover in London D: |
| 12:52:00 | BitPuffin | wat :/ |
| 12:53:00 | BitPuffin | haha I accidentally left olahol's profile picture open in a tab on the screen while I was making some sadwitches, kind of funny to come back to with him standing there xD |
| 12:59:16 | * | Ricky_Ricardo joined #nimrod |
| 12:59:42 | capisce | I'm from Göteborg too |
| 12:59:48 | capisce | but don't live there |
| 13:00:00 | BitPuffin | where do you live then? |
| 13:01:50 | capisce | Oslo atm |
| 13:01:59 | BitPuffin | ah cool |
| 13:02:07 | BitPuffin | for work I assume? |
| 13:02:32 | capisce | yep |
| 13:03:00 | * | Jesin quit (Remote host closed the connection) |
| 13:03:31 | * | ievleff quit (Remote host closed the connection) |
| 13:05:50 | * | mkb quit (Ping timeout: 240 seconds) |
| 13:10:38 | * | DAddYE joined #nimrod |
| 13:15:08 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 13:17:31 | * | Dispatch joined #nimrod |
| 13:18:20 | Araq | hi Dispatch welcome |
| 13:20:03 | Dispatch | Hi |
| 13:20:35 | Dispatch | I am playing with nimrod, so I though I'd check out the irc channel |
| 13:22:05 | capisce | to see what it's all about? |
| 13:22:32 | Dispatch | To see if there is help when I need it |
| 13:22:52 | Dispatch | So good to see there are people here |
| 13:25:20 | Dispatch | I am playing with opengl and I found this: https://github.com/rafaelvasco/nimrod-glfw and this: http://pastebin.com/7pfYer7u |
| 13:25:52 | Dispatch | With the second example I now have a triangle running with shaders. Anyone know of any other nimrod opengl examples? |
| 13:27:29 | * | OrionPK joined #nimrod |
| 13:28:16 | Araq | there are quite a few, I think but I don't know where to find them either |
| 13:28:35 | Araq | OrionPK: have some opengl code lying around? |
| 13:29:16 | OrionPK | only webGL |
| 13:29:47 | Dispatch | Ok, np, I'll try and figure it out |
| 13:32:50 | * | mkb joined #nimrod |
| 13:34:23 | Araq | see you later |
| 13:36:59 | BitPuffin | Dispatch: well if you get stuck on something we'll try and help you out best we can. I am currently working on a game with nimrod but I have some stuff to do before I can get some serious work done in it. |
| 13:37:15 | OrionPK | Araq, why does base64.encode break into newlines? |
| 13:38:10 | dom96 | OrionPK: I think that's just how base64 works |
| 13:38:42 | OrionPK | could be I guess.. |
| 13:39:13 | OrionPK | I've never gotten newlines out of something i base64 encode though |
| 13:39:27 | OrionPK | for example, converting an image to a datauri |
| 13:39:29 | OrionPK | it's all on 1 line |
| 13:39:32 | Dispatch | ok, thx. |
| 13:39:56 | dom96 | Dispatch: https://github.com/fowlmouth/nimlibs/tree/master/fowltek/musings/nim3d |
| 13:40:06 | dom96 | That may be an opengl example too |
| 13:40:25 | dom96 | OrionPK: Take a look at the example on wikipedia |
| 13:40:39 | OrionPK | I looked for "75" |
| 13:40:42 | OrionPK | in that article |
| 13:40:50 | OrionPK | which is the current line length in base64.encode |
| 13:41:02 | dom96 | https://en.wikipedia.org/wiki/Base64#Examples |
| 13:41:22 | dom96 | It's not all a single line there |
| 13:41:22 | OrionPK | I mean.. they would wrap that reguardless |
| 13:41:39 | OrionPK | or it would be very wide |
| 13:41:42 | Dispatch | dom96: thx, I'll check it out |
| 13:42:15 | dom96 | I was thinking the same thing when I was using it. |
| 13:42:19 | dom96 | Now I can't remember where i've used it. |
| 13:42:23 | OrionPK | dom96 I think several formats want newline separators, but not base64 encoding itself |
| 13:42:40 | dom96 | But if it was a problem I would've fixed it |
| 13:42:49 | OrionPK | dom96 like MIME |
| 13:43:36 | dom96 | OrionPK: You can always override newline to "" |
| 13:43:52 | OrionPK | yeah |
| 13:44:07 | OrionPK | dom96 I'm submitting a patch for it, is there an easy way to specify that a generic can be any integer type |
| 13:44:20 | OrionPK | int|int8|int16 etc is kind verbose |
| 13:44:40 | dom96 | TNumber |
| 13:44:55 | OrionPK | perfect, thanks |
| 13:45:04 | dom96 | actually, you probably want TInteger |
| 13:45:18 | dom96 | TNumber will match float |
| 13:45:20 | OrionPK | yeah probably better |
| 13:47:24 | C0C0 | OrionPK: at least ruby and python both add newlines unless one uses strict encoding |
| 13:47:25 | OrionPK | dom96 what about something with an [int] index and .len support |
| 13:47:41 | OrionPK | C0C0 thanks |
| 13:48:02 | C0C0 | (have seen so many people building broken code because of this) |
| 13:48:42 | dom96 | OrionPK: dunno, look through system you might find something |
| 13:49:32 | OrionPK | dom96 what about a way to pass a string to an openarray of chars |
| 13:50:21 | dom96 | just use: openarray[char] | string |
| 13:51:36 | OrionPK | hmm, not working |
| 13:51:40 | OrionPK | getting a type mismatch with my call |
| 13:53:30 | dom96 | gist the code |
| 13:53:35 | OrionPK | sec |
| 13:57:59 | OrionPK | dom96 using template instead |
| 13:58:06 | OrionPK | I just wanted to avoid code duplication |
| 13:58:18 | dom96 | alright |
| 14:01:22 | * | mflamer joined #nimrod |
| 14:08:19 | OrionPK | dom96 https://github.com/Araq/Nimrod/pull/646 |
| 14:11:24 | dom96 | why not just convert the integer into a string? |
| 14:11:33 | * | DAddYE joined #nimrod |
| 14:14:37 | OrionPK | you're basically treating the string as a series of integers |
| 14:15:36 | OrionPK | so might as well expose the ability to pass in a series of integers |
| 14:15:44 | dom96 | and then you can't decode into an integer anyway |
| 14:16:14 | dom96 | what is the use case here? |
| 14:16:15 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 14:16:28 | OrionPK | I'm encoding an array of uint8's in my sha1 module |
| 14:16:46 | OrionPK | which is also coming |
| 14:17:13 | dom96 | well, I dunno. Araq wrote base64 so i'll let him decide. |
| 14:21:19 | * | mflamer quit (Ping timeout: 272 seconds) |
| 14:22:28 | Dispatch | Anyone know how I pass a Pointer with a value of 9? |
| 14:29:44 | BitPuffin | Dispatch: pointer or reference? |
| 14:29:51 | BitPuffin | not that it makes a difference |
| 14:30:10 | Dispatch | a pointer to define the offset in glVertexAttribPointer |
| 14:30:40 | Dispatch | don't ask me why opengl wants it as a pointer |
| 14:32:08 | Dispatch | casting makes it compile but it crashed with a sigsegv |
| 14:35:33 | Dispatch | no wait, crashing was another problem |
| 14:35:50 | Dispatch | runs, but I don't see the expected result |
| 14:42:43 | * | pinchuk joined #nimrod |
| 14:44:47 | dom96 | hello pinchuk |
| 14:46:44 | Dispatch | fyi, solved my problem, pointer offset is in bytes not element :-s |
| 14:48:30 | * | pinchuk quit (Read error: Connection reset by peer) |
| 14:56:42 | * | Ricky_Ricardo quit (Quit: Ricky_Ricardo) |
| 14:57:05 | * | io2 joined #nimrod |
| 15:10:17 | OrionPK | dom96 araq https://github.com/onionhammer/onion-nimrod/blob/master/websockets/sha1.nim |
| 15:10:26 | OrionPK | this depends on that change I submitted |
| 15:10:40 | OrionPK | and websockets depends on it |
| 15:12:05 | * | DAddYE joined #nimrod |
| 15:14:07 | * | MFlamer joined #nimrod |
| 15:16:38 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 15:20:29 | dom96 | OrionPK: good work :) |
| 15:21:10 | Dispatch | thx people, cya next time |
| 15:21:21 | * | Dispatch quit (Quit: Page closed) |
| 15:25:53 | * | Associat0r quit (Quit: Associat0r) |
| 15:55:32 | MFlamer | Araq: what looks sketchey in my bug fix? |
| 15:55:43 | Araq | the logic :P |
| 15:56:12 | MFlamer | ok, I'll take a look at it |
| 15:57:29 | Araq | the thing is ... I didn't write that drunk :P |
| 15:57:40 | Araq | so it should be a 1-line fix |
| 15:57:42 | MFlamer | You had mereged it into your working branch and noticed a problem? |
| 15:57:52 | Araq | yeah |
| 15:58:31 | MFlamer | So, I need to get drunk before I'll see the compiler clearly |
| 15:58:43 | MFlamer | no prob |
| 15:58:47 | Araq | lol |
| 15:58:53 | MFlamer | brb |
| 15:58:55 | * | MFlamer quit (Remote host closed the connection) |
| 16:13:22 | * | DAddYE joined #nimrod |
| 16:14:03 | OrionPK | Araq, candidate for standard lib or a separate package? https://github.com/onionhammer/onion-nimrod/blob/master/websockets/sha1.nim |
| 16:16:49 | Araq | OrionPK: since you're the author and thus maintainer (you will maintain it, right?) it should be a babel package |
| 16:17:16 | OrionPK | yeah.. if so then so should md5 |
| 16:17:30 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 16:17:32 | Araq | true I guess |
| 16:17:34 | OrionPK | md5 and sha1 are such basic operations I thought it might be worth it to put it into the standard lib |
| 16:17:44 | Araq | yes and you're right |
| 16:17:57 | Araq | but it's also a question of who owns the code ;-) |
| 16:18:01 | OrionPK | lol |
| 16:18:19 | OrionPK | I can submit patches if it breaks :P |
| 16:19:43 | OrionPK | afk |
| 16:23:40 | Araq | OrionPK: you instantiate computeInternal twice ... this leads to code bloat which is unnecessary |
| 16:24:46 | Araq | well I think it's unnecessary ... does compute make sense for openarray[int], for instance? |
| 16:35:10 | * | MFlamer joined #nimrod |
| 16:40:49 | NimBot | Araq/Nimrod master 5e8a24f Dominik Picheta [+0 ±1 -0]: TPort is now uint16 and other small sockets fixes. |
| 16:40:49 | NimBot | Araq/Nimrod master 1ff2f4f Dominik Picheta [+0 ±4 -0]: Implemented boolean socket options.... 2 more lines |
| 16:41:37 | NimBot | dom96/jester master 4e3fe6b Dominik Picheta [+0 ±3 -0]: Implemented SO_ReuseAddr. |
| 16:41:37 | NimBot | dom96/jester master bed6fac Dominik Picheta [+0 ±1 -0]: Merge branch 'master' of github.com:dom96/jester |
| 16:41:57 | dom96 | BitPuffin: voila. |
| 16:42:11 | Araq | OrionPK: it's not that you can't submit patches, it's that we then need to review your patches and apply them in time |
| 16:42:22 | Araq | Which is getting harder and harder for me. :-/ |
| 16:49:27 | MFlamer | I wish I could take a couple weeks and do nothing but learn the compiler's inner workings... |
| 16:52:35 | OrionPK | Araq it makes sense if the situation calls for it |
| 16:52:52 | OrionPK | I would make it a generic [T:string|openarray[int]] but that doesnt seem to work |
| 16:56:27 | Araq | OrionPK: fine I guess ... I prefer 'cstring' over openarray[byte] but it's not important |
| 16:58:11 | OrionPK | websockets depend on sha1 |
| 16:58:27 | OrionPK | so those would have to be two new babel packages I guess |
| 16:59:11 | Araq | yeah I agree |
| 17:00:38 | Araq | ping zahary1, zahary___ |
| 17:01:45 | Araq | I plan to get rid of this 'nkDo' insertion rule. It's too confusing for macro writers. Instead we need a "skipDo" proc in macros.nim that lets you handle both syntaxes transparently. Any downsides with this solution? |
| 17:02:56 | OrionPK | Araq also line 57 depends on a modification I submitted to base64 earlier |
| 17:03:00 | Araq | anything that violates wysiwyg aspects for the AST is a no go |
| 17:08:30 | * | hoverbear joined #nimrod |
| 17:09:31 | Araq | OrionPK: promise me you tested the changes to base64 |
| 17:09:52 | OrionPK | Araq I did |
| 17:10:13 | NimBot | Araq/Nimrod master 126451f onionhammer [+0 ±1 -0]: Added base64 encode overload for arrays of integers/bytes |
| 17:10:13 | NimBot | Araq/Nimrod master 09569c4 Andreas Rumpf [+0 ±1 -0]: Merge pull request #646 from onionhammer/patch-1... 2 more lines |
| 17:11:10 | OrionPK | The change is only really 3 or 4 lines, idk why it highlights all that. |
| 17:11:31 | Araq | you changed the newlines I guess |
| 17:11:59 | OrionPK | I assumed git stripped out \r\n's and replaced with \n |
| 17:12:38 | Araq | yeah git is pretty smart when it comes to newlines. It'll happily corrupt binary files when you're not careful and doesn't know they are irrelevant in a diff at the same time. |
| 17:16:21 | * | DAddYE_ joined #nimrod |
| 17:16:25 | * | DAddYE_ quit (Remote host closed the connection) |
| 17:16:39 | * | DAddYE_ joined #nimrod |
| 17:23:02 | * | hoverbear quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 17:28:20 | Araq | so ... here is a tough problem for you guys out there: |
| 17:29:42 | Araq | the JS backend doesn't want lambda lifting because this makes Nimrod's closures not interoperable with JS. The compile time evaluation engine requires lambda lifting. |
| 17:30:18 | Araq | so if you evaluate a closure both at compile time and then at runtime for the JS backend things can't work. |
| 17:31:58 | Araq | at the same time, relying on JS's closures changes the semantics slightly. |
| 17:34:22 | dom96 | why does the eval engine require lambda lifting? |
| 17:34:40 | dom96 | oh, I guess it can evaluate lambdas now. |
| 17:35:06 | dom96 | can't we just not rely on JS' closures? |
| 17:35:49 | Araq | it's hard. Nimrod's closure is a [fn, env] pair in JS. You can't pass that to JS callback |
| 17:36:02 | Araq | and callbacks are everywhere in JS |
| 17:36:25 | Araq | I can live with the slightly changed semantics but having no interop would be a show stopper |
| 17:37:09 | OrionPK | you dont need env with a JS closure, right? |
| 17:39:24 | Araq | right that does JS for us |
| 17:39:54 | OrionPK | right, captures parent scope.. cant you just not lift closures for js backend? |
| 17:40:06 | OrionPK | erm, lift lambdas |
| 17:40:21 | Araq | that's what we currently do |
| 17:40:33 | Araq | but it breaks compile time evaluation |
| 17:40:51 | Araq | well it's not too bad really |
| 17:41:15 | Araq | we can lift closures for macros and .compileTime procs only for the JS target |
| 17:41:31 | Araq | or we could keep both versions of the code around |
| 17:41:36 | Araq | but I dislike that |
| 17:43:49 | OrionPK | sounds like a conundrum |
| 17:43:56 | * | MFlamer quit (Remote host closed the connection) |
| 17:44:32 | dom96 | Former sounds like a better option |
| 17:46:56 | Araq | bbl |
| 17:55:40 | * | MFlamer joined #nimrod |
| 18:35:38 | * | CarpNet quit (Quit: Leaving) |
| 18:59:21 | Araq | ping MFlamer |
| 18:59:29 | MFlamer | hey |
| 18:59:51 | Araq | so .. the code is this: |
| 18:59:58 | Araq | if c.cmp == dcEq: result = sameDistinctTypes(a, b) and sameFlags(a, b) |
| 19:00:00 | Araq | else: result = sameTypeAux(a.sons[0], b.sons[0], c) and sameFlags(a, b) |
| 19:00:42 | Araq | where sameDistinctTypes() is an alias to sameObjectTypes |
| 19:00:43 | MFlamer | thats the correct code? |
| 19:00:51 | Araq | that's the original version I think |
| 19:00:54 | * | Endy joined #nimrod |
| 19:01:30 | Araq | and sameObjectTypes creates a new "closure" (btw I keep using "closure" for "environment" in the compiler) |
| 19:02:27 | MFlamer | yeah, ok. The fix for the first bug was sending the existing env alog so we dont endup in a run away recursion |
| 19:02:48 | Araq | the question is why we run into this endless recursion |
| 19:02:56 | * | [1]Endy joined #nimrod |
| 19:03:24 | Araq | how does the type graph look like that triggers it? |
| 19:03:49 | MFlamer | because it just sends the same a & b into the function again |
| 19:04:24 | Araq | aha, good point |
| 19:04:46 | Araq | and we mustn't do this |
| 19:04:51 | MFlamer | theres no real work being done |
| 19:05:01 | MFlamer | what is wrong with that fix? |
| 19:05:35 | Araq | you can't just pass the closure along and expect it to work |
| 19:05:38 | MFlamer | There were 2 bugs in this code I tried to fix. You see tha, right? |
| 19:05:45 | Araq | yes |
| 19:05:57 | Araq | the closure merely prevents the endless recursion |
| 19:06:04 | Araq | but it's not the way to fix it |
| 19:06:14 | * | Endy quit (Ping timeout: 240 seconds) |
| 19:06:14 | * | [1]Endy is now known as Endy |
| 19:06:48 | MFlamer | oh. Ok, theres more to this closure and its lazy instiantiation then I understood |
| 19:07:31 | Araq | the fix is to inline 'sameDistinctTypes' but to recurse into a.sons[0], b.sons[0] in the case they come from a generic instantiation |
| 19:12:06 | MFlamer | inline? sameDistinctTypes already is inline. Or, do you mean something else? |
| 19:18:46 | wlhlm | Araq: the testsuite prints an error message when there is a problem, doesn't it? |
| 19:19:08 | dom96 | wlhlm: no. The testresults.html file shows the error. |
| 19:19:24 | wlhlm | dom96: ahh, thanks |
| 19:21:01 | wlhlm | dom96: how many tests are passed/skipped with your compiler? |
| 19:21:53 | dom96 | ehh, dunno. I don't run the tester. Check nimbuild. |
| 19:32:19 | Araq | MFlamer: SameTypeAux doesn't inline sameDistinctTypes in my version |
| 19:32:42 | BitPuffin | dom96: oh awesome!! |
| 19:34:25 | * | OrionPK quit (Quit: Page closed) |
| 19:34:41 | MFlamer | Araq: I dont understand what you mean by "inline sameDistinctTypes" |
| 19:34:53 | BitPuffin | oh fuck doxygen |
| 19:34:58 | BitPuffin | installs 1gb of shit |
| 19:42:23 | Araq | MFlamer: if sameFlags(a, b): |
| 19:42:24 | Araq | IfFastObjectTypeCheckFailed(a, b): |
| 19:42:26 | Araq | result = sameTypeAux(a.sons[0], b.sons[0], c) |
| 19:42:48 | Araq | in my line 840 |
| 19:42:56 | Araq | (before your patches I hope) |
| 19:43:16 | MFlamer | ok |
| 19:47:36 | BitPuffin | dom96: I suppose the optimization is a much larger issue to solve? |
| 19:47:48 | dom96 | BitPuffin: indeed. |
| 19:47:56 | BitPuffin | dom96: what needs to be done? |
| 19:48:04 | dom96 | Well first, I want to research it well. |
| 19:48:39 | dom96 | And ugh, it's already almost the end of the day... |
| 19:52:41 | wlhlm | that testsuite is pretty weird - some tests pass locally but fail on build.nimrod-code.org |
| 19:53:26 | dom96 | Well there are many factors which affect it: CPU, OS, C compiler and version etc. |
| 19:54:23 | * | enurlyx joined #nimrod |
| 19:55:55 | wlhlm | yeah that might be a thing… do you know which compiler the linux-x86_64 build system is using? |
| 19:56:05 | * | brson joined #nimrod |
| 19:56:33 | dom96 | wlhlm: 4.4.5 |
| 19:56:44 | wlhlm | gcc? |
| 19:56:48 | dom96 | yes |
| 19:59:10 | * | bittermoon joined #nimrod |
| 19:59:20 | dom96 | hi bittermoon |
| 20:01:12 | Araq | hi bittermoon, welcome |
| 20:02:41 | * | Dispatch joined #nimrod |
| 20:09:45 | BitPuffin | dom96: Ah well then I probably don't have time to do it! Plus you already know the source |
| 20:10:26 | dom96 | BitPuffin: ah, yeah. Don't worry, I will get it done ... eventually. |
| 20:10:50 | BitPuffin | dom96: no huge rush :D my personal site will do fine without it |
| 20:11:08 | BitPuffin | it's just if I'm gonna write my company site in nimrod |
| 20:11:57 | * | sebcrozet joined #nimrod |
| 20:12:07 | BitPuffin | Araq: do you want me to start maintaining a debian repo for nimrod? |
| 20:12:57 | * | bittermoon quit (Read error: Connection reset by peer) |
| 20:13:57 | Araq | tbh ... I don't care, BitPuffin. Linux package management is not my cup of tea. |
| 20:14:24 | BitPuffin | Araq: I was more thinking for the sake of adoption but okay |
| 20:14:53 | dom96 | BitPuffin: Do it. You're using debian nowadays anyway. |
| 20:15:01 | dom96 | How is Debian btw? |
| 20:15:17 | BitPuffin | one thing that I found very convenient when I was a D user was to have a debian repo for it that always had latest compiler |
| 20:15:46 | BitPuffin | dom96: Well I probably won't use that at least not until nimrod 1.0, I'll be on the git version most of the time |
| 20:15:58 | BitPuffin | dom96: It is nice so far, currently setting up the git version of wayland |
| 20:16:07 | BitPuffin | which would be a bit nicer in arch |
| 20:16:14 | BitPuffin | but I switched for the kxstudio repos |
| 20:16:19 | BitPuffin | and arch can't match those |
| 20:25:58 | * | shodan45 quit (Ping timeout: 245 seconds) |
| 20:29:11 | dom96 | I'm really tempted to just copy Python's approach to asyncio |
| 20:29:55 | BitPuffin | dom96: is it good? |
| 20:30:02 | dom96 | yeah, it looks good. |
| 20:31:09 | * | shodan45 joined #nimrod |
| 20:35:43 | * | klubbman joined #nimrod |
| 20:36:23 | * | [1]Endy joined #nimrod |
| 20:36:39 | dom96 | it looks pretty similar to what asyncio currently is like :) |
| 20:36:51 | BitPuffin | dom96: except? |
| 20:37:09 | dom96 | it supports epoll/kqueue/IOCP |
| 20:39:02 | * | Endy quit (Ping timeout: 240 seconds) |
| 20:39:02 | * | [1]Endy is now known as Endy |
| 20:42:58 | * | OrionPK joined #nimrod |
| 20:47:52 | * | Endy quit (Ping timeout: 264 seconds) |
| 20:56:18 | Araq | bbl |
| 20:59:51 | * | MFlamer quit (Ping timeout: 248 seconds) |
| 21:01:56 | * | MFlamer joined #nimrod |
| 21:11:31 | * | faassen left #nimrod (#nimrod) |
| 21:17:30 | * | klubbman quit (Ping timeout: 256 seconds) |
| 21:21:15 | * | kakoo joined #nimrod |
| 21:22:45 | kakoo | hey all... I am curious about nimrod. After a first look, it looks really cool, but I have a question: what is the current state of async io alternatives in nimrod? |
| 21:23:27 | dom96 | hello kakoo! |
| 21:23:36 | dom96 | Funnily enough I am improving asyncio right now. |
| 21:24:00 | dom96 | Currently it only supports select so it's not ideal. |
| 21:24:48 | dom96 | As for alternatives, you could use libevent if you really wanted to. But hopefully I will be able to get the improvements finished soon. |
| 21:25:36 | * | shodan45 quit (Quit: Konversation terminated!) |
| 21:27:29 | kakoo | I am not very familiar with underlying details of async libraries at low level... select, kqueue something-poll, I don't really know what those things are and how they provide async IO |
| 21:27:54 | dom96 | Ahh. Well what would you like to use asyncio for? |
| 21:28:20 | * | CarpNet joined #nimrod |
| 21:29:50 | kakoo | An experimental DHT, async network comunications are not a critical must-have. But I feel like in 2013, spawning processes or threads for blocking calls is just ancient bloat |
| 21:30:36 | kakoo | or is there any green thread implementation? |
| 21:30:55 | dom96 | No, currently just heavy threads. |
| 21:31:22 | wlhlm | Hi CarpNet! Did you get your linker problems solved? |
| 21:31:22 | kakoo | :( |
| 21:31:22 | dom96 | You can either try the current asyncio implementation or wait for my improvements; they may break some things. |
| 21:31:35 | * | Dispatch quit (Ping timeout: 250 seconds) |
| 21:32:06 | CarpNet | wlhm: unfortunately not so far, i've given up on that at the moment in favour of programming something in Nimrod that doesn't involve dynamically linked libraries :P |
| 21:32:14 | CarpNet | i'll get back to it after that i imagine |
| 21:32:21 | * | dyu_ quit (Quit: Leaving) |
| 21:32:27 | kakoo | so to use libevent.... how does that work, how does one use C libraries? I guess I would need to create some binding or something in those lines...? |
| 21:32:52 | * | shodan45 joined #nimrod |
| 21:33:44 | wlhlm | CarpNet: so, have fun with the other parts of nimrod :P |
| 21:33:51 | CarpNet | haha indeed |
| 21:34:10 | dom96 | kakoo: DAddYE_ made a wrapper for libuv: https://github.com/DAddYE/node.nim, you could use it if you wish. |
| 21:34:16 | BitPuffin | dom96: break what? :O |
| 21:34:33 | dom96 | BitPuffin: the asyncio API |
| 21:34:46 | * | MFlamer quit (Ping timeout: 246 seconds) |
| 21:35:18 | BitPuffin | dom96: ah so not jester api |
| 21:36:17 | dom96 | BitPuffin: nah, but that may change too. But just slightly for optimisation purposes so don't worry. |
| 21:36:38 | BitPuffin | dom96: there isn't really much to change :P |
| 21:36:49 | dom96 | yeah. |
| 21:37:21 | dom96 | Araq told me to optimise the routes into a case statement. So I may do that. |
| 21:37:46 | dom96 | That will require a 'routes' macro above all the 'get' etc. So changes should be minimal. |
| 21:37:52 | BitPuffin | dom96: you mean internally? |
| 21:38:25 | dom96 | no. You will have to place a routes: and put all your routes in its scope. |
| 21:39:16 | BitPuffin | dom96: "place a routes"? |
| 21:39:35 | dom96 | put it in your code. |
| 21:39:38 | dom96 | routes: |
| 21:39:41 | dom96 | get "/": ... |
| 21:39:42 | BitPuffin | oh |
| 21:39:54 | dom96 | Sorry, i'm being extremely unclear heh. |
| 21:39:58 | BitPuffin | oh okay so to update my code I would just put routes: |
| 21:40:03 | BitPuffin | and indent everythin below xD |
| 21:40:08 | dom96 | yeah. |
| 21:40:13 | dom96 | I hope so at least. |
| 21:40:16 | dom96 | :P |
| 21:40:41 | BitPuffin | I'm sorry but how much do we even gain from that? |
| 21:40:43 | dom96 | But I won't be wildly breaking things, so don't worry. |
| 21:40:54 | dom96 | I'll benchmark it and see :P |
| 21:41:40 | dom96 | But Araq is an optimisation God, so it may make a huge difference. |
| 21:41:59 | BitPuffin | I guess we'll see |
| 21:42:18 | BitPuffin | Araq is an * god :P |
| 21:42:20 | BitPuffin | kidding |
| 21:42:20 | BitPuffin | :D |
| 21:42:26 | BitPuffin | but yeah |
| 21:43:11 | * | enurlyx quit (Quit: Nettalk6 - www.ntalk.de) |
| 21:44:02 | * | dymk quit (Ping timeout: 264 seconds) |
| 21:44:41 | BitPuffin | ughh |
| 21:45:32 | BitPuffin | the worst thing about compiling stuff from source or rather configuring before compiling is that it stops as soon as it finds something that is missing. Tell me everything that is missing and not just freaking one at a time |
| 21:46:05 | dom96 | Use 'nimrod check' |
| 21:46:15 | dom96 | it lists all errors |
| 21:46:25 | BitPuffin | dom96: ah I don't mean nimrod |
| 21:46:31 | BitPuffin | I just mean errthing |
| 21:46:44 | dom96 | i see |
| 21:49:33 | Araq | CarpNet: it might be some 32bit vs 64bit build issue |
| 21:49:46 | CarpNet | hmmm i was thinking that, i never actually got round to testing that |
| 21:50:35 | CarpNet | though i built Nimrod from source, along with the shared library itself, unless Nimrod just builds as 32 bit anyway? |
| 21:51:31 | * | dymk joined #nimrod |
| 21:51:49 | Araq | nimrod builds as whatever build.sh detected |
| 21:52:00 | CarpNet | should be 64 bit in my case then |
| 21:53:10 | Araq | just invoke nimrod and see what it says |
| 21:53:32 | CarpNet | it links correctly in my simple C test case, however the lib does depend on libm so i had to explicity include that... not sure if nimrod handles that? |
| 21:54:03 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 21:54:15 | Araq | depends on how you wrap libm. is that just C's math.h? |
| 21:54:21 | CarpNet | yeah |
| 21:54:39 | Araq | nimrod should handle that then |
| 21:55:27 | BitPuffin | yeah nimrod already has math.h in the stdlib but nimrodified doesn't it? |
| 21:56:09 | BitPuffin | Araq: You wanted to make a company for nimrod right? |
| 21:56:48 | * | MFlamer joined #nimrod |
| 21:57:18 | Araq | BitPuffin: in the long term, sure. in short term I don't see a chance. |
| 21:57:32 | BitPuffin | Araq: how come a company and not a non-profit? |
| 21:57:53 | Araq | I like profit. |
| 21:58:46 | BitPuffin | well you would still be able to earn a living. Just that the goal of the non-profit is to finance nimrod |
| 21:58:55 | BitPuffin | ie you |
| 21:59:05 | * | DAddYE_ quit (Remote host closed the connection) |
| 21:59:11 | Araq | hah and I thought we already have that |
| 21:59:31 | BitPuffin | Araq: have what? |
| 21:59:35 | * | simpleirc1 joined #nimrod |
| 22:00:53 | Araq | BitPuffin: http://nimrod-code.org/community.html "Donations" |
| 22:01:12 | BitPuffin | Araq: well yeah but it's not going to a company it is going to an individual |
| 22:01:24 | BitPuffin | Araq: isn't there like a limit on how much we could donate to an individual |
| 22:01:50 | * | DAddYE joined #nimrod |
| 22:02:06 | BitPuffin | plus with a non-profit the money donated would be legally bound to the actual project |
| 22:02:45 | BitPuffin | there isn't anything legally that says that if I donate 10k to you that you can't use it to throw a burger party for your friends :P |
| 22:02:55 | BitPuffin | I think at least |
| 22:03:01 | BitPuffin | I'm not a lawyer |
| 22:03:11 | Araq | hey it's called "Nimrod Software Foundation" for a reason |
| 22:03:26 | BitPuffin | Araq: so there is a Nimrod Software Foundation? |
| 22:03:27 | dom96 | The amount of time and money spent setting up a non-profit probably would outweigh the amount of money donated. |
| 22:04:10 | BitPuffin | if so then great |
| 22:04:41 | Araq | BitPuffin: I'm no lawyer either but currently the donations are used to pay our server |
| 22:04:41 | BitPuffin | there is no problem in creating a separate for profit corporation that finances nimrod software foundation |
| 22:04:50 | BitPuffin | I believe that's how mozilla does it |
| 22:05:23 | * | OrionPK quit (Ping timeout: 250 seconds) |
| 22:05:41 | BitPuffin | Araq: I wasn't suggesting that money being donated are being used for anything other than nimrod |
| 22:06:05 | BitPuffin | I was saying that if there isn't a foundation there is probably no legal guarantee that that's what the money will be used for |
| 22:06:27 | Varriount | Meep |
| 22:06:38 | Araq | I don't think there is any guarantee anyway, BitPuffin |
| 22:06:42 | Varriount | Objective: Math Exam - Complete! |
| 22:06:56 | BitPuffin | Araq: That's why I said legal guarantee |
| 22:07:20 | BitPuffin | Araq: obviously even if there was a foundation taking the money they still COULD take the money and use it for other stuff |
| 22:07:30 | BitPuffin | Araq: just that the difference would probably be that it would be illegal |
| 22:08:07 | Araq | perhaps. I don't know. |
| 22:08:35 | Araq | it's not a charity foundation |
| 22:08:53 | Araq | you can't say "omg, poor kids in Africa never saw any money" |
| 22:08:56 | BitPuffin | Araq: but there is a foundation? |
| 22:09:59 | BitPuffin | Araq: lol :P no but I could say "omg. poor us the money wasn't used to pay Araq to work on nimrod". Well I can't because you work on nimrod but you know what I mean |
| 22:10:39 | Araq | BitPuffin: let me put it this way. Given enough money, I'm forced by law to make it official afaik. I haven't yet. |
| 22:12:14 | BitPuffin | Araq: Okay! Well I just wanted to know a little bit more about the current situation and explain what I am wondering. I did not intend any accusations if it came across that way |
| 22:12:25 | * | Varriount slaps BitPuffin around a bit with a average-sized trout. |
| 22:12:53 | BitPuffin | Varriount: xD |
| 22:13:37 | Varriount | dom96, are the test results stored on the hub server in any format other than html? |
| 22:13:53 | dom96 | no |
| 22:14:06 | * | dymk quit (Ping timeout: 252 seconds) |
| 22:15:46 | Araq | Varriount: I want them in an sqlite database so I can query test results easily |
| 22:16:01 | Araq | this html listing doesn't cut it anymore |
| 22:16:39 | BitPuffin | test result for what? |
| 22:16:46 | BitPuffin | for nimrod compiler? |
| 22:18:05 | Araq | yes |
| 22:19:16 | dom96 | But reading sqlite databases for people who don't have tools necessary to do that will suck. |
| 22:19:34 | BitPuffin | dom96: Guess we need to make a nice web front end then? |
| 22:20:13 | * | Scramblejams joined #nimrod |
| 22:20:52 | Araq | dom96: it would be an addition to what we have now |
| 22:21:01 | * | dymk joined #nimrod |
| 22:21:03 | Varriount | Araq, unfortunately, dom96 is the only one who knows how the builder, hub, etc work together |
| 22:21:06 | * | OrionPK joined #nimrod |
| 22:21:55 | Araq | Varriount: fortunately dom96 is online and ready for questions |
| 22:22:53 | * | ics joined #nimrod |
| 22:23:17 | Varriount | One part of me wants to rebuild the entire thing, and another part of me says that A: It would take too much work, and B: Be impolite to dom96 |
| 22:23:53 | BitPuffin | Varriount: a full rebuild shouldn't be necessary though, just a significant improvement :D |
| 22:23:55 | Scramblejams | Hi all. Teaching myself Nimrod now, it's pretty exciting. My first application for it is to manipulate a C library. I've looked through the docs, the FFI section, the pragmas, etc., but I'd like to see some real code examples. There are _lots_ of C wrappers in Nimrod -- which would you recommend as an approachable and canonical-ish example? |
| 22:24:16 | Varriount | Scramblejams, c2nim and magic. |
| 22:24:21 | BitPuffin | Scramblejams: nim-glfw3 perhaps? |
| 22:24:35 | BitPuffin | Scramblejams: or libao |
| 22:24:37 | BitPuffin | that one is small |
| 22:24:43 | wlhlm | Varriount: why is that impolite? When you write the thing and come up with a much better solution, then everybody wins! |
| 22:24:54 | Scramblejams | Varriount: I'm using c2nim, but I notice it omits some stuff, like header includes, so what's why I'm looking for examples. :-) |
| 22:25:03 | Scramblejams | Okay, thanks BitPuffin and Varriount, I'll give those a look. |
| 22:25:08 | Varriount | Scramblejams, inlcudes should be turned into imports |
| 22:25:19 | Varriount | sometimes you need to turn the imports back into includes. |
| 22:25:40 | Varriount | Or export things imported from another module. |
| 22:25:56 | Scramblejams | Varriount: I did a 5 line test script, ran it through c2nim, and it lacked any imports at all. I ended up using the header pragma to get the required header file into the proc. |
| 22:26:45 | Varriount | Scramblejams, what version of nimrod/c2nim are you using? |
| 22:26:53 | * | Jackneill quit (Remote host closed the connection) |
| 22:27:11 | Scramblejams | What I converted is here: http://pastebin.com/bC6Hq0NB I'm using 0.9.2. |
| 22:27:27 | Scramblejams | I admit I may be doing things entirely wrong, I'm a Nimr00b, as it were. |
| 22:27:31 | Varriount | Ah, that's why. |
| 22:27:34 | BitPuffin | Scramblejams: Not related, but it is probably a good idea to switch to 0.9.3, the git version |
| 22:27:43 | Varriount | c2nim skips includes surrounded by <> |
| 22:27:59 | Scramblejams | BitPuffin: Okay, will do. |
| 22:28:02 | Scramblejams | Varriount: Interesting, why? |
| 22:28:36 | * | Demos joined #nimrod |
| 22:28:37 | Varriount | If I had to guess, possibly because includes surrounded by <> are system headers, and thus, if changed to imports would fail. |
| 22:29:01 | Scramblejams | Would be be inappropriate to always automatically turn them into header pragmas? |
| 22:29:02 | Demos | I do not know the context of this but <> does /not/ denote a system header |
| 22:29:24 | Varriount | Demos, what does it denote then? |
| 22:29:33 | dom96 | Varriount: Why do you want to rebuild nimbuild? What's wrong with it? |
| 22:30:02 | Varriount | dom96, It's rather... hardwired. |
| 22:30:05 | Araq | Demos: yeah but it looked like a very good heuristic to me |
| 22:30:11 | Araq | and c2nim is all about heuristics |
| 22:30:43 | Demos | it just tells the compiler to search the include path (whatever that is for your compiler) first, as opposed to the directory of the source file |
| 22:30:53 | Demos | but in the context of c2nim then sure |
| 22:31:16 | Varriount | dom96, In a perfect vision, there would be a hub program, managing *only* storage of information, data requests, and notifications. |
| 22:31:41 | dom96 | Varriount: And what else do you think the hub does? |
| 22:31:45 | Varriount | dom96: Then there would be several kinds of bots - one for building documentation, one for generating html, etc |
| 22:32:12 | Varriount | dom96, Something roughly like what I just described. |
| 22:32:48 | Varriount | Currently, the building, testing, and html generation are all tied together, at least from what I have seen of builder.nim |
| 22:33:27 | dom96 | Yes, but the hub fits your specifications I think. |
| 22:34:39 | Demos | oh! idea for documentation! what if the documentation generator could look at comments and decide to put "member functions" together. It sucks to look at docs and just see like 14 versions of `[]=` all in a row |
| 22:34:41 | * | simpleirc1 quit (Ping timeout: 272 seconds) |
| 22:34:57 | Demos | perhaps select functions where the first param was named self or this.... |
| 22:35:23 | Araq | Demos: yeah that's a planned feature in fact |
| 22:35:24 | dom96 | They are tied together because they must be. It must happen sequentially: the bootstrap must happen before the testing occurs. |
| 22:35:32 | Demos | OK good |
| 22:35:47 | Varriount | dom96, but how hard-wired is the hubs configuration? |
| 22:35:59 | Demos | as long as it is not truely a language keyword |
| 22:36:15 | Varriount | dom96, not necessarily. |
| 22:36:16 | Araq | feel free to implement it, it's not even hard ... already hate it when I say that? |
| 22:36:24 | BitPuffin | dom96: well that could be insured by some kind of scheduler module |
| 22:36:47 | Varriount | the hub can manage notifying each bot when whatever action needs to be performed. |
| 22:36:54 | Demos | hm, could be interesting. I want to at least finish binding the lexer to C# and getting highlighting in VS though |
| 22:37:34 | Varriount | My main gripe is builder.nim - there's just too many hardcoded actions, variables, etc. |
| 22:38:36 | Demos | is builder.nim just for nimrod build servers? |
| 22:38:36 | dom96 | Varriount: My plan was to make the build process configurable, and that will happen. |
| 22:38:40 | Varriount | dom96, also, how *secure* is the bot using ftp to upload files? |
| 22:39:07 | Varriount | Could I, for example, completely wipe a bunch of data? |
| 22:39:14 | dom96 | no. |
| 22:39:27 | dom96 | Worst you could do is fill up my hard drive. |
| 22:40:07 | BitPuffin | Varriount: NOW YOU WOULD NOT DO THAT WOULD YOU? |
| 22:40:13 | Varriount | Please. |
| 22:40:19 | BitPuffin | I am joking :D |
| 22:40:25 | dom96 | But I agree that this particular thing could be improved. |
| 22:40:34 | dom96 | Remember that I implemented this when I was in full control of the builders. |
| 22:40:43 | Varriount | True. |
| 22:40:54 | Araq | BitPuffin: a dsipatcher that simply linearizes stuff is not a particular smart thing to do |
| 22:41:16 | Araq | linear execution is a language feature already |
| 22:41:52 | * | simpleirc joined #nimrod |
| 22:41:53 | dom96 | Varriount: I'm not sure how splitting up the builder into 3 parts helps. |
| 22:42:00 | Varriount | Redundancy, for one. |
| 22:42:01 | Demos | hm, how about a compiler option --codefry to turn that off :D |
| 22:42:16 | * | simpleirc is now known as Guest21850 |
| 22:42:24 | dom96 | Varriount: If the bootstrap fails then the testing should not happen. |
| 22:42:24 | Araq | Varriount: at the cost of a more complex state machine |
| 22:42:37 | BitPuffin | Araq: Yeah I never said it was a good thing to do, I am just saying that it would be possible to do that to satisfy Varriount |
| 22:42:39 | BitPuffin | and dom96 |
| 22:43:02 | Varriount | dom96, yes, but documentation could still be generated. |
| 22:44:10 | Araq | actually with "doc2" documentation would likely fail too |
| 22:44:14 | Varriount | dom96, currently, what happens if two builders of the same "type" connect to the hub? |
| 22:44:15 | * | io2 quit () |
| 22:44:17 | dom96 | It could be. But there are objectively more important things to improve in NimBuild. |
| 22:44:50 | dom96 | Varriount: Likely the hub will reject it. |
| 22:45:05 | Araq | Varriount: the documentation generation now uses "doc" mostly which does semantic checking etc. so if bootstrapping fails chances are high doc building fails too. |
| 22:45:16 | Araq | *uses "doc2" |
| 22:45:38 | Varriount | Why not use one bot as redundancy? So that if a build fails with one, the other can try? |
| 22:45:38 | dom96 | Only one builder performs building also, so it makes this improvement rather unimportant. |
| 22:46:13 | * | Guest21850 quit (Remote host closed the connection) |
| 22:46:48 | * | dymk quit (Ping timeout: 260 seconds) |
| 22:46:54 | dom96 | I don't think a second bot trying the build again would make things any different. |
| 22:47:01 | dom96 | The build would simply fail again. |
| 22:47:15 | Araq | it's also not at all what we want here |
| 22:47:15 | Varriount | What if one got disconnected. |
| 22:47:40 | Araq | we don't want to hide bugs by restarting processes etc. |
| 22:48:15 | dom96 | Varriount: If a builder gets disconnected in the middle of a build then bad things may happen. That is one of my TODOs. |
| 22:48:32 | Varriount | Hrm. I was just wondering if something like a peer-to-peer build network would be better. |
| 22:49:27 | Varriount | If nothing else, I feel that data generated by the builder, tester etc should at least be available in an easily parsed, machine readable format. |
| 22:49:48 | dom96 | Yes. The tester should generate JSON. |
| 22:50:04 | Araq | huh? it DOES generate JSON |
| 22:50:04 | Varriount | Also, it would be neat if the build bot could initiate builds, or read the results of tests, etc |
| 22:50:14 | dom96 | Araq: More detailed JSON. |
| 22:50:23 | Araq | I agree |
| 22:50:35 | Araq | and that JSON result needs to be stored in some sql database |
| 22:50:40 | dom96 | Why would the build bot need to read the results of tests? |
| 22:51:01 | Varriount | To generate a comparitive page of test results. |
| 22:51:21 | Varriount | Araq wants to be able to view, across all the OS builds, which ones fail and which ones don't |
| 22:51:21 | dom96 | That's the hub's job. |
| 22:52:01 | * | dymk joined #nimrod |
| 22:52:16 | Varriount | Huh, I was under the misimpression that the builder was the one that generated the test result pages. |
| 22:52:31 | dom96 | Araq: What kinds of queries do you plan to perform on this SQL db? |
| 22:52:53 | dom96 | Varriount: The tester does. The builder merely executes the tester. |
| 22:54:36 | Araq | select * from testsuite where platform like 'win%' and state = failed and id in (select id from testsuite where platform like 'linux%' and state = success) |
| 22:55:43 | Araq | and I also need the history of every test |
| 22:56:04 | Araq | so that I know "worked with commit A, failed with commit B" |
| 22:56:27 | Araq | "broken since then" |
| 22:57:34 | Araq | and no, you can't improve the UI easily to provide all these features and it would be much more work anyway |
| 22:59:41 | dom96 | But then it won't be easy for others to view it. |
| 22:59:51 | dom96 | You first query is easy to support. |
| 23:00:14 | dom96 | Well, I guess that query looks at all commits. |
| 23:00:49 | Araq | as I said, you can leave it as it is, so the others get what we currently have |
| 23:01:46 | Araq | I can also "release" my queries of course and we can have some instructions how to attach to the db and execute queries etc. |
| 23:02:10 | * | CarpNet quit (Quit: Leaving) |
| 23:09:10 | dom96 | hrm, alright. |
| 23:09:17 | dom96 | You've convinced me :P |
| 23:10:16 | Araq | yay |
| 23:10:35 | dom96 | But I still feel like putting a web UI in front of it:P |
| 23:11:17 | dom96 | I'm not exactly sure how this will work. |
| 23:11:40 | dom96 | Like, will the tester generate json, and then the hub will add the info from the json file into a sqlite db? |
| 23:12:14 | Araq | I think so, yes |
| 23:12:35 | BitPuffin | Araq: all your queries are belong to us |
| 23:12:40 | BitPuffin | we could have them logged |
| 23:13:26 | dom96 | So then what do you plan to do? Download the db from the website and run queries on it locally? |
| 23:13:57 | BitPuffin | why not have one interface where you can just view them, one with basic search, and one with read only sql queries |
| 23:14:17 | Araq | perhaps. I can also run them on the db directly, dom96 |
| 23:15:23 | kakoo | So I am giving a quick look at the libuv bindings... what is the actual binding? the repo at github appears to have a lot of examples and other related code |
| 23:15:24 | dom96 | BitPuffin: hrm, does sqlite have an option to execute some arbitrary SQL but restrict it to only read stuff? |
| 23:15:37 | dom96 | kakoo: I think uv.nim |
| 23:15:46 | BitPuffin | dom96: I don't really know, but having anyone being able to do any kind of query would be bad |
| 23:15:49 | BitPuffin | dom96: but however |
| 23:16:05 | BitPuffin | dom96: simple workaround would be to do the queries on a copy of the database |
| 23:16:08 | BitPuffin | for each query |
| 23:16:12 | BitPuffin | not the greatest thing for performane |
| 23:16:15 | BitPuffin | but yeah |
| 23:16:40 | BitPuffin | then they could do REMOVE * or whatever they do how much they want without hurting nnnnnbody |
| 23:17:18 | dom96 | yeah, but then they could also overflow the db |
| 23:17:38 | Varriount | dom96, it is possible to open a read-only connection to an sqlite database |
| 23:20:00 | * | wlhlm quit (Ping timeout: 245 seconds) |
| 23:20:04 | BitPuffin | one read only |
| 23:20:48 | Araq | we can also validate the query with our sql parser quite easily |
| 23:20:53 | dom96 | Still would make me feel nervous to allow anything to be executed :P |
| 23:21:09 | dom96 | who knows what weird bugs sqlite has |
| 23:21:21 | Araq | lol |
| 23:21:42 | Araq | sqlite is the most stable piece of software on the planet |
| 23:22:15 | Araq | but we'll do query validation too |
| 23:23:25 | * | wlhlm joined #nimrod |
| 23:24:23 | BitPuffin | yeah dom96, sqlite isn't really known for weird bugs |
| 23:25:46 | BitPuffin | hands down best software in the public domain :D |
| 23:25:52 | BitPuffin | except for linagl |
| 23:25:53 | BitPuffin | xD |
| 23:26:55 | * | dom96 can't tell if you guys are being sarcastic or not |
| 23:27:12 | BitPuffin | dom96: we aren't |
| 23:27:15 | BitPuffin | at least notme |
| 23:27:25 | dom96 | good |
| 23:27:57 | Araq | I'm never sarcastic anyway |
| 23:28:20 | Araq | it's always easy to tell when I am serious |
| 23:29:28 | BitPuffin | Araq: but how can we trust that you aren't sarcastic when you say you are never sarcastic |
| 23:29:58 | Araq | BitPuffin: you can't and I am sarcastic |
| 23:30:07 | BitPuffin | Araq: Thought so |
| 23:30:26 | BitPuffin | I've seen you sarcastic many times :D |
| 23:30:31 | Araq | seriously though, sqlite is superb when it comes to stability |
| 23:30:38 | BitPuffin | yup |
| 23:30:54 | BitPuffin | it's awesome |
| 23:33:51 | Varriount | Araq, this may be a silly question, but does nimrod have forward declarations/prototypes for types/objects? |
| 23:34:26 | * | brson quit (Quit: leaving) |
| 23:34:41 | * | brson joined #nimrod |
| 23:35:50 | Araq | Varriount: it's not a silly question and the answer is "no". and that means you need to resolve cyclic deps within a single 'type' section |
| 23:36:08 | * | p0nce quit (Quit: ZNC - http://znc.in) |
| 23:37:26 | Varriount | Araq, I'm trying to resolve it within a header file :/ |
| 23:38:01 | Araq | that's a very interesting approach given that Nimrod doesn't have header files |
| 23:38:20 | Varriount | Araq, it's translated using c2nim |
| 23:39:32 | Varriount | The header file contains multiple structs. Two in particular contain function pointers, which use each other's type. |
| 23:39:54 | Araq | that's fine as soon as you put them in the same 'type' section |
| 23:40:53 | Araq | you can also "merge" the C typedes so that no functions come in betwen and then c2nim will put the typedefs into the same 'type' section |
| 23:41:48 | Varriount | By "merge" I assume you mean put them right next each other in the file? |
| 23:42:02 | Araq | yes |
| 23:43:12 | Araq | good night |
| 23:47:30 | * | wlhlm quit (Ping timeout: 245 seconds) |
| 23:47:43 | Varriount | Good Night Araq. |
| 23:48:57 | * | MFlamer quit (Remote host closed the connection) |