00:36:31 | * | OrionPK quit (Read error: Connection reset by peer) |
01:00:41 | * | rleisti quit (Remote host closed the connection) |
01:06:20 | * | Demos quit (Quit: Lost terminal) |
01:07:40 | Skrylar | fowl, Varriount: what do you think of a finite state machine macro? |
01:08:01 | Skrylar | i was thinking about writing one since that SMC tool is neat for netcode |
01:10:28 | fowl | that site looked complicated and was missing half the code in the demos |
01:21:49 | Skrylar | what it mostly does is you give it a list of states and a list of functions, and it codegens it for you |
01:22:24 | Skrylar | i tested it out with networking once and it was neat, because you can put network messages in it and it will generate runtime errors for you if someone tries to send a message in the wrong state |
01:30:15 | * | Mordecai joined #nimrod |
01:30:37 | * | Mordecai is now known as Guest46912 |
01:30:54 | * | psquid quit (Ping timeout: 255 seconds) |
01:43:48 | * | Demos joined #nimrod |
01:54:16 | * | q66 quit (Quit: Leaving) |
02:06:56 | Varriount | Skrylar: What kind of finite state machine? |
02:07:00 | Varriount | Like a parser? |
02:08:30 | Skrylar | nah it just makes generic state machines |
02:08:37 | Skrylar | states events and transitions |
02:16:04 | Varriount | Skrylar: Sounds neat. |
02:26:36 | * | noam quit (Read error: Connection reset by peer) |
02:27:01 | * | noam joined #nimrod |
03:05:09 | Demos | BitPuffin: ping |
03:33:06 | * | DAddYE joined #nimrod |
04:18:20 | Varriount | Demos: Ping |
04:18:31 | Demos | Varriount: pong |
04:18:44 | Varriount | Demos: http://forum.nimrod-lang.org/t/409/1#2236 |
04:19:00 | Varriount | Consider that an.. RFC, of sorts. |
04:20:24 | Skrylar | that avatar is the minecraft moon |
04:20:34 | Varriount | Skrylar: Yes. Yes it is. |
04:21:15 | Varriount | I haven't bothered to change it to the stylized moon I made in GIMP and Photoshop. |
04:26:00 | Varriount | Demos: Sent a reply |
04:27:03 | Demos | I mean sure. I think the docs should note that atime is likely to be incorrect |
04:31:55 | Varriount | Demos: So, what made you say that access time wasn't correct on most systems? On what systems is it incorrect? |
04:32:44 | Varriount | Skrylar: Do you have any suggestions? |
04:33:08 | * | BitPuffin quit (Ping timeout: 255 seconds) |
04:33:44 | Varriount | (Also, the forum really needs a 'quote' button. |
04:34:13 | Demos | linux 2.6+ usually does not report it. Consider that to report atime correctly requires the system to /write/ to a file every time that file is read... not exactly ideal |
04:34:30 | Demos | check your fstab, you are probably mounting stuff with the relatime option |
04:34:42 | Demos | or the noatime option |
04:36:46 | Varriount | I think windows just uses a 1 hour resolution. |
04:39:51 | * | brson joined #nimrod |
04:44:06 | * | ics joined #nimrod |
04:45:58 | * | BitPuffin joined #nimrod |
04:47:49 | Demos | whyyyy is chocolatey so slow! Someone should totally clone that in nimrod |
04:48:14 | fowl | what is it |
04:49:11 | Demos | http://chocolatey.org/ |
04:50:46 | renesac | 98,1% PowerShell, 1,9% shell |
04:52:41 | Demos | yeah the speed issues are probably just powershell being powershell |
04:55:07 | * | DAddYE quit (Remote host closed the connection) |
04:55:34 | * | DAddYE joined #nimrod |
04:56:01 | Varriount | Powershell is.. interesting. |
04:56:24 | Varriount | I just wish there were good tutorials for it. |
04:56:33 | Demos | yeah it is. I like the driver for something that sort of resembles consistency |
04:58:11 | Varriount | Demos: At the bottom of this page - http://msdn.microsoft.com/en-us/library/windows/desktop/aa364953(v=vs.85).aspx - what does "redistributable" mean? |
04:58:51 | Varriount | Is it like, for things that want to support windows xp as well? |
05:00:06 | Demos | I have no idea, but the function should be in the dll listed, which comes with windows. So the redistributable is at most just XP support and the headers |
05:00:31 | * | DAddYE quit (Ping timeout: 264 seconds) |
05:01:23 | Varriount | Skrylar: Changed my gravatar. |
05:01:49 | fowl | ew powershell |
05:02:06 | fowl | quickest way to kill my boner is to mention powershell |
05:02:08 | fowl | thanks guys |
05:03:25 | * | Varriount is now known as PowerShell |
05:03:36 | fowl | great-_- |
05:03:42 | * | PowerShell whispers in fowl's ear, haunting his dreams. |
05:04:00 | PowerShell | :D |
05:04:07 | * | PowerShell is now known as Varriount |
05:06:21 | * | BitPuffin quit (Ping timeout: 255 seconds) |
05:13:33 | * | DAddYE joined #nimrod |
05:17:46 | * | [1]Endy joined #nimrod |
05:24:44 | fowl | he makes a good point: http://forum.nimrod-lang.org/t/410 |
05:25:54 | fowl | what does EFloatDivByZero exist for |
05:38:49 | * | BitPuffin joined #nimrod |
05:57:41 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
06:03:31 | * | BitPuffin quit (Ping timeout: 264 seconds) |
06:05:30 | * | Demos quit (Read error: Connection reset by peer) |
06:08:55 | * | brson quit (Ping timeout: 264 seconds) |
06:20:28 | * | brson joined #nimrod |
06:39:27 | * | DAddYE quit (Remote host closed the connection) |
06:39:53 | * | DAddYE joined #nimrod |
06:44:33 | * | DAddYE quit (Ping timeout: 255 seconds) |
06:56:22 | * | brson quit (Ping timeout: 252 seconds) |
06:58:15 | * | brson joined #nimrod |
07:11:36 | * | DAddYE joined #nimrod |
07:45:28 | * | [2]Endy joined #nimrod |
07:49:27 | * | [1]Endy quit (Ping timeout: 265 seconds) |
07:56:45 | * | [1]Endy joined #nimrod |
07:59:48 | * | [2]Endy quit (Ping timeout: 252 seconds) |
07:59:57 | * | [2]Endy joined #nimrod |
08:03:18 | * | [1]Endy quit (Ping timeout: 255 seconds) |
08:09:36 | * | brson quit (Ping timeout: 255 seconds) |
08:10:21 | * | [1]Endy joined #nimrod |
08:10:35 | * | shodan45 quit (Quit: Konversation terminated!) |
08:11:28 | * | brson joined #nimrod |
08:13:38 | * | [2]Endy quit (Ping timeout: 265 seconds) |
08:14:29 | * | BitPuffin joined #nimrod |
08:15:43 | * | [2]Endy joined #nimrod |
08:18:38 | * | DAddYE quit () |
08:18:57 | * | [1]Endy quit (Ping timeout: 255 seconds) |
08:19:36 | * | BitPuffin quit (Ping timeout: 240 seconds) |
08:21:02 | * | [1]Endy joined #nimrod |
08:23:59 | * | [2]Endy quit (Ping timeout: 255 seconds) |
08:32:02 | * | brson quit (Read error: Operation timed out) |
08:41:33 | * | [2]Endy joined #nimrod |
08:44:08 | * | [1]Endy quit (Ping timeout: 240 seconds) |
08:46:38 | * | Gr33n3gg joined #nimrod |
08:57:39 | * | EXetoC joined #nimrod |
09:02:09 | * | [1]Endy joined #nimrod |
09:05:36 | * | [2]Endy quit (Ping timeout: 240 seconds) |
09:22:37 | * | [2]Endy joined #nimrod |
09:25:08 | * | [1]Endy quit (Ping timeout: 240 seconds) |
09:29:19 | * | Matthias247 joined #nimrod |
09:43:07 | * | [1]Endy joined #nimrod |
09:45:53 | * | [2]Endy quit (Ping timeout: 255 seconds) |
10:03:40 | * | [2]Endy joined #nimrod |
10:03:53 | dom96 | 'morning |
10:06:15 | Gr33n3gg | oh god, finally |
10:06:34 | Gr33n3gg | apparently I didn't read hard enough, & is used to concatenate strings |
10:06:35 | * | [1]Endy quit (Ping timeout: 255 seconds) |
10:06:47 | dom96 | hey Gr33n3gg |
10:06:51 | Gr33n3gg | mornin |
10:07:17 | EXetoC | Gr33n3gg: 'add' is more common I think |
10:07:22 | EXetoC | and it's pretty short without the parens |
10:07:30 | Gr33n3gg | ah, neat |
10:08:49 | EXetoC | I was thinking of &= |
10:09:52 | Araq | hi Gr33n3gg welcome |
10:10:21 | Gr33n3gg | mornin Araq |
10:10:22 | Araq | dom96: I think it's a subtle codegen bug; the GC has nothing to do with it |
10:10:35 | EXetoC | so what about that write interface? if &/&= gets used for that, do we need add? |
10:11:11 | Araq | yes. we need 'add'. I'm not going to change > 100K LOC that use 'add'. |
10:11:16 | dom96 | Araq: Who introduced this long error? "Error: A nested proc can have generic parameters only when it is used as an operand to another routine and the types of the generic paramers can be infered from the expected signature." |
10:11:28 | dom96 | zahary I guess? |
10:12:07 | Araq | yeah |
10:12:10 | EXetoC | yeah ok backwards compatibility |
10:12:39 | dom96 | He broke my closure macro |
10:13:43 | Araq | I noticed but can't fix it easily |
10:13:47 | EXetoC | just introduce a 2-year deprecation path :p |
10:16:57 | dom96 | Araq: Are these two ASTs the same (except for the param names?) https://gist.github.com/dom96/08f70eee3d9a1bb2576f |
10:17:33 | Araq | dom96: yes |
10:17:44 | dom96 | Then I don't get what the problem is. |
10:17:50 | Araq | EXetoC: come on, a single alias won't kill us |
10:18:12 | dom96 | My macro generates the correct AST. |
10:18:13 | EXetoC | no? ok nevermind then |
10:20:21 | Araq | dom96: well it surely is a regression |
10:24:12 | dom96 | hard to fix? |
10:24:15 | * | [1]Endy joined #nimrod |
10:24:42 | Araq | pointless to fix, it's likely a 1-liner for zahary |
10:25:03 | dom96 | But he ain't here is he? |
10:25:25 | Araq | true. we could check his diffs to see how he broke it |
10:27:02 | * | [2]Endy quit (Ping timeout: 265 seconds) |
10:28:56 | Gr33n3gg | oh wow, I was going to ask what you guys use for syntax highlighting but there's a plugin for nimrod for sublime text |
10:30:27 | Matthias247 | there are 2, but you should use the NimLime plugin |
10:31:02 | Gr33n3gg | ah, okay |
10:31:49 | dom96 | Araq: https://github.com/Araq/Nimrod/commit/40d94436fdbe7ea5c5b508c6916064f803b79155 |
10:34:23 | * | [2]Endy joined #nimrod |
10:36:27 | Araq | dom96: well tbadgenericlambda should fail, tgenericlambda should not |
10:36:40 | Araq | what's the current situation? both fail? |
10:36:50 | * | BitPuffin joined #nimrod |
10:37:28 | * | [1]Endy quit (Ping timeout: 252 seconds) |
10:39:48 | dom96 | tbadgenericlambda fails |
10:39:52 | dom96 | tgenericlambda does not |
10:40:15 | Araq | but you get the errGenericLambdaNotAllowed message, right? |
10:40:21 | dom96 | I dunno |
10:40:26 | dom96 | I just looked at the gist |
10:40:34 | * | IrvMG joined #nimrod |
10:40:40 | dom96 | I think the test spec is wrong? |
10:40:50 | dom96 | tests/generics/C/tbadgenericlambda.nim (reNimrodcCrash) |
10:41:05 | IrvMG | Hello :) |
10:41:10 | dom96 | hey IrvMG |
10:41:56 | * | BitPuffin quit (Ping timeout: 240 seconds) |
10:42:11 | Araq | hi IrvMG welcome |
10:42:31 | Araq | dom96: can we focus on the async stuff instead please? |
10:43:39 | dom96 | fine |
10:43:52 | Araq | at /home/andreas/projects/nimrod/nimcache/stdlib_asyncdispatch.c:583 |
10:43:54 | Araq | 583 (*future).Cb.ClEnv = cb.ClEnv; |
10:44:04 | Araq | print *future |
10:44:06 | Araq | Cannot access memory at address 0x0 |
10:45:41 | Araq | coming from newconnection |
10:45:45 | * | BitPuffin joined #nimrod |
10:45:57 | Araq | await client.socket.connect(url.hostname, port) |
10:46:18 | Araq | so I guess 'await' expands to 'future', not 'fut' |
10:46:26 | * | io2 joined #nimrod |
10:48:12 | dom96 | yes |
10:48:16 | Araq | and future is nil ... |
10:48:36 | dom96 | Like I said, the macro outputs the generated code |
10:49:10 | * | Matthias247 quit (Read error: Connection reset by peer) |
10:49:27 | dom96 | it should have gotten initialised. |
10:49:39 | dom96 | so is your lambda lifting wrong? |
10:50:00 | Araq | I think so, but how come it works the first time then? |
10:52:54 | dom96 | no idea |
10:54:28 | Araq | hmm you re-use 'client' |
10:54:31 | * | BitPuffin quit (Ping timeout: 264 seconds) |
10:54:38 | Araq | lets see if it works when I don't do that |
10:54:51 | * | [1]Endy joined #nimrod |
10:58:08 | * | [2]Endy quit (Ping timeout: 265 seconds) |
10:59:24 | * | BitPuffin joined #nimrod |
11:04:16 | * | BitPuffin quit (Ping timeout: 240 seconds) |
11:05:43 | EXetoC | has anyone used the IRC module recently? messages sent to one of the channels never got through, and I might've had trouble connecting |
11:07:34 | EXetoC | I'll try again |
11:07:56 | * | bot28423 joined #nimrod |
11:08:03 | EXetoC | bot28423: test |
11:08:42 | * | bot28423 quit (Read error: Connection reset by peer) |
11:09:16 | EXetoC | should I have received anything with this code: "of evMsg: echo event.raw"? |
11:11:11 | dom96 | yes |
11:11:17 | * | bot28423 joined #nimrod |
11:11:23 | EXetoC | bot28423: test |
11:11:37 | * | bot28423 quit (Read error: Connection reset by peer) |
11:11:55 | dom96 | you should be receiving a lot of messages |
11:12:06 | EXetoC | parseMessage isn't being called after the connection phase |
11:12:10 | Araq | maybe that's related to Varriount's problems with ftp? |
11:12:39 | dom96 | EXetoC: what's your code? |
11:14:09 | IrvMG | to install in /usr/bin used koch install /usr/bin? |
11:14:11 | * | [2]Endy joined #nimrod |
11:14:51 | EXetoC | dom96: I just uncommented line 495 |
11:15:14 | EXetoC | will gist it |
11:15:51 | Araq | IrvMG: dunno, I think the install.sh script works better |
11:16:47 | EXetoC | dom96: actually, just do this: "of EvMsg: echo(repr(event))" and then nothing else in that block |
11:17:18 | * | [1]Endy quit (Ping timeout: 265 seconds) |
11:18:24 | dom96 | works for me |
11:18:30 | * | NimrodBot joined #nimrod |
11:18:40 | EXetoC | NimrodBot: you sure? can you see this? |
11:18:45 | dom96 | hrm |
11:18:50 | dom96 | interesting |
11:19:00 | dom96 | you're right |
11:19:04 | Gr33n3gg | also, there is no doc for parseopt2 on the website, considering cmdLineRest is deprecated |
11:19:33 | * | [1]Endy joined #nimrod |
11:19:42 | EXetoC | dom96: "if socks.len() != 0 and ret != 0:" is always false after the connection phase |
11:20:11 | dom96 | Ahh. Nice. |
11:20:20 | Araq | zielmicha_beta: Gr33n3gg complains about your parseopt2 ... :P |
11:20:28 | Gr33n3gg | :D |
11:20:32 | dom96 | Changing the behaviour of select was such a great idea... |
11:20:46 | EXetoC | why when how |
11:20:55 | dom96 | EXetoC: Change it to socks.len == 0 |
11:21:07 | dom96 | check if it works |
11:21:08 | dom96 | and make a PR |
11:21:41 | dom96 | Also how was this missed? |
11:21:48 | EXetoC | ok |
11:21:52 | * | IrvMG left #nimrod (#nimrod) |
11:21:59 | dom96 | Could you please grep for select and ensure that everything was changed in the stdlib? |
11:22:16 | * | [2]Endy quit (Ping timeout: 240 seconds) |
11:22:32 | * | [2]Endy joined #nimrod |
11:22:51 | EXetoC | dom96: I get no output then |
11:23:13 | dom96 | oh er. |
11:23:34 | dom96 | Bad guess. |
11:23:42 | dom96 | Why is that false then after some time? |
11:25:03 | * | [1]Endy quit (Ping timeout: 268 seconds) |
11:25:06 | * | NimrodBot quit (Read error: Connection reset by peer) |
11:25:57 | * | [1]Endy joined #nimrod |
11:28:36 | * | [2]Endy quit (Ping timeout: 240 seconds) |
11:30:01 | dom96 | ahh, so buffering is the problem. |
11:30:13 | * | BitPuffin joined #nimrod |
11:31:30 | dom96 | hah |
11:34:56 | * | BitPuffin quit (Ping timeout: 240 seconds) |
11:35:02 | * | [2]Endy joined #nimrod |
11:35:10 | EXetoC | how it was missed? apparently no one uses it :p |
11:35:41 | Araq | we do use it, but we don't constantly re-compile what works ... |
11:35:48 | EXetoC | ok maybe someone with an outdated version |
11:35:53 | EXetoC | right |
11:36:07 | * | [3]Endy joined #nimrod |
11:37:25 | dom96 | It would have been nice if the docs were updated to reflect the change to select. |
11:37:26 | dom96 | Seriously. |
11:37:45 | Araq | yeah I missed that, my bad |
11:37:56 | Araq | should have caught it in the review ... |
11:38:20 | * | [1]Endy quit (Ping timeout: 252 seconds) |
11:38:21 | Araq | nice to see that others do an even shittier job at everything :P |
11:39:03 | dom96 | I'm still 80% certain that this bug is because of this breaking change. |
11:39:08 | dom96 | Which I advised against. |
11:39:32 | * | [2]Endy quit (Ping timeout: 265 seconds) |
11:39:35 | dom96 | But why listen to me... |
11:39:51 | Araq | orionpk's points were more convincing |
11:40:00 | Araq | I did listen to you |
11:40:16 | * | [3]Endy quit (Ping timeout: 240 seconds) |
11:40:41 | Araq | but decided against your point. big difference. |
11:42:48 | * | [1]Endy joined #nimrod |
11:43:45 | EXetoC | so were there any redundancies associated with pairs like these: UnaryPlusI/UnaryPlusI64? I'm once again trying to shorten system.nim |
11:44:28 | EXetoC | I can't think of anything to do really, so I'm doing that |
11:44:49 | Araq | ok, that's super low priority |
11:45:01 | Araq | I'm sure I have more pressing stuff for you |
11:45:09 | * | Araq checks his todo |
11:45:56 | Araq | new VM: - implement overflow checking; something for you? |
11:47:18 | EXetoC | arithmetic overlows? |
11:47:28 | Araq | yeah |
11:47:32 | dom96 | awesome. |
11:47:38 | dom96 | Looks like my stack is being corrupted. |
11:48:44 | dom96 | all it takes is the removal of a single line |
11:48:54 | dom96 | lovely. |
11:49:57 | Araq | dom96: client.request hangs |
11:50:11 | Araq | var resp1 = await client.request("http://picheta.me/aboutme.html") |
11:50:12 | Araq | echo("Got response: ", resp1.status) # --> 404 |
11:50:51 | dom96 | it hangs but gives you a 404? |
11:50:51 | dom96 | huh? |
11:51:13 | Araq | yeah |
11:51:28 | dom96 | elaborate |
11:51:34 | Araq | thought it's because I don't call 'body' but I just added that and it still hangs |
11:53:00 | dom96 | if it reaches the echo then it completed? |
11:54:50 | * | q66 joined #nimrod |
11:55:10 | EXetoC | Araq: Do we have any relevant code outside the VM? I don't know much of anything unfortunately, but there's always google |
11:55:59 | Araq | EXetoC: semfold has an implementation with overflow checking iirc |
11:59:09 | Araq | no ... I was mistaken |
11:59:20 | Araq | cool this means the old evals.nim has the same bug, yay |
11:59:27 | Araq | new vm doesn't make it worse :P |
12:00:04 | Araq | anyway there is an implementation in lib/system/arithm.nim |
12:07:54 | Araq | bbl |
12:28:56 | EXetoC | "var pc = start" hm, pc.. |
12:40:02 | EXetoC | I think I know what to modify in the VM, but I don't know what to do about these: "proc negInt64(a: int64): int64 {.compilerProc, inline.} =" |
12:44:41 | EXetoC | aren't they useful for users too? so do I just split it up into foo/fooOverflows and then export? |
12:44:56 | EXetoC | I'll check back for an answer in a couple of hours |
12:45:31 | * | vendethiel quit (Ping timeout: 264 seconds) |
12:59:24 | * | darkf quit (Quit: Leaving) |
12:59:35 | * | vendethiel joined #nimrod |
13:31:48 | * | BitPuffin joined #nimrod |
14:26:26 | * | psquid joined #nimrod |
14:27:15 | * | Guest46912 quit (Ping timeout: 265 seconds) |
14:28:07 | * | BitPuffin quit (Ping timeout: 264 seconds) |
14:30:43 | * | BitPuffin joined #nimrod |
14:50:14 | * | Demos joined #nimrod |
15:00:48 | * | Mordecai joined #nimrod |
15:01:10 | * | Mordecai is now known as Guest67017 |
15:01:16 | * | psquid quit (Ping timeout: 240 seconds) |
15:01:24 | * | Guest67017 is now known as psquid |
15:18:33 | Araq | EXetoC: no, just copy, paste modify for the VM for now |
15:25:28 | Araq | dom96: it works better when I split the downloads into 2 async procs |
15:25:57 | Araq | but it hangs afterwards in selectors.select |
15:26:21 | dom96 | maybe there is a bug in selectors |
15:28:17 | Araq | argh |
15:28:25 | Araq | forget it I'm stupid |
15:28:37 | Araq | it calls runForever() at the end -.- |
15:32:05 | Araq | ok this works |
15:32:14 | Araq | good job |
15:32:36 | Araq | returns the 3rd request before the 2 has finished :-) |
15:32:46 | Araq | exactly as it should be, sweet |
15:42:32 | Araq | dom96: right? RIGHT!? |
15:43:04 | Araq | I wrote secondReq(); thirdReq() and thirdReq() is executed before secondReq() ... |
15:43:29 | dom96 | ehh what |
15:44:27 | dom96 | You can't have multiple requests running at the same time. |
15:44:40 | dom96 | You need multiple clients for that. |
15:44:53 | Araq | yeah each request got its own client |
15:45:46 | dom96 | well no. |
15:45:51 | dom96 | secondReq should be executed first |
15:46:00 | dom96 | It may not /finish/ first |
15:46:17 | dom96 | If you have an echo at the beginning of secondReq and thirdReq |
15:46:37 | dom96 | then you should see the message from secondReq first |
15:46:50 | dom96 | however, if it's after some 'await' |
15:47:02 | Araq | yeah that's it |
15:47:07 | dom96 | Then anything can happen |
15:48:38 | dom96 | In any case, multiple requests on the same client should work |
15:48:46 | dom96 | just not at the same time |
15:51:02 | Araq | ok, so this is the problem I think: |
15:51:24 | Araq | var future = client.request("http://picheta.me") |
15:51:25 | Araq | yield future |
15:51:27 | Araq | var resp = future.read |
15:51:28 | Araq | ... |
15:51:37 | Araq | var future = client.request("http://picheta.me/aboutme.html") |
15:51:39 | Araq | yield future |
15:51:40 | Araq | var resp1 = future.read |
15:51:59 | Araq | future is nil, so symbol look is screwed? |
15:52:02 | dom96 | the fact that it uses the same var name? |
15:52:06 | Araq | yes |
15:52:18 | dom96 | Yeah, that's possible. |
15:52:26 | Araq | gensym'ed these? |
15:52:41 | dom96 | everything should be gensym'd now |
15:52:47 | dom96 | with my latest commit |
15:55:49 | * | psquid quit (Quit: groceries) |
15:58:55 | Demos | BitPuffin: ping |
16:00:35 | Demos | also is anyone getting ambigous overloads between a user defined `$` and the generic one in system? |
16:00:49 | Demos | I think overload resolution may be more screwed up then I thought it was |
16:01:49 | Araq | all I know is that has new regressions |
16:01:53 | Araq | yay ... |
16:02:41 | Demos | my favorite ones are where it does stuff that depends on what generics (and regular procs) exist in your context. Gives this grand sense of reality falling apart around you |
16:03:30 | Araq | bug number? |
16:05:14 | Demos | 1051 and 1018 (1018 is fixed though) |
16:06:54 | Demos | I was also getting overload ambiguities between proc mult*(a: TMat4f, b: TMat4f): TMat4f and proc mult*(a: TMat4f, b: TVec4f): TVec4f. Which was kinda strange |
16:07:00 | Demos | and probably related |
16:08:43 | Araq | I'm so pissed off by these vector matrix clusterfucks you wouldn't believe it |
16:09:46 | * | nolan_d quit (Remote host closed the connection) |
16:09:54 | Araq | it's like everyone builds his own, using only unstable voodoo features and then complains nimrod is not stable |
16:10:26 | Araq | and what does it do anyway? it's a petty alias for 'array' for fuck's sake |
16:10:48 | Demos | well it does seem like a good way to find bugs in generics |
16:12:13 | Araq | sure, I'm not blaming you |
16:12:55 | Araq | but once these work, we will introcude .vector and .matrix pragmas to map structural types back to nominal types to support efficient opencl codegen ... |
16:13:47 | Demos | and I just want to point out that one of the first things people wrote with c++ templates was multidimensional array and matrix libraries :D. And it does suck if you are in C and you have to use functions named by a PRNG who could only generate 6 char strings |
16:15:05 | Demos | yeah, I think everyone's data layout is at least the same +/- a transpose |
16:15:37 | Araq | the hardware decided long ago for us how to store small vectors and matrixes |
16:15:54 | Araq | yet people still think it's "generic" |
16:16:44 | Araq | ok, go ahead and use your library with bignums. nobody does that for game programming and the math people usually have bigger matrixes than 3x3 or 4x4 |
16:20:30 | Demos | so we should all just write our own BLAS clone? |
16:21:05 | Araq | no, matrix and vector should be built-in for best interop |
16:21:53 | Araq | zahary argues for structural typing everywhere instead, I favor the nominal approach right from the 70ies |
16:24:30 | Araq | btw iirc the stdlib got vectors and matrixes long ago for exactly these reasons |
16:25:22 | * | Matthias247 joined #nimrod |
16:25:36 | Demos | I would not object to vector and matrix builtins, but at the same time our generic systems seems to be expressive enought to support them and it is a great way of finding bugs. As long as I don't have to pass 15 size params to each function |
16:50:45 | EXetoC | Araq: ./koch boot ... "lib/pure/strutils.nim(675, 10) Error: interpretation requires too many iterations" |
16:50:56 | EXetoC | compiler/commands.nim(34): const Usage = slurp"doc/basicopt.txt".replace("//", "") |
16:52:03 | * | nolan_d joined #nimrod |
16:53:40 | EXetoC | All I did was add an overflow check directly to the opcAddInt branch. I'll show you the code |
16:57:26 | Araq | but before your change it worked, right? |
16:57:54 | EXetoC | yes |
17:01:07 | * | [1]Endy quit (Ping timeout: 264 seconds) |
17:02:55 | EXetoC | Araq: any change causes this, so what do I do? https://gist.github.com/EXetoC/5d5031b9e3134ea7a0a1 |
17:04:21 | EXetoC | So I guess I'm missing some step of the process |
17:05:07 | Araq | edit vmdef.nim, MaxLoopIterations |
17:05:16 | Araq | set it to something higher |
17:05:36 | EXetoC | this includes just doing "regs[ra].intVal = 0", but ok I'll try that |
17:06:28 | EXetoC | 10_000_000 here we go |
17:06:53 | EXetoC | nope |
17:07:02 | Araq | er |
17:07:07 | Araq | your patch is wrong, lol |
17:07:24 | Araq | you need to add regs[rb] and regs[rc] |
17:07:34 | Araq | not add the indices rb, rc |
17:08:09 | Araq | with your patch 'opcAddInt' is broken and thus the compiler turns into an endless loop :P |
17:08:25 | Araq | the compiler runs 'replace' at compile-time |
17:08:33 | Araq | which does 'inc i' somewhere :P |
17:09:10 | Araq | keep in mind the compiler itself uses the VM for compile time evaluation |
17:09:25 | Araq | so bugs are exposed with 'koch boot' already |
17:09:50 | Araq | fyi 'pc' is a common abbrev for "program counter" |
17:10:08 | EXetoC | ok |
17:13:24 | EXetoC | oops "when false: ... elif false..." -.- Trying again |
17:13:53 | Araq | but you're editing the right thing |
17:14:17 | EXetoC | Araq: yes but I was basically commenting out everything. it does work now |
17:14:27 | EXetoC | (SUCCESS) |
17:14:44 | EXetoC | ok time to add some procs and cover the other ops |
17:16:00 | Araq | errConstantDivisionByZero # not quite :P |
17:16:02 | * | psquid joined #nimrod |
17:16:37 | EXetoC | I just copied something |
17:17:17 | EXetoC | the first instance that I found |
17:18:33 | EXetoC | errOverOrUnderflow |
17:19:24 | EXetoC | hm time for a second monitor maybe |
17:26:11 | EXetoC | Araq: "static: let x = int64.high" ... "vm.nim(183) putIntoNode Error: unhandled exception: intVal is not accessible [EInvalidField]" |
17:26:15 | renesac | does the '--os:standalone' disable the GC? |
17:27:15 | EXetoC | I'll check the type |
17:28:26 | Araq | EXetoC: that's likely another unrelated bug |
17:28:48 | Araq | put the 'x' into a proc so that it comes a local variable as a workaround |
17:29:30 | Araq | renesac: yes, iirc but use --gc:none to ensure |
17:31:06 | EXetoC | it works. time to turn it into a test |
17:37:24 | renesac | ok, i'm writing this answer on stack overflow: http://stackoverflow.com/questions/3557072/is-there-a-better-c/22747236#22747236 |
17:38:14 | renesac | there was already a mention of nimrod in another answer, but no details |
17:40:07 | renesac | should I mention the effect system plans to counter act the rust's safe pointers? |
17:45:10 | Araq | nah, but mention that we have "tagged" pointers in the works |
17:45:30 | Araq | that ensure you can't mix kernel level pointers with user level pointers |
17:47:18 | Demos | nobody seems to mention fortran either :D |
17:47:18 | * | q66 quit (Quit: Leaving) |
17:47:29 | Demos | it seems that fortran 2008 is actually a pretty good language |
17:47:39 | * | q66 joined #nimrod |
17:48:44 | Araq | quite possible, didn't look at it |
17:56:06 | * | Matthias247 quit (Quit: Matthias247) |
17:58:23 | * | q66 quit (Ping timeout: 252 seconds) |
17:59:43 | * | Matthias247 joined #nimrod |
18:00:42 | * | q66 joined #nimrod |
18:04:18 | Varriount | Bah, no-one but Demos has commented on my getFileInfo and FileInfo plans. |
18:05:10 | EXetoC | is there a proc that collects an exception that an expr throws? |
18:06:01 | EXetoC | nevermind |
18:07:17 | Araq | Varriount: lol should I comment? |
18:08:21 | Varriount | Araq: Yes, if nothing else, I would like some feedback on the questions I posted at the bottom |
18:15:35 | Araq | Varriount: ta-da |
18:19:19 | EXetoC | so how are failures reported for tests that rely on asserts? |
18:19:58 | Araq | asserts suck for testing |
18:20:04 | Araq | kind of |
18:20:24 | EXetoC | ok using the unittest module then or whatever |
18:20:41 | Demos | unittest has been telling me the incorrect value of late, so that is good |
18:20:42 | Araq | assert complexOp == simpleOp # now if we have a bug that affects both, the condition remains true and the bug is not detected |
18:21:21 | Araq | EXetoC: just look at what the other 600 tests do |
18:21:34 | Araq | it's not too hard to figure out |
18:22:21 | dom96 | That's not assert sucking, that's your usage of assert sucking. |
18:22:36 | dom96 | I don't see how the unit test module is any better here. |
18:23:32 | Araq | it is not |
18:23:48 | Araq | I'm talking about our 'discard' specifications in the tests |
18:24:18 | Araq | which encourages explicit 'output' listings |
18:24:29 | Araq | which mitigates this problem |
18:27:59 | EXetoC | how do I go through only the system test dir for example? |
18:28:33 | Araq | tests/testament/tester cat system |
18:28:46 | Araq | tests/testament/tester --print html |
18:29:45 | EXetoC | "env: wine: No such file or directory" :-) |
18:30:01 | EXetoC | I don't even.. |
18:36:40 | EXetoC | I'll just run everything and then rely on the caching mechanism |
18:37:07 | EXetoC | but I see several modules who uses assert but not "discard..." |
18:37:17 | EXetoC | *that |
18:48:05 | renesac | ok, added a mention to tagged pointers |
18:48:28 | Varriount | renesac: Fight the good fight! Huzzah! |
18:49:11 | * | [1]Endy joined #nimrod |
18:53:41 | * | foodoo joined #nimrod |
18:53:56 | Araq | hi foodoo wb |
18:56:11 | EXetoC | isn't it like saying that we shouldn't use the unittest module? which I think is pretty good because it collects the failed cases rather than just exiting on the first failure |
18:58:37 | EXetoC | the output specification gives you less information on failure, right? |
18:58:47 | reactormonk | EXetoC, araq doesn't want a brittle api between the tester and unittest :-/ |
18:59:13 | reactormonk | imo we should have unittest return non-zero on failure and tester should use the exit code... |
18:59:39 | Araq | unittest supports non-zero exit codes iirc |
19:00:32 | Araq | "brittle api" is a misnomer |
19:00:51 | EXetoC | it does, but you still need to specify 'output' for example |
19:01:07 | Araq | it's a full DSL that gets in my way when I debug the compiler |
19:02:17 | Araq | I have "test program + compiler" to debug |
19:02:17 | reactormonk | so you want to extract all the code out form the unittest DSL for one specific test? |
19:02:22 | foodoo | thanks for the wb Araq |
19:02:39 | EXetoC | people getting killed just because they support some opposing sports team.. people sure are morons |
19:02:43 | Araq | with unittest i have "test program + unittest layer + compiler" to debug |
19:02:54 | Araq | why is that so hard to understand? |
19:03:04 | reactormonk | EXetoC, s/sports team/religion/ s/sports team/political opinion/ ... |
19:03:29 | reactormonk | Araq, because we assume that the unittest layer is tested throughout |
19:04:06 | Demos | unittest is quite the bunch of macros as well |
19:04:12 | Araq | reactormonk: since it took me weeks to get the unittest module to work with the new VM, I disagree |
19:04:46 | EXetoC | You'd just rely on the exit code in this case so I don't get it, but ok nevermind. still, don't some tests omit "discard ..." and just use asserts? does that even work properly? |
19:05:04 | * | ruzu quit (Changing host) |
19:05:04 | * | ruzu joined #nimrod |
19:05:07 | Araq | no |
19:05:09 | renesac | even if not suitable for compiler debugging, hopefully unittest should be the default for programs developed with nimrod... |
19:05:12 | EXetoC | wonderful |
19:05:49 | Demos | can unittest collect stuff so that you can run all the tests for a bunch of different modules at the same time? |
19:06:15 | reactormonk | EXetoC, write something that extracts a single test so you can run it without unittest |
19:06:17 | Araq | Demos: in theory yes. |
19:07:05 | Araq | EXetoC: if there is no 'discard' section, the tester simply checks it still compiles |
19:07:16 | Araq | and doesn't run the compiled program |
19:08:01 | EXetoC | hm, were these only static asserts? I'll check again some time |
19:08:36 | renesac | http://stackoverflow.com/questions/3557072/is-there-a-better-c/22747236#22747236 <-- final version of this answer, I think |
19:08:51 | renesac | if I get as many upvotes as the Rust answer, I'm happy |
19:10:43 | Araq | renesac: I'm not on stack overflow so I can't upvote you, sorry |
19:10:58 | renesac | no problem |
19:11:20 | renesac | I should finish that whitespace FAQ too... |
19:12:44 | renesac | "Unlike some other suggestions, (Go, Nimrod, D, ...) Rust can directly compete with C and C++ because it has manual memory management and does not require garbage collection (see [1])." <-- I should comment that the GC is optional on Nimrod and D? (I don't know about Go) |
19:15:08 | renesac | ok, it seems it isn't optional in Go |
19:15:15 | Araq | perhaps but it's getting tiresome already |
19:16:42 | Araq | when you have a complex structure, Rust's ownership can't cope with it and you're back at RCing which is what nimrod's gc does anyway |
19:17:30 | foodoo | what does happen in that case? The Rust code fails to compile? |
19:17:55 | Araq | I think so, but have 0 experience with it |
19:18:41 | * | Skrylar puts on reading glasses and peers at the chat |
19:18:55 | Matthias247 | yes, wo won't make it legal to compile without using either a refcounted/garbagecollected type or using unsafe |
19:19:03 | Skrylar | Lol, I love that the GC was mandatory in Rust and now they're claiming they don't use it :) |
19:19:09 | dom96 | In the reddit thread about Go vs. Rust someone mentioned an old programming language called Hermes which tried to do what Rust does with its compile-time memory safety. |
19:19:16 | dom96 | I wonder how it worked out for Hermes. |
19:19:45 | dom96 | The history of Hermes can perhaps shed some light on whether Rust is in fact practical. |
19:20:09 | Skrylar | I think that GCs are not inherently bad (doesn't the python GC refcount too? which is what most of the "magic" C++STD does), they just have a few warts that need cooperative handling |
19:20:30 | Skrylar | its when a GC is the *only* way you're allowed to manage memory that pain sets in |
19:20:43 | foodoo | Skrylar: Yes, the Python GC does. You need to use the Refcount infrastructure when you write Python libs in C |
19:21:18 | Skrylar | IMO one of my biggest complaints about GCs (that they are oblivious to other apps, which leads to overallocation) would be easily solved with some kernel help |
19:21:42 | Demos | yeah, it would be nice if garbage collection was a kernel service |
19:21:54 | Araq | Skrylar: please explain |
19:22:03 | Matthias247 | I think the biggest complaints are that it is undeterministic |
19:22:05 | Skrylar | Araq: the overallocation issue? |
19:22:07 | Araq | oblivious to other apps? how is malloc better at that? |
19:22:24 | Skrylar | Araq: i didn't say malloc was better :) |
19:22:35 | Demos | Matthias247: hm.. I always figured that was a good thing for memory. I dont really need or want control over exactly when my memory is freed |
19:22:39 | Araq | how is stack allocation better at it? |
19:22:55 | Skrylar | though usually, malloc-based apps will use refcounting or some system to dispose of RAM when they know it is no longer needed, which means they will try to use less memory; a GC will usually return this memory back to the GC pool |
19:22:57 | Demos | unless I do. In which case I am probably going to need malloc |
19:23:05 | Skrylar | thing is, malloc/free in some OS will have an app pool too |
19:23:15 | Skrylar | but the GC doesn't free that back to the OS, so now *both* are trying to keep conservative pools |
19:23:16 | Matthias247 | Demos: that's you. But realtime code which should show a deterministic timing can't cope with undeterministic pauses |
19:23:35 | Araq | Skrylar: nimrod's GC gives memory back to the OS ... |
19:23:46 | Demos | Matthias247: right. But then malloc and free are going to be problems as well |
19:23:48 | Skrylar | Araq: okay, but most of them dont |
19:23:49 | Matthias247 | Demos: automotive code even prohibits malloc because it's undeterministic too |
19:24:15 | Araq | Matthias247: that's borderline programming |
19:24:21 | Skrylar | if the OS is pooling memory for an app, then the app itself is pooling memory, you end up with programs like MapTool where the JVM is hoarding 200+mb of RAM |
19:24:35 | Skrylar | just to idle |
19:24:36 | Araq | use the LTSF allocator and call it a day, Matthias247 :P |
19:25:00 | foodoo | Matthias247: "automotive" as in "car"? |
19:25:05 | Demos | My problem with GC'd langauges is that they tend to allocate lots of temp objects on the heap. Which is not exactly ideal |
19:25:10 | Matthias247 | foodoo: yes |
19:25:19 | Skrylar | mobile OS nowadays have that "please clean up your memory use" signal they send out, so it wouldn't be that hard to add in a posix signal for "hey can you look in to your insane RAM usage Mr Exe?" to trip GCs at least |
19:26:12 | foodoo | Skrylar: Add something to a standard and "not hard"? ;) |
19:26:31 | Skrylar | foodoo: i'm only interested in the technical aspects :) |
19:26:40 | Araq | fyi when I started nimrod I had no GC |
19:27:06 | Araq | I decided to add a GC when I figured writing a compiler without a GC is pure masochism |
19:27:13 | Skrylar | political retardation is fundamentally uninteresting :( its just a matter of memorizing social patterns and trickery :/ |
19:27:21 | renesac | foodoo, yes, when you have hard realtime systems, you can't call something like malloc in the middle of the program |
19:27:22 | reactormonk | Araq, how come? |
19:27:24 | Demos | does rust use their GC to do their compilers various tree structures? |
19:27:31 | Skrylar | rust dumped their GC |
19:27:50 | Demos | Skrylar: but it is still optional, heck even GCC uses a GC. In C! |
19:27:51 | foodoo | GC in Rust is now implemented as a library if I am not mistaken |
19:27:56 | renesac | many automotive programming fits in this, like ABS brakes |
19:28:07 | Demos | right, but the compiler is written in rust, and may use a GC |
19:28:25 | Matthias247 | they used @ pointers, and now these ugly Gc<RefMut<T>> types |
19:28:33 | Skrylar | Demos: let me point this out again: i did not say GC use is a sin. i said mandatory GC use is a sin. i also said that it would be more optimal that the OS realize prevalent GC use and factor that in to their design |
19:28:42 | Araq | renesac: yes you can. TSLF is O(1) alloc/dealloc with an guaranteed instruction count of ~160 |
19:28:43 | Demos | I agree with you |
19:29:11 | Matthias247 | Araq: but can you guarantee also that you never run out of RAM? That is also one goal that they want to achieve |
19:29:20 | Skrylar | the author of the game "Banished" wrote a blog post where he even chuckled about how if he hadn't used C++ the bug wouldn't have happened; C++ ref counting got really unruly, and he had objects that were deleted stuck in auto-save queues which caused weird crashes |
19:29:30 | Araq | Matthias247: now *that* is the real reason |
19:29:41 | renesac | Araq, oh, haven't heard about it |
19:29:53 | dom96 | Skrylar: You shouldn't stereotype GCs :) |
19:29:59 | renesac | anyway not a standard malloc |
19:30:00 | Skrylar | on the other hand, there was also an article about how .NET's mandatory collector caused infinite problems with an internet cache app, because the MSGC kept grandfathering data that lived *just* too long :( |
19:30:05 | Matthias247 | when you hae 2MB of RAM some parallel allocations in the wrong timeframe can end bad :) |
19:30:15 | Skrylar | dom96: most of the GC'd apps i've used have horrendous memory footprints |
19:30:50 | Araq | btw a GC can use another trick that is not used in practice yet |
19:31:12 | Araq | which is: free memory that is technically still alive but wasn't used for a long time |
19:31:26 | reactormonk | Matthias247, that's an interesting idea, but it makes dynamic structures such as maps kinda ugly to code |
19:31:31 | Araq | when it's accessed, ensure a segfault happens :-) |
19:31:35 | Skrylar | Araq: then suddenly, get a random crash because it happened to get used :P |
19:31:50 | Araq | Skrylar: the trick is to ensure it crashes |
19:32:14 | Araq | this way the application can run MUCH longer without running out of memory |
19:32:14 | Skrylar | doesn't that then become a game of "now i have to figure out how to get the GC to stop that" |
19:32:15 | Matthias247 | reactormonk: I think it makes many things ugly to code ;) But it's not about beautifulness in that industry |
19:32:50 | Skrylar | i guess crashing it could in some way force derps to finally rewrite some code, though it would probably annoy the smaller dev teams |
19:33:11 | Araq | Skrylar: it's simply another form of memory overcommitting |
19:33:26 | Skrylar | i'd rather have a better way to introspect the allocations and graph out where all this less-used space is |
19:33:52 | Araq | Skrylar: yes. YOU. but the average Java developer likes to not care about leaks |
19:34:28 | Skrylar | Araq: would it be bad to say that i don't care about the average java developer because they tend to be idiots? :( |
19:34:31 | Demos | why not just design a CPU that detected a java app being run and just halted instead |
19:34:57 | EXetoC | I like that |
19:35:00 | Araq | I fear that's what the JVM will do and it will "fix" all the logical memory leaks in practice |
19:35:07 | Matthias247 | Demos: that's easy. Simply choose one for which JVM is not ported ;) |
19:35:07 | * | Skrylar grumbles at why a glorified die-roller needs TWO HUNDRED MB to do nothing o_o |
19:35:33 | reactormonk | Skrylar, I needed 10GB on the jvm to do something ;-) |
19:35:38 | Araq | and so people like us have no good argument left ;-) |
19:35:44 | Demos | Skrylar: tell that to matlab :D |
19:36:02 | Skrylar | delian66: matlab isn't a consumer language though |
19:36:08 | Skrylar | and by delian i meant demos |
19:36:11 | Skrylar | because i tabfail |
19:36:19 | Araq | on the other hand, "who cares, it works in practice" is an argument I use myself from time to time |
19:36:25 | Demos | matlab is a java app |
19:36:34 | Matthias247 | although I don't like Java as a language - the JVM seems to be pretty fast nowadays |
19:36:38 | Araq | Demos: what? o.O |
19:36:39 | delian66 | Skrylar: np |
19:36:43 | Demos | I think so at least |
19:36:48 | dom96 | What we should be able to do is to somehow mark data which can be forgotten but which can be recalculated if it's needed again at some extra CPU cost. |
19:36:54 | Skrylar | I usually don't accept "good enough don't care" until i've become exhausted trying to tune the correct ways and seen that the less correct way is actually good enough :( |
19:36:56 | dom96 | Now THAT would actually be pretty cool. |
19:36:59 | reactormonk | dom96, caches \o/ |
19:37:01 | Skrylar | case in point the event module i need to push on github |
19:37:25 | Skrylar | "i'd rather have O(1) instead of O(n)/O(2n)" <a week later> "Apparently even FLTK uses O(n) so i give up" |
19:37:25 | Matthias247 | Demos: the GUI might be in Java. The core is C++. I wrote extesions for it in C++ some time ago |
19:37:29 | reactormonk | dom96, should be easy enough to code - but you need a guarantee that there are no side-effects |
19:38:09 | dom96 | Actually, perhaps it would just be easier to dump the extra memory to the hard drive. |
19:38:16 | dom96 | Instead of ensuring that it can be recalculated. |
19:38:21 | reactormonk | dom96, also known as swap? ;-) |
19:38:24 | Demos | wait what is O(n)/O(2n) it sounds like something I may want? |
19:38:30 | dom96 | reactormonk: lol yes |
19:38:52 | reactormonk | dom96, tl;dr fuck it. Implement it for standalone, if needed. |
19:38:54 | Araq | Matthias247: yeah but it's still a memory hog... |
19:39:17 | Demos | also big-o complexity is dumb for stuff like memory management and such |
19:39:22 | dom96 | Perhaps recalculating the data would be useful in some circumstances. |
19:39:28 | foodoo | module gtk2: TWindowType* = int32 #does anyone here happens to know how to choose a proper value for a dialog window? I can't find the magic constant/symbol in the GNOME gtk2 docs |
19:39:33 | dom96 | Instead of swapping. |
19:39:58 | Araq | foodoo: use the dialogs module if you can |
19:40:21 | dom96 | foodoo: https://developer.gnome.org/gtk3/stable/gtk3-Standard-Enumerations.html#GtkWindowType |
19:40:28 | EXetoC | how do I get the name of the run-time type of an object? |
19:40:32 | Araq | dialogs.nim kicks ass, it means aporia doesn't feel weird like shit on windows :-) |
19:40:40 | foodoo | Araq: Yes, that's what I want to use. But the first argument to each function is an argument of PWindow |
19:40:42 | Araq | EXetoC: you can't for now |
19:41:01 | foodoo | Araq: And PWindow is created with gtk2.window_new( TWindowType ) |
19:41:17 | Araq | foodoo: ok, check out how aporia does it then |
19:41:23 | dom96 | foodoo: The names are likely: WINDOW_TOPLEVEL/WINDOW_POPUP |
19:41:40 | foodoo | Araq: okay. Yes, dialogs.nim surely kicks as. That's why I want to play around with it |
19:41:55 | Skrylar | Demos: nah, the slash is "or" not divided :) |
19:41:59 | EXetoC | Araq: ok. validating a test based on a series of true/false outputs seems a little lame |
19:42:02 | foodoo | Most programming languages don't come with an easy way to create simple dialogs with few lines of code |
19:42:21 | EXetoC | whatever. I can't be bothered to mess about anymore |
19:42:53 | Araq | EXetoC: but the fun hasn't even started |
19:43:14 | Araq | the vm should also care about {.push infChecks:on.} ... |
19:43:21 | reactormonk | EXetoC, just test unittest to hell and back |
19:44:22 | EXetoC | reactormonk: I'd just use assert if it was possible, but I'm just going to output a true/false sequence |
19:44:40 | EXetoC | Araq: I meant with trying to output something meaningful |
19:46:28 | Araq | dom96: argh. your async stuff makes my head explode |
19:46:45 | Araq | so where is this 'future' used? and why is it nil? |
19:46:52 | EXetoC | reactormonk: you mean as a way to convince Araq that it's not going to get in the way anymore? :> |
19:46:59 | dom96 | Araq: Which future? |
19:47:18 | Araq | var future = client.request("http://picheta.me/aboutme.html") |
19:47:19 | Araq | yield future # that one |
19:47:29 | EXetoC | dom96: now? |
19:48:11 | dom96 | Araq: `request` is a proc which returns a future. It initialises that future at the beginning of its execution. |
19:48:23 | dom96 | An iterator is defined inside that proc |
19:48:28 | dom96 | which captures that future |
19:49:12 | foodoo | Araq: The window is created with a proc called windowNew(). But this proc doesn't seem to be defined in Aporia or in the standard library (I searched the index) |
19:50:38 | reactormonk | btw, what's `export' |
19:50:49 | dom96 | Araq: when that iterator finishes then that future is completed. |
19:51:01 | reactormonk | EXetoC, basically, yup |
19:51:11 | dom96 | foodoo: The gtk wrapper was moved out of the stdlib |
19:51:56 | Varriount | How would I form a 64 bit int by concatenating 2 32 bit int's? |
19:51:59 | dom96 | reactormonk: http://build.nimrod-lang.org/docs/manual.html#export-statement |
19:53:04 | reactormonk | cool |
19:53:15 | foodoo | dom96: So the next version of Nimrod won't include the module gtk2? |
19:53:44 | dom96 | foodoo: Yes. |
19:54:04 | dom96 | foodoo: You need to get babel and install it by executing babel install gtk2 |
19:54:06 | Araq | Varriount: lowerBits or (higherBits shl 32) |
19:54:38 | foodoo | dom96: I guess dialogs will then also leave the stdlib as it depends on gtk2? |
19:54:46 | dom96 | yeah |
19:54:59 | Varriount | Araq: Thanks. I thought it was something like that - Unfortunately I'm not too experienced with bit-shifting. |
19:55:28 | Araq | Varriount: there is also code in winlean which does that iirc |
19:55:29 | foodoo | dom96: What's the rationale behind removing gtk2? Is it because gtk2 is deprecated and people should use gtk3 instead? |
19:55:31 | EXetoC | Araq: can't I catch EOverflow in a static block? Am I going to have to copy the output that the exception generates? |
19:55:46 | EXetoC | and use that as the expected output |
19:56:02 | Araq | EXetoC: exactly |
19:56:48 | reactormonk | foodoo, trim down the stdlib and move stuff to babel isntead |
19:57:00 | EXetoC | Araq: but I need to do that multiple times |
19:57:03 | Varriount | Araq: Of course, now I'm wondering whether I should combine the lowerBits and higherBit's of a Windows file index in the first place. :/ |
19:57:06 | EXetoC | in which case I must catch the exception somehow |
19:57:08 | EXetoC | brb |
19:57:28 | dom96 | foodoo: The gtk2 is updated too often, it is easier for people to update it using babel than by updating the whole stdlib. |
19:57:39 | dom96 | *gtk2 wrapper |
20:00:38 | Araq | dom96: the stack trace comes from newconnection but that does the same as request, right? |
20:02:10 | dom96 | Araq: Depends what you mean by the same? |
20:02:29 | dom96 | Similar code is generated, but the procedures do different things |
20:03:00 | Araq | yeah that's what I mean |
20:03:02 | Araq | however |
20:03:09 | Araq | newConnection calls newConnectionIter |
20:03:20 | dom96 | and like I keep saying: the code that is generated is printed by the macro |
20:03:24 | Araq | but it doesn't crash there |
20:03:37 | Araq | I keep looking at what the macro produces, dude |
20:03:42 | dom96 | then why ask me? |
20:04:10 | Araq | listen to me |
20:04:18 | Araq | newConnection calls newConnectionIter |
20:04:28 | Araq | newConnectionIter has a 'future' that is nil |
20:04:32 | Araq | however |
20:04:43 | renesac | http://stackoverflow.com/questions/3557072/is-there-a-better-c/22747236#comment34675668_20331936 <-- comment on needing a gc, needs one upvote to not stay hidden |
20:04:44 | Araq | newConnectionIter is *not* part of the stack trace |
20:05:28 | dom96 | renesac: upvoted, s/requires/require/ btw |
20:05:42 | dom96 | Araq: what does that mean? |
20:09:38 | Araq | dom96: there is an anon proc in newconnection's body |
20:09:44 | Araq | and that gets a future |
20:09:53 | Araq | and here things are nil |
20:10:15 | Araq | but I don't know where the anon proc comes from |
20:10:27 | Araq | seriously just try your example program in gdb |
20:10:49 | dom96 | I can't right now. |
20:11:10 | EXetoC | Araq: so I couldn't catch EOverflow statically. bug or feature? |
20:11:24 | dom96 | Maybe you're generating some anon proc by accident? There is no anon procs in newConnection. |
20:11:55 | dom96 | well wait |
20:12:06 | dom96 | there is |
20:12:19 | Araq | EXetoC: known bug |
20:12:20 | renesac | dom96, there is no edit button... |
20:12:22 | dom96 | see the createCb() invokation? |
20:12:40 | Araq | yeah I assumed that is the cause, dom96 |
20:13:02 | dom96 | That's defined in asyncdispatch:742 |
20:13:31 | Araq | createCb(cb, newConnectionIterVar, retFuture) |
20:13:42 | Araq | but that does not define a *future* param, does it? |
20:14:25 | dom96 | ahh. But `callback=` does. |
20:14:33 | dom96 | `callback=` is overloaded. |
20:14:47 | EXetoC | I'll create lots of little tests for now then unless there's some way to work around this |
20:15:02 | dom96 | asyncdispatch:73 |
20:15:11 | Araq | yeah I know |
20:15:12 | Araq | ok got it |
20:15:18 | Araq | cbName == future |
20:15:29 | Araq | no wait |
20:15:44 | Araq | next == future? wtf |
20:17:24 | Araq | dom96: asyncdispatch, line 746 |
20:17:44 | dom96 | yes? |
20:18:31 | Araq | well 'callback=' gets a nil future |
20:18:41 | Araq | now you tell me how that's possible |
20:18:49 | Araq | the if even checks against that |
20:18:56 | dom96 | I see. |
20:19:13 | dom96 | Yeah, I don't know man. |
20:22:55 | NimBot | nimrod-code/babel master 58a6808 fenekku [+0 ±1 -0]: Update readme.markdown... 2 more lines |
20:22:55 | NimBot | nimrod-code/babel master f0fcf5c Dominik Picheta [+0 ±1 -0]: Merge pull request #36 from fenekku/patch-1... 2 more lines |
20:25:03 | foodoo | {.pragma: rtl, exportc: "nimrtl_$1", dynlib.} |
20:25:49 | Araq | dom96: things are only getting weirder here |
20:26:09 | foodoo | is there something about the pragma syntax that changed recently? I can't build the nimrod git-package from my Linux distro because it says that there is an invalid exported symbol |
20:27:06 | Araq | foodoo: yeah gradha found it a good idea to add some exportc name checking for idiots |
20:27:31 | foodoo | fyi: The file is nimrod/lib/system/inclrtl.nim and the line is 27 |
20:27:45 | Araq | let me try on this machine |
20:28:07 | Araq | what command did you use to compile? |
20:29:07 | foodoo | I used this package script: https://aur.archlinux.org/packages/nimrod-git/ |
20:29:24 | foodoo | so basically the stuff that's defined in build() https://aur.archlinux.org/packages/ni/nimrod-git/PKGBUILD |
20:33:37 | Araq | foodoo: thanks, can reproduce |
20:40:48 | NimBot | Araq/Nimrod devel d8ce49c Araq [+0 ±1 -0]: disable extern name checking as it breaks building of nimrtl.dll |
20:41:04 | Araq | foodoo: there you go, thanks for the bug report. |
20:41:15 | foodoo | Araq: you're welcome :) |
20:44:49 | foodoo | aaand compiles :) |
21:04:43 | * | [1]Endy quit (Ping timeout: 268 seconds) |
21:29:09 | * | Matthias247 quit (Read error: Connection reset by peer) |
21:55:59 | * | q66 quit (Ping timeout: 252 seconds) |
21:57:08 | * | foodoo quit (Ping timeout: 240 seconds) |
22:10:00 | * | q66 joined #nimrod |
22:13:28 | * | OrionPK joined #nimrod |
22:37:37 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
23:04:33 | * | brson joined #nimrod |
23:07:25 | * | IrvMG joined #nimrod |
23:07:29 | * | IrvMG quit (Read error: Connection reset by peer) |
23:07:46 | * | IrvMG joined #nimrod |
23:09:16 | IrvMG | Hi. convert biggestint to string? |
23:10:58 | EXetoC | IrvMG: strutils.intToStr? |
23:12:22 | IrvMG | intToStr: type mismatch: got (int64) |
23:13:21 | IrvMG | Type is biggestint, return from getFileSize |
23:16:02 | EXetoC | IrvMG: I don't know what you'd do on x86 for large values, but you can convert it to int if you want |
23:16:10 | EXetoC | x.int or int(x) |
23:18:37 | IrvMG | Thanks. Found with intToStr(getFileSize(f).int) |
23:22:53 | * | darkf joined #nimrod |
23:40:41 | dom96 | IrvMG: Does $ not work? |
23:41:04 | EXetoC | :o |
23:41:47 | dom96 | $ is the ultimate universal toString operator. |
23:41:49 | EXetoC | I think I should know that by now |
23:41:56 | dom96 | Yes :P |
23:42:30 | IrvMG | for example? |
23:42:41 | EXetoC | $x |
23:44:04 | IrvMG | $getFileSize(f) :O |
23:44:51 | EXetoC | looks correct |
23:45:01 | dom96 | EXetoC: You on arch? |
23:45:05 | EXetoC | dom96: yes |
23:45:12 | * | BitPuffin quit (Ping timeout: 265 seconds) |
23:45:19 | dom96 | EXetoC: Wanna become the maintainer of babel-git on AUR? :P |
23:47:05 | * | BitPuffin joined #nimrod |
23:47:13 | dom96 | oh look, I found a picture of zahary: http://www.quora.com/Zahary-Karadjov |
23:52:11 | dom96 | Araq: Is this a bug? http://stackoverflow.com/questions/22689671/tuples-without-field-names |
23:54:08 | * | BitPuffin quit (Ping timeout: 240 seconds) |
23:57:42 | * | BitPuffin joined #nimrod |
23:59:05 | dom96 | well i'm away to sleep. |
23:59:16 | dom96 | EXetoC: let me know later |