| 00:19:22 | * | vbtt quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 00:29:41 | * | BitPuffin quit (Read error: Operation timed out) |
| 00:29:56 | * | BitPuffin joined #nimrod |
| 00:32:10 | * | vbtt joined #nimrod |
| 00:33:50 | * | Demos joined #nimrod |
| 00:37:20 | * | icebattle quit (Quit: leaving) |
| 00:57:59 | Varriount | vbtt: Have you marked the fields as public? |
| 00:58:34 | vbtt | no. |
| 00:59:05 | Varriount | See what happens when you make them public. |
| 01:00:24 | vbtt | Varriount:still wont compile. |
| 01:00:32 | Varriount | Hrm. |
| 01:00:38 | vbtt | it's ok. using accessing through the parent type is acceptable. |
| 01:01:03 | Varriount | Yeah, but it's kinda unexpected. |
| 01:01:41 | vbtt | specially because it's undocumented. |
| 01:02:32 | Varriount | vbtt: I would be thankful if you could add to the distinct types section in the manual. |
| 01:03:28 | vbtt | ok, not sure but i'll try. |
| 01:03:32 | vbtt | anyway, g2g now. |
| 01:03:50 | vbtt | later guys. |
| 01:03:54 | * | vbtt quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 01:12:44 | * | Icefoz quit (Quit: Lost terminal) |
| 01:23:29 | * | DAddYE quit (Remote host closed the connection) |
| 01:23:44 | * | DAddYE joined #nimrod |
| 01:24:34 | * | DAddYE quit (Remote host closed the connection) |
| 01:25:11 | * | DAddYE joined #nimrod |
| 01:29:41 | * | DAddYE quit (Ping timeout: 248 seconds) |
| 01:31:44 | * | Icefoz joined #nimrod |
| 01:36:38 | * | Jesin joined #nimrod |
| 02:12:07 | * | gsingh93 joined #nimrod |
| 02:13:15 | gsingh93 | How can I recv all data currently available on a socket? |
| 02:13:33 | gsingh93 | None of the recv calls seem to match up to the recv call in C |
| 02:21:57 | * | brson quit (Quit: leaving) |
| 02:38:56 | * | Jesin quit (Quit: Leaving) |
| 03:18:15 | * | Varriount quit (Ping timeout: 272 seconds) |
| 03:19:10 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 03:27:52 | * | vendethiel joined #nimrod |
| 03:50:04 | * | Varriount joined #nimrod |
| 04:03:36 | * | renesac quit (Quit: Leaving) |
| 04:11:06 | Varriount | Yay! I now get forum updates sent to my email. :) |
| 04:27:33 | * | BitPuffin quit (Ping timeout: 272 seconds) |
| 04:44:49 | * | discoloda quit (Read error: Operation timed out) |
| 04:44:56 | * | discoloda joined #nimrod |
| 04:58:49 | Varriount | Araq: Updated my pull request for os/add-linkprocs |
| 04:59:07 | Varriount | gsingh93: You still there? |
| 05:01:14 | * | renesac joined #nimrod |
| 05:04:36 | Varriount | Hi renesac |
| 05:04:42 | renesac | hi |
| 05:05:16 | renesac | I'm going sleep o/~~ |
| 05:05:50 | Varriount | Goodnight |
| 05:11:15 | gsingh93 | Varriount: yea, I'm here |
| 05:15:46 | * | gsingh93 quit (Quit: ERC Version 5.3 (IRC client for Emacs)) |
| 05:19:06 | * | gsingh93 joined #nimrod |
| 05:22:03 | Varriount | gsingh93: Did you get your problem fixed? |
| 05:24:32 | gsingh93 | no, I couldn't figure it out. I need to recv as much text as the server sent |
| 05:24:37 | gsingh93 | I don't know how much text that is |
| 05:24:55 | Varriount | gsingh93: What module are you using? |
| 05:25:00 | gsingh93 | sockets |
| 05:25:07 | Varriount | Not asyncio? |
| 05:25:13 | gsingh93 | should I be using that? |
| 05:25:16 | gsingh93 | I'm new to nimrod |
| 05:26:24 | Varriount | gsingh93: What exactly are you trying to do, and what is your current code? |
| 05:27:08 | gsingh93 | There's a server that's listening on a certain port |
| 05:27:14 | gsingh93 | It sends me a line of text |
| 05:27:21 | gsingh93 | and based on that line of text I respond with some number |
| 05:27:43 | Varriount | Are you going to need to be doing other things while waiting for the line of text? |
| 05:27:55 | gsingh93 | No, I can't do anything until I have it |
| 05:28:48 | Varriount | gsingh93: And what trouble are you having with sockets? |
| 05:29:31 | gsingh93 | If I use recv() I need to give it a size |
| 05:29:43 | gsingh93 | And I don't know the size |
| 05:29:47 | gsingh93 | If that many bytes aren't sent |
| 05:29:53 | gsingh93 | It blocks |
| 05:29:58 | gsingh93 | I can set size to 1 and loop |
| 05:30:02 | Varriount | gsingh93: Thats the low-level interface. Why not use readline? |
| 05:30:03 | gsingh93 | but that's not a good way to do it |
| 05:30:09 | Varriount | http://nimrod-lang.org/sockets.html#148 |
| 05:30:49 | gsingh93 | I'll give it a shot |
| 05:32:26 | gsingh93 | Ok, I think the issue with that is that the server doesn't send newlines at the end of text |
| 05:32:38 | gsingh93 | It's queries look like, "some text here: " |
| 05:32:54 | gsingh93 | And when I use netcat to connect, I type on the same line |
| 05:33:03 | Varriount | gsingh93: Then it's not sending "lines" |
| 05:33:03 | gsingh93 | I think readline will block until it gets a newline |
| 05:33:24 | gsingh93 | Ah, sorry, didn't realize it until I tried it |
| 05:33:59 | gsingh93 | In C, I can call recv and it'll get as much data as is available and I can manually check for the terminating condition (in this case a semicolon) |
| 05:34:08 | gsingh93 | Any way to do that here? |
| 05:34:17 | Varriount | gsingh93: Is a semicolon what seperates a 'line'? |
| 05:34:28 | gsingh93 | Yea |
| 05:35:03 | Varriount | gsingh93: Then I would look at the implementation of readline, copy it, and change it so that it works with a semicolon |
| 05:35:41 | Varriount | Actually, a good addition to sockets would be a generic version of readline that allowed that. |
| 05:36:50 | gsingh93 | I agree |
| 05:37:34 | Varriount | gsingh93: Maybe you could implement it? |
| 05:39:03 | gsingh93 | I can try |
| 05:39:14 | gsingh93 | I'll probably need to get a bit better with nimrod first |
| 05:39:20 | gsingh93 | Anyway, thanks for the help |
| 05:39:24 | gsingh93 | I'll be back if I can't get it working |
| 05:39:29 | Varriount | It's my pleasure. |
| 05:39:39 | * | gsingh93 left #nimrod ("ERC Version 5.3 (IRC client for Emacs)") |
| 06:06:11 | * | xtagon quit (Quit: Leaving) |
| 06:22:11 | * | delian66 quit (Ping timeout: 272 seconds) |
| 06:23:30 | * | bbodi joined #nimrod |
| 06:33:49 | shodan45 | omg... I played this when I was a kid: http://www.slate.com/articles/technology/bitwise/2014/01/robot_odyssey_the_hardest_computer_game_of_all_time.html |
| 06:34:25 | shodan45 | I didn't get far in the main game, but it was still fun |
| 06:36:14 | shodan45 | I first saw a link to that article on HN titled "hardest game of all time", and immediately thought of Robot Odyssey... couldn't believe I was right |
| 06:42:28 | * | gsingh93_ joined #nimrod |
| 07:44:16 | * | DAddYE joined #nimrod |
| 08:07:45 | * | io2 joined #nimrod |
| 08:07:46 | * | ddl_smurf joined #nimrod |
| 08:10:19 | * | Amrykid quit (Ping timeout: 260 seconds) |
| 08:11:36 | * | dom96 quit (Ping timeout: 252 seconds) |
| 08:11:43 | * | Araq quit (Ping timeout: 260 seconds) |
| 08:12:17 | * | Araq_bnc joined #nimrod |
| 08:12:47 | * | Amrykid joined #nimrod |
| 08:13:04 | * | io2 quit (Read error: Operation timed out) |
| 08:13:47 | * | dom96 joined #nimrod |
| 08:13:55 | * | Araq_bnc is now known as Araq |
| 08:16:03 | * | [1]Endy joined #nimrod |
| 08:28:24 | * | _nano joined #nimrod |
| 08:30:59 | * | [2]Endy joined #nimrod |
| 08:33:37 | * | [1]Endy quit (Ping timeout: 252 seconds) |
| 08:49:39 | * | [1]Endy joined #nimrod |
| 08:53:38 | * | [2]Endy quit (Ping timeout: 264 seconds) |
| 08:57:49 | * | [2]Endy joined #nimrod |
| 09:01:15 | * | [1]Endy quit (Ping timeout: 260 seconds) |
| 09:13:49 | * | aruniiird joined #nimrod |
| 09:20:09 | * | aruniiird quit (Ping timeout: 272 seconds) |
| 09:57:54 | * | LordAndrew quit (Read error: Connection reset by peer) |
| 10:07:23 | * | DAddYE quit (Remote host closed the connection) |
| 10:07:50 | * | DAddYE joined #nimrod |
| 10:12:27 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 10:28:00 | * | Mordecai joined #nimrod |
| 10:29:29 | * | psquid quit (Ping timeout: 240 seconds) |
| 11:04:28 | * | jbe_ joined #nimrod |
| 11:07:39 | jbe_ | hi everyone |
| 11:08:16 | jbe_ | were the gl bindings removed? |
| 11:08:48 | fowl | jbe_, they're in a babel package now |
| 11:09:03 | * | DAddYE joined #nimrod |
| 11:09:08 | jbe_ | oh i see |
| 11:13:28 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 11:36:48 | * | tdc joined #nimrod |
| 11:53:25 | jbe_ | is there a way to use module names as template parameters? |
| 12:00:09 | Araq | could work, but last time I tried it it didn't work due to a bug |
| 12:00:22 | Araq | or rather a limitation which I can't remember |
| 12:06:35 | jbe_ | ah ok.. thanks |
| 12:09:56 | * | DAddYE joined #nimrod |
| 12:14:57 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 12:35:32 | Araq | zielmicha1, zielmicha-cloud_ what if we make a different constructor that supports poShell? we could give that a new FExecShell so people can be extra careful |
| 12:35:49 | Araq | startProcess then wouldn't support poShell at all |
| 12:37:11 | zielmicha-cloud_ | Maybe. But backward compatibility would suffer. |
| 12:37:22 | zielmicha-cloud_ | Or maybe not. |
| 12:38:11 | zielmicha-cloud_ | Actually it may be a good idea. |
| 12:38:18 | Araq | well startCmd will stay but be marked as FExecShell |
| 12:38:38 | Araq | I like the idea, make it happen please :-) |
| 12:39:21 | dom96 | why the 'F'? |
| 12:39:43 | Araq | because effects still have the F prefix |
| 12:39:47 | zielmicha-cloud_ | Ok |
| 12:40:06 | * | filwit joined #nimrod |
| 12:40:24 | filwit | morning nimrod |
| 12:40:42 | filwit | i read the new type-classes article posted on reddit |
| 12:41:09 | dom96 | oh I see. Thought it would be a function, totally skipped the 'marked' part. |
| 12:41:14 | dom96 | hello filwit |
| 12:41:36 | filwit | very good. simple enough, and clearly illustrates the feature |
| 12:41:55 | Araq | I only skimmed it ... |
| 12:42:08 | Araq | no time these days |
| 12:42:53 | filwit | Araq, we have got to get you funding somehow mate |
| 12:43:15 | filwit | you're too valuable, and Nimrod is becoming very feature completely |
| 12:44:17 | filwit | it doesn't make a whole lot of sense that you're fighting for time to work on your passion project, as in my eyes, it's worth a lot |
| 12:45:04 | filwit | if i had more money, i would donate you something, but as it is i'm sacrificing all my time and money trying to build my start-up |
| 12:46:45 | filwit | anyways, the article was good, though i think the complaint's in the comment section was somewhat valid |
| 12:47:06 | Araq | what's the complaint? |
| 12:48:05 | filwit | basically a guy was saying (in many words I had to look up) that he find's duck-typing not well suited to every programmers understanding |
| 12:48:40 | Araq | *shrug* |
| 12:48:41 | filwit | however, i think that could easily be fixed with one "addition" to the type-class system |
| 12:49:03 | Araq | that's the old "can be confusing" complaint |
| 12:49:19 | Araq | in german we call this a Totschlagargument |
| 12:49:48 | Araq | "death's kiss argument" perhaps |
| 12:50:08 | Araq | it's hard to argue against but only because it's very general and applies to everything |
| 12:50:42 | filwit | well, as I said, i see an "easy" solution |
| 12:51:04 | filwit | (though i agree in general it's a "meh" issue, especially ATM) |
| 12:51:32 | filwit | the solutions is just to have have: type Foo = object of Bendable # where 'Bendable' is a generic |
| 12:52:24 | Araq | also Nimrod doesn't care about average joe programmer. we have already languages that care about those. Java and Golang. And they are design desasters. ymmv of course. |
| 12:52:26 | filwit | or whatever, basically it would just be sugar for "test Foo against Bendable" |
| 12:52:38 | Araq | yeah it's a sweet idea |
| 12:52:49 | Araq | but also fights the purpose somewhat |
| 12:53:09 | filwit | well, considering it would be completely optional, i don't see a downfall |
| 12:53:36 | Araq | aha hmm |
| 12:53:49 | Araq | I thought you propose it to be mandatory |
| 12:54:49 | filwit | nope, i agree that would defeat the purpose entirely |
| 12:54:57 | filwit | (if it was manditory) |
| 12:55:01 | Araq | ok good |
| 12:55:53 | filwit | it's just a suggestion to Zahary, and could easily be added later (post 1.0) |
| 12:56:48 | Araq | yeah indeedd |
| 12:57:22 | filwit | but i think it would basically squash any arguments about type-classes being "inferior" to interfaces due to "human error or misunderstanding" (which seems to be the crust of the guys arguments) |
| 12:58:05 | filwit | anyways, glad that you agree with me :) |
| 12:58:17 | Araq | interfaces are inferior because they are resolved at runtime. |
| 12:58:31 | Araq | plain and simple. |
| 12:58:49 | filwit | yes, which actually i was questioning that.. |
| 12:59:27 | filwit | how can you have a seq[Bendable], which doens't invoke it's objects proc's dynamically? |
| 13:00:09 | Araq | a seq[Bendable] is still a seq[T] |
| 13:00:22 | Araq | it's instantiated for some T |
| 13:02:05 | filwit | i'm still confused, sorry. I'm meant, since Any type can be a "Bendable", iterating over the seq and calling a specific proc would need to invoke differen't proc for different types.. |
| 13:02:21 | filwit | wouldn't that require dynamic dispatch? |
| 13:02:54 | Araq | the 'generic' feature adds constraints to a generic type. that's it. |
| 13:05:06 | Araq | you can't store different bendables in a seq |
| 13:05:24 | filwit | the article seems to say otherwise |
| 13:06:52 | filwit | in the article, he illustrates a seq[Bendable], adds two different types (paper and rope) to it, then iterates over the seq and calls a proc that is unique to each type by name |
| 13:07:18 | Araq | uh oh ... |
| 13:08:19 | filwit | ^ i'm not sure if that means you're confused about something i just said, or concerned the article wasn't properly written.. |
| 13:08:29 | Araq | oh well ... that's what happens when I don't do everything myself |
| 13:08:35 | filwit | lol |
| 13:10:21 | filwit | it would be possible, but I dont' see how without dynamic dispatch (in that particular situation). |
| 13:10:48 | Araq | well it's possible with ref object + methods |
| 13:12:13 | filwit | yes, my point exactly, but that's invisibly translating 'proc's into methods, for these scenarios, which could have some unexpected performance implications |
| 13:12:30 | filwit | not that it's a big deal really |
| 13:13:42 | * | zielmicha-experi joined #nimrod |
| 13:14:50 | Araq | well no but we should claim the examples are slightly wrong and call it day :P |
| 13:17:16 | filwit | yeah, i agree, clear documentation of this is all that's needed |
| 13:19:26 | filwit | though I don't think the article is doing any harm as it stands (it doesnt' talked about dynamic vs static dispatch at all to begin with). |
| 13:22:45 | filwit | okay, well, all-in-all, good article. i'll bbl |
| 13:24:50 | * | darkf quit (Quit: Leaving) |
| 13:25:26 | NimBot | Araq/Nimrod devel 4af987b Araq [+0 ±1 -0]: nativeStackTrace might work again |
| 13:25:26 | NimBot | Araq/Nimrod devel eba8ed0 Araq [+0 ±2 -0]: updated asyncio and ftpclient modules |
| 13:25:26 | NimBot | Araq/Nimrod devel 579b29b Araq [+0 ±1 -0]: fixes a minor parser bug |
| 13:25:26 | NimBot | Araq/Nimrod devel ca557d9 Araq [+0 ±1 -0]: more efficient calls for closure iterators |
| 13:25:26 | NimBot | 1 more commits. |
| 13:51:42 | EXetoC | any plans to raise anything more specific than EOS in the sockets module? |
| 13:52:07 | Araq | no, why |
| 13:52:11 | Araq | is it a problem? |
| 14:01:28 | EXetoC | I'd just like to ignore send errors high up in the call chain, without accidentaly hiding unrelated errors |
| 14:01:58 | renesac | http://force7.de/nimrod/ <-- link rot. Not sure if it is safe to click, it is parked. |
| 14:02:18 | renesac | that is a sad thing in internet |
| 14:02:51 | Araq | renesac: not sure what you mean. the official URL was nimrod-code.org and now nimrod-lang.org |
| 14:03:02 | Araq | force7.de is archaic |
| 14:03:06 | renesac | sure |
| 14:03:37 | renesac | only commenting that old links rot... |
| 14:04:30 | renesac | http://web.archive.org/web/20120910042606/http://force7.de/nimrod/ |
| 14:04:33 | renesac | \o/ |
| 14:05:37 | Araq | tell them to remove it from their archives |
| 14:05:50 | renesac | you can do that, but why? |
| 14:06:08 | Araq | because old things should be allowed to die in the internet |
| 14:06:20 | Araq | it's immorale to cache everything |
| 14:06:25 | renesac | right.... |
| 14:06:58 | renesac | well, tell them if you want |
| 14:16:05 | * | zielmicha-experi quit (Ping timeout: 248 seconds) |
| 14:18:07 | * | Mordecai quit (Ping timeout: 260 seconds) |
| 14:25:11 | * | psquid joined #nimrod |
| 14:25:11 | * | psquid quit (Changing host) |
| 14:25:11 | * | psquid joined #nimrod |
| 14:39:54 | * | psquid quit (Ping timeout: 252 seconds) |
| 14:57:03 | * | psquid joined #nimrod |
| 15:09:25 | * | BitPuffin joined #nimrod |
| 15:11:38 | * | filwit quit (Ping timeout: 264 seconds) |
| 15:25:15 | Araq | renesac:: why is proc toGlVec(a: Array[3, int]) : array[TCoord, GLfloat] = |
| 15:25:17 | Araq | return [GlFloat(a[x.ord]), GlFloat(a[y.ord]), GlFloat(a[z.ord])] necessary? |
| 15:26:30 | renesac | because I could't get it to convert automatically |
| 15:27:18 | NimBot | Araq/Nimrod devel 47d7b7a Erik O'Leary [+3 ±0 -0]: Added docgen documentation |
| 15:27:18 | NimBot | Araq/Nimrod devel d081b84 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Fixes two minor typos. |
| 15:27:18 | NimBot | Araq/Nimrod devel 897a356 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Reformats text to fit width of 80 columns. |
| 15:27:18 | NimBot | Araq/Nimrod devel 7ff610d Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds docgen to list of documentation to build. |
| 15:27:18 | NimBot | 4 more commits. |
| 15:27:18 | Araq | it's only for teh convenience of 0, 1, -1 etc. right? |
| 15:27:34 | renesac | yes |
| 15:28:06 | Araq | well there are better ways to do this |
| 15:28:41 | renesac | and I also could't figure out how to call a function that needs arrays indexed by enum w/o separatedly declaring the arrays to be passed before |
| 15:29:15 | renesac | that is why there is a '3' there |
| 15:30:39 | Araq | wind: array[TCoord, float64] = [0.0, 0.0, 0.0] # Wind speed. |
| 15:30:44 | Araq | works ... |
| 15:32:07 | renesac | ? |
| 15:32:44 | renesac | you mean, doing that for each parameter in newVectorGroup? |
| 15:34:07 | * | psquid quit (Quit: work) |
| 15:44:33 | renesac | oh, now it works (parameter passing) |
| 15:44:49 | renesac | still, no implicit float > GLFloat |
| 15:46:47 | * | renesac is now known as renesac|away |
| 15:55:57 | renesac|away | I mean, 'let gf:GLFloat = 0.0' works but 'let gfv:array[1,GLFloat] = [0.0]' don't |
| 15:56:16 | renesac|away | really away noe |
| 15:56:19 | renesac|away | *now |
| 16:01:31 | * | ics joined #nimrod |
| 16:06:23 | * | ics quit (Ping timeout: 272 seconds) |
| 16:07:02 | dom96 | Araq: Shall I make a pull request to the main repo or do you want to fix that? |
| 16:07:37 | Araq | nah I don't care |
| 16:15:50 | EXetoC | renesac|away: the type can be used as a constructor |
| 16:16:22 | EXetoC | and the first literal in an array construction determines the type, which reduces typing a little |
| 16:18:31 | EXetoC | [0.GLFloat, 0, 0] -> array[3, GLFloat] (or array[0 .. 2, GLFloat]) |
| 16:18:59 | Araq | bbl |
| 16:19:32 | EXetoC | GLFloat(1) -> 1.GLFloat |
| 16:24:35 | OrionPK | ah thanks gradha |
| 16:31:23 | * | Icefoz quit (Ping timeout: 265 seconds) |
| 16:40:36 | * | io2 joined #nimrod |
| 16:48:48 | * | Icefoz joined #nimrod |
| 17:01:25 | * | jbe_ quit (Read error: Operation timed out) |
| 17:19:59 | * | Icefoz quit (Ping timeout: 240 seconds) |
| 17:21:59 | * | Icefoz joined #nimrod |
| 17:22:04 | * | algoban joined #nimrod |
| 17:22:07 | * | algoban left #nimrod (#nimrod) |
| 17:29:45 | * | zielmicha-exper_ joined #nimrod |
| 17:34:59 | * | zielmicha-exper_ quit (Ping timeout: 252 seconds) |
| 17:44:20 | * | vbtt joined #nimrod |
| 17:50:37 | * | Icefoz quit (Ping timeout: 272 seconds) |
| 17:53:33 | * | vbtt_ joined #nimrod |
| 17:53:36 | vbtt_ | hi guys |
| 17:53:52 | OrionPK | hola |
| 17:58:58 | vbtt_ | so I think my article is wrong. |
| 17:59:09 | vbtt_ | I'm doing dynamic dispatch as I realized after reading irc. |
| 17:59:32 | vbtt_ | In retrospect, it's obvious. |
| 18:01:36 | vbtt_ | I think I've fixed the text now. Please review. |
| 18:02:14 | * | ics joined #nimrod |
| 18:04:31 | vbtt_ | shouldv'e waited to get my edits reviewed too :) the first version of the post didn't have that example.. |
| 18:04:37 | vbtt_ | oh well. |
| 18:04:42 | vbtt_ | later guys. |
| 18:06:23 | * | ics quit (Ping timeout: 245 seconds) |
| 18:11:10 | * | vbtt_ quit (Ping timeout: 245 seconds) |
| 18:12:51 | * | Icefoz joined #nimrod |
| 18:16:25 | * | Varriount_ joined #nimrod |
| 18:16:27 | * | vbtt quit (Read error: Connection reset by peer) |
| 18:18:03 | * | Varriount quit (Ping timeout: 245 seconds) |
| 18:23:29 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 18:24:28 | * | vendethiel joined #nimrod |
| 18:33:26 | * | xtagon joined #nimrod |
| 18:39:17 | Araq | dom96: I m tired of nimbuild's hard debuggung |
| 18:40:02 | Araq | we need a way to fake coommon messages |
| 18:48:14 | * | bbodi quit (Ping timeout: 264 seconds) |
| 18:48:44 | dom96 | So you essentially want a fake hub? |
| 18:51:17 | Araq | yeah |
| 18:58:43 | * | vbtt joined #nimrod |
| 18:58:55 | Araq | hi vbtt |
| 18:59:11 | vbtt | Hi |
| 18:59:48 | vbtt | how goes it? |
| 19:00:25 | vbtt | I updated the blog. |
| 19:00:35 | Araq | cool |
| 19:00:41 | vbtt | I feel stupid :/ |
| 19:00:50 | Araq | have no time, just wanted to say your "obsolete" idea is very nice |
| 19:00:56 | Araq | and I will do it this way |
| 19:00:58 | Araq | bbl |
| 19:01:32 | vbtt | cool Ttyl |
| 19:10:03 | * | BitPuffin quit (Ping timeout: 272 seconds) |
| 19:10:08 | * | Varriount_ quit (Ping timeout: 245 seconds) |
| 19:12:24 | Araq | dom96: how should var s = proc (x, y): auto = x+5 work? |
| 19:12:44 | Araq | what's 'x' ? a float, an int, a generic? |
| 19:12:56 | dom96 | A generic. |
| 19:13:03 | Araq | what is 's' then? how can it reasonably be instantiated? |
| 19:13:36 | * | renesac|away is now known as renesac |
| 19:13:50 | dom96 | I can write proc s(x, y): auto = x + 5 no problem |
| 19:13:56 | renesac | dom96: did you take this idea from Clay? |
| 19:14:03 | dom96 | Is it unreasonable to apply this reasoning to closures? |
| 19:14:16 | dom96 | renesac: no |
| 19:14:18 | Araq | 1. there is no closure here |
| 19:14:43 | renesac | clay does whole program type inference (though, I heard it is dead now...) |
| 19:14:44 | Araq | 2. proc s can reasonably be instantiated, 'var s =...' cannot |
| 19:14:57 | Araq | renesac: we got the idea from clay, yes |
| 19:15:09 | Araq | the implicit generics stem from clay |
| 19:15:57 | Araq | clay probably still does it better as that compiler has been written with this feature in mind, whereas in nimrod we patched the compiler ... |
| 19:16:16 | dom96 | What code do you suggest the lambda macro should generate then? |
| 19:16:40 | Araq | lambda is just sugar for an anon 'proc' |
| 19:18:12 | Araq | \(a, b, a + b) is transformed into proc (a, b): auto = a + b |
| 19:18:48 | dom96 | Yeah, but that doesn't work. |
| 19:18:57 | Araq | that's the bug then |
| 19:19:06 | Araq | not that the assignment to 'var s' doesn't work |
| 19:19:17 | dom96 | oh right |
| 19:19:21 | renesac | Araq: the only problem I can see now is how to treat reference vs value types |
| 19:19:29 | dom96 | I get you now. Then the error makes sense. |
| 19:19:54 | Araq | renesac: what's your context? |
| 19:19:54 | renesac | if you pass a 'ref intnumber' for example, this lambda will probably fail |
| 19:20:00 | renesac | as x |
| 19:21:05 | renesac | or 'ptr intnumber', though I'm not sure how the language does implicit deferencing |
| 19:21:05 | Araq | I don't care if the lambda fails for edge cases, we have a slightly more verbose syntax that handles everything |
| 19:21:11 | renesac | yes |
| 19:21:34 | renesac | in clay everything was passed by reference to avoid this, but that is probably not optimal |
| 19:21:34 | dom96 | Araq: https://gist.github.com/dom96/508388bb5292d6e418d0 |
| 19:21:39 | dom96 | Should that work? |
| 19:22:07 | Araq | ultimately yes |
| 19:22:17 | dom96 | It gives the exact same error. |
| 19:22:22 | Araq | but I don't know what's the current status wrt type inference is |
| 19:22:56 | Araq | well the error message is nice |
| 19:23:07 | Araq | the internal error you mention too is not |
| 19:23:17 | dom96 | The error message could be better. |
| 19:23:29 | renesac | shouldn't it be: 'proc test(x = proc (a, b: int): int) =' |
| 19:23:30 | renesac | ? |
| 19:23:33 | renesac | '=' |
| 19:24:06 | Araq | x has the type "proc ...." |
| 19:24:10 | dom96 | no, types come after ':' |
| 19:24:12 | Araq | not the value "proc ..." |
| 19:24:19 | renesac | humm |
| 19:24:41 | renesac | that many ':' is confusing ^^' |
| 19:25:01 | renesac | but yeah, I understand now |
| 19:25:02 | Araq | read it from left to right like everythin else in nimrod |
| 19:26:01 | dom96 | Araq: Why can't instantiation be deferred until I invoke the variable 's'? |
| 19:26:36 | Araq | dom96: because there is no notion of a generic variable in the language |
| 19:27:02 | Araq | dom96: btw how does it work? we make the language always more complex to optimizie for key strokes and get zero new compiler devs? |
| 19:27:04 | dom96 | ahh ok. So when assigning a proc to a variable it has to be fully instantiated? |
| 19:27:42 | Araq | yes |
| 19:28:09 | Araq | unles the variable is in a generic proc, then its instantation is bound to the instantion of the proc |
| 19:28:14 | dom96 | Well I was wrong. The var s = ... example I give doesn't have to work for the lambda macros. |
| 19:28:28 | Araq | still the question is valid |
| 19:28:32 | dom96 | Just bad testing on my part. But i'm just curious. |
| 19:28:56 | Araq | we have 2 compiler devs. those who try, fail. |
| 19:29:33 | dom96 | bbl dinner |
| 19:29:45 | Araq | that's a fundamental problem and how do we deal with it? we listen to the guys who are not happy we're not reinventing haskell |
| 19:30:06 | renesac | well, you may deffer those key stroke optimizations for latter... |
| 19:31:51 | Araq | renesac: that would be wise |
| 19:31:51 | renesac | I find that nimrod is already quite concise, except for requiring many explicit type conversions (not that I'm complaining, and part are 'bugs' regarding uint) |
| 19:33:26 | Araq | yeah and what's worse, all these lambda chains do not compose well, imho |
| 19:33:41 | Araq | I know i can't say that in 2014 when the world finally loves FP |
| 19:33:53 | Araq | but it's true, FP does not compose well |
| 19:34:24 | EXetoC | certain things in some languages are verbose for no apparent reason |
| 19:34:44 | EXetoC | in other cases, verbosity can make the code easier to parse |
| 19:36:05 | EXetoC | renesac: got an example of unnecessary verbosity, that isn't caused by a bug? |
| 19:36:47 | renesac | EXetoC: that call to getVertexGroup if you are to put .GLFloat in the first parameter of all vectors |
| 19:36:56 | renesac | for example |
| 19:37:44 | renesac | or the need of doing 'enumvalue.ord' to get a number |
| 19:37:51 | renesac | to index in a normal array |
| 19:37:54 | renesac | for example |
| 19:38:06 | renesac | but those are relatively minor things |
| 19:39:19 | Araq | you don't need enumvalue.ord when you use the enum as the index type in the array |
| 19:39:21 | renesac | or math.log2 only taking floats as input (that may be corrected easily, but will mean moving the type conversion to inside de function, of course) |
| 19:39:32 | renesac | Araq: true |
| 19:39:42 | renesac | but when you don't you need |
| 19:39:53 | EXetoC | TGLfloat? that's a bug then isn't it? |
| 19:39:54 | Araq | that's a feature |
| 19:40:15 | EXetoC | it's only an alias |
| 19:40:42 | Araq | but it's an alias to float32 I guess and float literals are of type float(64) |
| 19:41:24 | EXetoC | does this have anything to what you tried to fix a couple of months back? |
| 19:41:32 | EXetoC | and maybe that float PR that I submitted |
| 19:42:17 | renesac | Araq> that's a feature <-- I'm not sure to which line you are answering |
| 19:42:33 | Araq | renesac: to the enum as array index conversion |
| 19:42:49 | Araq | it's easy enough to declare the array properly |
| 19:43:32 | EXetoC | *to do with |
| 19:44:36 | Araq | EXetoC: what I fixed now works |
| 19:45:01 | renesac | I still think that 'let gfv:array[1,GLFloat] = [0.0]' should work, but as I said, this can be fixed latter |
| 19:45:16 | * | vbtt quit (Read error: Connection reset by peer) |
| 19:45:25 | * | vbtt joined #nimrod |
| 19:45:50 | * | vbtt quit (Client Quit) |
| 19:46:25 | renesac | the new coffescript style function calling syntax will be in 0.8.4? |
| 19:46:48 | Araq | 0.9.4, but yes |
| 19:46:56 | renesac | oops, yeah |
| 19:47:17 | Araq | that extension was obvious in hindsight |
| 19:47:42 | renesac | I hate typing parenthesis, but I'm a bit afraid of loosing them ;P |
| 19:48:11 | Araq | I hate them too or else I would have invented a Lisp :P |
| 19:48:26 | renesac | but for simple nested calls with one parameter it is interesting |
| 19:48:45 | Araq | let future = await foo(a, b) |
| 19:48:50 | EXetoC | renesac: you don't mean this "var a: TGLfloat = 1.0"? |
| 19:48:53 | Araq | is also a very important use case |
| 19:49:21 | renesac | EXetoC, no, that works, and thats why I think the array example should also work (for any size of array) |
| 19:49:48 | renesac | Araq, right |
| 19:50:23 | Araq | renesac: that's the old "<: doesn't compose" issue |
| 19:50:51 | Araq | we'll fix it eventually by introducing more complex type conversion/subtyping rules |
| 19:51:13 | Araq | but it's not hard to understand why A <: B doesn't imply C[A] <: C[B] |
| 19:51:35 | renesac | right, that is all I wanted to hear |
| 19:51:37 | renesac | ;) |
| 19:53:33 | Araq | renesac: are you familiar with 'cas'? |
| 19:54:03 | Araq | (compare and swap) |
| 19:54:14 | renesac | oh, kinda |
| 19:54:27 | Araq | kinda ain't good enough |
| 19:54:28 | renesac | we have atomic operations in nimrod? |
| 19:54:41 | Araq | lib/system/atomics exists |
| 19:55:00 | Araq | but imho it sucks, so I wrap the things I need on my own |
| 19:55:22 | EXetoC | [1.TGLfloat, 1, 1] is not that bad. You didn't answer so I don't know if you saw that |
| 19:56:03 | EXetoC | you can't do the equivalent for varargs though |
| 19:56:14 | Araq | screw C++11 with it's absurdly complex weak consistency memory model |
| 19:56:36 | Araq | I wonder if there is a single benchmark out there where C++'s memory model makes a difference |
| 19:56:38 | EXetoC | actually you could, since the brackets can be included |
| 19:57:50 | dom96 | back |
| 19:58:45 | * | tdc quit (Quit: Leaving) |
| 20:00:07 | Araq | dom96: does babel register an environment var? |
| 20:00:08 | renesac | well, in case it works for all arguments on newVectorGroup, it makes a 80 column line 156 columns, but that is a special case of course |
| 20:00:16 | dom96 | Araq: no |
| 20:00:45 | renesac | in most cases I agree with you that it isn't a big problem |
| 20:01:41 | * | BitPuffin joined #nimrod |
| 20:04:27 | Araq | dom96: how can I determine where babel installs its stuff? |
| 20:04:48 | dom96 | It's always ~/.babel |
| 20:05:15 | EXetoC | renesac: shorter version: 1'f32 |
| 20:05:44 | renesac | are you sure it works? But that is kinda hackish too... |
| 20:15:51 | EXetoC | I guess it's not that different compared to when the compiler "converts" an int literal to an int16 for example at compile-time |
| 20:18:00 | EXetoC | the behavior that you proposed that is |
| 20:19:19 | EXetoC | BitPuffin: what do you think? you complained about it before, but that was before you knew about this shortcut: [1'f32, 1'f32, 1'f32] -> [1'f32, 1, 1] |
| 20:22:17 | EXetoC | BitPuffin: are you fine with that? renesac wants to allow array literals to be implicitly convertible |
| 20:24:22 | EXetoC | renesac: what's vector group? just an array/seq of vectors? |
| 20:31:20 | renesac | https://github.com/dom96/ParticleBench/blob/master/N.nim <-- it's a function from this script |
| 20:37:49 | EXetoC | well now you know how to make it even shorter. ' can even be omitted but I don't think it's documented |
| 20:38:26 | Araq | I think it is |
| 20:39:41 | EXetoC | yes "var myInt16 = 5i16" |
| 20:40:05 | EXetoC | the exception being hex literals |
| 20:42:03 | Araq | that's because 'f' is ambiguous in a hex literal |
| 20:43:32 | Araq | ugh wow glfw.nim does some uncommon 'static' things |
| 20:43:42 | Araq | no wonder my vm fails for that |
| 20:44:44 | EXetoC | yeah. I thought it worked but then I realized that |
| 20:44:54 | EXetoC | ok I can't remember. will have a look |
| 20:45:06 | Araq | no, no |
| 20:45:12 | Araq | I need to fix the bug |
| 20:45:48 | EXetoC | just curious |
| 20:46:07 | Araq | proc `monitorCb=`*(cb: TMonitorCb) = |
| 20:46:08 | Araq | monitorCb = cb |
| 20:46:12 | Araq | how can that work? |
| 20:47:32 | EXetoC | there's a corresponding var. it has worked before |
| 20:47:45 | EXetoC | the compiler is often clever in cases like that |
| 20:48:22 | Araq | no, it can't work |
| 20:48:44 | Araq | it will not produce an endless recursion |
| 20:48:54 | Araq | but I don't think it's ever invoked either |
| 20:49:23 | Araq | proc `title=`*(o: PWnd, val: string) = |
| 20:49:24 | Araq | wrapper.setWindowTitle(o.handle, val) # this makes sense |
| 20:49:42 | * | Varriount joined #nimrod |
| 20:49:47 | Araq | see the difference? |
| 20:50:09 | EXetoC | apparently it's not in the events example. I'll fix that |
| 20:51:01 | Araq | just for the record glfw does compile on master, right? |
| 20:51:19 | Araq | or at least there was a version which did compile it? |
| 20:52:23 | * | BitPuffin quit (Ping timeout: 272 seconds) |
| 20:52:56 | * | jbe_ joined #nimrod |
| 20:53:30 | EXetoC | yes. I think BitPuffin got it to work not long ago |
| 20:53:45 | Araq | hi jbe_ are you the guy who once wrote a couple of benchmarks? |
| 20:54:12 | * | zahary joined #nimrod |
| 20:55:12 | EXetoC | I don't know if it matters, but it's fixed now |
| 20:55:33 | Araq | no ... I didn't push my fix yet |
| 20:57:33 | EXetoC | I meant the recursion |
| 20:58:04 | Araq | there never was a recursion your unary 'op=' simply is never invoked |
| 21:02:16 | Araq | zahary: your destructor creation is awful :P perhaps we can adapt semstmts.semForFields for this |
| 21:02:19 | EXetoC | ok only in theory then |
| 21:02:49 | Araq | and of course the assignment operator needs the same mechanism |
| 21:04:14 | * | zahary quit (Quit: Leaving.) |
| 21:04:42 | Araq | that's what happens when you're not friendly. people leave. |
| 21:05:11 | Varriount | :( |
| 21:05:46 | Araq | Varriount: lol, zahary has been here since forever |
| 21:05:55 | Araq | no worries |
| 21:23:45 | * | BitPuffin joined #nimrod |
| 21:27:07 | * | aftersha_ joined #nimrod |
| 21:27:10 | EXetoC | I just made a feature request, and yes I remember that you said it would be difficult to implement |
| 21:31:15 | * | ics joined #nimrod |
| 21:40:24 | Araq | thinking about it, it's actually easy to implement :P |
| 21:40:32 | Araq | and I might do it |
| 21:44:13 | Araq | damn it's a ~3 lines of code patch to the compiler |
| 21:55:30 | Varriount | What's the feature? |
| 22:00:14 | EXetoC | oic |
| 22:01:59 | EXetoC | Varriount: let x = if true: 0 elif true: 0 else: raise newException(E_Base, "") |
| 22:04:01 | * | Demos quit (Read error: Connection reset by peer) |
| 22:04:41 | NimBot | Araq/Nimrod devel 2cb119b Araq [+0 ±2 -0]: fixes #838 |
| 22:04:41 | NimBot | Araq/Nimrod devel 928465c Araq [+2 ±3 -0]: Merge branch 'devel' of https://github.com/Araq/Nimrod into devel |
| 22:06:26 | EXetoC | or that? |
| 22:07:16 | Varriount | EXetoC: Eew. Why not use normal if/elif statements? |
| 22:09:11 | Araq | Varriount: the expr/stmt unification is one of the best features of nimrod :P |
| 22:09:51 | Varriount | Araq: Tell that to my aching eyeballs. |
| 22:09:52 | EXetoC | very useful indeed |
| 22:09:57 | EXetoC | ? |
| 22:10:18 | Varriount | I don't like it when all those logical conditions are bunched together on one line. |
| 22:10:31 | EXetoC | that's just a really short example |
| 22:10:33 | Araq | oh you don't have to do that |
| 22:14:38 | Araq | hmm the baby is crying ... but is it hungry? |
| 22:15:56 | Araq | hmm it is sucking on the pacifier ... |
| 22:16:03 | * | Araq wonders what that means |
| 22:16:25 | Varriount | Araq: Either it's teething, or hungry, or bored. |
| 22:18:14 | Araq | lol |
| 22:22:40 | * | brson joined #nimrod |
| 22:34:15 | Araq | it was a drwaing-pin in her bed ... |
| 22:37:59 | * | [2]Endy quit (Ping timeout: 240 seconds) |
| 22:42:08 | * | brson_ joined #nimrod |
| 22:42:51 | OrionPK | do babbies get bored? |
| 22:43:51 | * | brson_ quit (Client Quit) |
| 22:44:06 | * | brson_ joined #nimrod |
| 22:45:25 | * | brson quit (Ping timeout: 248 seconds) |
| 22:47:06 | discoloda | OrionPK: as a father of 3 boys, yes i do believe they do |
| 22:47:14 | OrionPK | :) |
| 22:47:21 | OrionPK | damn you're busy |
| 22:47:46 | * | radsoc joined #nimrod |
| 22:48:29 | discoloda | 3.5yo, 2.5yo and 2mo. indeed |
| 22:49:20 | OrionPK | im just gonna leave this here http://upload.wikimedia.org/wikipedia/commons/3/3f/Trojan_her_pleasure.jpg |
| 22:49:36 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 22:49:41 | Varriount | -_- |
| 22:49:57 | discoloda | lol |
| 22:50:33 | Varriount | I'm the oldest of 5 siblings. My youngest brother is 5 years old. I've been changing daipers for a little less than half my life. |
| 22:50:50 | Varriount | *diapers |
| 22:51:01 | * | zahary joined #nimrod |
| 22:51:13 | Varriount | Hey zahary |
| 22:51:27 | zahary | hi |
| 22:53:01 | OrionPK | ugh |
| 22:53:08 | * | OrionPK is not a fan of children/babies |
| 22:53:54 | discoloda | im the oldest of 10, never changed a diaper until my own kids :D |
| 22:53:59 | OrionPK | holy balls |
| 22:54:07 | OrionPK | catholic? |
| 22:54:30 | discoloda | Mormon parents, i cant stand churches |
| 22:54:37 | OrionPK | ahh |
| 22:55:05 | OrionPK | where are u from? mountain time somewhere? |
| 22:55:19 | discoloda | central california |
| 22:55:51 | OrionPK | i wish i lived in california |
| 22:55:57 | * | psquid joined #nimrod |
| 22:56:06 | OrionPK | or just the west coast anywhere |
| 22:57:26 | discoloda | yeah, i would like to move to washington or oregon |
| 22:58:18 | OrionPK | ive never been to oregon, but i hear good things |
| 22:58:39 | OrionPK | i like seattle and san fran a lot |
| 22:59:36 | * | gsingh93_ is now known as gsingh93 |
| 22:59:43 | Varriount | Hi gsingh93 |
| 22:59:47 | Varriount | Hi psquid |
| 23:00:01 | psquid | 'lo |
| 23:00:32 | * | radsoc quit (Quit: Quitte) |
| 23:01:30 | Araq | zahary: got the memo? |
| 23:02:59 | zahary | which memo? |
| 23:05:25 | * | jbe_ quit (Ping timeout: 245 seconds) |
| 23:05:36 | Araq | about the messy destructor construction |
| 23:06:30 | zahary | nope |
| 23:06:44 | zahary | let me look at the logs |
| 23:07:30 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 23:08:12 | zahary | my creation is awful? how dare you! |
| 23:08:12 | zahary | seriously tho, as far as I remember the code, it was just a couple of simple for loops, what's so bad about it? |
| 23:08:31 | Araq | it's wrong |
| 23:08:41 | Araq | look at my latest patch to it |
| 23:09:01 | zahary | there is a posted bug that I haven't looked at yet. is that what you are referring to? |
| 23:09:23 | Araq | it crashed compiling nimbuild |
| 23:09:31 | Araq | I fixed the crash but not the bug |
| 23:09:49 | Araq | and TThread[X] should trigger it, I think |
| 23:10:14 | Araq | you don't deal with nkRecList recursively properly |
| 23:10:40 | zahary | which one is the patch? can't find it in the recent commits |
| 23:13:47 | zahary | this analyzingDestructor marker is supposed to help with recursive types |
| 23:15:36 | Araq | https://github.com/Araq/Nimrod/commit/f2e6ceaee6a29192e05fcb8f2e0d2699f9226949 |
| 23:21:53 | Araq | also GCC seems to support __get_frame_address which might help to get the dreaded stack bottom right |
| 23:24:17 | * | darkf joined #nimrod |
| 23:24:33 | Varriount | Hi darkf |
| 23:24:39 | Varriount | !lastseen darkf |
| 23:26:40 | zahary | so you are saying that some types have structures like case X: of Y: case Z: … ; Alright, makes me wonder why this haven't been noticed until now. |
| 23:27:31 | zahary | I thought I've done something more substantial to earn the awful badge :P |
| 23:28:26 | Araq | well I wanted to fix it but then lost my motivation so it must be awful :P |
| 23:29:31 | Araq | also TMaybe[void] or similar produces a regression where 'void' ends up in the marker generation phase |
| 23:29:48 | Araq | looked at that too and it wasn't immediately obvious how to fix it |
| 23:30:07 | Araq | and that's a regression so prio is super duper high |
| 23:30:46 | zahary | I've noticed this one. actually, it was me who allowed void to appear in type fields. I don't know if it used to handle this particular case correctly |
| 23:31:11 | Araq | some critbittree test case used to work |
| 23:31:28 | Araq | with 'void', so it's definitely a regression |
| 23:31:41 | zahary | as long as we are complaining, do tstringinterp work for you? |
| 23:31:52 | zahary | It causes my computer to run out of memory when I try to compile it |
| 23:32:28 | Araq | is that in macros/ now? |
| 23:32:45 | zahary | yes |
| 23:33:31 | Araq | fails for me immediately with "intVal not accessible" |
| 23:33:48 | Araq | but good point, will fix it |
| 23:33:51 | zahary | I've tested it only on a mac |
| 23:35:38 | Varriount | Araq or zahary: Can you explain what all the % do in this snippet? -> https://gist.github.com/Varriount/8625520 |
| 23:36:25 | Araq | Varriount: they construct JSON data |
| 23:36:42 | Araq | we should make % a macro and then that's not necessary anymore |
| 23:36:50 | Araq | but we didn't |
| 23:37:18 | Varriount | How hard would it be to turn it into a macro? |
| 23:38:08 | Araq | not hard if you watched my talk :P |
| 23:38:20 | Araq | or read the DrDobbs article |
| 23:42:53 | Araq | hmm capturing a newSeq'ed argument is evil ... |
| 23:43:02 | NimBot | Araq/Nimrod devel 6ee5902 Zahary Karadjov [+0 ±6 -0]: support for parametric user-defined type classes |
| 23:43:02 | NimBot | Araq/Nimrod devel 0348692 Zahary Karadjov [+0 ±11 -0]: implements #766;... 4 more lines |
| 23:43:02 | NimBot | Araq/Nimrod devel 7b3b9ed Zahary Karadjov [+0 ±3 -0]: the `is` operator now uses exactly the same algorithm as proc signature matching |
| 23:43:02 | NimBot | Araq/Nimrod devel d5c0235 Zahary Karadjov [+18 ±27 -15]: Merge branch 'devel' of https://www.github.com/Araq/Nimrod into devel |
| 23:44:07 | Varriount | par·a·met·ric ˌparəˈmetrik |
| 23:44:07 | Varriount | adjective |
| 23:44:07 | Varriount | of, relating to, or expressed in terms of a parameter or parameters. |
| 23:44:21 | Araq | so zahary ... any release date for 0.9.4 ? |
| 23:45:27 | Araq | dom96: same question |
| 23:45:53 | zahary | I plan to fix all bug that I've assigned to myself in guthub |
| 23:49:45 | dom96 | Araq: I doubt getting newasync into 0.9.4 will be possible. |
| 23:52:42 | Varriount | dom96: Having trouble with iocp? |
| 23:53:02 | dom96 | Varriount: yep |
| 23:53:14 | Varriount | I don't supposed I could have a look? |
| 23:53:33 | * | zahary quit (Quit: Leaving.) |
| 23:53:36 | Araq | dom96: that's fine |
| 23:55:44 | dom96 | Varriount: https://gist.github.com/dom96/74a81eb2001f1f9265c8 |
| 23:56:25 | dom96 | Varriount: Try to figure out why it segfaults when you uncomment L166-168 |
| 23:56:52 | Varriount | dom96: Have you looked at windows error logs? |
| 23:57:07 | dom96 | Varriount: nope |
| 23:58:11 | Varriount | I would use the event logs utility, process monitor (from sysinternals) and look somewhere in your local appdata directory for the crash data logs. |
| 23:58:53 | Varriount | dom96: Does this code run on it's own? Can I download it and run it? |
| 23:59:05 | dom96 | Varriount: yes, you can. |
| 23:59:19 | dom96 | (I hope) |
| 23:59:32 | Varriount | :3 |
| 23:59:45 | dom96 | I can't remember if I changed anything in windows.nim/winlean.nim |
| 23:59:58 | dom96 | But if I did it's minor so you should be able to figure it out. |
