00:01:03 | kjo1 | good to know! |
00:01:52 | * | xificurC quit (Ping timeout: 240 seconds) |
00:03:11 | * | reem_ joined #nim |
00:03:27 | * | BlaXpirit quit (Quit: Quit Konversation) |
00:04:48 | * | clynamen quit (Ping timeout: 246 seconds) |
00:05:55 | k1i | are nim arrays compatible with C-arrays? docs weren't clear |
00:06:55 | * | clynamen joined #nim |
00:08:14 | * | mpthrapp joined #nim |
00:08:15 | fowl | compatible in what sense |
00:09:12 | fowl | array[1,int] should be int[1] |
00:09:22 | k1i | +1 |
00:09:23 | k1i | thanks |
00:09:31 | kjo1 | omg |
00:10:06 | kjo1 | (sorry wrong window) |
00:11:23 | * | brson quit (Quit: leaving) |
00:11:57 | * | brson joined #nim |
00:18:35 | reactormonk | kjo1, nice ^^ |
00:20:12 | * | bcinman joined #nim |
00:20:59 | * | Matthias247 quit (Read error: Connection reset by peer) |
00:21:06 | * | bcinman_ quit (Read error: Connection reset by peer) |
00:21:36 | * | reem_ quit (Remote host closed the connection) |
00:21:42 | * | TEttinger joined #nim |
00:22:38 | * | TEttinger quit (Client Quit) |
00:23:30 | * | TEttinger joined #nim |
00:29:03 | kjo1 | Has anyone thought about making an ipython/jupyter kernel for nim? In some sense that would happen after the REPL, but thought I'd ask ... |
00:30:22 | EXetoC | "for x in coll.find: ..." -> no segfault, "for x in toSeq(coll.find): ... " -> segfault somewhere in the loop *shrug* |
00:30:26 | flaviu | kjo1: That seems like a good idea. |
00:31:02 | EXetoC | one day I'll be able to write code without stumbling into issues every other line |
00:31:03 | flaviu | the current repl doesn't do FFI and still has occasional bugs, btw. |
00:31:22 | EXetoC | one can dream |
00:34:39 | EXetoC | at some point I'll have to blame stupidity rather than bad luck :p |
00:35:46 | flaviu | I've been looking at Sphinx, and it seems like it shouldn't be too hard to make it do nim. |
00:37:01 | reactormonk | flaviu, not the search engine I assume? |
00:37:10 | EXetoC | it has sections and such I assume |
00:37:30 | EXetoC | haven't used it yet |
00:37:31 | flaviu | reactormonk: Nope, http://sphinx-doc.org/ |
00:38:32 | reactormonk | flaviu, could we replace nim doc with that? |
00:39:07 | flaviu | reactormonk: Doubt araq would go along with that, but it could be an unofficial alternative. Looking to see if it's possible to leverage nimc to avoid having to parse nim. |
00:39:34 | reactormonk | flaviu, non-nim doc builder? heresy! |
00:39:50 | EXetoC | might as well use something with more features in the meantime, if necessary |
00:39:58 | reactormonk | EXetoC, like? |
00:40:18 | girvo | Sphinx is used by a lot of projects these days. Pretty sure "readthedocs" is based on it too |
00:40:41 | girvo | https://readthedocs.org/ |
00:40:54 | flaviu | Yep, like the beautiful Python Requests docs. |
00:40:56 | EXetoC | reactormonk: I mean than what we have |
00:41:03 | flaviu | and it has search too! |
00:41:25 | reactormonk | yup, the search is what makes it awesome. |
00:42:16 | EXetoC | much less work than improving doc2? |
00:42:26 | * | bcinman_ joined #nim |
00:42:29 | flaviu | *much less* |
00:42:33 | * | bcinman quit (Read error: Connection reset by peer) |
00:42:49 | flaviu | All I've got to do is replace https://bitbucket.org/birkenfeld/sphinx/src/40bd03003ac6fe274ccf3c80d7727509e00a69ea/sphinx/ext/autodoc.py?at=default with something that takes nim. |
00:44:14 | * | MagusOTB joined #nim |
00:45:41 | EXetoC | go nuts |
00:54:16 | reactormonk | flaviu, go for it? I can help you next two days |
00:54:46 | flaviu | Well, looks like nim has jsondoc. That looks useful. Unfortunately it segfaults, but I think I've got a patch |
00:55:01 | EXetoC | and then port sphinx to nim \o/ |
00:55:15 | flaviu | EXetoC: Are you working on py2nim? |
00:55:25 | flaviu | ;) |
00:57:35 | EXetoC | not yet |
00:58:47 | * | brson quit (Quit: leaving) |
01:04:17 | reactormonk | flaviu, going for the sphinx stuff? |
01:04:49 | * | bcinman_ quit (Ping timeout: 245 seconds) |
01:05:02 | flaviu | reactormonk: yep |
01:05:10 | flaviu | I'm digging around in docgen right now |
01:05:20 | reactormonk | sweet |
01:06:31 | * | bcinman joined #nim |
01:08:58 | EXetoC | will it be able to categorise based on the first argument? |
01:13:26 | flaviu | hmm, yeah, that is a problem |
01:14:42 | EXetoC | it ought to be flexible if it is to be language-agnostic |
01:17:45 | * | bcinman_ joined #nim |
01:18:35 | * | bcinman quit (Ping timeout: 256 seconds) |
01:20:42 | * | tmku quit (Ping timeout: 256 seconds) |
01:21:59 | flaviu | reactormonk: I'll work out all the bugs in jsondoc, but EXetoC does have a point. |
01:22:13 | flaviu | Docgen is of limited usefulness if it doesn't somehow sort by first parameter type. |
01:22:51 | reactormonk | flaviu, jsondoc produces a json? |
01:23:31 | flaviu | yep, but atm it crashes. see https://github.com/flaviut/Nim/commit/ca38246d21b32a294c97e99657d97f5ef493aefb for a fix |
01:23:36 | EXetoC | indirectly at least, by giving more control to the plugin |
01:24:36 | * | reem joined #nim |
01:26:38 | * | bcinman_ quit (Ping timeout: 265 seconds) |
01:27:03 | * | tmku joined #nim |
01:27:50 | reactormonk | flaviu, put a PR up |
01:28:05 | reactormonk | ... if it works as expected |
01:28:14 | flaviu | reactormonk: I will, I've got some other stuff I'd like to change first though. |
01:30:16 | * | bcinman joined #nim |
01:34:54 | * | filwit quit (Quit: Leaving) |
01:45:13 | * | bcinman quit (Ping timeout: 256 seconds) |
01:52:22 | * | bcinman joined #nim |
01:53:32 | * | banister joined #nim |
02:00:28 | * | darkf joined #nim |
02:09:10 | * | bcinman quit (Ping timeout: 265 seconds) |
02:09:47 | * | saml_ joined #nim |
02:19:23 | * | bcinman joined #nim |
02:21:09 | * | dhasenan quit (Remote host closed the connection) |
02:23:49 | * | fizzbooze quit (Ping timeout: 264 seconds) |
02:27:14 | * | jholland quit (Quit: Connection closed for inactivity) |
02:32:08 | * | chemist69_ joined #nim |
02:32:13 | * | bcinman quit (Ping timeout: 264 seconds) |
02:32:28 | * | mwbrown quit (Ping timeout: 244 seconds) |
02:34:39 | * | bcinman joined #nim |
02:35:15 | * | chemist69 quit (Ping timeout: 250 seconds) |
02:46:38 | * | bcinman quit (Ping timeout: 252 seconds) |
02:49:03 | * | bcinman joined #nim |
02:58:37 | * | bcinman quit (Ping timeout: 264 seconds) |
02:59:18 | * | kjo1 quit (Quit: Leaving.) |
03:00:30 | * | bcinman joined #nim |
03:03:14 | * | elbow_jason joined #nim |
03:04:26 | * | elbow_jason quit (Client Quit) |
03:06:38 | * | brson joined #nim |
03:14:09 | * | bcinman quit (Read error: Connection reset by peer) |
03:14:24 | * | bcinman joined #nim |
03:33:06 | * | dtscode joined #nim |
03:38:28 | * | brson quit (Quit: leaving) |
03:42:57 | * | bcinman_ joined #nim |
03:44:01 | * | bcinman quit (Read error: Connection reset by peer) |
04:09:24 | * | reem quit (Remote host closed the connection) |
04:10:54 | * | elbow_jason joined #nim |
04:13:45 | * | reem joined #nim |
04:16:13 | * | saml_ quit (Quit: Leaving) |
04:19:10 | * | fizzbooze joined #nim |
04:34:12 | cazov | hi, while reading about the website on the forums I noticed that the link bar on the top right has different entries when in the forums versus when in other parts of the site. the entries while viewing the forums are: "home, docs, learn, download, forum, faq" and the logo is clickable and goes to forums.nim-lang.org. on all other sections the entries are "learn, docs, download, support, forum, faq" and the logo goes to nim-lang.org/index.html |
04:35:17 | * | fizzbooze quit (Quit: WeeChat 1.1.1) |
04:35:30 | * | fizzbooze joined #nim |
04:56:55 | * | elbow_json joined #nim |
04:57:30 | * | elbow_jason quit (Read error: Connection reset by peer) |
04:59:02 | * | a5i quit (Quit: Connection closed for inactivity) |
04:59:13 | * | elbow_json quit (Client Quit) |
04:59:18 | * | elbow_jason joined #nim |
04:59:35 | reactormonk | cazov, yeah, gotta bug dom96 about that |
04:59:56 | cazov | ok, next time I am lurking and I see him talking I will ping him again :] |
05:05:00 | * | reem quit (Remote host closed the connection) |
05:05:43 | * | elbow_jason quit (Quit: Leaving) |
05:07:40 | * | reem joined #nim |
05:15:18 | * | gsingh93 quit (Ping timeout: 264 seconds) |
05:18:20 | * | CryptoToad joined #nim |
05:18:41 | CryptoToad | Hey, anyone have experience setting callback methods for setWindowsHookEx? |
05:19:14 | CryptoToad | I've done it in C++ but I can't figure out how to do it in nim |
05:20:35 | CryptoToad | Should I just do them inline with embedded C? |
05:28:54 | fowl | CryptoToad, whats the problem |
05:29:40 | CryptoToad | I just can't figure out how to declare the callback functions, I see that setWindowHookEx takes a HOOKPROC as a parameter but no matter what I can't cast my proc or a pointer to it into that variable. |
05:29:51 | * | gsingh93 joined #nim |
05:30:09 | CryptoToad | ready to do the whole thing with .emit lol |
05:31:15 | fowl | do you use windows or winlean |
05:31:33 | CryptoToad | windows |
05:32:16 | fowl | HOOKPROC* = proc (para1: int32; para2: WPARAM; para3: LPARAM): LRESULT {.stdcall.} |
05:32:26 | fowl | you need stdcall pragma |
05:33:41 | Varriount | CryptoToad: Using Windows API's? |
05:34:32 | Varriount | CryptoToad: Just an FYI, the windows module isn't entirely tested, so the wrappings should be double-checked before use. |
05:34:50 | Varriount | It was translated from a Pascal module originally. |
05:34:59 | CryptoToad | Ahh, so here be dragons? |
05:35:19 | CryptoToad | I'm going to try just adding the pragma |
05:35:48 | Varriount | CryptoToad: Usually things work fine (for 32 bit programs) |
05:36:14 | Varriount | Occasionally there is a mistake in the size of a type, or the number of parameters, etc. |
05:36:28 | CryptoToad | ahh gotcha |
05:43:23 | CryptoToad | Got that fixed, or at least it compiles |
05:43:24 | CryptoToad | thanks guys |
05:59:25 | * | phira quit (Quit: ZNC - http://znc.sourceforge.net) |
06:03:09 | * | fizzbooze quit (Ping timeout: 245 seconds) |
06:25:19 | CryptoToad | I don't think the types on the message loop function arguments are right |
06:30:00 | CryptoToad | nvm |
06:46:30 | * | xificurC joined #nim |
06:53:42 | * | ehaliewicz quit (Ping timeout: 264 seconds) |
07:01:50 | * | CryptoToad quit (Quit: Leaving) |
07:04:49 | * | gsingh93 quit (Ping timeout: 245 seconds) |
07:09:21 | * | Demon_Fox quit (Quit: Leaving) |
07:18:53 | * | banister quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
07:27:25 | * | shodan45 quit (Ping timeout: 255 seconds) |
07:31:24 | * | shodan45 joined #nim |
07:43:32 | * | BlaXpirit joined #nim |
07:55:15 | * | banister joined #nim |
08:39:30 | * | irrequietus joined #nim |
08:44:54 | ekarlso | shalabh: nah, nvm would be too similar to the Node JS thing |
08:45:53 | * | irrequietus quit () |
08:49:26 | * | Trustable joined #nim |
08:50:26 | * | irrequietus joined #nim |
08:52:58 | * | epichero quit (Remote host closed the connection) |
08:55:48 | * | Trustable quit (Remote host closed the connection) |
08:56:33 | * | Trustable joined #nim |
09:03:03 | * | zahary quit (Read error: Connection reset by peer) |
09:03:15 | * | zahary joined #nim |
09:08:57 | * | tumult joined #nim |
09:09:07 | * | bcinman_ quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
09:18:43 | * | reem quit (Remote host closed the connection) |
09:31:12 | * | BlaXpirit quit (Read error: Connection reset by peer) |
09:32:08 | * | BlaXpirit joined #nim |
09:53:46 | * | epichero joined #nim |
09:58:37 | * | epichero quit (Ping timeout: 255 seconds) |
10:37:17 | * | TEttinger quit (Ping timeout: 252 seconds) |
10:39:11 | * | a5i joined #nim |
10:53:34 | * | girvo quit (Ping timeout: 245 seconds) |
11:09:31 | * | epichero joined #nim |
11:14:13 | * | epichero quit (Ping timeout: 255 seconds) |
11:30:49 | * | banister quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
11:34:22 | * | banister joined #nim |
11:44:39 | * | sepisoad joined #nim |
11:50:06 | * | girvo joined #nim |
11:54:41 | * | girvo quit (Ping timeout: 250 seconds) |
12:19:20 | * | reem joined #nim |
12:20:17 | * | girvo joined #nim |
12:23:51 | * | reem quit (Ping timeout: 256 seconds) |
12:25:01 | * | girvo quit (Ping timeout: 264 seconds) |
12:44:31 | * | chemist69_ quit (Quit: WeeChat 1.1.1) |
13:00:05 | * | mwbrown joined #nim |
13:00:19 | * | nimnoob123 joined #nim |
13:00:36 | nimnoob123 | Can anyone help me w/ this aporia issue? https://github.com/nim-lang/Aporia/issues/77 |
13:07:33 | * | jfchevrette joined #nim |
13:09:49 | * | jfchevrette quit (Client Quit) |
13:09:51 | * | banister quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
13:12:49 | * | kjo1 joined #nim |
13:25:00 | * | mpthrapp_ joined #nim |
13:25:16 | * | epichero joined #nim |
13:26:34 | * | Ven joined #nim |
13:29:44 | * | epichero quit (Ping timeout: 246 seconds) |
13:30:14 | * | clone1018_ quit (Read error: Connection reset by peer) |
13:32:30 | Araq | nimnoob123: you need to compile aporia with nim devel |
13:32:40 | nimnoob123 | I did |
13:33:27 | nimnoob123 | Nim Compiler Version 0.10.3 (2015-03-19) [Windows: i386] |
13:34:03 | nimnoob123 | unless nim devel means something totally different |
13:34:20 | * | mwbrown quit (Ping timeout: 272 seconds) |
13:34:25 | EXetoC | no, it hasn't been released |
13:36:05 | EXetoC | so it's definitely the devel version that you have |
13:36:33 | nimnoob123 | i did a git pull from the repo about an hour ago |
13:39:43 | nimnoob123 | EXetoC: http://i.imgur.com/sR81V4v.png 110% sure |
13:40:14 | * | clone1018_ joined #nim |
13:40:15 | * | clone1018_ quit (Remote host closed the connection) |
13:40:34 | Araq | nimnoob123: you also need @head from the gtk2 nimble package |
13:41:01 | nimnoob123 | that i might not have, sec |
13:41:18 | EXetoC | that's what I'm saying, and the date is right there :-) |
13:42:14 | nimnoob123 | EXetoC: ? |
13:42:38 | EXetoC | how about defaulting to HEAD at this point? |
13:43:00 | nimnoob123 | the only thing i didn't have was the gtk2 nimble package |
13:43:45 | nimnoob123 | which actually isn't listed anywhere here https://github.com/nim-lang/Aporia on the readme, going to recompile now |
13:44:08 | nimnoob123 | i didn't install aporia through nimble btw |
13:44:11 | EXetoC | but, "Requires: "nimrod >= 0.9.2, gtk2#head"" |
13:44:58 | EXetoC | that syntax is not used anymore though, I think, and a .nimble file hasn't even been added yet |
13:45:21 | nimnoob123 | again nothing on that aporia readme says anything regarding gtk2 nimble package |
13:45:24 | EXetoC | perhaps it works because it is a .babel. things are changing quickly |
13:45:49 | EXetoC | nimnoob123: no, but it is a dependency as you can see, and so it should be installed automatically if things work correctly |
13:45:51 | nimnoob123 | works now Araq, thanks |
13:47:05 | EXetoC | did aporia@#head alone not work? |
13:47:17 | nimnoob123 | EXetoC: that's not really my point, point is it's 8am, barely had a sip of coffee and the Readme.md doesn't mention it and it should. Sure when I'm fully awake maybe my brain would go "hey how about checking that nimble/babel file to see if im missing a package |
13:47:34 | nimnoob123 | simple solution would just to add that little detail to the read me file lol |
13:48:45 | nimnoob123 | and like I said before I didn't install aporia through nimble |
13:50:14 | * | clone1018_ joined #nim |
13:50:15 | * | clone1018_ quit (Remote host closed the connection) |
13:51:59 | * | gokr quit (Quit: Leaving.) |
13:54:29 | * | pregressive joined #nim |
13:54:59 | nimnoob123 | so now I'm going to do a PR to include that small detail in the readme if you're installing by cloning the repo instead of installing through nimble :D |
13:55:41 | * | BlaXpirit quit (Quit: Quit Konversation) |
13:57:41 | EXetoC | you want it to be mentioned in every package? it just seems a little redundant |
13:58:17 | * | BlaXpirit joined #nim |
13:59:07 | EXetoC | or just for "core" packages? |
14:00:13 | * | clone1018_ joined #nim |
14:00:14 | * | clone1018_ quit (Remote host closed the connection) |
14:04:32 | EXetoC | redundant as in it's not a package-specific piece of information |
14:05:12 | nimnoob123 | it's aporia specific |
14:05:43 | * | pregressive quit () |
14:05:53 | EXetoC | I was referring to this "hey how about checking that nimble/babel file to see if im missing a package" |
14:06:49 | nimnoob123 | that's not even what I was talking about PRing |
14:07:22 | nimnoob123 | All I did was add gtk2 to the aporia dependencies readme file, that's it. leaving it there |
14:08:44 | nimnoob123 | Going to go work now and it's cool that I've finally got aporia working and will play with that later. |
14:08:54 | * | nimnoob123 quit (Quit: Page closed) |
14:09:03 | * | girvo joined #nim |
14:10:13 | * | clone1018_ joined #nim |
14:10:14 | * | clone1018_ quit (Remote host closed the connection) |
14:13:37 | * | girvo quit (Ping timeout: 264 seconds) |
14:20:13 | * | clone1018_ joined #nim |
14:20:14 | * | clone1018_ quit (Remote host closed the connection) |
14:21:23 | * | banister joined #nim |
14:21:28 | * | banister quit (Max SendQ exceeded) |
14:26:06 | * | epichero joined #nim |
14:27:06 | * | banister joined #nim |
14:29:54 | * | zahary quit (Ping timeout: 252 seconds) |
14:30:14 | * | clone1018_ joined #nim |
14:30:14 | * | clone1018_ quit (Remote host closed the connection) |
14:30:39 | * | epichero quit (Ping timeout: 245 seconds) |
14:39:04 | * | sepisoad quit (Quit: Leaving) |
14:40:13 | * | clone1018_ joined #nim |
14:40:14 | * | clone1018_ quit (Remote host closed the connection) |
14:48:32 | * | jholland joined #nim |
14:50:14 | * | clone1018_ joined #nim |
14:50:14 | * | clone1018_ quit (Read error: Connection reset by peer) |
14:50:45 | * | zahary joined #nim |
14:53:34 | * | darkf quit (Quit: Leaving) |
14:55:24 | kjo1 | Any one have any experience manipulating Image's using the Javascript DOM? I'm having trouble going from a TNode to a TImage (let imageObj:TImage = document.getElementById("source")) |
15:06:13 | Araq | kjo1: 'cast' it? |
15:06:53 | * | reem joined #nim |
15:09:50 | * | girvo joined #nim |
15:10:08 | * | ehaliewicz joined #nim |
15:10:10 | kjo1 | Araq, that's not a bad idea … |
15:10:14 | * | clone1018_ joined #nim |
15:10:14 | * | clone1018_ quit (Read error: Connection reset by peer) |
15:10:27 | kjo1 | just wondering if they should be related in the object hierarchy |
15:14:16 | * | girvo quit (Ping timeout: 256 seconds) |
15:18:25 | kjo1 | I was able to successfully add an image to the DOM using: let imageObj = cast[ref TImage](document.createElement("IMG")) |
15:19:06 | * | brson joined #nim |
15:20:26 | kjo1 | creating an imageObj like this: let imageObj = new TImage gives me an error in the javascript though |
15:22:40 | * | tumult quit (Ping timeout: 246 seconds) |
15:23:41 | kjo1 | maybe creating Image elements with TImage is not correct |
15:24:56 | * | sepisoad joined #nim |
15:25:35 | * | epichero joined #nim |
15:29:02 | sepisoad | i'm tryin to port fltk to nim using c2nim, unfortunately c2nim fails at converting most header files |
15:29:10 | sepisoad | for example this one: https://github.com/rageworx/fltk-1.3.3-ts/blob/master/FL/Fl.H |
15:29:59 | sepisoad | i have trouble using c2nim, maybe you can help me |
15:30:14 | * | clone1018_ joined #nim |
15:30:14 | * | clone1018_ quit (Remote host closed the connection) |
15:32:02 | def- | sepisoad: you will have to change the parts that fail |
15:32:35 | sepisoad | I ended up commenting most of the failed parts :( |
15:32:49 | sepisoad | ant that's not going to work for me |
15:33:20 | sepisoad | for example Fl.H(50, 0) Error: ';' expected |
15:33:30 | sepisoad | I don't get it |
15:35:07 | def- | Maybe a #def instead of #define: http://nim-lang.org/c2nim.html#def-directive |
15:36:10 | tstm | def-: For fun, I tried out something else on the nbody thing. It's not faster, in fact it seems to be a touch slower, but less repetition. http://tstm.info/files/nbody_5.nim |
15:37:50 | * | arnetheduck quit (Ping timeout: 272 seconds) |
15:37:53 | def- | tstm: cool |
15:38:28 | EXetoC | sepisoad: it usually requires some manual work |
15:39:01 | EXetoC | but less than if you had done everything manually |
15:39:03 | * | Stefan_S joined #nim |
15:39:07 | * | gokr joined #nim |
15:39:09 | reactormonk | Araq, what's the official way to map javascript functions that are defined on an object, but only used in direct reference e.g. window.foobar()? I've assume it's proc foobar() {.importc: "window.foobar".} |
15:40:08 | Stefan_S | sepisoad, are you using Nim comment markers # for C code? Will not work! |
15:40:13 | * | clone1018_ joined #nim |
15:40:14 | * | clone1018_ quit (Remote host closed the connection) |
15:40:54 | sepisoad | Stefan_S, you mean I use nim comment in c Code??? |
15:41:22 | Araq | reactormonk: yes |
15:41:38 | Stefan_S | Yes, a very short look at you given file link give me that impression. |
15:42:15 | sepisoad | no, no, I'm not that dump ;) |
15:42:19 | reactormonk | Araq, hm. it's different in dom.nim where they are attached to an object an then exposed via var window: ref TWindow |
15:43:00 | reactormonk | on another note, what is {.nimcall.} in JS? |
15:43:29 | sepisoad | Stefan_S, for example a line like this would fail: |
15:43:30 | sepisoad | #define FL_SOCKET unsigned __int64 |
15:43:33 | Araq | reactormonk: .nimcall means it's not .closure |
15:43:59 | tstm | What's the recommended way for debugging nim? |
15:44:02 | Araq | sepisoad: for example use #def FL_SOCKET unsigned __int64 |
15:44:09 | reactormonk | Araq, can I ask what's .closure or should I RTFM? |
15:44:18 | sepisoad | and if i remove __int64, c2nim would proceed without error, but i'm wondering what is wrong with that |
15:44:25 | Stefan_S | sepisoad: Sorry, seems I am wrong. It is just C define. |
15:45:21 | sepisoad | id #def specific to c2nim or is it a part of C standard? |
15:45:26 | Araq | reactormonk: .closure means it's a tuple[procPtr, environment] or the js equivalent |
15:45:50 | Araq | sepisoad: last time I checked c2nim's manual was 5 pages. |
15:46:16 | Araq | 5 pages that happen to explain the difference between #def and #define ;-) |
15:46:23 | Araq | and why it's necessary |
15:47:25 | sepisoad | Araq, oop, sorry ;) |
15:49:37 | Stefan_S | sepisoad, you should try to use latest c2nim called 0.97, it has many advantages over the last stable one. |
15:51:02 | Stefan_S | And, __int64 will not be a valid Nim symbol either, so you have to rename it later. Currently I am not sure why c2nim does not like it. |
15:53:08 | Araq | cause I got tired of C's never ending clusterfuck of a type zoo |
15:53:25 | Araq | there is only so much you can support in a lifetime |
15:53:49 | reactormonk | Araq, should I go rewrite dom.nim? |
15:54:00 | Araq | maybe I missed __int64 :P |
15:54:17 | reactormonk | or go with https://github.com/Araq/Nim/issues/2371 |
15:54:38 | Araq | reactormonk: rewrite dom.nim? and break the code that uses it? |
15:54:47 | reactormonk | Araq, exactly. >:) |
15:55:18 | Araq | just create dom2 and tell everybody dom1 is deprecated |
15:55:30 | Araq | that worked for parseopt ... |
15:57:42 | kjo1 | I'm currently messing around with HTML5 & canvas with nim |
15:57:47 | kjo1 | kind of fun |
15:58:45 | tstm | kjo1: Interesting. Do you feel it's easier or faster to do than with just, you know, javascript?-) |
15:59:02 | kjo1 | :) |
15:59:27 | sepisoad | WOW, my system goes out of memory while parsing Fl.H file and c2nim crashes |
15:59:28 | kjo1 | it's a fun way to learn nim |
15:59:39 | kjo1 | and relearn javascript/html5 |
16:00:32 | Araq | sepisoad: well maybe you shouldn't make it expand an infinitely recursive #def macro |
16:00:37 | tstm | What I would like to toy around is something like an ORM + lightning fast nim json server + html5 |
16:01:05 | tstm | To get something that serves static pages and data in json and scales well |
16:02:20 | Stefan_S | Oh, my c2nim devel installed yesterday is strange, line int i; gives Error: unhandled exception: invalid format string [ValueError] while old c2nim096 works still. |
16:02:40 | Stefan_S | Sorry, can not help, have to investgate that first. |
16:03:23 | Araq | Stefan_S: use latest Nim devel and c2nim master |
16:04:40 | Stefan_S | Thanks Araq, will do that. |
16:05:00 | * | Stefan_S quit () |
16:09:05 | EXetoC | now I just need to put the nimcache dirs elsewhere when building the compiler, so as to avoid having to do "rm -r" in the package script |
16:09:58 | EXetoC | /tmp probably |
16:11:11 | * | filwit joined #nim |
16:17:34 | * | sepisoad quit (Quit: Leaving) |
16:17:59 | * | CryptoToad joined #nim |
16:18:35 | EXetoC | can it not be omitted? it might not be possible to use gcc in such a way |
16:19:29 | Araq | EXetoC: cannot follow. --nimcache exists fwiw |
16:21:24 | CryptoToad | Araq i figured out my app:gui error from yesterday, I was using the mingw that's bundled with the windows version and it was the wrong mingw version. I installed 4.9.2 and i've been smooth sailing ever since. |
16:21:26 | EXetoC | yeah I had no reason to announce it really. I'll use that and mktemp |
16:21:34 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
16:24:49 | * | ehaliewicz quit (Ping timeout: 244 seconds) |
16:26:13 | CryptoToad | can anyone take a look at my keyboard hook code? it compiles and runs fine but it's just not hitting the callback. |
16:26:23 | CryptoToad | It may be a 64 bit issue. |
16:26:40 | CryptoToad | os: windbloat |
16:27:06 | * | gokr quit (Quit: Leaving.) |
16:27:37 | * | bcinman joined #nim |
16:28:46 | CryptoToad | http://hastebin.com/mekeponapi.coffee |
16:34:39 | * | Ven joined #nim |
16:38:59 | * | Jesin quit (Quit: Leaving) |
16:40:29 | CryptoToad | nevermind, it just doesn't work in the IDE |
16:40:32 | CryptoToad | works fine standalone |
16:45:37 | * | Jesin joined #nim |
16:46:32 | * | gsingh93 joined #nim |
16:48:06 | * | kjo1 quit (Quit: Leaving.) |
16:50:44 | * | davidhq joined #nim |
16:53:26 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
16:54:42 | * | adn_ joined #nim |
16:54:44 | * | adn_ quit (Client Quit) |
16:58:37 | * | girvo joined #nim |
17:00:19 | * | pregressive joined #nim |
17:03:04 | * | girvo quit (Ping timeout: 256 seconds) |
17:18:00 | * | shodan45 quit (Quit: Konversation terminated!) |
17:22:00 | * | reem quit (Remote host closed the connection) |
17:22:38 | * | reem joined #nim |
17:24:01 | * | pregressive quit (Remote host closed the connection) |
17:24:34 | * | kjo1 joined #nim |
17:25:30 | * | fizzbooze joined #nim |
17:27:02 | * | reem quit (Ping timeout: 246 seconds) |
17:31:43 | * | smodo joined #nim |
17:33:03 | * | S_Salewski joined #nim |
17:35:24 | S_Salewski | sepisoad: My c2nim097 works again after reinstall. For your __int64 -- seems to be not a gnu, but a windows extension as google told me. |
17:37:20 | S_Salewski | For similar gnu gcc extensions I used something like "#def --int64" to let c2nim ignore it. But for your case maybe replace "unsigned __int64" by Nim's uint64? |
17:38:44 | * | zipR4ND joined #nim |
17:38:55 | * | ehaliewicz joined #nim |
17:40:03 | * | pregressive joined #nim |
17:40:56 | EXetoC | ignoring it seems like a bad idea, so the latter might be a better approach |
17:42:20 | S_Salewski | Sure -- I have checked all my gnu extensions of GTK carefully if it could be ignored. |
17:46:47 | * | UberLambda joined #nim |
17:46:56 | EXetoC | the GTK 3 lib? |
17:49:06 | S_Salewski | Yes, sure GTK3. |
17:56:03 | EXetoC | are you going to add a high-level interface? |
17:57:07 | S_Salewski | What is high level for you? Full Garbage collector support? |
17:57:08 | * | kjo1 quit (Quit: Leaving.) |
17:59:02 | S_Salewski | I think I will not try to make full GC support for GTK3, it would be very much work and overhead and we do not need it really. |
17:59:58 | S_Salewski | What is not high level for GTK3 is, that we can not extend GTK types. |
18:00:51 | S_Salewski | But that is not a big problem, composition instead of inheritance. As someone in the forim wrote. |
18:03:39 | EXetoC | if only the allocation could be delegated to the user, but I suspect that it isn't possible. there are many other things that can be made more high level though, as is the case for most bindings |
18:05:57 | * | reem joined #nim |
18:05:58 | S_Salewski | GC support is really difficult Golang recently did it, and a few other bindings too. But all these bindings becomme very large 100k lines of code! |
18:07:03 | EXetoC | it already allocates memory for you, so reference counting should be more appropriate, but destructors might still be limited |
18:07:05 | S_Salewski | My GTK3 is already high level, most usage is very similar as used from Python or Ruby. |
18:08:22 | EXetoC | I'll go look at some GTK 3 tutorials and see if I can think of anything. I've only used the GTK 2 bindings and that was some time ago so I can't remember any specifics |
18:08:29 | S_Salewski | Ref counting really works not bad for GTK. Most C code hash not to really struggle with allocating and deallocating memory. |
18:09:25 | S_Salewski | I like the Ruby GTK tutorial, but it is partly GTK2 still. |
18:09:31 | EXetoC | ok. it'll have to wait though |
18:09:40 | EXetoC | I think lack of documentation was the biggest issue I had |
18:10:28 | S_Salewski | Python has a GTK3 tutorial, but is uses classes for each example. |
18:10:53 | EXetoC | what about signals? is the C interface good enough? |
18:12:02 | S_Salewski | Tutorials are generally a weak point for GTK3: No users, so no one enjoys writing tutorials, which means even fever users. |
18:12:13 | EXetoC | anyway, great work. some things are more convenient in GTK3 IIRC |
18:13:49 | S_Salewski | Yes, signals and callbacks need some work. Aporia, which I used for testing GTK3, uses some low level dirty code. |
18:14:32 | S_Salewski | Much is already improved, addr statement is mostly not necessary for my bindings. |
18:15:56 | S_Salewski | Callbacks is one point I can improve, maybe a special signal-connect function for each important type and signal. |
18:16:16 | EXetoC | ok |
18:17:14 | S_Salewski | And I have to rework some flags: Currently all are enums as generated by c2nim, but some should be sets, so or operation is easily possible. |
18:18:04 | S_Salewski | But all that depends on interest, I will not spent muchmore time on it when really no one will ever use it. |
18:19:09 | S_Salewski | I do understand well that some people prefer Qt and wxWidgets with more native look on windows and mac. |
18:19:48 | * | fizzbooze quit (Ping timeout: 252 seconds) |
18:19:52 | S_Salewski | Bye, have to do some work... |
18:19:56 | EXetoC | Automatic generation of sets is something I've considered. I might look into it |
18:19:56 | * | S_Salewski quit () |
18:20:02 | EXetoC | .. bye |
18:21:11 | EXetoC | quitting when there's work to do - very wise |
18:31:04 | * | zipR4ND quit (Ping timeout: 245 seconds) |
18:43:18 | * | dewdrop quit (Read error: Connection reset by peer) |
18:47:25 | * | girvo joined #nim |
18:47:29 | * | fizzbooze joined #nim |
18:52:05 | * | girvo quit (Ping timeout: 265 seconds) |
19:00:49 | * | zipR4ND joined #nim |
19:05:50 | * | pipeep quit (Quit: Bye!) |
19:06:45 | * | pipeep joined #nim |
19:09:01 | * | a5i quit (Quit: Connection closed for inactivity) |
19:09:51 | * | reem quit (Remote host closed the connection) |
19:15:40 | * | dtscode quit (Ping timeout: 256 seconds) |
19:16:03 | * | epichero quit () |
19:16:21 | * | reem joined #nim |
19:16:53 | * | smodo quit (Quit: Leaving) |
19:17:01 | * | OderWat joined #nim |
19:17:05 | * | pregressive quit (Remote host closed the connection) |
19:17:27 | Araq | hi OderWat |
19:17:50 | OderWat | Hi there.. |
19:17:51 | EXetoC | should I omit the compiler source from the package since it's a package now? |
19:17:54 | Araq | I was wondering: did you consider Lazarus for the UI stuff? |
19:18:03 | * | pregressive joined #nim |
19:18:16 | Araq | EXetoC: what's the context of that question? |
19:18:44 | OderWat | wow never heared of it araq |
19:18:52 | EXetoC | Araq: generation of linux package |
19:19:14 | EXetoC | I noticed how confusing that sentence was |
19:19:54 | Araq | OderWat: sarcasm is hard to detect |
19:20:07 | EXetoC | perhaps I should keep it anyway, at least for a little while. until 1.0 perhaps, at which point all this should be stable I assume |
19:20:22 | OderWat | Sorry no sarcasm I would have marked that with ;-) |
19:20:34 | Araq | ok |
19:20:35 | OderWat | I really never heard of it ... afair |
19:21:12 | Araq | well now that they managed to release version 1.0 after one or two decades of work put into it |
19:21:18 | Araq | it works rather nicely |
19:21:36 | Araq | but I haven't done much with it, since I don't do native UIs |
19:22:46 | OderWat | I guess I always ignored that quickly because there is pascal and delphi all around. Which I always avoided :) |
19:22:59 | Araq | pfff :P |
19:23:55 | OderWat | Hehe.. Last Turbo Pascal I wrote was "guess the animal" in "informatik" showing the teacher how cool that is :) |
19:24:16 | Araq | EXetoC: the linux package should include the compiler's sources |
19:24:34 | Araq | the compiler's sources should become part of the stdlib anyway |
19:24:56 | Araq | so that this "I cannot install c2nim" dance goes away |
19:25:20 | EXetoC | /compiler -> package -> /lib/compiler? got it :p |
19:27:16 | * | brson quit (Quit: leaving) |
19:28:50 | * | epichero joined #nim |
19:31:36 | Araq | EXetoC: btw when you don't report your 'find works, toSeq(find)' bug properly, we cannot fix it. |
19:36:57 | EXetoC | I will |
19:54:55 | * | fizzbooze quit (Ping timeout: 265 seconds) |
20:13:20 | * | zipR4ND quit (Ping timeout: 272 seconds) |
20:13:35 | k1i | Araq: really liking nim thus far |
20:13:43 | k1i | awesome job, you and team |
20:14:27 | CryptoToad | ^ nim is a really great language |
20:14:48 | Araq | wow thanks. Always nice to hear. :-) |
20:15:11 | EXetoC | I like nim too btw |
20:15:20 | k1i | the C interop is beautifully seamless |
20:15:31 | k1i | re: type conversion, references, etc. |
20:15:57 | k1i | is there a way to go from seq[T] -> array[T]? |
20:16:48 | k1i | (no idea what the in-memory representation of seq is) |
20:17:12 | Araq | no, array's size has to be known at compile-time |
20:17:31 | k1i | i need to alloc a null-terminated c-style array from a seq |
20:17:46 | Araq | that said, for C interop you can simply do addr(s[0]) |
20:17:53 | Araq | to get a C compatible pointer |
20:17:54 | k1i | is it null terminated? |
20:17:55 | k1i | ok |
20:18:06 | def- | k1i: only if your actual seq is null terminated as well |
20:18:09 | CryptoToad | http://hastebin.com/apomahexur.coffee can anyone tell me just by looking at this why this throws an illegal storeage access error? |
20:18:19 | * | fizzbooze joined #nim |
20:18:24 | * | UberLambda quit (Quit: Leaving the Matrix) |
20:19:09 | CryptoToad | sorry for all of my fail guys, docs are a bit sparse in this area and googling symbols is a good way to get nowhere fast |
20:19:29 | k1i | one thing i'd be happy to help with when i get some free time, would be the "piecing together of the docs" |
20:19:51 | k1i | i think that's the only thing that's missing - a unified, general way to get from doc-to-doc, look up various builtins, etc |
20:19:55 | CryptoToad | yeah, while nim is great to code in i do find myself reading lots of compiler source xD |
20:20:40 | k1i | the fact that the compiler source is approachable at all is great |
20:20:47 | CryptoToad | yeah absolutely |
20:20:52 | CryptoToad | i love that it's an option |
20:21:20 | def- | CryptoToad: maybe because of the dereferncing of the casted int pointer? |
20:21:49 | k1i | the friendliness of real, low-level interop is a killer feature for me |
20:22:16 | k1i | only thing I am really missing is the ability to do FFI w/o a wrapper (e.g. just including headers) , but it's understandable that it's necessary |
20:22:49 | def- | k1i: i guess the way to go would be to improve c2nim so it can handle more automatically |
20:22:52 | EXetoC | there's a header pragma |
20:23:05 | EXetoC | and C code can be emitted |
20:23:05 | k1i | yeah, def- that's probably the right pathway |
20:23:29 | CryptoToad | oh i see what i'm doing |
20:23:30 | CryptoToad | derp |
20:23:31 | CryptoToad | wow |
20:23:36 | k1i | i just wrote the wrappers around CoreFoundation I needed |
20:23:38 | k1i | by hand |
20:24:13 | CryptoToad | so now that i know what the wrong way is, what's the right way to obtain a value from a pointer in nim? |
20:25:26 | EXetoC | foo[] |
20:25:46 | * | nande joined #nim |
20:26:03 | EXetoC | or do you mean the pointer type? |
20:26:18 | CryptoToad | basically |
20:26:28 | CryptoToad | i recieve an LPARAM as an arg from a callback |
20:26:36 | CryptoToad | and i cast that to an int pointer |
20:26:43 | CryptoToad | but i can't grab the int value it points to |
20:27:04 | CryptoToad | using foo[] throws illegal storage access |
20:29:57 | EXetoC | is it nil? is stdcall correct? |
20:30:30 | EXetoC | yeah seems correct |
20:31:36 | CryptoToad | it's probably something to do with the cast |
20:31:46 | CryptoToad | but i can't seem to get it to work how it should |
20:34:47 | EXetoC | does -d:useSysAssert add anything? |
20:35:00 | k1i | len(seq[T]): int vs. a uint |
20:35:20 | EXetoC | uint is very rarely needed |
20:36:12 | * | girvo joined #nim |
20:36:23 | k1i | C interop :shrug: |
20:36:34 | k1i | is there any way to import C constants? |
20:37:04 | fowl | CryptoToad, gist it ill look at it |
20:37:05 | EXetoC | but you already have a seq so where does the C interop come in? |
20:37:28 | EXetoC | convert to uint if necessary |
20:37:35 | k1i | EXetoC: the C function requires a uint length of the array you are passing |
20:37:47 | k1i | yea |
20:37:47 | k1i | i did |
20:38:38 | EXetoC | and then seq[0].addr I assume |
20:38:45 | EXetoC | why is null termination necessary though? |
20:39:08 | EXetoC | is that a difference issue? |
20:39:12 | * | dtscode joined #nim |
20:39:22 | k1i | different issue and the docs were unclear |
20:39:32 | k1i | i guess CF is open-source ,i probably should have looked at the actual C impl vs. just the headers |
20:39:40 | k1i | but everything is nicely wrapped/abstracted now :) |
20:40:16 | def- | k1i: try importcing them as a var |
20:40:41 | EXetoC | it's not specifically a null terminated string that's needed then? that's more common, and consider using a string instead then |
20:40:50 | * | girvo quit (Ping timeout: 265 seconds) |
20:41:00 | def- | hm, no. c2nim converts them into a regular nim constant without an importc |
20:41:14 | k1i | def-: that's what i was seeing |
20:41:25 | k1i | so i wasnt sure |
20:41:39 | EXetoC | if c2nim wasn't used then maybe you don't have any cstring parameters, but char* can be substituted with cstring, and then you get implicit conversion from string to cstring |
20:42:04 | EXetoC | or was it the other way around? but str.cstring can also be used |
20:42:27 | fowl | CryptoToad, this says the keycode is passed in wParam not lParam (and lParam is int not a pointer) https://msdn.microsoft.com/en-us/library/windows/desktop/ms646281%28v=vs.85%29.aspx |
20:42:41 | EXetoC | uh oh |
20:42:46 | * | kjo joined #nim |
20:49:26 | * | dewdrop joined #nim |
20:54:06 | k1i | TIL: cstringarray is a thing |
20:54:51 | * | fizzbooze quit (Ping timeout: 265 seconds) |
20:56:08 | k1i | doesn't look like there are any built-in functions to convert that to a safe nim array type though? |
20:56:25 | k1i | i am blind - cstringArrayToSeq :D |
20:57:12 | fowl | i didnt know that existed |
20:58:35 | * | Woflox joined #nim |
20:59:22 | * | filwit quit (Quit: Leaving) |
20:59:29 | k1i | https://github.com/Araq/Nim/blob/master/lib/system.nim#L2447 - fowl |
21:02:02 | * | brson joined #nim |
21:11:22 | * | epichero quit (Remote host closed the connection) |
21:14:45 | * | epichero joined #nim |
21:15:23 | * | mpthrapp_ quit (Remote host closed the connection) |
21:16:52 | k1i | how do I cast a pointer to a proc back to an executable proc? |
21:16:57 | k1i | (i have the proc type defined) |
21:18:49 | EXetoC | cast[proc(x: Foo, ...): Bar] ...? |
21:19:05 | EXetoC | include a calling convention if necessary |
21:20:17 | * | chewbranca quit (Quit: Adios) |
21:20:42 | k1i | and to go from proc -> pointer? addr(theProc) yields "Error: expression has no address" |
21:21:36 | EXetoC | is it a var? |
21:21:38 | Araq | k1i: theProc is already the address |
21:21:50 | EXetoC | ok |
21:22:25 | k1i | i am trying to pass said proc to a function accepting type 'pointer' |
21:23:02 | Araq | k1i: cast[pointer](theProc) |
21:23:19 | k1i | proc foo(cb: proc) = bar(cb) - using cb as a pointer works fine |
21:23:33 | k1i | using a proc type though, foo(cb: myProcType) = bar(cb) fails |
21:23:34 | * | ChrisMAN quit (Read error: Connection reset by peer) |
21:23:59 | Araq | don't use 'cb: proc' |
21:24:24 | k1i | (i'm not, that was just what was working) |
21:24:30 | Araq | use 'cb: proc(){.stdcall.}' instead |
21:24:53 | k1i | is this just a lack of specified calling convention? |
21:24:54 | EXetoC | on mac? |
21:25:23 | k1i | i really like the pragma system |
21:26:14 | Araq | and yeah, you better get the calling convention right |
21:27:42 | EXetoC | Araq: stdcall is used in mac? |
21:28:07 | Araq | EXetoC: no. |
21:28:19 | Araq | I thought he's using the winapi |
21:28:32 | Araq | but anyway, he has to ensure it doesn't end up as .closure |
21:28:47 | k1i | CoreFoundation- osx |
21:29:06 | EXetoC | cdecl then? |
21:32:48 | Araq | best idea is nimcall then |
21:32:51 | k1i | ^ |
21:33:01 | Araq | as it's compatible and most nim procs use it |
21:33:17 | k1i | is there an easy way to re-use proc type definitions |
21:33:30 | k1i | (in definition, etc.) |
21:35:00 | k1i | btw, thanks on the {.nimcall.} call- works perfectly |
21:35:22 | def- | k1i: type x = proc(a: foo): bar |
21:35:35 | k1i | and then to define a function of type x? |
21:35:53 | k1i | can I re-use said type in definition? |
21:35:53 | EXetoC | aren't you interfacing with C? if so then I don't get how it's compatible, and cdecl seems to be used in other cases |
21:36:40 | k1i | EXetoC: this API is a kqueue/epoll-like context object - arbitrary data structure - i need to pass a proc pointer -> the ctx object for it to be used later in the fired events |
21:36:47 | k1i | C doesn't execute this |
21:37:49 | k1i | rather, the system C I am wrapping doesn't actually call this particular proc |
21:38:05 | EXetoC | it's "user data"? |
21:38:27 | k1i | yeah |
21:38:39 | EXetoC | makes sense then |
21:40:03 | EXetoC | what was the motivation for requiring procvar in some cases? |
21:40:16 | k1i | https://developer.apple.com/library/mac/documentation/Darwin/Reference/FSEvents_Ref/index.html#//apple_ref/c/tag/FSEventStreamContext - is the userdata object |
21:40:24 | k1i | it's mostly userdata, they intrude a bit on the struct w/ "version" |
21:41:09 | * | Mat4 joined #nim |
21:41:12 | Mat4 | hello |
21:41:17 | k1i | i'd like to put my work into the builtin fsmonitor package for OSX |
21:41:21 | EXetoC | nice enum names |
21:41:23 | EXetoC | Mat4: wb |
21:41:31 | k1i | EXetoC: wrapping this has not been fun |
21:41:41 | Mat4 | hi EXetoC |
21:42:30 | EXetoC | kFSEventStreamEventFlagItemFinderInfoMod |
21:43:33 | k1i | i am really liking how easy C integration is for the most part, how seamless it is |
21:43:35 | k1i | EXetoC: they're all like that |
21:43:43 | k1i | EXetoC: the objective C ecosystem is 100% like that |
21:43:47 | k1i | everything has absurd prefixing |
21:44:11 | k1i | with references to the 90s (NS = nextstep) |
21:44:34 | EXetoC | C/Java |
21:46:51 | CryptoToad | fowl, WM_KEYUP is a different thing entirely and works as it should. |
21:47:09 | CryptoToad | if para2 == WM_KEYUP: detects if a key is up or down |
21:47:22 | CryptoToad | and that is passwd by the WPARAM |
21:47:32 | CryptoToad | the LPARAM passes the keycode. |
21:48:41 | Mat4 | k1i: Can I summarize your statement in the sense that you dislike notations which uses prefixes (like the Ungarian one) ? |
21:48:55 | fowl | oh so i was looking at the wrong thing? |
21:49:06 | CryptoToad | yes. I did that earlier too though, so don't feel bad. |
21:55:21 | CryptoToad | did some re organization, same error on var intPtr: string = cast[ptr string](para3)[] |
21:56:03 | * | epichero quit (Read error: Connection reset by peer) |
21:56:16 | * | epichero joined #nim |
21:58:07 | Araq | CryptoToad: passing string around to some callback looks dangerous |
21:58:14 | Araq | it that called from another thread? |
21:58:15 | CryptoToad | yes it is |
21:58:27 | CryptoToad | no it's from within the same thread |
21:58:42 | CryptoToad | and Araq |
21:58:45 | CryptoToad | what i'm after is an int |
21:58:45 | Araq | hrm but still |
21:58:50 | CryptoToad | but i can't get it |
21:59:02 | Araq | cast[int](myptr) works |
21:59:10 | Araq | cast[pointer](someint) works |
21:59:53 | * | ChrisMAN joined #nim |
22:02:52 | CryptoToad | okay |
22:03:54 | CryptoToad | got it working, thanks a bunch |
22:03:59 | CryptoToad | can't believe it was that easyt |
22:04:41 | * | fizzbooze joined #nim |
22:06:58 | * | girvo joined #nim |
22:08:43 | * | johnsoft quit (Ping timeout: 250 seconds) |
22:09:47 | * | johnsoft joined #nim |
22:11:23 | * | girvo quit (Ping timeout: 252 seconds) |
22:12:21 | k1i | is there a built-in os-aware path manipulation library in the stdlib? |
22:12:28 | k1i | ctrl+f on the lib.html doc isn't turning anything up |
22:16:11 | EXetoC | k1i: http://nim-lang.org/lib.html look for "os" |
22:16:17 | * | epichero quit () |
22:17:04 | * | shalabh quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
22:17:05 | EXetoC | http://nim-lang.org/theindex.html + ctrl-f |
22:18:42 | CryptoToad | one issue Araq |
22:18:45 | CryptoToad | var intPtr: int = cast[int](para3) returns the address |
22:18:47 | CryptoToad | I need the value |
22:20:07 | k1i | thanks EXetoC |
22:21:07 | Araq | CryptoToad: it doesn't return the address |
22:21:32 | Araq | but maybe you pass wrong stuff to it |
22:21:36 | CryptoToad | yeah maybe |
22:21:43 | Araq | try to pass this: cast[pointer](33) |
22:21:50 | Araq | and see if the value is 33 |
22:22:24 | CryptoToad | ahh |
22:22:27 | CryptoToad | yeah i'm doing something wrong |
22:22:27 | CryptoToad | thanks |
22:22:43 | CryptoToad | it happened to output something that looked like an addr |
22:24:01 | * | phira joined #nim |
22:25:35 | * | bcinman quit (Ping timeout: 246 seconds) |
22:27:52 | * | bcinman joined #nim |
22:28:21 | * | BlaXpirit quit (Quit: Quit Konversation) |
22:31:05 | tstm | def-: Still around? |
22:31:37 | def- | tstm: yes |
22:32:02 | tstm | def-: I made the nbody even faster! Do you have something else than mac to test it on? |
22:32:14 | def- | I'm on Linux |
22:32:20 | tstm | I shaved almost 20% off using avx intrinsics |
22:32:45 | Araq | tstm: nice! :-) |
22:32:51 | * | girvo joined #nim |
22:33:19 | def- | Nice, but my CPU is too old for AVX anyway |
22:33:26 | def- | I'm interested in seeing the code still |
22:33:31 | tstm | Oh. Then it won't work. |
22:33:33 | tstm | http://tstm.info/files/nbody_vec.nim |
22:33:54 | tstm | And it depends on these https://github.com/bsegovia/x86_simd.nim |
22:34:31 | fowl | k1i, path functions in os module |
22:35:01 | tstm | The squaresum is still a bit odd, I was having some trouble in the m256d conversions |
22:35:41 | tstm | If someone has linux with avx, could you test that one how it fares against the other versions? |
22:35:50 | * | brson quit (Ping timeout: 272 seconds) |
22:35:54 | tstm | (and against optimized c!) |
22:36:22 | def- | tstm: ah, let me test on another system |
22:37:26 | tstm | At least on my mac it beats everything |
22:37:49 | tstm | The non-avx version ran in about 5s and this one does it in 4.1s |
22:39:54 | tstm | And you guys are smarter with memory conversions than I am, how would I implement the squaresum properly, when the store_pd() just wants to write the stuff to an array starting from pointer. |
22:40:39 | fowl | tstm, arr[0].addr |
22:41:12 | * | fluoride joined #nim |
22:42:38 | * | a5i joined #nim |
22:44:52 | tstm | fowl: Cool. =) |
22:46:30 | * | mwbrown joined #nim |
22:46:59 | def- | tstm: on a Xeon E5-2680: nbody_c: 5.17, nbody_nim: 7.95, nbody_nim_vec: 6.54 |
22:47:23 | tstm | def-: Well, getting closer in any case. :D |
22:48:01 | * | Mat4 left #nim (#nim) |
22:48:57 | tstm | I was kind of surprised how easy it was to get SIMD intrinsics going |
22:49:37 | * | BlaXpirit joined #nim |
22:55:23 | * | pregressive quit (Remote host closed the connection) |
22:57:33 | * | epichero joined #nim |
22:57:42 | * | TEttinger joined #nim |
23:02:42 | flaviu | def-: What compiler are you using? |
23:07:10 | * | fluoride quit (Quit: Leaving) |
23:09:08 | * | fluoride joined #nim |
23:09:48 | def- | flaviu: gcc |
23:11:00 | flaviu | def-: What happens with clang? Also try ICC if you have that. |
23:12:03 | def- | don't have clang on that machine |
23:13:42 | tstm | def-: I installed nim on a decent Ubuntu server box as well, and even there it's faster (on regular gcc, not clang) than the C version. I thought that was only a mac compiler thing that enabled nim to be so fast. |
23:14:19 | tstm | On a Xeon E5-1650 with gcc 4.8.2 |
23:16:34 | tstm | Of course sse is bound to be somewhat slower than avx I guess. The optimized c version is not quite as good as the single vector operations you can do with avx I guess. |
23:16:44 | def- | with icc: C: 6.76, nim: 7.28, nim-vec: 6.63 |
23:30:10 | * | irrequietus quit () |
23:33:16 | * | xificurC quit (Ping timeout: 258 seconds) |
23:38:48 | * | bcinman quit (Ping timeout: 252 seconds) |
23:46:02 | * | ehaliewicz quit (Remote host closed the connection) |
23:48:49 | * | bcinman joined #nim |
23:57:27 | * | BlaXpirit quit (Quit: Quit Konversation) |
23:58:45 | * | Trustable quit (Remote host closed the connection) |