| 00:02:02 | * | nande quit (Ping timeout: 260 seconds) |
| 00:06:04 | * | Fr4n joined #nimrod |
| 00:08:27 | Joe_knock | When trying to compile this: https://github.com/nimrod-code/gtk2/blob/master/examples/ex1.nim ... I keep getting this error: ex1.nim(2, 2) Error: cannot open 'glib2' |
| 00:08:32 | * | Boscop quit (Read error: Connection reset by peer) |
| 00:09:00 | * | Boscop joined #nimrod |
| 00:10:09 | Varriount | Joe_knock: It may rely on a wrapper that has since been moved. |
| 00:10:18 | * | nande joined #nimrod |
| 00:10:41 | * | Boscop quit (Read error: Connection reset by peer) |
| 00:10:45 | Joe_knock | I did install a development version of libglib2 on my system though. |
| 00:11:09 | * | Boscop joined #nimrod |
| 00:11:14 | EXetoC | you need the nimrod wrapper too |
| 00:11:23 | Varriount | Yes, but that file is trying to *import* a nimrod module called glib2 |
| 00:11:25 | EXetoC | or is that what you meant? |
| 00:11:44 | Varriount | EXetoC: Where is the wrapper? |
| 00:12:45 | EXetoC | it's part of the gtk2 wrapper still |
| 00:13:54 | * | Boscop quit (Read error: Connection reset by peer) |
| 00:14:11 | EXetoC | so it's not in the path then |
| 00:14:18 | * | Boscop joined #nimrod |
| 00:14:19 | Joe_knock | weird, can either of you get ex1.nim to compile? |
| 00:14:54 | Varriount | I'll see... |
| 00:17:56 | * | Boscop quit (Read error: Connection reset by peer) |
| 00:18:21 | * | Boscop joined #nimrod |
| 00:18:41 | Varriount | Joe_knock: I can get it to compile. I have gtk installed via babel. |
| 00:18:58 | Varriount | Joe_knock: I can't run it, but that's because I don't have the gtk dll built/installed |
| 00:19:21 | bogen | ok, looking at this filed by def- https://github.com/Araq/Nimrod/issues/1334 Array subscript is not an integer |
| 00:20:16 | bogen | I need to see why the cast information is lost (or why the cast is not being generated). |
| 00:20:56 | Varriount | bogen: Ooo, good work. Few of us are brave enough to fiddle with the compile. |
| 00:20:58 | Varriount | *compiler |
| 00:21:33 | Varriount | bogen: Make sure to document any procedures that you modify. Unfortunately, the compiler code is in serious need of documentation. |
| 00:21:35 | bogen | also, that generated code shows the line number trace registration is wrong (it allows for many duplicates) |
| 00:21:51 | bogen | I'll need to find if there is already a bug report on that |
| 00:22:33 | bogen | unless someone else wants to track that down for me, I need to find out either why the cast is getting lost or not being performed |
| 00:22:55 | Varriount | bogen: There isn't. The duplicate lines might be from last minute optimizations. |
| 00:23:45 | Joe_knock | Varriount: Did you install Babel in the same folder as Nimrod? |
| 00:24:14 | bogen | well, it is still is a bug, the registration function for those line traces needs to not lay down multiple sequential traces for the same line, that is superflous (and wasteful) |
| 00:24:32 | bogen | (not a harmful bug, just excess baggage) |
| 00:24:37 | Varriount | Joe_knock: I'm on windows. Babel is in it's own folder, but it installs all modules to ~/.babel/pkgs/ |
| 00:24:53 | Varriount | And the nimrod compiler adds those to my path. |
| 00:25:59 | Joe_knock | Let me try installing Babel in the Nimrod folder . |
| 00:26:22 | Joe_knock | or wait, let me do it like how you did it. |
| 00:27:05 | Varriount | Joe_knock: The simple answer is that glib2.nim isn't in your path environment. |
| 00:31:52 | * | nande quit (Ping timeout: 245 seconds) |
| 00:33:07 | Joe_knock | Varriount: I have Babel installed now, but I'm unsure how to add it to $PATH? |
| 00:34:04 | Varriount | Joe_knock: Nimrod should detect packages installed by babel automatically, those don't need to be added to $path |
| 00:35:01 | Joe_knock | This is what the instructions say: "You should then add ~/.babel/bin to your $PATH" |
| 00:35:21 | def- | Joe_knock: only relevant for binary packages |
| 00:35:27 | Varriount | Yeah, to add the binary. |
| 00:35:32 | def- | Joe_knock: library packages should still work |
| 00:36:43 | * | Stefan__ joined #nimrod |
| 00:37:05 | Joe_knock | Well after installing babel, when I run "babel install babel" nothing happens (it tells me: "The program 'babel' can be found in the following packages:") |
| 00:37:58 | Varriount | Try 'babel update' |
| 00:38:23 | bogen | Varriount: ah, optimizations, yeah, I get it. Then the final code emitter needs to look for duplicate sequential line trace calls and omit the extras |
| 00:38:34 | Stefan__ | I put this in my path, it is from april this year, and was working. Maybe not necessary any more now? |
| 00:38:55 | Stefan__ | cat .bashrc |
| 00:39:18 | Stefan__ | PATH=$PATH:/home/stefan/gitnimrod/Nimrod/bin/ |
| 00:39:21 | Varriount | bogen: Yes, but why spend the effort to get rid of them? It's generated code, and more than that, debug generated code. |
| 00:39:48 | Joe_knock | I think the reason it may be saying add "~/.babel/bin" to $PATH is so that babel can run anywhere in the terminal? |
| 00:39:57 | Varriount | Joe_knock: Yes |
| 00:40:09 | Stefan__ | PATH=$PATH:/home/stefan/gitnimrod/babel/src/ |
| 00:40:18 | Varriount | Stefan__: You still have to have the nimrod binary in your path to run it without specifying the direct binary path. |
| 00:40:30 | Stefan__ | PATH=$PATH:/home/stefan/.babel/bin |
| 00:40:45 | bogen | Varriount: ok, so not a bug, I'll put in a feature request and get to it later. I do need put in a compile time trace that puts which compiler function is generating the code (via /*from blah*/) insertions. |
| 00:41:20 | bogen | because I need to be able to find out what compiler procs are generating the code, so I know what to fix |
| 00:41:20 | Joe_knock | Stefan__: Are you using debian/ubuntu ? |
| 00:41:21 | Stefan__ | Three entries total, maybe new login is necessary before it is working. |
| 00:41:32 | Stefan__ | good night |
| 00:41:35 | Stefan__ | quit |
| 00:41:37 | Varriount | Stefan__: Good night. |
| 00:43:25 | * | nande joined #nimrod |
| 00:45:13 | Joe_knock | yikes. No effect :-/ |
| 00:45:27 | bogen | it is /quit |
| 00:45:48 | bogen | That Stefan__ forgot |
| 00:46:07 | Varriount | Joe_knock: Copy the example to directory of the gtk wrapper source and compile it from there. |
| 00:47:32 | * | Stefan__ quit () |
| 00:47:35 | Joe_knock | Varriount: I found the solution. I simply copied the executable into my /usr/bin folder. Now babel works. |
| 00:47:47 | * | nande quit (Ping timeout: 245 seconds) |
| 00:47:56 | Joe_knock | bogen: You sure "quit" isn't an auto-message he setup when he exits? |
| 00:48:16 | bogen | :) yeah maybe... |
| 00:52:24 | Varriount | Hm, why is this supposed to be invalid code? -> https://github.com/Araq/Nimrod/issues/1435 |
| 00:52:48 | Varriount | You can cast a nil value to a pointer, why not a struct/object? |
| 00:54:50 | bogen | it is not valid code, and that is stated |
| 00:55:01 | bogen | the issue is that the compiler should not crash |
| 00:55:47 | bogen | It should not be an "internal error" |
| 00:56:36 | bogen | it should be a language level error (not the compiler not knowing how to deal with it) |
| 00:58:00 | * | Varriount goes to work yet again on semCast and isCastable |
| 01:02:40 | * | nande joined #nimrod |
| 01:26:38 | * | Joe_knock quit (Quit: Leaving) |
| 01:29:36 | flaviu | "Jester is making jokes at http://localhost:5000" |
| 01:29:37 | flaviu | lol |
| 01:32:06 | * | brson quit (Ping timeout: 250 seconds) |
| 01:43:40 | * | saml_ joined #nimrod |
| 01:51:19 | * | q66 quit (Quit: Leaving) |
| 02:04:01 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 02:10:52 | * | nande quit (Remote host closed the connection) |
| 02:19:52 | flaviu | "NULL database values will be transformed always to the empty string" looses information. What was the purpose of that? |
| 02:20:12 | Varriount | flaviu: Source? |
| 02:20:16 | flaviu | http://build.nimrod-lang.org/docs/db_sqlite.html |
| 02:21:05 | flaviu | Also, getRow returns a seq[ TRow["", "", "", ...] ] on empty, not seq[] |
| 02:21:32 | Varriount | flaviu: Sounds like those behaviors should be changed. :/ |
| 02:23:55 | Varriount | flaviu: Besides pointer/ref/int types, is there any valid reason for casting `nil` to something? |
| 02:25:15 | flaviu | Not that I can think of, although I don't see the point of casting nil to an int |
| 02:26:20 | Varriount | flaviu: I'm wondering what reasonable behavior https://github.com/Araq/Nimrod/issues/1435 should have. |
| 02:27:12 | flaviu | It should emit an error and fail to compile. Nil is only defined as "invalid pointer" |
| 02:27:24 | Varriount | Oh, really? |
| 02:27:35 | Varriount | That makes things easy. |
| 02:27:40 | flaviu | Well, that's how I'd define it |
| 02:46:48 | * | saml_ quit (Ping timeout: 246 seconds) |
| 04:35:02 | * | flaviu quit (Ping timeout: 260 seconds) |
| 05:32:43 | * | Demos quit (Read error: Connection reset by peer) |
| 05:59:44 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 06:01:50 | * | gkoller joined #nimrod |
| 06:14:20 | * | gkoller quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 06:15:47 | * | gkoller joined #nimrod |
| 06:27:26 | * | gkoller quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 06:29:06 | * | gkoller joined #nimrod |
| 06:46:21 | Araq | bogen: the multiple line tracing lines are a bug and should be easy to fix |
| 06:49:04 | Araq | and the most useful thing you can do, is in fact, helping with the compiler. 3D demos, UI apps etc. are nice but it's really discouraging people that compiler bugs take an eternity to be fixed. |
| 06:50:16 | Araq | we have lots of people working on tooling and the libraries, but pretty much 1 compiler developer left (me) |
| 06:53:38 | bogen | Araq: yeah, I'm going to fix it if no one else it going to (the multiple line trace) |
| 06:54:21 | bogen | I need to because I'm using debug builds of nimrod and I need it to base fast as possible (for a debug build) |
| 06:55:44 | Araq | it's not hard to fix |
| 06:56:03 | bogen | I'm working on a cgenTrace to append a one line abbreviated stack trace to every generated line of C Code (as a /* comment */) |
| 06:56:33 | Araq | my theory is that nkStmtList, nkEmpty and nkStmtListExpr all produce line info but shouldn't |
| 06:56:58 | bogen | I could not find a common code emitter in the compiler, the closest thing I found was "indentLine" |
| 06:57:37 | Araq | no, wait a sec |
| 06:58:38 | bogen | ok, I'm not heavily comitted yet to indentLine |
| 06:59:35 | Araq | proc genLineDir in cgen.nim does it |
| 07:00:19 | bogen | genLineDir does the line tracing |
| 07:00:26 | bogen | yes, I know |
| 07:00:46 | Araq | oh, what's your problem then? |
| 07:01:56 | bogen | I'm adding a comment to the end of each line (only with the debug build of the compiler) that has the call trace |
| 07:02:10 | bogen | so that I know where each line of C code is coming from |
| 07:02:26 | Araq | that already exists |
| 07:02:30 | bogen | really? |
| 07:02:33 | bogen | where? |
| 07:02:34 | Araq | really. |
| 07:02:48 | Araq | --embedsrc |
| 07:03:08 | bogen | that being the source of the input code? |
| 07:03:26 | bogen | if so that is not what I mean |
| 07:03:40 | bogen | I mean where in nimrod the C code is coming from |
| 07:04:05 | bogen | not where in the source files being fed to nimrod |
| 07:04:12 | Araq | I see |
| 07:05:35 | Araq | well what you want won't be useful |
| 07:05:47 | Araq | but go ahead and see for yourself |
| 07:06:27 | bogen | ok, well, I can't learn without trying |
| 07:07:16 | bogen | why would knowing where the code was being generated from not be useful? |
| 07:11:16 | * | kunev joined #nimrod |
| 07:11:27 | bogen | you know the system better than me :) (and I know I'm going to go down a lot of dead ends trying to figure things out) |
| 07:13:20 | * | gkoller quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 07:16:55 | Araq | foo(bar, baz[i].hoho) |
| 07:17:13 | Araq | /* genCall */ |
| 07:17:31 | Araq | echo "moo" /* genEcho */ |
| 07:17:55 | Araq | abc(boo) /* genCall */ |
| 07:18:15 | Araq | if foo: bar /* genIf */ |
| 07:18:33 | Araq | what do you think the stack traces will contain? |
| 07:18:50 | bogen | that information |
| 07:19:00 | Araq | I can't imagine they'll contain anything useful |
| 07:19:33 | Araq | that problem is that genLineDir is statement based and there are only a couple of statements |
| 07:19:56 | Araq | you won't get the information that a[i] is produced by genArrayAccess |
| 07:20:48 | Araq | you need to fix the format strings for that like: "#chckNil((void*)$1);$n" |
| 07:21:00 | Araq | --> "#chckNil((void*)$1); /* resetLoc */$n" |
| 07:21:25 | bogen | ok, well, I'll find out, if I can get the above items from it, it will be, if not, oh well. The stack line proc was easy enough to write, and tacking it on to linefmt was easy enough, if it does not work, that is fine. Either way, I'm still learning. |
| 07:22:30 | Araq | ok, but here are some hints: |
| 07:22:52 | Araq | echo renderTree(someNode) # pretty prints the nimrod ast |
| 07:23:14 | Araq | debug(someNode) # outputs some JSON representation |
| 07:23:32 | Araq | echo typeToString(someType) # pretty prints some type |
| 07:23:38 | Araq | debug(someType) |
| 07:23:53 | Araq | echo symbol.name.s |
| 07:23:58 | Araq | debug(symbol) |
| 07:24:27 | Araq | echo renderTree(someNode, {renderIds}) # pretty prints the nimrod ast, but annotates symbol IDs |
| 07:25:11 | Araq | if n.info ?? "temp.nim": echo renderTree(n) # only output when it comes from "temp.nim" |
| 07:25:47 | Araq | if n.info ?? "temp.nim": writeStackTrace() # why the fuck does it process temp.nim here? |
| 07:26:17 | Araq | this is what I use |
| 07:26:26 | bogen | ok |
| 07:26:36 | Araq | you know "koch temp" right? |
| 07:28:18 | bogen | temp options -- creates a temporary compiler for testing, ok I see that now, that is what I should be using. I was just doing boot with no options (and not installing it), that takes a while |
| 07:29:00 | Araq | you should use a release version of the compiler for "koch temp" |
| 07:29:22 | Araq | this way the fast compiler will produce a slow debug compiler that then runs your example test program |
| 07:29:51 | Araq | the slow debug compiler won't overwrite your release compiler |
| 07:31:04 | bogen | ok, I see, that will be useful, that is why this taking so long to build, ok, I'll stop it and do "cd csources && ./build.sh" again |
| 07:31:44 | Araq | the other problem that you'll encounter is information overload |
| 07:32:10 | bogen | yeah, I thought that too, but still figured I try it |
| 07:32:19 | Araq | you have to be very careful to only get debug output for the cases that matter, otherwise the information will overwhelm you |
| 07:32:34 | Araq | and you lose hours in some huge debug.txt file |
| 07:35:10 | * | superfunc joined #nimrod |
| 07:40:22 | bogen | ok, nimrod_temp is more than twice the size of the release build |
| 08:01:34 | Araq | the array indexing bug is due to astalgo.skipConv being too permissive |
| 08:01:41 | Araq | bbl |
| 08:01:45 | bogen | ok |
| 08:03:24 | * | kunev quit (Remote host closed the connection) |
| 08:10:02 | * | kunev joined #nimrod |
| 08:11:53 | * | Trustable joined #nimrod |
| 08:41:07 | * | Matthias247 joined #nimrod |
| 09:51:37 | * | zahary joined #nimrod |
| 09:55:16 | * | zahary quit (Read error: No route to host) |
| 09:55:25 | * | zahary joined #nimrod |
| 09:56:40 | * | zahary1 joined #nimrod |
| 09:56:40 | * | zahary quit (Read error: Connection reset by peer) |
| 09:56:56 | * | superfunc quit (Ping timeout: 250 seconds) |
| 09:58:15 | * | EXetoC joined #nimrod |
| 10:48:29 | * | q66 joined #nimrod |
| 10:58:52 | * | zahary joined #nimrod |
| 11:02:03 | * | zahary1 quit (Ping timeout: 246 seconds) |
| 11:23:03 | * | zahary quit (Quit: Leaving.) |
| 11:42:02 | dom96 | hello |
| 11:46:40 | Araq | hi dom96 |
| 11:47:05 | dom96 | brb |
| 11:58:46 | dom96 | back |
| 11:58:49 | dom96 | hi Araq |
| 12:01:13 | dom96 | what's new? |
| 12:11:17 | * | skyfex joined #nimrod |
| 12:15:04 | * | darkf quit (Quit: Leaving) |
| 12:30:19 | * | kunev quit (Quit: leaving) |
| 13:18:00 | * | flaviu joined #nimrod |
| 13:18:29 | Araq | hi skyfex wb |
| 13:18:38 | Araq | dom96: I'm working on spawn |
| 13:18:38 | skyfex | hi Araq :) |
| 13:31:29 | dom96 | Araq: cool, i'm working on async |
| 14:04:01 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 14:38:52 | * | flaviu quit (Read error: Connection reset by peer) |
| 14:40:41 | * | flaviu joined #nimrod |
| 15:21:44 | * | io2 joined #nimrod |
| 15:23:14 | NimBot | nimrod-code/packages master 363eff7 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds lazy_rest package. |
| 15:23:14 | NimBot | nimrod-code/packages master 2ea1994 Dominik Picheta [+0 ±1 -0]: Merge pull request #79 from gradha/pr_adds_lazy_rest... 2 more lines |
| 15:28:24 | * | Trustable quit (Quit: Leaving) |
| 15:47:31 | * | zahary joined #nimrod |
| 15:48:04 | * | zahary1 joined #nimrod |
| 15:52:20 | * | zahary quit (Ping timeout: 272 seconds) |
| 15:52:31 | bogen | Araq: you are right, I had to play around some with my cgenTrace to not be too noisy and just return relevant part of of the backtrace (in reverse order) that I was looking for. So while I'm getting the relevant part of the backtrace, the information I'm really looking for is not there. Inside genLine dir I'm seeing that is being called from different places, but in a non-linear manner. And while I've not verfified it yet, it appears they li |
| 15:55:11 | bogen | The relevant part of the backtrace still is useful to me though, just not useful for the immediate things I'm trying to track down |
| 16:05:15 | bogen | reverse order meaning the calls higher up to the right and calls closer to ropecg on the left so that only the first few items on the left of the trimmed down back trace are relevant |
| 16:07:24 | * | zahary1 quit (Quit: Leaving.) |
| 16:15:47 | NimBot | Araq/Nimrod devel 4f5f98f Dominik Picheta [+1 ±3 -0]: Fixes incorrect async exception handling. Adds sleepAsync.... 12 more lines |
| 16:22:01 | skyfex | Araq: I'm playing around with TCC. I need a simple C compiler for a small MCU core I might be making at work. It's interesting.. it doesn't produce optimized code at all, but it's very fast and simple to get started with. It would be nice if Nimrod had some kind of super-simple backend like that one day. |
| 16:23:13 | skyfex | TCC actually looks like it might produce OK code for a stack machine, which is what I'll be making. I might make a simple optimization pass just for the low-hanging fruits. I think I can teach our firmware folks to get around the lack of CSE. |
| 16:27:36 | * | zahary joined #nimrod |
| 16:28:23 | bogen | skyfex: nimrod already has a TCC backend |
| 16:29:42 | skyfex | bogen: Yeah, but I was thinking of something actually written in Nimrod. I can't imagine it'd be too hard to port backend parts of TCC to Nimrod. |
| 16:30:13 | bogen | you mean by wrapping libtcc ? |
| 16:30:44 | bogen | with cimports? |
| 16:31:23 | bogen | by the way, where are you getting your TCC from? Activity had been dormant for a while |
| 16:31:42 | skyfex | No, I mean by actually rewriting the code in Nimrod.. It's a few thousand lines of code.. But should just be a few hundred in Nimrod right ;) |
| 16:32:21 | skyfex | bogen: Yeah, I've seen that. I just forked from here: http://bellard.org/tcc/ |
| 16:32:43 | bogen | (Development on it had dwindled) but it seems like someone in India has been doing some updates on it. That is old. |
| 16:33:03 | bogen | Let me track down the latest stuff, there was some work this year on it. |
| 16:33:10 | skyfex | Cool, thanks |
| 16:33:33 | skyfex | It can be hard to find the best version of a code that has been dormant and then forked by various people |
| 16:34:13 | * | nande joined #nimrod |
| 16:34:13 | skyfex | The official version seems fine for my use though, but it's always nice to get in some improvements if they exist |
| 16:35:11 | bogen | https://github.com/Amorph/tcc here is one, but it is not the one I had found earlier |
| 16:43:05 | bogen | well, can't find the one I had stumbled upon earlier |
| 16:44:50 | skyfex | bogen: No worries, thanks though! |
| 16:46:55 | * | ics joined #nimrod |
| 16:50:06 | bogen | https://github.com/mb-14/tcc found it, but it looks like Amorph might have some more up to date fixes |
| 17:10:57 | NimBot | Araq/Nimrod devel f8e714b Dominik Picheta [+0 ±1 -0]: Fixes async on Linux. |
| 17:14:06 | * | Jesin quit (Quit: Leaving) |
| 17:17:53 | * | Jesin joined #nimrod |
| 17:20:11 | dom96 | Ok. So try #2. http://forum.nimrod-lang.org:8080/ |
| 17:20:13 | dom96 | Please test. |
| 17:26:53 | dom96 | flaviu: You around? |
| 17:27:26 | flaviu | yep |
| 17:28:10 | dom96 | You were good at crashing it last time :P |
| 17:28:13 | dom96 | Please test it if you can |
| 17:28:45 | def- | dom96: it's down |
| 17:28:50 | dom96 | yay, thanks |
| 17:28:56 | def- | (I didn't do anything) |
| 17:29:14 | flaviu | I didn't even get one response |
| 17:29:33 | flaviu | $ wget --spider http://forum.nimrod-lang.org:8080/ |
| 17:29:53 | dom96 | cool, didn't know wget can do that. |
| 17:30:27 | def- | wget -m -p -np http://forum.nimrod-lang.org:8080/ is what i would have done |
| 17:31:11 | * | zahary quit (Ping timeout: 255 seconds) |
| 17:31:13 | dom96 | Seems my patch worked, although I was hoping for a more meaningful exception. |
| 17:31:16 | dom96 | All I got was "Error: unhandled exception: false [E_Base]" |
| 17:31:30 | dom96 | which is likely 'assert false' |
| 17:32:14 | dom96 | I just got a great idea. |
| 17:34:22 | dom96 | argh, that won't help |
| 17:34:38 | flaviu | Well, it looks like --spider does pretty much nothing. |
| 17:34:55 | flaviu | wget -r is what I should've used |
| 17:38:43 | dom96 | It was easy enough to find, I will definitely need to look into improving the stack trace though. |
| 17:45:54 | OrionPK | aloha |
| 17:46:30 | dom96 | guten tag |
| 17:46:58 | OrionPK | wie gehts |
| 17:47:12 | Trixar_za | goeie dag |
| 17:47:20 | OrionPK | god dag |
| 17:49:17 | flaviu | dog gad |
| 17:49:44 | bogen | dom96: yeah, I'm transforming getStackTrace for something I'm working on: https://gist.github.com/bogen/8b3981242dc6a9491cf6 but it is a bit of a hack |
| 17:50:24 | dom96 | bogen: you should instead expose a new function which returns some sort of object containing all the stack trace information |
| 17:50:41 | dom96 | that is more complicated of course |
| 17:50:45 | dom96 | but would help all of us :) |
| 17:53:27 | bogen | well, I'm kind of hitting a brick wall (for now) on looking into compiler issues, so I'll look at writing that function you are wanting |
| 17:58:03 | bogen | dom96: are you trying to use getStackTrace for what you are trying to do? |
| 17:59:51 | bogen | I can use mine make a function that returns the non skipped/dropped sequence (rather an transforming it to text). Is that what you want? |
| 18:05:14 | bogen | getStackTrace is getting text from what it calls (auxWriteStackTrace* procs return text not an object), so I'd have to reimplment those.... (which is why I just turned the string into a sequence) |
| 18:15:15 | dom96 | bogen: kinda |
| 18:15:29 | dom96 | I don't really need that function for what i'm doing right now |
| 18:23:32 | * | Matthias247 joined #nimrod |
| 18:35:44 | * | nande quit (Remote host closed the connection) |
| 18:36:18 | * | Trustable joined #nimrod |
| 19:03:22 | Araq | skyfex: nimrod supported TCC |
| 19:04:25 | Araq | compiler/tccgen.nim |
| 19:04:55 | Araq | it's been disabled because it doesn't work anymore with recent versions of linux |
| 19:05:04 | Araq | linker scripts etc. |
| 19:05:18 | Araq | standard C headers are full of magic and GCC specific |
| 19:06:35 | Araq | without constant maintenance these things don't work |
| 19:10:52 | Araq | oh sorry ... I should have read the full history lol |
| 19:13:24 | Araq | skyfex: mat3 wrote some native codegen backends but once they are incorporated, we'll have a JIT, not a static compiler |
| 19:14:01 | Araq | I guess adding more code so that ELF binaries are produced is not too hard though |
| 19:14:02 | OrionPK | no static compiler? |
| 19:14:27 | Araq | OrionPK: no static compiler according to mat3 |
| 19:14:45 | OrionPK | what about the c-like performance |
| 19:15:36 | Araq | what about it? the C backend will not go away |
| 19:16:07 | OrionPK | oh ok |
| 19:16:16 | OrionPK | thought u meant no static compilation |
| 19:26:48 | * | tinAndi joined #nimrod |
| 19:27:18 | Varriount | Meep |
| 19:31:34 | Varriount | Araq: How should the compiler handle cast[ValueType](nil) ? |
| 19:31:50 | Araq | just reject it |
| 19:32:12 | Araq | cast to 'nil' should never be allowed |
| 19:32:48 | Varriount | Araq: What about for pointers? |
| 19:33:14 | Araq | cast to 'nil' should never be allowed |
| 19:34:55 | dom96 | hey Araq |
| 19:35:24 | Araq | dom96! |
| 19:37:26 | Varriount | Araq: Just to confirm, when you say "cast to 'nil' should never be allowed" you mean 'cast[nil](value)', right? |
| 19:38:17 | Araq | let me put it this way: |
| 19:38:24 | * | wan joined #nimrod |
| 19:38:45 | Araq | the 'expr' in cast[nil](expr) is irrelevant, casting to 'nil' makes no sense whatsoever |
| 19:39:29 | dom96 | Araq: Did you see my commit? :P |
| 19:39:45 | Araq | dom96: only the message |
| 19:40:10 | Varriount | Araq: But casting nil to a pointer is done throughout wrapper code. |
| 19:40:21 | Araq | what? |
| 19:40:43 | Araq | Varriount: cast[Foo](nil) is different |
| 19:41:09 | Araq | which wrappers use cast[nil](expr) ? |
| 19:42:19 | Varriount | None - I never said wrappers did. |
| 19:42:25 | skyfex | Araq: I don't mind the C backend, it's quite a nice way to easily hook into all the optimization work that's been done for C. Making an optimizing compiler is not something that's done overnight |
| 19:43:00 | Varriount | I was just confused, because I was talking cast[expr](nil) and you were talking about cast[nil](expr) |
| 19:43:24 | Varriount | Araq: Just for reference, I'm trying to fix https://github.com/Araq/Nimrod/issues/1435 |
| 19:43:33 | skyfex | What's the status of LLVM backend though? |
| 19:44:29 | Varriount | Nonexistant, I think. |
| 19:45:02 | Araq | is there something the LLVM backend can do, that clang can't? |
| 19:45:21 | Araq | I guess efficient integer overflow detection |
| 19:45:37 | dom96 | Araq: We will have to look into somehow making the stack traces nicer. |
| 19:46:56 | skyfex | Araq: No, can't think of any feature-wise reason to go directly to LLVM bytecode. Only compiler speed, which is good as it is anyway. Perhaps also an idea of elegance? |
| 19:47:20 | Araq | dom96: the stack traces are as nice as they get (ignoring the bug that's left) |
| 19:48:10 | dom96 | Araq: I'm not talking about the macro issues. This is entirely different and I think you need to experience it yourself :P |
| 19:49:22 | Araq | skyfex: before I write an LLVM backend, I'll write a GPU backend |
| 19:50:34 | Araq | brb |
| 19:50:38 | skyfex | Araq: Ah, yeah. You should perhaps look into Outtrack's Realtime Studio/Uno |
| 19:50:40 | NimBot | Araq/Nimrod devel 7358fc2 Dominik Picheta [+0 ±4 -0]: More future debug info. Added new error code to SafeDisconn list. |
| 19:50:51 | skyfex | Some people I know working on it.. |
| 19:51:12 | skyfex | Seamlessly splits code into GPU and CPU code |
| 19:51:32 | skyfex | I haven't tried it, but it looks very promising on the surface |
| 19:51:52 | skyfex | Good people working on it too, lot's of old demoscene guys |
| 19:51:55 | skyfex | *lots |
| 19:53:45 | NimBot | dom96/jester new-async a39cee6 Dominik Picheta [+0 ±1 -0]: Fixes crash on invalid req method. |
| 19:55:49 | flaviu | skyfex: easier gc, easy exceptions, faster stack traces |
| 19:57:01 | dom96 | http://forum.nimrod-lang.org:8080/ |
| 19:57:11 | dom96 | 3rd time lucky |
| 20:03:59 | def- | dom96: when i click on reply or edit post nothing happens |
| 20:04:13 | dom96 | yeah, known bug. |
| 20:04:19 | dom96 | I'm mostly looking for crashes though |
| 20:04:22 | def- | ok |
| 20:04:41 | skyfex | dom96: What's new? |
| 20:05:24 | dom96 | skyfex: It's using the new async await features. |
| 20:09:38 | Araq | oh no, not demoscene guys |
| 20:09:43 | * | superfunc joined #nimrod |
| 20:10:18 | skyfex | Araq: Heh, what's your problem with them? |
| 20:10:25 | * | brson joined #nimrod |
| 20:10:45 | dom96 | Demoscene is awesome! |
| 20:10:47 | Araq | they tend to be smarter than me :P |
| 20:12:11 | Varriount | Araq: In the compiler code, how would I test if a the type a PTyp represents is larger than a pointer? |
| 20:13:23 | Araq | typ.getSize > platform.ptrSize |
| 20:13:31 | Araq | or something like that |
| 20:16:38 | flaviu | Well, dom96, it doesn't see, to be crashing |
| 20:16:47 | flaviu | *seem |
| 20:16:54 | dom96 | flaviu: lol, is that you DoS'ing it? |
| 20:17:03 | flaviu | no very efficently |
| 20:17:06 | flaviu | *not |
| 20:17:18 | flaviu | I just ran a bunch of wget on it |
| 20:17:38 | dom96 | it was using 100% CPU |
| 20:18:05 | flaviu | that's not good... |
| 20:18:21 | dom96 | Jester does print a lot of crap though |
| 20:18:37 | flaviu | why does it take 60ms to generate a page? |
| 20:19:03 | dom96 | No idea |
| 20:19:15 | Araq | flaviu: the forum is usually deployed as non optimized debug build |
| 20:19:25 | dom96 | oh yes, that. |
| 20:19:28 | flaviu | Still shouldn't take that long... |
| 20:19:37 | dom96 | Maybe sqlite is also just slow. |
| 20:19:47 | flaviu | lol no |
| 20:19:51 | Araq | no sqlite is fast |
| 20:20:00 | flaviu | dom96: The queries might be slow |
| 20:20:25 | dom96 | Yeah. That's what I meant :P |
| 20:20:26 | Varriount | It's no use guessing; what needs to be done is profiling. |
| 20:20:44 | dom96 | I'll compile it in release mode |
| 20:21:31 | flaviu | dom96: realistic side channel attack here: https://github.com/nimrod-code/nimforum/blob/master/forum.nim#L414 |
| 20:21:44 | dom96 | Doesn't seem to affect the time. |
| 20:22:22 | dom96 | what is a side channel attack? |
| 20:22:43 | flaviu | An attack that doesn't attack the crypto, it just goes around it |
| 20:23:05 | Varriount | Also, is the password sent plaintext? |
| 20:23:20 | dom96 | how can someone get around that? |
| 20:23:25 | * | Varriount notices the lack of 'https' in the URL |
| 20:23:32 | dom96 | Varriount: yes |
| 20:24:05 | Varriount | O_o |
| 20:24:40 | flaviu | dom96: If the first character in the hashed password is not equal to the first char in the hashed db password, then the string comparison will break out eary |
| 20:25:00 | flaviu | which can be taken advnatage of to determene an account |
| 20:25:03 | dom96 | flaviu: Can you run wget on it again? |
| 20:25:06 | flaviu | 's salted password |
| 20:25:22 | flaviu | and hash, etc |
| 20:25:36 | Varriount | flaviu: Isn't that one of the more 'theoretical' attacks? |
| 20:25:47 | flaviu | No, its one of the more practical of the theoretical attacks |
| 20:27:06 | flaviu | http://codahale.com/a-lesson-in-timing-attacks/ |
| 20:27:21 | dom96 | flaviu: fix it then |
| 20:27:24 | Varriount | I'd be more worried about my login password being sent in the clear when I'm trying to log in :/ |
| 20:27:37 | flaviu | dom96: Too lazy lol |
| 20:27:41 | flaviu | easier to complain |
| 20:27:55 | dom96 | of course... |
| 20:28:02 | dom96 | ugh, it's way too easy to DoS this. |
| 20:28:28 | dom96 | The DB access is not async yet though |
| 20:29:18 | dom96 | But at least it finally works. |
| 20:30:19 | EXetoC | Varriount: so negative :p |
| 20:30:29 | flaviu | dom96: Use an transaction! |
| 20:30:53 | dom96 | I'll leave it running and we'll see if it lasts. |
| 20:30:56 | flaviu | I dunno if it'll help, but it got execution time down from 10 min or so to less than a second when I was inserting some stuff |
| 20:31:30 | dom96 | i'll worry about that alter |
| 20:31:31 | dom96 | *later |
| 20:33:57 | Araq | flaviu: awesome link, thanks for sharing! |
| 20:34:40 | Araq | that means we need a safeEquals |
| 20:37:31 | Varriount | Which is tricky, because you usually need to tell the compiler that nothing should be done to optimize that comparison code. |
| 20:38:55 | flaviu | Which is why you should use a library made by people who know what they are doing |
| 20:39:51 | flaviu | Anyway, they say that the resolution of timing attacks over a LAN is not less than 100ns |
| 20:40:16 | flaviu | I don;t think that compilers do that gross of optimizations |
| 20:42:28 | Varriount | flaviu: "A library made by people who know what they are doing" <- Like the OpenSSL team? |
| 20:42:46 | Varriount | Araq: Is this PR acceptable? https://github.com/Araq/Nimrod/pull/1468 |
| 20:42:51 | flaviu | I don't think they had problems with their string comparisons |
| 20:43:09 | flaviu | Although they did do some stupid stuff... |
| 20:54:02 | Araq | hu? did we read the same article? |
| 20:55:12 | Araq | Varriount: yes |
| 20:55:19 | NimBot | Araq/Nimrod devel e46a735 Clay Sweetser [+0 ±1 -0]: Fixes #1435 |
| 20:55:19 | NimBot | Araq/Nimrod devel f8ea5f1 Clay Sweetser [+0 ±2 -0]: Adds documentation on skipTypes and mapType |
| 20:55:19 | NimBot | Araq/Nimrod devel 0f15ebf Andreas Rumpf [+0 ±3 -0]: Merge pull request #1468 from Varriount/fix-1435... 2 more lines |
| 21:04:19 | flaviu | Araq: Yes, "Internet induces significant timing jitter, we can reliably distinguish remote timing differences as low as 20µs. A LAN environment has lower timing jitter, allowing us to reliably distinguish remote timing differences as small as 100ns" |
| 21:04:29 | * | johnsoft quit (Read error: Connection reset by peer) |
| 21:04:37 | * | johnsoft joined #nimrod |
| 21:06:11 | Araq | flaviu: well I don't get it. the line in nimforum is a string == |
| 21:06:32 | Araq | and now you tell me it's not a string comparison that's been the problem |
| 21:07:11 | flaviu | sorry if I was unclear. I do mean that the problem is the string comparison |
| 21:20:12 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 21:20:52 | * | tinAndi quit (Quit: ChatZilla 0.9.90.1 [Firefox 31.0/20140716183446]) |
| 21:24:50 | Araq | ping Varriount |
| 21:27:28 | * | Jehan_ joined #nimrod |
| 21:36:36 | * | flaviu quit (Read error: Connection reset by peer) |
| 21:38:32 | bogen | Varriount: can you point me towards compiler documentation? |
| 21:45:00 | * | wan quit (Ping timeout: 250 seconds) |
| 21:57:57 | * | superfunc quit (Ping timeout: 272 seconds) |
| 21:59:51 | * | bogen quit (Quit: Leaving.) |
| 22:08:26 | Varriount | Araq: Pong |
| 22:08:37 | Varriount | Araq: I got the comment on the isHidden() proc |
| 22:08:47 | * | bogen joined #nimrod |
| 22:10:36 | Araq | Varriount: where is the gist about how the compiler works? |
| 22:18:40 | * | ARCADIVS quit (Quit: WeeChat 0.4.3) |
| 22:24:54 | Varriount | Araq: Uh.. I'm looking for it. |
| 22:27:29 | * | tinAndi joined #nimrod |
| 22:28:52 | * | Varriount_ joined #nimrod |
| 22:29:29 | * | Varriount quit (Disconnected by services) |
| 22:29:35 | * | Varriount_ is now known as Varriount |
| 22:29:46 | Varriount | Araq: https://gist.github.com/Varriount/a58f39b40f7da93feb8b |
| 22:31:31 | dom96 | Varriount: Please clean it up and put it on the wiki. |
| 22:41:40 | Varriount | Araq: What is the aliases module used for currently? |
| 22:42:15 | Varriount | Araq: My notes state that it was originally used for term-rewriting macros, but it is now used for "something completely different" |
| 22:42:55 | Araq | no |
| 22:47:49 | Varriount | Araq: Uh, could you explain? |
| 22:48:45 | Varriount | dom96: You do know that most of the compiler modules contain comments at the top of their source which contains information on the module, right? |
| 22:49:54 | dom96 | Varriount: Having all this information on one page is good. |
| 22:52:57 | * | tinAndi quit (Quit: ChatZilla 0.9.90.1 [Firefox 31.0/20140716183446]) |
| 22:58:18 | * | darkf joined #nimrod |
| 23:00:32 | * | superfunc joined #nimrod |
| 23:01:28 | * | Boscop quit (Read error: Connection reset by peer) |
| 23:01:54 | * | Boscop joined #nimrod |
| 23:04:39 | Araq | Varriount: it IS used for better code generation |
| 23:04:47 | Araq | and then was used for TR macros |
| 23:04:55 | Araq | but these have different requirements |
| 23:06:10 | Araq | well it still IS used for TR macros too |
| 23:06:17 | Araq | but it's broken for them |
| 23:07:14 | * | brson quit (Quit: leaving) |
| 23:13:49 | * | skyfex quit (Quit: Computer has gone to sleep.) |
| 23:31:04 | * | superfunc quit (Ping timeout: 272 seconds) |
| 23:38:08 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 23:42:08 | * | superfunc joined #nimrod |