| 00:03:15 | Skrylar | i haven't heard of neovim |
| 00:04:04 | Skrylar | i hope it works out |
| 00:08:39 | EXetoC | Skrylar: were you going to parse gl.xml? I'm working on it again now |
| 00:09:00 | Skrylar | EXetoC: its a possibility; right now i'm tinkering with sdl |
| 00:09:02 | EXetoC | it is fun: of "**": ... of "*const*": ... |
| 00:09:11 | EXetoC | ok |
| 00:09:22 | Skrylar | i don't know what the nimrod xml parser is |
| 00:10:17 | EXetoC | just a lib, that parses and stuff :> |
| 00:11:00 | * | Skrylar takes a chalk eraser and tries again |
| 00:11:09 | Skrylar | I don't know what the nimrod xml parser is titled and where to find it |
| 00:11:30 | EXetoC | Skrylar: check lib/pure. you probably want xmltree.nim |
| 00:11:55 | EXetoC | but then you have the low level parser module xmlparser.nim, and also xmldom.nim and xmldomparser.nim |
| 00:12:16 | EXetoC | and htmlparser.nim |
| 00:12:24 | Skrylar | why do we have module soup |
| 00:12:37 | Skrylar | import x.y works but the stdlib has old sdl1.1 modules in different parts in the TLD |
| 00:13:39 | Skrylar | hm |
| 00:13:49 | Skrylar | don't we actually have property setter syntax with `Blah=`? |
| 00:13:59 | EXetoC | yes |
| 00:14:21 | Skrylar | i was just looking at SetXProperty thinking "I can just make that 'SetProperty'" and then further realized "can't i just map SetWindowTitle to Title=" |
| 00:14:59 | EXetoC | yeah |
| 00:15:20 | Skrylar | yay nimrod |
| 00:15:59 | EXetoC | woohoo |
| 00:16:02 | Skrylar | i remember doing this in rust and C#, and all the manual boilerplating you had to do just so bind a method so you could say mywindow.Title = "Yes" instead of having uglly unsafe { SDL_SetWindowTitle("yus") } /* clean code zone */ |
| 00:17:17 | EXetoC | you can do that at the declaration in Rust |
| 00:20:04 | EXetoC | dom96: I might do that tomorrow. Just gonna parse the gl spec |
| 00:22:34 | EXetoC | well have fun and don't step on lava |
| 00:22:45 | dom96 | alright |
| 00:24:45 | Araq | good night |
| 00:24:55 | EXetoC | bb |
| 00:25:15 | EXetoC | maybe parse this and generate some code https://www.alien.net.au/irc/irc2numerics.html |
| 00:36:13 | Skrylar | EXetoC: i might suggest parsing the GL xml in to an AST of its own instead of trying to source-to-source it |
| 00:36:52 | Skrylar | would make it easier to put in filters for edge cases, and overall easier to have it output a proper nimly module |
| 00:39:54 | Skrylar | since nimrod definitely has a good means of type-safing quite a bit of the GL API, its just a matter of actually flagging the distincts correctly |
| 00:42:41 | EXetoC | there isn't really much of an AST to speak of, but it's easy to just query the tables that I store the data in |
| 00:43:12 | Skrylar | i guess that works |
| 00:43:33 | Skrylar | i'd have ended up like.. parsing the spec in to an sqlite database or something and tagging all of the special conditions in the DB |
| 00:44:53 | flaviu | Skrylar: Seems like a lot of work for one-off code gen |
| 00:45:21 | flaviu | Probably easier to do the last 1% manually |
| 00:45:45 | Skrylar | flaviu: the point of the gl registry is that its not one-off though |
| 00:45:54 | Skrylar | whenever theres a new extension/revision they update the spec file |
| 00:46:27 | Skrylar | though i tend to do a lot of bindings by hand, in multiple steps and using vim macros/exps for most of the lifting |
| 00:47:14 | EXetoC | I should end up with nice looking diffs if I do some sorting, but we'll see |
| 00:50:04 | Skrylar | as long as its neat and nimrod-y |
| 00:50:35 | Skrylar | if it feels like C barfed in to the middle of nimrod code i'll be sad ;< |
| 00:50:37 | Skrylar | * :< |
| 00:51:36 | EXetoC | there's only so much you can do, but some pointers have length information attached to them in the spec |
| 00:54:34 | flaviu | Is there any way to compile modified generated c files? |
| 00:54:53 | Skrylar | they have the gcc line used to build them as a comment |
| 00:55:02 | Skrylar | they're just C files, use gcc |
| 00:56:12 | * | Varriount joined #nimrod |
| 00:56:25 | * | eigenlicht quit (Ping timeout: 240 seconds) |
| 00:56:41 | flaviu | I didn't notice the header, I just jumped to the line I needed to edit |
| 00:56:43 | flaviu | thanks |
| 00:57:36 | Varriount | Yeesh. Over an hour of time gone for what seems to be an essentially simple update. :/ |
| 01:10:23 | * | Demos joined #nimrod |
| 01:11:57 | Demos | allright, how can I get a datastructure that is write-only at compile time and read-only at runtime |
| 01:12:31 | Varriount | Demos: Macros and templates. |
| 01:12:37 | * | jbe quit (Quit: Leaving) |
| 01:12:52 | Varriount | Oh, and "static" blocks |
| 01:13:08 | Demos | I really do not want to build up the code that adds stuff with a macro... maybe I can have the macro invoke the template.. or something |
| 01:13:09 | flaviu | isn't that what `const` does? |
| 01:13:29 | Varriount | Demos: Do you mean, you want a constant structure? |
| 01:13:31 | Demos | flaviu: I don't think you can write to a const thing in a macro |
| 01:13:56 | flaviu | Why do you need a macro? Just do `cost foo = bar()` |
| 01:14:34 | Demos | because I want to use it to record stuff each time the macro runs |
| 01:15:46 | Varriount | Demos: You do know that ast nodes are refs, right? |
| 01:16:06 | Demos | Varriount: yes. But how does that help me? |
| 01:16:23 | Varriount | Try using a static global var to store a single const node, and then have each macro call modify the node. |
| 01:16:48 | Varriount | I can't really give better help without a clearer understanding of what it is you are trying to achieve. |
| 01:18:37 | Demos | I think I will have a regular global var and have the macro generate code to insert the proper thing |
| 01:28:27 | Demos | macros + closures + templates + pointer (the void* kind) WHAT COULD GO WRONG! |
| 01:28:47 | * | Demos is a terrable, terrable programmer |
| 01:29:53 | * | Skrylar readies the paddle |
| 01:30:03 | * | Varriount gets the tar and feathers |
| 01:30:40 | Demos | that said I think I just "unerased" a type, which is kinda cool |
| 01:31:38 | * | Skrylar always feels like vim's regular expressions are arbitrary as to when \ is used to escape and when it isn't :\ |
| 01:32:28 | Demos | in java I used to just add more \ till it worked... been a long time since then |
| 01:32:47 | Skrylar | well you have to escape () to make groups |
| 01:32:59 | Skrylar | but you escape * if you want the actual character |
| 01:33:13 | Skrylar | so there's sort of an arbitrary pick and choose as to "which special symbol is inlined" |
| 01:33:42 | Skrylar | some of the regexps are more explicit in that if its a symbol you use \ to get a literal of that symbol otherwise its taken |
| 01:46:24 | Demos | ugh I need to decrustify this module... there are like 12 functions that all do the same thing... |
| 01:50:38 | * | Guest78262 quit (Ping timeout: 240 seconds) |
| 01:51:15 | * | Guest78262 joined #nimrod |
| 01:58:57 | * | Demos quit (Ping timeout: 268 seconds) |
| 02:08:23 | * | q66 quit (Ping timeout: 252 seconds) |
| 02:10:05 | * | Demos joined #nimrod |
| 02:21:46 | Demos | dom96: ping |
| 02:40:20 | runvnc | hello |
| 02:40:26 | runvnc | what projects are using redis that I can test with |
| 02:40:59 | runvnc | Im adding pipelining and a different version of transactions |
| 02:50:27 | * | Demos quit (Ping timeout: 255 seconds) |
| 02:51:59 | * | noam quit (Ping timeout: 268 seconds) |
| 02:52:43 | * | noam joined #nimrod |
| 02:54:45 | * | eigenlicht joined #nimrod |
| 03:08:25 | * | Demos joined #nimrod |
| 03:24:37 | * | noam_ joined #nimrod |
| 03:27:10 | flaviu | echo($$locals) is really useful for debugging |
| 03:28:22 | * | noam quit (Ping timeout: 268 seconds) |
| 03:28:30 | Demos | how is that different from echo $locals? |
| 03:28:59 | flaviu | It compiles |
| 03:30:11 | flaviu | if any local field doesn't have a $ method, echo $locals fails because it requires everything to have the $ method |
| 03:30:24 | Demos | oh |
| 03:30:39 | Demos | but doesent $$ still fail? |
| 03:31:13 | flaviu | No, because $$ is from the marshal module, which (I think) uses the fields iterator to get all the fields |
| 03:31:22 | Demos | oh |
| 03:31:45 | Demos | so it is `$$`(locals) and not `$`(`$`(locals)) |
| 03:32:19 | flaviu | Yes, and echo needs its parenthesizes or the parser thinks there's a syntax error |
| 03:38:09 | * | Demos quit (Ping timeout: 255 seconds) |
| 03:54:01 | * | flaviu quit (Remote host closed the connection) |
| 03:58:01 | * | Demos joined #nimrod |
| 04:07:50 | * | Demos quit (Ping timeout: 268 seconds) |
| 04:21:29 | * | Demos joined #nimrod |
| 04:26:08 | * | Demos quit (Ping timeout: 240 seconds) |
| 04:50:08 | * | ehaliewicz quit (Ping timeout: 240 seconds) |
| 05:12:19 | * | filwit quit (Quit: Page closed) |
| 05:19:20 | Skrylar | oh hey, filwit was here |
| 05:45:18 | * | [1]Endy joined #nimrod |
| 06:46:26 | * | shodan45 joined #nimrod |
| 07:17:57 | * | [2]Endy joined #nimrod |
| 07:21:38 | * | [1]Endy quit (Ping timeout: 240 seconds) |
| 08:58:22 | * | nande quit (Remote host closed the connection) |
| 09:34:40 | * | io2 joined #nimrod |
| 09:39:17 | * | Matthias247 joined #nimrod |
| 10:09:52 | * | BitPuffin joined #nimrod |
| 10:17:13 | * | Trimsty quit (Ping timeout: 268 seconds) |
| 10:42:30 | dom96 | hello |
| 10:50:00 | runvnc | hello dom96 |
| 10:51:18 | dom96 | hey runvnc, NimBuild uses redis but testing it requires a lot of set up. |
| 10:52:12 | runvnc | ok. well I am mostly done with the pipelining for redis. I am using your tests with a few little modifications |
| 10:52:16 | runvnc | need to fix a few things tomorrow |
| 10:52:59 | runvnc | that was actually what I wanted before instead of the transactions thing, just wanted to send a bunch of gets in one go |
| 10:54:58 | runvnc | just curious are there modules using the new await async feature |
| 10:55:07 | runvnc | hm well you showed me one yesterday |
| 10:55:15 | runvnc | besides that one |
| 10:55:25 | dom96 | httpclient and asynchttpserver use it |
| 10:56:31 | runvnc | hm are you going to change jester so it uses it |
| 10:57:06 | NimBot | nimrod-code/nimforum master aae5609 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds published tag as duplicate of updated for old rss clients. |
| 10:57:06 | NimBot | nimrod-code/nimforum master 1740471 Dominik Picheta [+0 ±1 -0]: Merge pull request #24 from gradha/pr_published_rss_tag... 2 more lines |
| 10:57:16 | dom96 | yeah, once it's stable. |
| 11:01:37 | dom96 | Currently there seems to be a corruption which causes the async http server to fail under a high load. |
| 11:05:49 | runvnc | k so what kind of corruption |
| 11:06:20 | dom96 | memory |
| 11:07:17 | runvnc | did you guys figure it out already |
| 11:07:30 | dom96 | nope |
| 11:07:43 | dom96 | it looks difficult :( |
| 11:08:42 | runvnc | is there a bug report |
| 11:09:06 | * | Test931812 joined #nimrod |
| 11:09:23 | dom96 | not yet. |
| 11:09:27 | * | Test931812 quit (Remote host closed the connection) |
| 11:10:03 | runvnc | so the process uses a lot of memory when you send a lot of requests to the httpserver or something? |
| 11:10:27 | dom96 | No, the process crashes because the memory gets corrupted somewhere. |
| 11:14:07 | runvnc | ok last question about it.. what sort of error message do you get when it crashes? just curious |
| 11:14:24 | dom96 | Same one you get when you try to access a nil pointer. |
| 11:14:28 | dom96 | A SIGSEGV. |
| 11:14:50 | runvnc | and no stack trace? |
| 11:14:56 | * | Test931812 joined #nimrod |
| 11:14:59 | * | Test931812 quit (Remote host closed the connection) |
| 11:15:04 | dom96 | oh no, there is one. |
| 11:21:39 | dom96 | doesn't help much though |
| 11:24:43 | BitPuffin | ping fowl |
| 11:25:00 | BitPuffin | dom96: helps more than xcode probably |
| 11:25:09 | BitPuffin | everytime something crashes it says it happened it main |
| 11:25:11 | BitPuffin | in* |
| 11:25:13 | BitPuffin | no shit |
| 11:25:57 | runvnc | I have a bit of a moral disagreement with Objective-C so |
| 11:26:20 | EXetoC | BitPuffin: at least you know where to start looking |
| 11:26:34 | BitPuffin | EXetoC: \o/ |
| 11:26:55 | EXetoC | I think we should have a version of echo that aids in debugging |
| 11:27:13 | EXetoC | I have something basic that prints the location, ast and value |
| 11:27:30 | EXetoC | someone else was working on something similar, but I can't remember who that was |
| 11:27:34 | BitPuffin | EXetoC: you mean "debug" |
| 11:27:37 | BitPuffin | in the compiler? |
| 11:27:59 | EXetoC | it could be used anywhere |
| 11:28:22 | BitPuffin | probabyl yea |
| 11:29:13 | EXetoC | example output: "gen.nim:339: []($ x, 0 .. min(len($ x), 1000))\n<extensions><extension..." |
| 11:30:54 | EXetoC | I'll have to do something about that character limit expression. there's probably a better way |
| 11:31:32 | EXetoC | but that's just the expression that I passed to the template so nvm that |
| 11:36:56 | runvnc | dom96 what is the stack trace |
| 11:38:17 | dom96 | https://gist.github.com/dom96/2dc313817c551be579a3 |
| 11:42:16 | runvnc | if you hack on gc.nim is there information about the symbol name in forallchildren |
| 11:48:03 | * | jbe joined #nimrod |
| 11:48:27 | * | q66 joined #nimrod |
| 11:49:18 | * | foodoo joined #nimrod |
| 11:59:05 | * | q66 quit (Ping timeout: 252 seconds) |
| 12:01:09 | * | q66 joined #nimrod |
| 12:09:46 | * | rleisti quit (Remote host closed the connection) |
| 12:17:14 | * | q66 quit (Ping timeout: 252 seconds) |
| 12:19:30 | dom96 | runvnc: There is a shorter stack trace if I compile with the mark and sweep GC. |
| 12:19:50 | runvnc | k |
| 12:19:52 | dom96 | The retFuture in asyncdispatch.recv is 0x07 for some reason |
| 12:20:11 | dom96 | Not sure how to work out where it gets corrupted. |
| 12:20:14 | * | q66 joined #nimrod |
| 12:24:32 | Araq | hi dom96 |
| 12:24:37 | dom96 | hey Araq |
| 12:24:54 | Araq | what you need for this to hunt down are decent watchpoints |
| 12:25:18 | Araq | which ENDB supports ... sometimes it works out |
| 12:25:38 | Araq | sometimes ENDB masks the error or has other problems (*cough* multi threading) |
| 12:25:58 | dom96 | Don't watchpoints impact performance? |
| 12:26:52 | Araq | yeah but according to you it crashes almost immediately |
| 12:27:15 | Araq | do you know which envrionment gets corrupted? |
| 12:27:27 | Araq | or rather where this environment is created? |
| 12:28:02 | dom96 | It's the env of the closure in asyncdispatch:357 |
| 12:28:18 | dom96 | in the mark and sweep gc at least |
| 12:29:20 | Araq | ok, compile with --debugger:on and add {.watchpoint: retFuture.} to line 344 |
| 12:29:33 | Araq | *after line 344 |
| 12:31:36 | dom96 | you mean 347? |
| 12:31:41 | dom96 | 344 is a comment |
| 12:32:02 | Araq | hmmm |
| 12:32:08 | Araq | let me update |
| 12:34:43 | Araq | yeah I mean line 348 |
| 12:35:09 | dom96 | endb| rawsockets.nim(79) rawsockets *** |
| 12:35:41 | dom96 | why would it stop there? |
| 12:37:01 | dom96 | It's printing A LOT. |
| 12:37:25 | dom96 | asyncdispatch.nim(74) callback= etc constantly |
| 12:38:41 | * | q66 quit (Ping timeout: 252 seconds) |
| 12:39:58 | Araq | it's printing everywhere where the env gets changed |
| 12:40:06 | Araq | usually 1 stack trace comes up that is weird |
| 12:40:20 | Araq | that is where the memory gets corrupted |
| 12:40:37 | dom96 | It prints one stack trace for each time it gets changed right? |
| 12:40:48 | dom96 | if so then it's not weird. |
| 12:40:54 | dom96 | recv is called A LOT |
| 12:51:29 | * | q66 joined #nimrod |
| 12:59:06 | * | darkf quit (Quit: Leaving) |
| 13:14:10 | dom96 | ping zahary |
| 13:14:41 | * | simargl joined #nimrod |
| 13:14:48 | dom96 | hello simargl |
| 13:15:05 | * | foodoo quit (Quit: Lost terminal) |
| 13:15:11 | simargl | hey |
| 13:15:12 | zahary | hi dom96 |
| 13:15:46 | dom96 | zahary: It seems you broke my closure macro with your recent changes. Have some time to take a look? |
| 13:16:56 | EXetoC | did someone report the fact that fields can be skipped when constructing objects? |
| 13:18:26 | zahary | dom96: can I see the closure macro? do you know which change broke it? |
| 13:19:01 | dom96 | zahary: https://gist.github.com/dom96/9155536 |
| 13:20:56 | dom96 | I think this commit breaks it: https://github.com/Araq/Nimrod/commit/40d94436fdbe7ea5c5b508c6916064f803b79155 |
| 13:21:07 | dom96 | because I get the error you introduced in that commit |
| 13:25:44 | simargl | Been playing with nimrod/gtk2, ported two samples from vala page to nimrod and later noticed some stuff are missing in gtk2.nim like AboutDialog, ToolButton, get_context_area in GtkDialog and more... But intead of fixing missing parts in gtk2 I thought to ask here - is there support for gtk3? or at least plan... |
| 13:28:04 | dom96 | Yeah, thanks for those PRs. The gtk2 wrapper was generated a long time ago and so it's missing some procedures. Foodoo was here yesterday talking about wrapping gtk3 so support may happen, but no official plans yet. |
| 13:31:38 | simargl | okay, thanks I will check it from time to time. |
| 13:31:47 | * | simargl left #nimrod (#nimrod) |
| 13:56:17 | NimBot | Araq/Nimrod devel 42188b8 Zahary Karadjov [+0 ±5 -0]: propagate semExpr flags in macro/template expansion |
| 13:56:26 | zahary | dom96: that should fix the problem |
| 14:08:10 | BitPuffin | I wonder if the show stopping bugs for linagl are fixed yet |
| 14:08:16 | BitPuffin | so that I can work on a god damn nimrod game :D |
| 14:09:14 | Araq | zahary: we want to release today. so better hurry and fix some bugs |
| 14:10:08 | zahary | I thought we were going to fix the bugs marked as showstoppers on github |
| 14:11:07 | zahary | btw, have we fixed the brew installation on mac os? |
| 14:12:33 | Araq | no idea |
| 14:12:43 | Araq | let me see what showstoppers are left |
| 14:13:01 | * | jbe quit (Quit: Leaving) |
| 14:16:56 | EXetoC | dom96: does it work does it work does it work? :p |
| 14:29:39 | Araq | babel install nake |
| 14:29:59 | Araq | Error: unhandled exception: Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch. |
| 14:37:54 | dom96 | zahary: Thanks, i'll test it now. |
| 14:38:31 | dom96 | Araq: I'm thinking of writing a web crawler as an example of await and the new async httpclient. |
| 14:38:48 | Araq | dom96: I found a babel bug |
| 14:39:02 | dom96 | Araq: Tell me more. |
| 14:39:31 | Araq | "babel install nake" fails for me with OSError when babel tries to move stuff from temp to its destination |
| 14:39:58 | Araq | it's not a hard bug, I think, since Windows' explorer frequently shows the same bug on vista ... |
| 14:40:20 | EXetoC | dom96: you might hit that XML bug that I reported then, for values that contain ampersands |
| 14:40:45 | Araq | EXetoC: just fix it properly |
| 14:41:56 | dom96 | what does that error say? |
| 14:46:00 | EXetoC | Araq: I've spent too much time on it without getting anywhere |
| 14:47:33 | Araq | dom96: "the syntax of the filename/dirname oder disk is wrong" |
| 14:47:39 | Araq | *or disk |
| 14:48:00 | dom96 | weird. |
| 14:48:14 | Araq | maybe some slash / backslash thing? |
| 14:48:20 | dom96 | Compile in debug mode and execute it again |
| 14:48:26 | dom96 | to get a traceback |
| 14:48:57 | Araq | later perhaps |
| 14:49:05 | Araq | I'm fixing bugs |
| 14:49:16 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 14:51:12 | Araq | as I said it says the '->' move arrow and lists files and then dies |
| 14:51:20 | dom96 | zahary: Still fails. |
| 14:52:21 | dom96 | Araq: Can you give me the full output? |
| 14:52:52 | Araq | well I performed the file move on my own to get nake |
| 14:52:58 | Araq | so no |
| 14:53:53 | dom96 | I can't reproduce it, so you will have to help me now or later. |
| 14:56:13 | dom96 | Araq: Do you think a web crawler is a good example for the news post? |
| 14:57:02 | Araq | what do you want to say? "nimrod can now be used for web crawlers because we have async httpclient"? |
| 14:57:25 | dom96 | No I want to show an example of async await |
| 14:57:45 | Araq | ok. well a web crawler is a good example |
| 14:57:47 | dom96 | "The following is an example of a web crawler built using the new await API" |
| 14:57:54 | Araq | sure, nice |
| 14:58:00 | dom96 | I fear I may run into more bugs though... lol |
| 14:58:26 | Araq | btw web crawlers can be cpu bound too |
| 14:58:42 | zahary | dom96: the error is on line 39, which is not supported yet on purpose - I agree it could be fixed tho |
| 14:59:20 | zahary | if you comment out that line, the other places, where the closure is used as a param are ok |
| 14:59:49 | dom96 | But it used to work :\ |
| 15:00:27 | zahary | well, it triggers a "safety net" error - it's not a missing path in the compiler |
| 15:00:59 | zahary | the error is supposed to catch bad usages such as var p = (x) => x*x |
| 15:01:06 | zahary | p has not proper type here |
| 15:03:37 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 15:05:55 | BitPuffin | Araq: you are mentioned in this video lol http://youtu.be/PXxO75jAGX0 |
| 15:06:16 | dom96 | zahary: alright. |
| 15:07:44 | BitPuffin | brb |
| 15:08:46 | * | io2 joined #nimrod |
| 15:12:16 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 15:27:11 | Araq | zahary: have you seen that exponential blow-up? |
| 15:27:33 | Araq | I tried to track it but my gdb refuses to show stack traces for the test case ... |
| 15:28:05 | Araq | it's worrying me. maybe it's even a fundamental flaw in nimrod's macro design |
| 15:28:18 | zahary | I haven't seen it - where should I look? |
| 15:29:35 | Araq | https://gist.github.com/jbe/9996803 |
| 15:30:24 | Araq | compling niminst also takes quite a long time now. I think it has nothing to do with templates but with nested calls thanks to our complex overloading resolution |
| 15:30:35 | Araq | might be introduced with my laziness patches long ago |
| 15:33:05 | Araq | btw I think OR should always take a nkSymChoice and do the matching in parallel |
| 15:33:28 | zahary | interesting |
| 15:33:38 | Araq | where "in parallel" means all candidates' first param is checked, then their 2nd param etc. |
| 15:34:04 | Araq | and we can already decide for the first param which matches better |
| 15:34:28 | zahary | but we still have to look at the rest of the params to detect ambiguity I think |
| 15:35:02 | Araq | sure |
| 15:35:29 | NimBot | Araq/Nimrod devel 883a958 Araq [+0 ±1 -0]: fixes #866 |
| 15:35:29 | NimBot | Araq/Nimrod devel 20cc46d Araq [+1 ±2 -0]: fixes #913 |
| 15:35:29 | NimBot | Araq/Nimrod devel 9ff7ab1 Araq [+0 ±5 -0]: Merge branch 'devel' of https://github.com/Araq/Nimrod into devel |
| 15:35:41 | Araq | take this you showstoppers |
| 15:36:13 | dom96 | You broke 300 tests. |
| 15:36:19 | dom96 | Just kidding :P |
| 15:36:45 | EXetoC | are there restrictions for nested tuples already? |
| 15:37:31 | EXetoC | nvm |
| 16:00:48 | renesac | what should be the nextPowerOfTwo() result for negative numbers? |
| 16:11:37 | Araq | renesac: just assert |
| 16:11:47 | Araq | these things should be *fast* |
| 16:13:44 | renesac | assert that the input is not negative? |
| 16:14:11 | renesac | I'm changing the last line to: result += 1 + ord(x>=0) |
| 16:15:04 | renesac | this gives 1 as result, even if the number is negative, and is branchless (I hope this 'ord' is transparent on the generated C code) |
| 16:15:47 | renesac | *(x<=0) |
| 16:16:02 | Araq | ok that's fine too of course |
| 16:16:33 | renesac | I'm having trouble with the branchless isPowerOfTwo() though |
| 16:16:51 | renesac | I will try solving it |
| 16:17:32 | renesac | but a 'if' would be much easier |
| 16:18:03 | renesac | or simply accept only "Positive" numbers, but that might be annoying |
| 16:18:34 | EXetoC | why? it's basically a contract |
| 16:18:58 | EXetoC | same as with the assert, except that it's not part of the interface |
| 16:19:49 | EXetoC | and it'd be nice to see how well these work. I don't think ranges are very common yet |
| 16:20:59 | EXetoC | speaking of which, did anyone report the (range[T], range[T]) (T, T) incompatibility? |
| 16:21:14 | renesac | well, you would need to 'convert' the number from int to Positive if the compiler can't prove that it will aways be positive |
| 16:21:21 | Araq | no but I know 'range' is quite broken, EXetoC |
| 16:21:49 | Araq | renesac: that is actually the question ... |
| 16:21:57 | EXetoC | in what way? |
| 16:22:22 | EXetoC | renesac: I thought it was implicit |
| 16:22:24 | Araq | (1, 2) doesn't match tuple[a,b: range[1..2]] iirc |
| 16:23:05 | EXetoC | I thought you meant something else, as I just said something similar |
| 16:30:28 | * | nequitans joined #nimrod |
| 16:31:31 | EXetoC | any other cases? |
| 16:32:09 | Araq | lots of but they are all equivalent |
| 16:36:59 | renesac | can I make nextPowerOfTwo() and isPowerofTwo generic, to accept any integer type? Or should I just bugfix for now? |
| 16:37:41 | renesac | right now it don't works on 16bit plataforms, for example |
| 16:37:49 | renesac | the nextPowerOfTwo() |
| 16:38:14 | nequitans | Hi all, I'm porting some basic C code to Nimrod. In C, I have a struct with, among other things, a char[4] variable in it. I write this struct out in binary to disk. In nimrod I use array[0..<4, char], but the bytes being written out are different. I'm probably doing something really stupid here I think |
| 16:38:16 | * | nande joined #nimrod |
| 16:40:40 | EXetoC | shortcut: array[4, char] |
| 16:41:17 | Skrylar | nequitans: a nimrod array stores its size |
| 16:41:31 | Skrylar | i'm guessing the size of the fixed-size array is getting saved too |
| 16:41:54 | nequitans | I see |
| 16:41:58 | OrionPK | morning |
| 16:42:01 | EXetoC | huh |
| 16:42:09 | nequitans | when I use array[4,char], i get "Error: type expected" |
| 16:42:26 | renesac | are you using the latest devel? |
| 16:42:28 | renesac | or at least master? |
| 16:42:41 | nequitans | i should pull the latest (it's been a while) |
| 16:43:03 | renesac | well, any devel in the last months should allow this syntax, I think |
| 16:48:28 | nequitans | kk -- so I'm using a dev version now and that syntax works, but i suppose I still have this issue of the fact that the nimrod array stores its size. Is there something else i can do to write out a char[4] but in a 'raw' c-like way? |
| 16:48:57 | Araq | array[4, char] is C's char[4] |
| 16:49:03 | Araq | no length stored |
| 16:49:07 | nequitans | ah, i see |
| 16:49:42 | Araq | array[0.. <4, char] is the same |
| 16:50:01 | nequitans | hmm...so i must be doing something else wrong then |
| 16:50:17 | Araq | I guess you have wild casts in C that expose endianness but you don't do that in nimrod |
| 16:50:29 | Araq | and so the order changes |
| 16:52:16 | renesac | ## returns the nearest power of two, so that |
| 16:52:17 | renesac | ## result**2 >= x > (result-1)**2. <--- the square of result -1 is smaller than x? |
| 16:52:18 | EXetoC | is nil supposed to be a valid value for TXmlNode.fAttr (PXmlAttributes)? |
| 16:52:32 | EXetoC | an empty table might make more sense |
| 16:53:07 | Araq | I bet nil is valid here |
| 16:53:12 | Araq | everything else would take up too much ram |
| 16:54:06 | EXetoC | ok. that should be more obvious once "not nil" ends up being used |
| 16:55:59 | renesac | Araq, some documentation comments start with an uppercase letter, an others don't |
| 16:56:18 | EXetoC | :p |
| 16:56:20 | renesac | what should be the standard? |
| 16:57:42 | Araq | dunno |
| 16:58:01 | Araq | what is used more often in the stdlib |
| 16:58:50 | renesac | it seems lower case letters are used more |
| 16:59:03 | dom96 | despite that uppercase should be used IMO |
| 16:59:13 | EXetoC | Uppercase is correct for English last time I checked |
| 16:59:28 | renesac | yeah |
| 16:59:35 | Araq | "uses foo to build bar baz" is not a full sentence though |
| 16:59:52 | Araq | proc p uses foo to build baz |
| 16:59:58 | Araq | ergo lower case |
| 17:01:28 | Araq | and i consider good style to not repeat the symbol's name here |
| 17:01:34 | dom96 | No. The proc definition is not a part of the sentence. |
| 17:01:45 | Araq | it is imho |
| 17:02:11 | dom96 | In most cases if you look at it that way the docs don't make sense. |
| 17:02:25 | dom96 | 'int default integer type' |
| 17:02:33 | dom96 | 'int8 signed 8bit integer type' |
| 17:03:31 | EXetoC | I prefer "do x" to "does x" |
| 17:03:31 | renesac | should I put {.inline.} on those power of two procs? |
| 17:03:52 | dom96 | It looks like the docs for procs work better for this. |
| 17:04:55 | nequitans | ah, i was doing somethign stupid: clobbering my file later -- should have used sizeof(cint) rather than sizeof(int)! |
| 17:05:07 | nequitans | thanks for the help |
| 17:05:31 | dom96 | But let's not worry about this for now. |
| 17:05:47 | renesac | yeah, latter a script can be made to homogenize that |
| 17:10:56 | * | foodoo joined #nimrod |
| 17:13:12 | Araq | nequitans: c2nim wouldn't have made this mistake :P |
| 17:13:22 | Araq | if you can get c2nim to eat your code, that is |
| 17:13:37 | nequitans | lol -- I used c2nim, but this was an 'added' piece of code |
| 17:13:56 | Araq | yay people use c2nim |
| 17:14:21 | nequitans | yea, worked pretty well! |
| 17:14:43 | nequitans | just had to convert ptr FILE to TFile and a couple of minor tweaks |
| 17:16:07 | Araq | I should add pattern matching rules to c2nim |
| 17:17:13 | Araq | like swig |
| 17:17:43 | Araq | speaking of which, any volunteers for swig support? though it's likely a dead end with clang as a library |
| 17:17:58 | Araq | any volunteers for clang2nim? |
| 17:19:09 | nequitans | that would be pretty sweet. c2nim could also serve a nice 'example-driven' tutorial on how to canonically do things you would in C in nimrod |
| 17:19:36 | Araq | yeah I thought about this too but unfortunately c2nim is not good enough for that |
| 17:20:06 | Araq | people expect a header translator to simply work these days. most likely because they never used one ... |
| 17:20:38 | nequitans | ic |
| 17:22:04 | fowl | how come there is no json.delete(int) or []= for int indexes |
| 17:24:10 | Araq | dom96: I am fixing docgen for asyncdispatch but now I get |
| 17:24:24 | Araq | asyncdispatch.nim(210, 22) Error: ambiguous identifier: 'TSocketHandle' -- use a qualifier |
| 17:24:45 | Araq | any idea why that is? |
| 17:25:07 | Araq | fowl: I dunno, add it |
| 17:25:10 | renesac | https://github.com/Araq/Nimrod/pull/1071 <-- pull request |
| 17:25:19 | renesac | oh, should I add tests? |
| 17:25:29 | dom96 | Araq: rawsockets exports TSocketHandle. |
| 17:25:55 | dom96 | So i'm guessing it exports the posix one, and then there is an import winlean too which exports the windows version |
| 17:26:56 | Araq | so it doesn't use rawsockets on windows? |
| 17:27:13 | Araq | but for the docgen, lol wtf |
| 17:27:21 | Araq | must be in some other module |
| 17:27:33 | Araq | renesac: get rid of the ; in line 86 |
| 17:27:58 | Araq | renesac: imho no tests necessary. how likely is it to fail again? |
| 17:30:11 | Araq | rawsockets always exports TSocketHandle ... |
| 17:30:35 | dom96 | yes. |
| 17:30:48 | dom96 | But depending on the current OS it either exports it from posix or winlean |
| 17:30:51 | Araq | ah got it |
| 17:31:19 | Araq | we need to do 'when defined(windows)' -> 'when defined(windows) or defined(nimdoc)' everywhere ... gah |
| 17:32:24 | dom96 | Yeah... |
| 17:32:30 | dom96 | There must be a better way... |
| 17:35:29 | Araq | no, there isn't |
| 17:35:35 | Araq | and I am done already |
| 17:35:48 | EXetoC | is using 'mget' to make modifications only possible for reference types? |
| 17:36:15 | EXetoC | t.mget(x).y = ... |
| 17:36:38 | NimBot | Araq/Nimrod devel b9a17dc Araq [+0 ±3 -0]: doc generation for asyncdispatch works |
| 17:37:19 | Araq | dom96: we only have time for brute force :P we'll think of a better solution later but I don't think there is any really |
| 17:37:51 | dom96 | My web crawler works |
| 17:37:56 | dom96 | But tries to request .zip files :P |
| 17:38:00 | dom96 | from nimbuild |
| 17:38:03 | Araq | EXetoC: t has to modifyable for this to work |
| 17:38:51 | dom96 | It's only 27 lines :D |
| 17:38:53 | EXetoC | Araq: it is, but the original table value isn't being modified |
| 17:39:34 | Araq | EXetoC: that's a bug then. :-/ |
| 17:39:58 | EXetoC | Araq: for value keys too? |
| 17:40:20 | EXetoC | value objects |
| 17:40:35 | Araq | not sure what you mean |
| 17:41:06 | EXetoC | Araq: for keys that are value objects rather than references |
| 17:41:16 | Araq | t.mget(x).y = z should modify t[x].y to contain z |
| 17:41:29 | Araq | value objects have nothing to say here |
| 17:41:54 | EXetoC | I'll make a test case when I'm done with this |
| 17:42:29 | Araq | ping Varriount |
| 17:48:55 | Skrylar | i was just wondering about something |
| 17:49:10 | Skrylar | why are people suddenly obsessed with voxels + geometry filters? |
| 17:50:35 | Skrylar | i was just thinking about sauerbraten's octree algorithm again, and how if you look at it sideways it actually does a better job at modifiable maps than voxel generators do |
| 17:53:38 | Skrylar | probably easier to pathfind too, since you could render the top sides of each cuboid region to a navmesh and just exclude extreme slopes |
| 17:53:40 | Skrylar | hmmm |
| 17:54:22 | NimBot | Araq/Nimrod devel 5643b84 Araq [+1 ±0 -0]: fixes #297 |
| 17:54:38 | Araq | I love it when things have been already fixed in the meantime |
| 17:56:08 | Araq | Skrylar: I'm not qualified to comment on your thoughts |
| 18:00:03 | dom96 | So this just happened: Crawling http://www.nih.at/libzip/index.html/../index.html/.. and it just kept adding '../index.html/' on and on. |
| 18:00:35 | dom96 | Gotta love the web. |
| 18:01:05 | Araq | you need a max depth |
| 18:01:27 | dom96 | meh, too complex. |
| 18:01:33 | dom96 | I also should request HEAD |
| 18:01:36 | Araq | oh |
| 18:01:37 | dom96 | and check content-type etc |
| 18:01:41 | Araq | er |
| 18:01:52 | Araq | I think you must not add this as an example sorry |
| 18:02:02 | dom96 | why? :( |
| 18:02:12 | Araq | it encourages denail of service attacks |
| 18:02:29 | Araq | especially with a toy like this that has no protection at all |
| 18:02:40 | dom96 | So you fear someone will call it a DDoS tool? |
| 18:04:01 | Araq | also people are likely to try it out against nimrod-lang.org crashing our servers |
| 18:04:21 | Araq | the redditors will scream and shout |
| 18:04:22 | Araq | let's not do this |
| 18:05:03 | dom96 | Ok. |
| 18:05:10 | dom96 | I just got it to crash in gc.nim anyway... |
| 18:05:40 | Araq | same bug as with async http server? |
| 18:05:48 | dom96 | dunno |
| 18:05:52 | dom96 | the stack trace is different |
| 18:06:03 | dom96 | I may have a hunch as to the cause of this corruption now though |
| 18:06:04 | Araq | that doesn't mean much |
| 18:06:20 | dom96 | Because I removed a single 'await' |
| 18:07:15 | dom96 | Executing an async proc in its place. |
| 18:07:59 | dom96 | Maybe the GC frees the closure inside that async proc |
| 18:08:19 | dom96 | by accident |
| 18:08:55 | dom96 | It's hard to explain but let's not worry about it for now I guess |
| 18:09:02 | dom96 | What example should I create then? |
| 18:10:44 | Araq | dunno, please fix the docgen instead |
| 18:11:35 | renesac | https://github.com/Araq/Nimrod/pull/1071 <-- updated the pull request |
| 18:12:04 | dom96 | Araq: If you can't fix it then how am I supposed to? |
| 18:12:24 | Araq | dom96: it's likely a new issue |
| 18:12:38 | Araq | some other module now fails, I hope |
| 18:12:48 | NimBot | Araq/Nimrod devel b8d6994 ReneSac [+0 ±1 -0]: Zero is not a power of two. Fix #1047... 2 more lines |
| 18:12:48 | NimBot | Araq/Nimrod devel fd19d59 ReneSac [+0 ±1 -0]: Fix typo in previous commit. |
| 18:12:48 | NimBot | Araq/Nimrod devel 63503f0 ReneSac [+0 ±1 -0]: Removed trailing ';'. |
| 18:12:48 | NimBot | Araq/Nimrod devel 6c98814 Andreas Rumpf [+0 ±2 -0]: Merge pull request #1071 from ReneSac/devel... 2 more lines |
| 18:17:31 | renesac | now bug #1047 crashes with Error: unhandled exception: isPowerOfTwo(initialSize) [EAssertionFailed] |
| 18:17:43 | renesac | that is correct, but still a runtime error |
| 18:18:38 | * | Gr33n3gg joined #nimrod |
| 18:19:27 | dom96 | I still feel obligated to share this crappy but cool web crawler with you guys so here it is: https://gist.github.com/dom96/10009691 |
| 18:19:27 | Araq | yeah |
| 18:19:34 | * | Gr33n3gg left #nimrod (#nimrod) |
| 18:20:14 | EXetoC | kept alive as in keep-alive? |
| 18:20:22 | Araq | dom96: learn to use containsOrIncl |
| 18:21:20 | Araq | if url in visited # lol, sorry but it's still funny |
| 18:21:37 | Araq | many pages are dynamically generated |
| 18:21:59 | Araq | the only thing that works is to limit the crawling depth |
| 18:22:17 | dom96 | EXetoC: yeah |
| 18:23:24 | EXetoC | nice. was it implemented recently? |
| 18:23:35 | dom96 | yeah |
| 18:25:50 | NimBot | Araq/Nimrod devel 4456702 Dominik Picheta [+0 ±1 -0]: Fixes docgen. |
| 18:25:50 | NimBot | Araq/Nimrod devel ca9d02d Dominik Picheta [+0 ±1 -0]: Get rid of incorrect assert in asyncdispatch. |
| 18:25:50 | NimBot | Araq/Nimrod devel 2ace637 Dominik Picheta [+0 ±3 -0]: Documentation for async httpclient. Notes for url modules. |
| 18:25:50 | NimBot | Araq/Nimrod devel 8b38ddd Dominik Picheta [+0 ±1 -0]: Select implementation in selectors module compiles again. |
| 18:26:15 | dom96 | Araq: now then, what example should I give? |
| 18:26:20 | Araq | dom96: your 'crawl' is recursive |
| 18:26:34 | Araq | which might be the reason for the crashes |
| 18:27:01 | dom96 | yes, asynchttpserver is recursive too |
| 18:27:23 | Araq | I don't know if we can support recursive async stuff |
| 18:27:46 | dom96 | Why not? |
| 18:28:07 | Araq | because we don't capture the full stack, remember? |
| 18:29:08 | dom96 | Recursion is very useful though. |
| 18:29:10 | Araq | the compiler disallows recursive iterators but I guess you found a way around my checks |
| 18:29:23 | zahary | if I'm not mistaken, it doesn't need the stack |
| 18:29:40 | zahary | calling the async function recursively creates a new instance of the resumable iterator |
| 18:29:48 | dom96 | yeah |
| 18:30:03 | Araq | ok, makes sense |
| 18:30:06 | zahary | when it gets yielded, it lives in the "callbacks" fields in the outstanding futures |
| 18:30:08 | dom96 | It doesn't call the same iterator again |
| 18:30:24 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 18:31:24 | dom96 | I can get rid of the recursion in async http server pretty easily though |
| 18:31:26 | dom96 | So i'll try it |
| 18:31:50 | * | ics joined #nimrod |
| 18:31:53 | * | ics quit (Client Quit) |
| 18:32:12 | * | ics joined #nimrod |
| 18:32:13 | zahary | dom96: this example is already pretty impressive, but you should try to make it parallel too |
| 18:32:34 | dom96 | zahary: You mean introduce threads? |
| 18:33:11 | zahary | no, you need to composed futures; the simples example is the "await download1 & download2" from my original gist |
| 18:33:40 | dom96 | That's what the call to 'crawl' without an 'await' prefix accomplishes. |
| 18:33:45 | zahary | but a more complete version is to await a sequence of futures (this means that the code is suspended until all of the futures complete) |
| 18:34:36 | zahary | hmm, you are right - you need the serial processing in order to not fool the servers otherwise (when it's the same url)? |
| 18:34:54 | dom96 | yes |
| 18:34:54 | zahary | * same host * |
| 18:34:59 | dom96 | Exactly. |
| 18:35:22 | zahary | ok, I see, but still the combinators I describe are really useful |
| 18:35:52 | dom96 | Indeed. They should be pretty trivial to implement. |
| 18:35:59 | EXetoC | will keep-alive pooling be easy to implement? |
| 18:36:34 | dom96 | I would like what I have now to work before worrying about adding sugar like that. |
| 18:36:40 | EXetoC | sure |
| 18:37:50 | dom96 | You mean storing a list of http clients based on the host they are connected to and routing the requests to the correct ones? |
| 18:38:23 | * | zezba9000 left #nimrod (#nimrod) |
| 18:41:02 | * | OrionPK quit (Ping timeout: 268 seconds) |
| 18:41:37 | EXetoC | just a list of hosts encountered, so that keep-alive doesn't only if the host is the same as the previous one |
| 18:42:17 | EXetoC | *doesn't work |
| 18:42:31 | EXetoC | or maybe it's not that simple, but it seems like it |
| 18:44:01 | * | OrionPK joined #nimrod |
| 18:44:10 | dom96 | i'm not sure what you mean. If you do client.request("nimrod-lang.org") and then client.request("nimrod-lang.org/blah.html") then a new connection will not be created. |
| 18:44:13 | * | vendethiel quit (Remote host closed the connection) |
| 18:44:33 | dom96 | But if the second request is to say google.com then the old connection to nimrod-lang.org will be terminated. |
| 18:44:36 | EXetoC | and if you visit another host inbetween? |
| 18:44:52 | dom96 | still terminated |
| 18:45:31 | EXetoC | yeah you just said that. the Requests library manages this automatically |
| 18:46:02 | dom96 | It seems that getting rid of the recursion doesn't change much |
| 18:47:33 | dom96 | EXetoC: We partially manage it then :P |
| 18:47:55 | * | vendethiel joined #nimrod |
| 18:48:05 | EXetoC | so that'd just be session.get rather than get in Requests |
| 18:48:15 | EXetoC | I guess |
| 18:48:38 | dom96 | It should be easy to write a session lib on top of httpclient |
| 18:48:55 | Araq | dom96: what came out of the ENDB session? |
| 18:49:08 | dom96 | Too much output came out |
| 18:49:33 | Araq | I see |
| 18:49:52 | Araq | I guess I need to implement stack trace sets |
| 18:50:22 | dom96 | Araq: So what example should I make then? |
| 18:51:02 | Araq | just use some nosql database that happens to run over http |
| 18:51:37 | Araq | couchdb does that iirc |
| 18:51:41 | dom96 | meh |
| 18:51:53 | dom96 | I don't feel like researching things for this |
| 18:51:57 | Araq | hey, it shows how useful this really is |
| 18:53:30 | dom96 | Maybe I should create some simple command server? |
| 18:53:46 | dom96 | with some silly commands like "add 5 5" |
| 18:54:23 | dom96 | actually |
| 18:54:30 | dom96 | I'll create a simple chat server |
| 18:56:19 | Araq | ok |
| 18:59:11 | EXetoC | wee fixes |
| 19:00:53 | Araq | EXetoC: how come extracting a small example program from #919 is so hard? |
| 19:01:02 | Araq | I thought I got it |
| 19:01:25 | Araq | you iterate over an empty set, empty known at compiletime |
| 19:01:59 | EXetoC | no idea. I don't think I could reproduce it |
| 19:04:12 | Araq | er ... |
| 19:04:33 | Araq | you do set[TCursorOpts] where TCursorOpts is alreay bitset'ish |
| 19:04:41 | Araq | in other words the enum has holes |
| 19:04:53 | Araq | the compiler should catch that |
| 19:07:17 | dom96 | Araq: https://gist.github.com/dom96/10010212 |
| 19:07:30 | EXetoC | I don't know why the enumerators matter, and not just the enumerator, whose base type is an integer |
| 19:07:41 | Araq | dom96: excellent |
| 19:07:41 | dom96 | Just realised that exceptions are a big problem ... |
| 19:08:11 | EXetoC | but there's a range limit, right? so maybe I should use TSet |
| 19:08:22 | dom96 | But we'll worry about that some other time. |
| 19:08:27 | Araq | no you should fix your types, EXetoC |
| 19:08:38 | Araq | will tell you how later |
| 19:10:58 | dom96 | Araq: I fear many people will try this and then i'll get all the blame when it fails :( |
| 19:11:11 | Araq | dom96: exactly |
| 19:11:44 | dom96 | What you mean "exactly"? |
| 19:11:57 | Araq | you will get all the blame |
| 19:12:19 | dom96 | But I don't want all the blame. |
| 19:12:41 | Araq | now you know why we have a showoff directory in tests/ |
| 19:13:05 | dom96 | Should I not mention it then? |
| 19:13:38 | Araq | nah, ensure it works, ensure I tested it both on linux and windows and you'll be fine and I take the blame |
| 19:18:43 | * | dom96 makes 'experimental' bold in the release notes :P |
| 19:27:38 | fowl | monthly point releases plz |
| 19:28:09 | Araq | you mean 0.9.4.x fowl ? |
| 19:28:44 | fowl | yea |
| 19:29:41 | fowl | im having a problem with () matching locals instead of functions |
| 19:30:58 | fowl | point2d(x,y).p is matching the local p instead of a function |
| 19:31:36 | Araq | bug report |
| 19:33:09 | dom96 | Adding another dot is a bad idea I think. |
| 19:33:43 | dom96 | Appending the date may be better. |
| 19:36:00 | Araq | no that's worse |
| 19:36:10 | Araq | we might as well give up and only use the date then |
| 19:36:35 | dom96 | yeah |
| 19:37:06 | dom96 | Is the ```nimrod code block syntax not supported for whatever generates the .html for the website? |
| 19:39:02 | fowl | https://github.com/Araq/Nimrod/issues/1072 |
| 19:40:54 | Araq | dom96: no thats markdown |
| 19:41:05 | * | Matthias247 joined #nimrod |
| 19:41:09 | Araq | the website uses rst |
| 19:41:32 | dom96 | Would be nice if the doc gen supported this syntax too |
| 19:42:25 | Araq | I disagree |
| 19:43:02 | * | OrionPK quit (Ping timeout: 252 seconds) |
| 19:44:24 | * | BitPuffin joined #nimrod |
| 19:44:31 | NimBot | Araq/Nimrod devel f53c318 Dominik Picheta [+0 ±6 -0]: Updates docs and news. |
| 19:44:50 | dom96 | Araq: Take a look at news.txt |
| 19:48:23 | Araq | later |
| 19:50:33 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 19:58:33 | * | ics quit (Ping timeout: 240 seconds) |
| 20:00:03 | * | ics joined #nimrod |
| 20:01:57 | Araq | zahary: have you looked at the exponential explosion? |
| 20:03:44 | zahary | not yet, I'm busy reading some work-related stuff |
| 20:04:46 | Araq | it's sunday night ... |
| 20:05:03 | Araq | plus reading is overrated :P |
| 20:07:07 | Skrylar | i still use asciidoc :B |
| 20:07:19 | * | nande quit (Remote host closed the connection) |
| 20:07:30 | Skrylar | it has plugs that make the [source,nimrod] blocks actually colorized |
| 20:07:46 | Araq | lol |
| 20:07:50 | Araq | Q. What do you call a beautiful woman in Ireland? |
| 20:07:51 | Araq | A. A tourist. |
| 20:07:53 | Araq | XD |
| 20:07:55 | Skrylar | :< |
| 20:10:10 | NimBot | Araq/Nimrod devel 20afe8e Araq [+11 ±1 -11]: fixes #798 |
| 20:10:10 | NimBot | Araq/Nimrod devel 99fb0c1 Araq [+0 ±13 -0]: Merge branch 'devel' of https://github.com/Araq/Nimrod into devel |
| 20:11:12 | dom96 | Araq: What is the reason we include libzip_all.c? |
| 20:11:27 | Araq | the alternative doesn't work on my linux iirc |
| 20:11:46 | Araq | I could install the package on my linux but my package manager is broken ... |
| 20:11:53 | Araq | and I never find the time to fix it |
| 20:12:01 | dom96 | A package for fedora will likely not be accepted unless we get rid of that .c file |
| 20:12:06 | Araq | hey |
| 20:12:15 | Araq | we did get rid of that file for fedora |
| 20:12:26 | Araq | there is some -d:option to activate the .c file |
| 20:13:03 | * | nande joined #nimrod |
| 20:13:38 | Araq | personally I consider it a feature to not be listed on OSes that care more about some weird notion of "correctness" than about being useful but it's a lost fight |
| 20:14:09 | dom96 | Alright. |
| 20:14:31 | Araq | I guess I should blog about it, "programmer's common misconceptions" |
| 20:15:53 | * | nande quit (Remote host closed the connection) |
| 20:16:34 | * | BitPuffin joined #nimrod |
| 20:17:38 | * | Araq wonders if a programmer throws away his phone when he gets a busy signal |
| 20:18:51 | Araq | why are the term rewriting macro bugs the easiest to fix for me? |
| 20:19:37 | Araq | we should use term rewriting for everything |
| 20:29:00 | * | vendethiel quit (Read error: Connection reset by peer) |
| 20:29:27 | * | vendethiel joined #nimrod |
| 20:32:15 | * | Mat3 joined #nimrod |
| 20:32:18 | Mat3 | hi all |
| 20:35:17 | * | [2]Endy quit (Ping timeout: 252 seconds) |
| 20:38:58 | * | zahary1 joined #nimrod |
| 20:39:20 | * | noam__ joined #nimrod |
| 20:40:42 | * | Puffin joined #nimrod |
| 20:41:38 | * | nande joined #nimrod |
| 20:42:03 | * | silven_ joined #nimrod |
| 20:42:23 | NimBot | Araq/Nimrod devel 66945f8 Dominik Picheta [+0 ±3 -0]: Selectors module now uses select on operating systems other than Linux. |
| 20:43:22 | dom96 | Araq: Seems the crash doesn't happen on Linux. |
| 20:46:52 | * | Puffin quit (Ping timeout: 246 seconds) |
| 20:48:18 | * | fowl quit (*.net *.split) |
| 20:48:19 | * | Raynes quit (*.net *.split) |
| 20:48:19 | * | silven quit (*.net *.split) |
| 20:48:20 | * | BitPuffin quit (*.net *.split) |
| 20:48:22 | * | noam_ quit (*.net *.split) |
| 20:48:23 | * | zahary quit (*.net *.split) |
| 20:48:24 | * | comex quit (*.net *.split) |
| 20:49:30 | * | Raynes joined #nimrod |
| 20:49:34 | Araq | hey ho Mat3 |
| 20:49:43 | Araq | where are mat1 and mat2? |
| 20:49:45 | * | Raynes quit (Changing host) |
| 20:49:45 | * | Raynes joined #nimrod |
| 20:49:46 | Mat3 | hi Araq |
| 20:50:20 | Mat3 | some other IRC users use them |
| 20:50:37 | Mat3 | I mean the nick names |
| 20:50:57 | Araq | I see |
| 20:55:12 | * | comex joined #nimrod |
| 20:55:55 | * | fowl joined #nimrod |
| 20:57:28 | Araq | ping Varriount |
| 20:58:11 | EXetoC | any planned feature that won't make it into the next release? |
| 20:58:42 | Araq | no, but the features we have for 0.9.4 are all buggy |
| 20:58:55 | EXetoC | :> |
| 20:59:44 | Araq | I just hope we get all features for 1.0 by the end of this year and then it will only be 1 year of bugfixes left :P |
| 21:00:12 | Araq | but then working on new stuff is always MUCH more fun than fixing bugs |
| 21:00:25 | Araq | it's a hard problem and especially for open source |
| 21:01:16 | Araq | also I think github's bug tracker sucks |
| 21:01:45 | Araq | it shouldn't list RFCs and feature requests as issues |
| 21:01:45 | Mat3 | well, then its time for a feature freeze and concentration on bug fixing |
| 21:02:01 | Araq | Mat3: that's what we're doing for months already |
| 21:02:24 | Araq | we're all tired of doing that, we need a new round of adding features |
| 21:03:13 | Araq | well just to be clear we want to release tonight but Varriount is missing |
| 21:04:14 | * | Puffin joined #nimrod |
| 21:04:22 | EXetoC | Puffin: morning |
| 21:04:52 | Araq | hi Puffin. are you bitpuffin or easy_muffin? |
| 21:05:13 | EXetoC | bitpuffin |
| 21:05:21 | Mat3 | hi BitPuffin |
| 21:05:22 | Araq | ssshhhtt |
| 21:05:38 | EXetoC | assuming that [email protected] isn't occupied by anyone else |
| 21:05:43 | NimBot | Araq/Nimrod devel 1643e35 Dominik Picheta [+0 ±2 -0]: setLen now used on asyncdispatch.recv's return value on Linux.... 2 more lines |
| 21:06:24 | Mat3 | ned some sleep, ciao |
| 21:06:35 | * | Mat3 quit (Quit: Verlassend) |
| 21:07:54 | Araq | fowl: congrats I consider bug #1063 scary enough to make it showstopper |
| 21:11:53 | * | OrionPK joined #nimrod |
| 21:12:26 | * | Puffin quit (Ping timeout: 246 seconds) |
| 21:23:35 | * | foodoo quit (Quit: Lost terminal) |
| 21:55:55 | OrionPK | whats this on devel (osx) : lib/pure/selectors.nim(17, 14) Error: undeclared identifier: 'TSocketHandle' |
| 21:56:07 | * | Demos joined #nimrod |
| 21:56:35 | Araq | I think selectors lacks a macosx implementation |
| 21:57:11 | OrionPK | looks like |
| 21:57:33 | dom96 | indeed, but the select implementation should work |
| 21:57:41 | dom96 | fix it if you can please |
| 21:57:43 | dom96 | brb |
| 21:57:54 | OrionPK | dont have time today |
| 21:58:14 | Araq | or maybe we need to finally admit that 3 OSes are 2 too many |
| 21:59:00 | Araq | and that it is religion and not technical reasons that keep all 3 alive |
| 21:59:21 | OrionPK | which should we all use? |
| 21:59:33 | Araq | NimOs. Built to resist. |
| 22:05:06 | EXetoC | if we can just get 1-2 devs to work on it full-time for a year |
| 22:06:38 | * | OrionPK quit (Ping timeout: 253 seconds) |
| 22:06:39 | EXetoC | generating source code is so fun |
| 22:10:38 | * | Matthias247 quit (Ping timeout: 255 seconds) |
| 22:12:48 | EXetoC | can importc string patterns do "fooBar" -> "glFooBar"? |
| 22:17:09 | Araq | EXetoC: yes. |
| 22:17:46 | Araq | another good option is MongoOS which makes you type in JSON instead of paths seperated by / |
| 22:21:22 | NimBot | Araq/Nimrod devel fdabf69 Dominik Picheta [+0 ±1 -0]: Fixes selectors module on Mac OS X. |
| 22:22:26 | dom96 | Let's just make an OS where each application communicates with the OS via JSON. |
| 22:22:50 | Araq | that's called the "internet" and already exists :P |
| 22:27:11 | EXetoC | Araq: ok, how? |
| 22:27:33 | Araq | EXetoC: importc: "prefix_$1" |
| 22:29:43 | EXetoC | I didn't think anything other than $1 would be expanded |
| 22:33:21 | Araq | EXetoC: want to learn how to fix your mongo wrapper? |
| 22:34:23 | EXetoC | which it has to since it needs to modify the case of one of the characters, but I'll try it soon |
| 22:34:49 | EXetoC | Araq: By introducing another enumeration? |
| 22:35:08 | EXetoC | one without any holes |
| 22:35:23 | EXetoC | but then you might as well just use TSet, right? so what did you have in mind? |
| 22:35:57 | Araq | TupdateOpts* = enum |
| 22:35:59 | Araq | UPDATE_UPSERT = 0x00000001, |
| 22:36:00 | Araq | UPDATE_MULTI = 0x00000002, |
| 22:36:02 | Araq | UPDATE_BASIC = 0x00000004 |
| 22:36:03 | Araq | --> |
| 22:36:33 | Araq | TUpdateOpt* = enum UpdateUpsert, UpdateMulti, UpdateBasic |
| 22:36:52 | Araq | TUpdateOpts* = set[TUpdateOpt] |
| 22:37:28 | Araq | for this the binary representation of the set will produce exactly the right values as UPDATE_UPSERT == 1 shl 0 |
| 22:37:43 | Araq | TCursorOpts* = enum |
| 22:37:45 | Araq | coTailable = 1 shl 1, ## Create a tailable cursor. |
| 22:37:46 | Araq | coSlaveOk = 1 shl 2, ## Allow queries on a non-primary node. |
| 22:37:48 | Araq | coNoTimeout = 1 shl 4, ## Disable cursor timeouts. |
| 22:37:49 | Araq | coAwaitData = 1 shl 5, ## Momentarily block for more data. |
| 22:37:51 | Araq | coExhaust = 1 shl 6, ## Stream in multiple 'more' packages. |
| 22:37:52 | Araq | coPartial = 1 shl 7 ## Allow reads even if a shard is down. |
| 22:37:54 | Araq | Here is is harder but still solvable: |
| 22:38:11 | * | Matthias247 joined #nimrod |
| 22:38:45 | Araq | TCursorOpt = enum coReserved1, coTailable, coSlaveOk, coReserved2, coNoTimeout, coAwaitData, coExhaust, coPartial |
| 22:38:57 | Araq | TCursorOpts = enum[TCursorOpt] |
| 22:39:05 | * | BitPuffin joined #nimrod |
| 22:39:07 | Araq | note how I use coReserved |
| 22:39:15 | Araq | to make it binary compatible |
| 22:40:24 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 22:48:02 | EXetoC | ok so just treat the set as an integer? |
| 22:48:20 | Araq | the set is compiled to an integer |
| 22:49:37 | Araq | I made it binary compatible so that no mapping between nim and mongo is necessary |
| 22:50:36 | * | BitPuffin quit (Ping timeout: 255 seconds) |
| 22:50:48 | EXetoC | yeah but you just need to cast it |
| 22:51:30 | Araq | hu? |
| 22:51:42 | Araq | where do you need to cast it? |
| 22:51:53 | Araq | you simply change the original prototypes :P |
| 22:51:59 | Araq | no casting is necessary |
| 22:53:48 | EXetoC | yeah fine |
| 22:58:49 | * | Demos quit (Ping timeout: 246 seconds) |
| 22:59:29 | EXetoC | Araq: so can I modify the first character of $1? I'd have to do that too |
| 22:59:57 | Araq | unfortunately not |
| 23:00:05 | Araq | we need better subexes |
| 23:01:17 | Araq | gl$(capitalize(1)) |
| 23:01:40 | Araq | there are only a couple of operations we need |
| 23:02:10 | Araq | captialize, capitalizeAddUnderscores, ... |
| 23:02:29 | Araq | somebody needs to come up with a cute syntax for it |
| 23:08:25 | * | darkf joined #nimrod |
| 23:10:32 | Varriount | Araq: You wanted me? |
| 23:10:47 | Araq | ah! |
| 23:10:52 | Araq | Varriount: is here, dom96 |
| 23:10:57 | Varriount | Sorry, I was asleep. |
| 23:11:07 | Araq | excuses ... |
| 23:12:07 | dom96 | well we won't be releasing /now/, surely. |
| 23:12:45 | Araq | why not? |
| 23:12:58 | Araq | the last show stopper bug turns out to be too hard |
| 23:13:34 | dom96 | because i'm sleep deprived |
| 23:13:52 | Araq | come on |
| 23:14:03 | dom96 | what about your news.txt changes? |
| 23:14:15 | Araq | I'm drunk but I don't consider that a hindrance |
| 23:15:32 | dom96 | another reason to wait :P |
| 23:16:04 | * | Demos joined #nimrod |
| 23:18:25 | Araq | Varriount: we're ready to release when you are |
| 23:19:02 | Varriount | Ok. I'd like a chance to test the installers on a vm, but other than that, I should be ready. |
| 23:19:17 | Varriount | What branch do you want used for the installers? |
| 23:19:37 | Araq | devel needs to merged into master, so master |
| 23:19:53 | dom96 | what about your news.txt changes? |
| 23:19:57 | Varriount | Ok. Tell me when it's merged. |
| 23:20:12 | Demos | so making static[T] work correctly is for 0.9.6 then? (I am fine with that) |
| 23:20:50 | Araq | Demos: yup |
| 23:25:04 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 23:29:49 | * | xenagi joined #nimrod |
| 23:30:13 | Varriount | Hm. How would one efficiently create a pipeline of iterators that takes advantage of CPU caches? |
| 23:35:56 | Demos | well what are the iterators doing? do you mean changeing the order you execute stuff to optimize for cache? |
| 23:36:30 | Varriount | I dunno, I'm just openly wondering. |
| 23:37:46 | Varriount | I keep reading these articles on how important it is to be cache-conscious when programming. |
| 23:39:01 | xenagi | ^ |
| 23:39:31 | EXetoC | always depends of course |
| 23:42:19 | Varriount | Araq, dom96: As soon as you give me the ok, I'll generate installers based on the master branch, and test them. |
| 23:43:43 | dom96 | hey xenagi |
| 23:44:02 | xenagi | hey |
| 23:44:11 | dom96 | Varriount: My todo for this release is complete, so you have my OK. |
| 23:44:15 | Demos | anyone know if there is a typeclass for things I can memcpy around? |
| 23:44:28 | dom96 | Although would be great if someone could test my async stuff on Mac OS X. |
| 23:44:32 | Varriount | dom96: Yeah, but has master been merged? |
| 23:44:50 | dom96 | Varriount: No. Wait until Araq gives you his OK :) |
| 23:50:34 | * | supporters joined #nimrod |
| 23:50:44 | Varriount | Hello supporters |
| 23:50:49 | EXetoC | how did I misuse void now? >.< Error: internal error: getTypeDescAux(tyEmpty) |
| 23:55:20 | EXetoC | ptr void |
| 23:55:48 | EXetoC | reported? I found one reference in an IRC log |
| 23:56:18 | Varriount | I thought a void pointer in nimrod was just a cast to an int. :/ |
| 23:56:30 | Araq | use pointer instead of ptr void |
| 23:56:42 | dom96 | Yeah, I think I reported that. |
| 23:56:54 | Araq | hi supporters welcome |
| 23:56:59 | EXetoC | I know |
| 23:57:03 | EXetoC | ok good |