| 00:10:53 | dom96 | 'night |
| 00:13:08 | Varriount | Goodnight. |
| 00:14:40 | Varriount | dom96: Why are you using a distinct *int* as a file descripter? |
| 00:15:53 | * | Skrylar quit (Ping timeout: 246 seconds) |
| 00:22:51 | * | superfunc joined #nimrod |
| 00:31:53 | njoejoe | should the devel branch of nimrod display "0.x.x -devel" or somesuch for nimrod --version |
| 00:32:04 | * | DAddYE quit (Remote host closed the connection) |
| 00:38:03 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:45:16 | njoejoe | is it a no-no to "import" when in "nimrod i"? I get an unhandled exception: https://gist.github.com/jots/4bef53a2d56853c45b25 |
| 00:50:23 | EXetoC | "nimrod i" is pretty unusable |
| 00:53:00 | * | Demos joined #nimrod |
| 00:59:14 | njoejoe | ah. durn it. would be a nice thing to use while learning nimrod. |
| 01:03:59 | njoejoe | dom96: what branch of nimrod to run your downforeveryone? |
| 01:04:27 | njoejoe | dom96: I'm getting Error: 'yield' cannot be used within 'try' in a non-inlined iterator when i try it |
| 01:06:24 | * | Skrylar joined #nimrod |
| 01:07:42 | Varriount | njoejoe: 'nimrod i' doesn't have foreign function support, so a great many procedures can't be used. |
| 01:08:13 | Varriount | njoejoe: Try updating your branch to the latest devel. He only pushed it a couple hours ago. |
| 01:18:29 | * | Demos quit (Read error: Connection reset by peer) |
| 01:19:14 | njoejoe | oh yeah i just switched to devel and it is working |
| 01:24:02 | * | q66 quit (Quit: Leaving) |
| 01:26:39 | * | Demos joined #nimrod |
| 01:28:27 | Demos | EXetoC, was it you that linked to linguistic relativity? |
| 01:30:36 | EXetoC | Demos: Jehan did |
| 01:31:48 | * | superfunc quit (Ping timeout: 240 seconds) |
| 01:32:02 | * | noam joined #nimrod |
| 01:33:24 | Demos | Allright Well he is gone it seems, but linguistic relativity is somewhat truthy notion that has little actual evidence to back it up |
| 01:34:38 | Demos | also note that human language is not constrained by the petty realities of electrical engineering |
| 01:37:01 | Varriount | Hi noam |
| 01:37:19 | noam | hi friendly stranger |
| 01:37:26 | Varriount | :D |
| 02:00:18 | * | Demos quit (Read error: Connection reset by peer) |
| 02:14:02 | njoejoe | how weird that Demos mentions "linguistic relativity" and then a minute later "noam" logs in. |
| 02:14:12 | * | springbok joined #nimrod |
| 02:14:53 | Varriount | njoejoe: Oh? How so? |
| 02:15:41 | noam | refering noam chomsky probably :P |
| 02:16:18 | njoejoe | Noam Chomsky, renowned linguist has a lot to say about lingusitic relativity. coinky dink. |
| 02:18:12 | * | gsingh93 quit (Remote host closed the connection) |
| 02:18:43 | * | gsingh93 joined #nimrod |
| 02:22:09 | * | gsingh93 left #nimrod (#nimrod) |
| 02:22:43 | * | gsingh93 joined #nimrod |
| 02:27:54 | * | Varriount bashes head against wall |
| 02:28:12 | Varriount | I really dislike memory bugs. |
| 02:31:00 | njoejoe | yeah they're no fun. whack-a-mole |
| 02:32:31 | Varriount | njoejoe: This particular I think dom96 and I squabbled over. We disagreed about the size of types in this windows structure. Either he didn't believe me, or the change somehow got reversed, or maybe I'm misremembering, but the error just bit me in the butt. |
| 02:34:22 | njoejoe | What does {.deprecated.} mean at the top of https://github.com/Araq/Nimrod/blob/devel/lib/impure/ssl.nim ? don't use? I need to connect to some weird xml servers that serve over ssl |
| 02:36:49 | EXetoC | use it if you want but it might go away some day |
| 02:37:09 | njoejoe | ok |
| 02:38:51 | renesac | usually if something is deprecated there should be something better in place |
| 02:39:59 | Varriount | Anyone have any good reading material for developing an interpreted language/vm? |
| 02:41:07 | EXetoC | the sockets module has ssl stuff in it, and the newer net module too |
| 02:41:19 | Varriount | njoejoe: ^ |
| 02:41:37 | EXetoC | and the async ones too |
| 02:43:43 | njoejoe | ah. thanks EXetoC |
| 02:47:26 | EXetoC | c(:)-< |
| 02:47:48 | EXetoC | haven't used SSL, but I assume that those modules replace that one |
| 02:49:29 | Varriount | Yay! I got filesystem changes! |
| 02:50:14 | EXetoC | what did you do wrong? |
| 02:50:25 | Varriount | Before? Nothing. |
| 02:50:52 | Varriount | One of the OS level structures used by asyncdispatch was wrapped improperly. |
| 02:51:32 | * | DAddYE joined #nimrod |
| 02:53:15 | Varriount | What tipped me off was the fact that A) I kept getting an "Invalid Handle" error when running the call that requests file system changes, and B) A search for my problem on the internet reveal that a certain structure had to be zeroed out before use by this call. |
| 02:54:05 | Varriount | Since Nimrod nearly always zeroes out memory, I concluded that a possible problem might be that a structure was too small, and the OS was accessing unallocated space. |
| 02:54:42 | EXetoC | oh |
| 02:54:48 | EXetoC | time for some more tests maybe |
| 02:54:57 | Varriount | Simple deduction, dear EXetoC |
| 02:54:58 | EXetoC | test everything (tm) |
| 02:55:11 | njoejoe | or a beer :-) |
| 02:55:24 | * | gsingh93 quit (Remote host closed the connection) |
| 03:11:37 | Varriount | Hm.. Creating an abstracted interface over the Window's ReadFileChanges and Linux inotify apis is going to be... interesting. |
| 03:16:06 | Varriount | Araq: Thanks for designing a language/compiler that, by default, zeroes newly allocated memory. |
| 03:19:59 | EXetoC | new does that? |
| 03:20:42 | njoejoe | dom96: i forgot i had your downforeveryone script running and just noticed it had 100% cpu on one of my cores. so it's spinning somewhere. |
| 03:20:54 | EXetoC | I wonder if unsafeNew doesn't initialize. seems pretty likely |
| 03:24:38 | EXetoC | yep, after the first response |
| 03:27:27 | * | gsingh93 joined #nimrod |
| 03:28:52 | * | xenagi quit (Quit: Leaving) |
| 03:30:22 | EXetoC | maybe asynchttpserver is the culprit |
| 03:35:39 | * | DAddYE quit (Remote host closed the connection) |
| 03:36:08 | * | DAddYE joined #nimrod |
| 03:40:45 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 03:45:08 | * | XAMPP_8_ joined #nimrod |
| 03:45:20 | * | XAMPP-8 joined #nimrod |
| 03:45:24 | * | XAMPP_8 joined #nimrod |
| 03:45:42 | * | XAMPP_8 quit (Read error: Connection reset by peer) |
| 03:46:09 | * | XAMPP_8_ quit (Read error: Connection reset by peer) |
| 03:46:16 | * | XAMPP-8 quit (Read error: Connection reset by peer) |
| 03:59:40 | Skrylar | one wonders why i decided to make a nimrod native version of SOIL/FreeImage >_< |
| 04:17:14 | * | bjz joined #nimrod |
| 04:19:34 | njoejoe | Skrylar: because you can? :-). i have never heard of SOIL/FreeImage before. |
| 04:23:07 | Skrylar | njoejoe: they are image loading libraries |
| 04:23:21 | Skrylar | so you can just say "load this jpeg" in one line of code, and they give you a texture/etc |
| 04:23:25 | Varriount | Skrylar: Because such libraries could put Nimrod on the map. |
| 04:23:39 | Skrylar | Varriount: you should see the jpeg6b headers |
| 04:23:46 | Skrylar | they are awful |
| 04:24:20 | Varriount | Skrylar: I've wrapped/helped wrap DevIL and FreeImage. I wasn't able to get SOIL working. :/ |
| 04:25:52 | Skrylar | weird |
| 04:26:11 | Skrylar | huh, i just wondered if that distance field technique would work in a document format |
| 04:26:18 | Skrylar | they did say it works for any monochrome high resolution input |
| 04:26:32 | Skrylar | aaaand the weakness in DjVu is their bitonal compressor is patented... |
| 04:26:43 | Varriount | Skrylar: DjVu? |
| 04:26:59 | Skrylar | I'm thinking convert the text layer to a distance field, then deflate that image |
| 04:27:08 | Skrylar | Varriount: djvu is a document format about as old as PDF |
| 04:27:19 | Skrylar | they designed it to store scanned documents from print-to-PC instead of pc-to-print |
| 04:28:11 | Skrylar | Varriount: it basically works by having a jpeg compressor for the "background" data, and a bitonal compressor for "text", where the background can be half-DPI without the text getting blurry |
| 04:30:19 | Skrylar | oh good |
| 04:30:36 | Skrylar | this header uses #defines to put crap in struct bodies, and nimrod won't let me invoke a macro to do the same |
| 04:33:35 | Varriount | Skrylar: You do know about the #def macro for c2nim, right? |
| 04:35:55 | Skrylar | Varriount: i really doubt c2nim would enjoy this file |
| 04:36:01 | Skrylar | ANSI C circa 1998 |
| 04:36:48 | reactormonk | any idea where to start on the idetools bugs? :-/ |
| 04:37:36 | Varriount | reactormonk: Command line parsing first. Then make your way down. |
| 04:37:59 | Varriount | reactormonk: If you can fix any of them, we IDE tool devs will be thankful. |
| 04:44:08 | Skrylar | ide tool devs :< |
| 04:47:59 | Varriount | Skrylar: What? |
| 04:53:33 | * | xtagon quit (Quit: Leaving) |
| 04:55:44 | reactormonk | Varriount, command line parsing? |
| 04:55:57 | reactormonk | Varriount, I'm interested in the bug where it fails to restart properly... |
| 04:56:11 | Varriount | reactormonk: Oh, well that's an important one too. |
| 04:57:35 | Varriount | A random guess would be to locate the variables that are cleared by the reset command, and figure out which ones aren't being reset automatically. |
| 04:57:58 | Varriount | (Yes, there is a reset command for IDE tools, it's just not documented) |
| 04:58:11 | reactormonk | Varriount, where is it? |
| 04:59:59 | Varriount | reactormonk: compiler/main.nim, line 239 |
| 05:01:27 | Varriount | Anyway, off to bed. Ta! |
| 05:05:07 | * | DAddYE joined #nimrod |
| 05:06:32 | * | menscrem joined #nimrod |
| 05:07:29 | njoejoe | trying to make SSL connection, but getting compile error: "undeclared identifier: 'isSSL=' https://gist.github.com/jots/11467894 |
| 05:12:47 | * | superfunc joined #nimrod |
| 05:16:49 | reactormonk | njoejoe, apparently TSocket doesn't define isssl ... |
| 05:17:25 | * | darithorn quit (Ping timeout: 265 seconds) |
| 05:17:30 | reactormonk | njoejoe, did you define ssl when compiling? |
| 05:17:34 | reactormonk | when defined(ssl): |
| 05:17:36 | reactormonk | case isSsl: bool |
| 05:19:58 | njoejoe | i did -d:ssl when compiling |
| 05:21:02 | * | isenmann joined #nimrod |
| 05:24:23 | reactormonk | hmmm |
| 05:29:44 | reactormonk | njoejoe, it's not exposed |
| 05:30:50 | reactormonk | njoejoe, you need an SSL context via newContext and then connect it via wrapSocket |
| 05:31:01 | reactormonk | SSL isn't simply setting a flag to `true` |
| 05:31:40 | njoejoe | oh. ok, let me look into doing that. |
| 05:32:08 | reactormonk | sockets.nim:237 |
| 05:32:26 | reactormonk | could be simpler, I have to agree :-/ |
| 05:32:35 | reactormonk | I have the feeling those are for a server socket |
| 05:37:31 | reactormonk | njoejoe, if you figure out how to do it, tell me how, or write a blog post about it |
| 05:38:03 | njoejoe | will do |
| 05:38:35 | reactormonk | njoejoe, or put it on stackoverflow via self-answering ;-) |
| 06:10:05 | njoejoe | this works, but i'm hoping for a sock.read() function instead of sock.readLine(line) https://gist.github.com/jots/11468460 |
| 06:17:31 | * | [1]Endy joined #nimrod |
| 06:21:30 | reactormonk | njoejoe, what would read() do? |
| 06:21:51 | reactormonk | there's recv() which slurps |
| 06:26:00 | njoejoe | this protocol i'm working with, the server give first 4 bytes as a binary int telling how much more data to read. perhaps recv() will do it. |
| 06:29:39 | Skrylar | what is a cint (*foo)[NUM] |
| 06:29:40 | njoejoe | so in ruby i do: nb = @s.read(4).unpack("N").first; data = @s.read(nb-4) |
| 06:29:47 | Skrylar | it looks like a function |
| 06:32:49 | Skrylar | huh |
| 06:32:58 | Skrylar | apparently ages ago someone already bound libjpeg |
| 06:38:35 | njoejoe | this one? https://github.com/Schala/nimrod-modules/tree/master/lib/wrappers |
| 06:40:38 | njoejoe | i wish i would stumble across already done nimrod bindings for leveldb... |
| 07:04:43 | * | [2]Endy joined #nimrod |
| 07:07:39 | * | [1]Endy quit (Ping timeout: 252 seconds) |
| 07:15:18 | njoejoe | how to include 'packed' data in a string? like the ruby "pack" method? https://gist.github.com/jots/11469118 |
| 07:22:40 | * | [1]Endy joined #nimrod |
| 07:25:47 | * | [2]Endy quit (Ping timeout: 245 seconds) |
| 07:30:04 | * | superfunc quit (Quit: Page closed) |
| 07:30:48 | * | menscrem quit (Ping timeout: 240 seconds) |
| 07:45:05 | dom96 | njoejoe: I don't think we have anything for that in the stdlib. |
| 07:45:34 | Araq | njoejoe: learn how to use 'cast' and low level programming ;-) |
| 07:45:40 | Araq | hi dom96 |
| 07:45:51 | dom96 | hi Araq |
| 07:47:00 | njoejoe | i'm trying to send down a socket like: s.send(pkt.len) but gives a type error, so i tried s.send(cast[string](pkt.len)) and get sigsegv when running |
| 07:47:53 | Araq | s.send(addr pkt.len, 4) perhaps? |
| 07:48:08 | Araq | well requires a temporary ofc |
| 07:48:15 | Araq | var tmp = pkt.len |
| 07:48:26 | Araq | s.send(addr tmp, 4) |
| 07:48:49 | njoejoe | ah. yeah i tried add pkt.len, let me try with tmp |
| 07:49:00 | Araq | or rather: var tmp: int32 = pkt.len |
| 07:49:23 | Araq | you can swap it to netword order with the endians module |
| 07:49:30 | Araq | *network |
| 07:52:12 | Araq | njoejoe: are you wrapping leveldb? |
| 07:53:02 | njoejoe | not hardly :-). i'm talking to some server with a weird protocol. |
| 07:53:12 | Araq | aww |
| 07:53:25 | Araq | a leveldb wrapper would be sweet in Babel |
| 07:54:31 | njoejoe | yeah it would. and i need it! but first i have to get through my baby steps |
| 07:59:57 | njoejoe | trying bigendian32 but get sigsegv https://gist.github.com/jots/9a003099f6417da5152f |
| 08:08:04 | njoejoe | I think i fixed it. no sigsegv anymore. |
| 08:09:38 | Araq | cast[int32](pkt.len) is wrong |
| 08:09:44 | Araq | use a type conversion instead |
| 08:14:36 | njoejoe | like var tmp = int32(pkt.len) ? |
| 08:15:53 | Araq | yes |
| 08:21:19 | Skrylar | okay, jpeg bound |
| 08:24:05 | * | bjz_ joined #nimrod |
| 08:30:57 | Araq | Skrylar: put it on babel please |
| 08:31:15 | Skrylar | i wouldn't even begin to know how to do that |
| 08:31:25 | Skrylar | i also don't know if i would want to subject someone to the horrors of that header file |
| 08:34:01 | Skrylar | lol webp headers |
| 08:34:09 | Skrylar | "Copyright Google all rights reserved [..] provided under BSD" |
| 08:34:15 | Skrylar | someone doesn't understand what all rights reserved means |
| 08:34:35 | Araq | dom96: please help and push Skrylar |
| 08:34:40 | * | noam quit (*.net *.split) |
| 08:34:42 | * | Raynes quit (*.net *.split) |
| 08:34:43 | * | JStoker quit (*.net *.split) |
| 08:34:45 | * | Guest69942 quit (*.net *.split) |
| 08:34:45 | * | musicalchair quit (*.net *.split) |
| 08:34:48 | * | Raynes_ joined #nimrod |
| 08:34:54 | * | bjz quit (*.net *.split) |
| 08:35:03 | * | Raynes_ is now known as Raynes |
| 08:35:04 | * | JStoker joined #nimrod |
| 08:35:04 | * | epsylon joined #nimrod |
| 08:35:05 | * | Raynes quit (Changing host) |
| 08:35:05 | * | Raynes joined #nimrod |
| 08:35:14 | dom96 | Skrylar: do it |
| 08:35:33 | dom96 | https://github.com/nimrod-code/babel/blob/master/developers.markdown |
| 08:36:33 | Skrylar | lol push skrylar |
| 08:37:17 | Skrylar | i put it in the giant todo list |
| 08:38:54 | Skrylar | i need to make sure theres also .nims for gif, png and webp, then writing a nimrod-native image loader, then i can't put off GL any longer and will have to see how EXetoC's is coming along |
| 08:40:11 | * | DAddYE quit (Remote host closed the connection) |
| 08:40:37 | * | DAddYE joined #nimrod |
| 08:42:03 | * | renesac quit (Ping timeout: 245 seconds) |
| 08:42:49 | Araq | njoejoe: the devel branch is 0.9.5. in general odd numbers mean it's a development version |
| 08:44:42 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 08:53:22 | * | noam joined #nimrod |
| 08:53:22 | * | musicalchair joined #nimrod |
| 08:58:18 | * | [2]Endy joined #nimrod |
| 09:02:03 | * | [1]Endy quit (Ping timeout: 245 seconds) |
| 09:34:07 | * | menscrem joined #nimrod |
| 09:35:04 | * | brechtm joined #nimrod |
| 09:35:10 | brechtm | hello |
| 09:36:21 | dom96 | hi brechtm |
| 09:36:26 | brechtm | I just discovered Nimrod and I like what I've seen so far |
| 09:37:11 | dom96 | That's good to hear. |
| 09:37:22 | brechtm | I wanted to try to use a C library (libgit2) in a nimrod application, but it's not fully clear to me how to go about it |
| 09:37:42 | brechtm | I understand I should use c2nim to translate the headers |
| 09:37:57 | dom96 | indeed |
| 09:38:12 | brechtm | but I'm not sure what to do with header guards and the GIT_EXTERN defines, for example |
| 09:38:27 | Araq | remove the header guards |
| 09:38:28 | dom96 | You likely want to remove those. |
| 09:38:35 | brechtm | is there a tutorial-esque document on c2nim? The c2nim manual seems more like a reference document |
| 09:38:59 | Araq | not sure, the FFI is also documented in the manual |
| 09:39:18 | brechtm | Araq: thanks, I will look for that |
| 09:40:41 | Araq | GIT_EXTERN is likely to become a #def so that c2nim's preprocessor handles it |
| 09:40:42 | * | springbok quit (Ping timeout: 240 seconds) |
| 09:41:01 | brechtm | Araq: so I guessed correctly, good to see that confirmed :) |
| 09:41:51 | brechtm | any tips on how to maintain up-to-date nimrod bindings for C libs? |
| 09:42:15 | brechtm | Since it is required to alter the header files fed to c2nim |
| 09:44:27 | brechtm | I suppose one would directly edit the nim files after the initial conversion? |
| 09:47:17 | Araq | yeah and no I don't have tips. you could try to generate patch files to automate it |
| 09:47:44 | Araq | "C11 attempts to fix what was broken in C99. It makes some of the mandatory features of C99 (variable length arrays, complex types and more) optional" yay! They recognized C99 was crap. |
| 09:51:40 | Skrylar | brechtm: keep a separate git repository with the last header you ported in it |
| 09:51:53 | Skrylar | or a private branch |
| 09:52:04 | Skrylar | then its a trivial matter of putting a newer header in, and asking git what you have to change |
| 09:53:48 | * | brechtm quit (Ping timeout: 240 seconds) |
| 09:57:26 | * | renesac joined #nimrod |
| 10:04:03 | * | springbok joined #nimrod |
| 10:19:31 | * | brechtm joined #nimrod |
| 10:39:51 | Skrylar | Araq: that sounds like a bailout for microsoft |
| 10:40:04 | Skrylar | IIRC microsoft didn't want to support c99 features and probably whined them out of the spec |
| 10:42:55 | Araq | these features were deliberately designed to be incompatible with C++ |
| 10:43:06 | Araq | it's good they got nowhere |
| 10:46:04 | Araq | but every C standard that does not include builtins for overflow checking is a crime anyway |
| 10:47:26 | Araq | "how do I check for overflows? oh I can't, but instead I got better support for complex numbers... " |
| 10:48:58 | * | Jehan_ joined #nimrod |
| 10:54:35 | brechtm | c2nim doesn't translate typedefs... should I write these myself? |
| 10:54:49 | brechtm | struct typedefs |
| 11:01:41 | Araq | it does translate these |
| 11:02:05 | brechtm | "typedef struct git_odb git_odb;" |
| 11:02:23 | Araq | works for me |
| 11:03:05 | brechtm | c2nim 0.9.5 |
| 11:03:30 | brechtm | produces an empty line in the nim file |
| 11:04:04 | brechtm | Araq: what does it generate? |
| 11:05:18 | brechtm | I don't know where the struct is defined though... that probably explains it |
| 11:05:33 | Araq | well look at c2nim's tests. "typedef struct" is definitely in the test suite |
| 11:06:38 | Araq | people used it to compile thousands of lines of C code and you tell me "typedef struct" doesn't work... ;-) |
| 11:07:47 | brechtm | Araq: it doesn't seem to work for *me* at this particular moment :) |
| 11:08:04 | brechtm | Araq: I believe you when you say it should work |
| 11:08:27 | Araq | wait a sec |
| 11:08:52 | brechtm | I'm not sure about the details of C typedefs, so I'm probably missing something obvious |
| 11:09:27 | * | brechtm reads about C "typedef struct" |
| 11:11:08 | brechtm | ok, so "typedef struct git_odb git_odb;" just aliases "git_odb" to "struct git_odb"... but where is "struct git_odb" defined? |
| 11:11:24 | brechtm | Should be in an included headers somewhere, I suppose, no? |
| 11:12:36 | brechtm | I'm looking at https://github.com/libgit2/libgit2/blob/development/include/git2/types.h |
| 11:17:11 | brechtm | indeed, they are... |
| 11:17:47 | brechtm | mmm, though not the git_commit struct |
| 11:27:04 | * | Matthias247 joined #nimrod |
| 11:27:53 | brechtm | Or are these structs only defined in the lib and not in the headers because they should not be modified by the user? |
| 11:29:08 | Araq | brechtm: never mind, I take it back. doesn't work for me either. wtf |
| 11:29:19 | Araq | that's either a regression or a feature :P |
| 11:29:31 | Araq | the translation simply is: |
| 11:29:32 | brechtm | Araq: too bad, but thanks for checking |
| 11:29:44 | Araq | type git_odb* = object |
| 11:30:22 | Araq | it's an "opaque" struct in C. it means the fields are deliberately left out and only pointers to it can be used. |
| 11:30:41 | Araq | the nimrod translation is an empty object. Not quite the same, but close enough. |
| 11:30:58 | brechtm | Araq: so the fields are indeed an implementation detail no shared with the lib user? |
| 11:31:17 | Araq | brechtm: exactly |
| 11:31:48 | brechtm | great, learning some things about C too :) |
| 11:32:20 | Araq | that's the spirit |
| 11:36:06 | Araq | brechtm: you can create a bug report but there is not much point in it. since the bug offends me on a personal level I will fix it tonight. |
| 11:40:34 | brechtm | what more can I ask for? :) |
| 11:46:26 | * | [1]Endy joined #nimrod |
| 11:48:34 | * | Jehan_ quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 11:49:18 | * | [2]Endy quit (Ping timeout: 240 seconds) |
| 11:51:38 | * | Jehan_ joined #nimrod |
| 12:01:02 | * | foodoo joined #nimrod |
| 12:16:04 | brechtm | How are platform-specific defines typically handled? |
| 12:16:27 | brechtm | Looking at sqlite3.nim, it appears is it handled at another level |
| 12:19:29 | Araq | depends. Usually I use 'when' or don't even wrap it |
| 12:20:11 | Araq | C header files tend to consist of garbage like MY_OWN_INLINE_MACRO_FOR_QUESTIONABLE_PORTABILITY |
| 12:22:08 | Jehan_ | Heh. |
| 12:22:56 | Jehan_ | If I could go back in time, I'd convince the inventor of the C preprocessor that studying yoga in India was a better use of his time than computers. |
| 12:23:35 | Jehan_ | Maybe I'm biased, but the mere existence of the C preprocessor has caused me more pain in the past five years than anything else I can think of. |
| 12:24:31 | Araq | I dunno. I think I'd merely tell them to shave and lose weight ... |
| 12:24:46 | brechtm | Jehan_: you must have never tried to use C++ |
| 12:25:05 | Jehan_ | Umm. I wish. |
| 12:25:21 | Jehan_ | C++, of course, has the same issue. |
| 12:25:39 | brechtm | plus a whole bunch of other issues |
| 12:26:45 | Jehan_ | Yeah, but that's a matter of putting the effort in to deal with syntax and semantics. |
| 12:27:04 | Jehan_ | The preprocessor is the programming language equivalent of a one-way hash function. |
| 12:27:47 | Araq | Jehan_: lets be a bi tmore productive though. How does a thread pool determine when it needs to grow? |
| 12:27:54 | Araq | *a bit |
| 12:27:59 | Jehan_ | Try to instrument C/C++ code when either it's not parsable or first needs to be run through an irreversible transformation. |
| 12:28:28 | Jehan_ | Araq: Well, you first get a dead chicken or two, then you wait for the next full moon ... |
| 12:29:32 | Jehan_ | In reality, I think that most implementations punt and either leave it to programmers to specify some size or use a heuristic that somebody thinks is not completely illogical. |
| 12:30:14 | Jehan_ | More practically, it depends on the environment. |
| 12:30:44 | * | [2]Endy joined #nimrod |
| 12:30:59 | Araq | well my idea is to inject every IO operation to add some measurements |
| 12:31:10 | Jehan_ | E.g. whether you have a dedicated compute server running a specific job or whether it's another desktop app competing with other desktop apps and background jobs for resources. |
| 12:31:18 | Araq | or perhaps in the thread's main loop we can compute cpuTime - realTime |
| 12:31:35 | Araq | to dermine if it is CPU bound or IO bound |
| 12:32:05 | Jehan_ | Practical example: I was running something on an 8x8 NUMA architecture last year that just didn't scale beyond eight cores per process. |
| 12:32:24 | Jehan_ | So I ran eight processes with 16 threads, each process locked to a separate node. |
| 12:32:50 | Jehan_ | 16 threads to make sure nodes were fully utilized, because sometimes they had to wait. |
| 12:33:38 | * | [1]Endy quit (Ping timeout: 240 seconds) |
| 12:33:54 | Jehan_ | As a rule, it is important to give programmers (1) control over the thread pool size and (2) ways to query what the architecture is like. |
| 12:35:20 | Jehan_ | There's only so much you can do with heuristics. |
| 12:36:45 | Jehan_ | For example, a dual core desktop/laptop is qualitatively quite different from a quadcore one. |
| 12:37:07 | Jehan_ | You generally want to not use all cores so that the user always has one to keep the UI etc. responsive. |
| 12:37:29 | Araq | no you describe what to provide for the people who know what they are doing |
| 12:37:29 | Jehan_ | But that means a dual core machine becomes sort of single threaded for other work. |
| 12:38:11 | Araq | I aim for a "never mind, good enough for the average programmer" solution |
| 12:38:14 | Jehan_ | With a quadcore machine, you still have three cores to play with relatively freely. |
| 12:39:48 | Jehan_ | In that case, I'd require an option to initialize the worker pool. |
| 12:40:47 | Jehan_ | Something simple like maximum load vs. three quarters or half load or specifying a concrete number of threads/cores/nodes to utilize. |
| 12:41:15 | * | springbok quit (Changing host) |
| 12:41:15 | * | springbok joined #nimrod |
| 12:42:12 | EXetoC | Skrylar: referring to my changes to opengl.nim? |
| 12:42:47 | Jehan_ | I.e. make a thread pool an ADT with configurable CPU utilization, scheduling strategy, etc. |
| 12:43:17 | Jehan_ | And give either sensible defaults or require parameters upon initialization where they cannot be guessed. |
| 12:43:31 | Araq | that's exactly what I don't want to do, that's boring |
| 12:44:12 | Araq | for windows there is GetThreadTimes, for linux one can read procfs to get some performance counters |
| 12:45:41 | Jehan_ | How do you coordinate thread pools across multiple processes, then? That's the big problem you always have. |
| 12:48:11 | Araq | I don't, I assume if people use threads they don't use multi processing |
| 12:49:26 | Jehan_ | Simple example: Two people running different processes on a multi-user server. |
| 12:50:41 | Jehan_ | Or someone writing a photoshop clone that needs to coexist with a web browser on the same computer. |
| 12:51:00 | Araq | Simple example: I don't do scientific computing when playing a game. :P |
| 12:51:45 | Jehan_ | Well, if you only want it for writing games, then you don't really need to get all that fancy with thread pools. :) |
| 12:53:49 | Araq | what if I do the canonical 'spawn' example: |
| 12:53:58 | Araq | for x in lines("input.txt"): |
| 12:54:02 | Araq | spawn f(x) |
| 12:54:04 | Araq | sync() |
| 12:54:17 | Araq | and don't know whether it's IO bound or CPU bound? |
| 12:54:28 | Araq | then I need to profile and tune my thread pool. not cool. |
| 12:54:55 | Araq | if the thread pool could easily do that for me at runtime |
| 12:55:06 | Jehan_ | Always make sure that you have N active threads running, and register a thread as inactive when it does I/O or blocks. |
| 12:55:36 | Araq | ah now we're beginning to talk about the same things |
| 12:56:05 | Jehan_ | But, quite honestly, if all you want is max performance on a given rig, you just spawn enough threads to saturate all cores. |
| 12:56:52 | Jehan_ | I.e. multiply number of cores by a constant that depends on how CPU intensive stuff is. |
| 12:57:05 | Jehan_ | That will solve most problems for fairly little effort. |
| 12:57:32 | Jehan_ | Assuming you have a reasonably smart scheduling algorithm, of course, and no serialization bottlenecks. |
| 12:58:23 | Jehan_ | When you have a global lock in your allocator, for example, and an allocation-heavy workload, you can be lucky to fully utilize two cores. |
| 12:59:09 | Jehan_ | (Or, why I had to hack the Boehm GC last year to allow for better thread-local allocation, sigh.) |
| 12:59:44 | Jehan_ | Being smart about the number of threads is primarily important when you do not want to utilize a machine fully. |
| 12:59:51 | Araq | Boehm uses a single lock even these days? |
| 13:00:00 | Jehan_ | Yes and no. |
| 13:00:19 | Jehan_ | It has a thread-local allocator, but only for certain types of allocations. |
| 13:00:51 | Jehan_ | Plus, it refills the thread-local pools in page-sized quantities. |
| 13:01:36 | Jehan_ | You do not, for example, have thread-local allocations in conjunction with type allocations by default (i.e. where you specify what words can contain pointers). |
| 13:02:18 | * | brechtm quit (Ping timeout: 240 seconds) |
| 13:02:40 | Jehan_ | You have to roll your own thread-local allocator for that (for which the GC provides facilities) and you probably also want to increase the blocksize (for which there aren't facilities, and where you can break the GC if you don't know what you're doing). |
| 13:02:54 | Araq | you should patch --gc:boehm so that we give boehm type information |
| 13:03:25 | Araq | I tried it once |
| 13:03:27 | dom96 | Is there really a point to spawn when we have async await? |
| 13:03:28 | Jehan_ | Well, as I just said, that comes at the cost of really killing thread-local allocation performance. |
| 13:03:45 | Araq | oh well |
| 13:03:47 | dom96 | if the stuff i'm doing is IO bound I will use async anyway. |
| 13:04:01 | Araq | dom96: read the article please : |
| 13:04:17 | dom96 | In most cases it will also be CPU bound too so the async dispatcher will get parallelised. |
| 13:04:36 | Jehan_ | Mono has performance problems with the Boehm GC for just that reason. |
| 13:04:46 | Araq | http://www.1024cores.net/home/scalable-architecture/parallel-disk-io |
| 13:05:22 | Jehan_ | dom96: Tasks/futures are important primitives, but not the only ones you may need. |
| 13:05:42 | Araq | http://www.1024cores.net/home/scalable-architecture/wide-finder-2 |
| 13:05:57 | dom96 | Ok, but then shouldn't spawn only worry about CPU bound tasks? |
| 13:06:06 | Araq | "The program handles 45GB 218-million-lines logfile in 3 minutes 11 seconds, total consumed CPU time is 16:54, that is, ~5.5 hardware threads are busy on average (however, in reality there is a crucial difference between processing of the cached and uncached file parts). Average processing speed is 235MB/s (while disks are able to provide only 150MB/s, once again it's due to file caching).... |
| 13:06:08 | Araq | ...The entry contains ~1345 LOC, from which 926 are reusable code (parallel IO subsystem and hash map) and 419 are application-specific. The program contains 17 times more LOC than the initial Ruby program, and is 479 times faster." |
| 13:07:42 | Araq | the guy claims to have benchmarked async IO but async IO lost against his way to multithread |
| 13:08:20 | dom96 | So he uses blocking IO + threads? |
| 13:09:05 | Jehan_ | Araq, for what it's worth, that's one example. Different workloads often require different threading architectures. |
| 13:09:37 | Araq | dom96: yes. |
| 13:10:10 | Araq | Jehan_: true but the guy works for intel, and seems to know what he talks about :-) |
| 13:10:34 | Jehan_ | http://www.gap-system.org/hpcgap2013/Talks/Neunhoeffer1_orbits.pdf |
| 13:10:45 | dom96 | Interesting. |
| 13:11:18 | dom96 | Alright. It's definitely nice to provide alternatives. |
| 13:11:34 | dom96 | Especially if there are use cases where one is faster than the other. |
| 13:12:05 | dom96 | But we should try the same benchmark ourselves someday :P |
| 13:12:22 | Jehan_ | As you can see, this particular problem uses N worker threads and M hash servers. |
| 13:12:49 | Jehan_ | On a multi-threaded architecture. |
| 13:14:04 | Jehan_ | Araq: Different people have different pet problems, and different problems benefit from different approaches. |
| 13:14:39 | Araq | Jehan_: of course but that can't be the reason to provide nothing in the stdlib :-) |
| 13:14:58 | Jehan_ | Oh, I fully agree! |
| 13:15:22 | Jehan_ | But I'd argue for something that's configurable, not a one-size-fits-all solution. |
| 13:17:01 | Jehan_ | If I had to pick ONE solution, I'd go with a task/future-based approach based on expressiveness. |
| 13:17:52 | Jehan_ | Everyone can parallelize an embarallel problem, but you want facilities for when you don't have one. |
| 13:20:40 | Jehan_ | Incidentally, how robust are Nimrod's marshalling facilities? |
| 13:21:53 | Araq | quite robust, we use them for a couple of things |
| 13:22:10 | Araq | the limitations wrt inheritance are documented |
| 13:23:20 | Araq | it uses nimrod's RTTI though and so is not as fast as a macro based solution will be |
| 13:24:04 | Jehan_ | Since I'm interested in using them in conjunction with ZeroMQ, I'm not particularly stressed about marshalling performance. |
| 13:24:08 | * | faassen joined #nimrod |
| 13:24:17 | Jehan_ | Sending them over the wire is likely more expensive than marshalling. |
| 13:26:19 | Araq | watch out our ZeroMQ wrapper wraps some old version of it. iirc there is a babel package that's up to date |
| 13:27:56 | Jehan_ | Will look at it. It's nothing that I'd actually work on for another couple of weeks at least, anyway. |
| 13:34:51 | * | Jehan_ quit (Quit: Leaving) |
| 13:35:20 | * | Puffin joined #nimrod |
| 13:35:38 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 13:45:13 | * | Puffin is now known as BitPufiin |
| 13:48:13 | * | darkf quit (Quit: Leaving) |
| 13:52:44 | OrionPK | araq you make any progress on that 40 registers VM thing? |
| 14:03:08 | * | springbok quit (Quit: Leaving) |
| 14:15:12 | * | xyproto joined #nimrod |
| 14:16:04 | xyproto | Hi. I'm packaging nimrod for Arch Linux, but the install.sh script is no longer provided. Besides lib files in /usr/lib/nimrod and the binary as /usr/bin/nimrod, where should files be placed? The config directory, for example? |
| 14:16:19 | xyproto | As /etc/nimrod/ ? |
| 14:17:36 | foodoo | xyproto: Thank you. I am an Arch user :) |
| 14:18:34 | xyproto | foodoo: nice :) |
| 14:19:18 | foodoo | xyproto: Does nimrod-git in the AUR work for you? Maybe you can use the same approach |
| 14:20:07 | xyproto | foodoo: I think it's important that the official Arch Linux are well suited for programmers, since they lay the groundwork for so much other activities and packages. Also up and coming programming languages that are not that popular yet. |
| 14:20:23 | xyproto | foodoo: I'll take a look, thanks! |
| 14:20:38 | foodoo | I have to admit I'm currently using the AUR version because of the changes to babel and the package ecosystem that I wanted to have |
| 14:21:10 | xyproto | I see. What would it take for the official package to be preferable? I'm open for suggestions. :) |
| 14:21:26 | EXetoC | for the latest release? |
| 14:21:41 | xyproto | It is not unheard of to package -git packages as official packages either, if that's what it takes. |
| 14:21:47 | * | BitPufiin quit (Ping timeout: 252 seconds) |
| 14:22:37 | xyproto | EXetoC: the latest release of nimrod is about to be packaged? |
| 14:23:17 | foodoo | xyproto: As I have said: There were some fresh changes in the Nimrod package ecosystem/infrastructure that I wanted to have. So in the end it was just an issue of the git version being more recent. |
| 14:23:55 | xyproto | foodoo: I see! |
| 14:23:57 | foodoo | xyproto: But because Arch is bleeding edge I would not mind using the package from the official repos |
| 14:24:19 | EXetoC | xyproto: no |
| 14:24:29 | EXetoC | apparently 0.9.4 was added very recently |
| 14:24:37 | xyproto | foodoo: looking at the AUR package, it seems to be focused on version 0.9.0? And uses different build instructions than the official text files? |
| 14:24:56 | EXetoC | and I don't even know if I tested nimrod-git, but I'm doing it now. no one has complained yet |
| 14:25:13 | xyproto | EXetoC: Yes, 0.9.4 was recently released and is now about to be packaged. Sorry, I don't understand the question you had. |
| 14:25:24 | xyproto | EXetoC: "for the latest release?" |
| 14:26:03 | EXetoC | yes 0.9.4. packaged how? the nimrod package is for 0.9.4 since two days ago |
| 14:27:08 | xyproto | EXetoC: yes, 0.9.4 was packaged, but it packages more files than it needs to, by just copying over the directory to /usr/lib/nimrod. Not pretty. I'm trying to fix this now. |
| 14:27:16 | foodoo | xyproto: Yes, the PKGBUILD seems to do use it's own way of installing. But so far it works fine on my system. |
| 14:27:18 | EXetoC | oh |
| 14:27:30 | xyproto | EXetoC: the lack of installation instructions and installation scripts makes it akward |
| 14:28:39 | xyproto | Oh well. Perhaps the current package ain't all that bad. I'll look at the nimrod-git package and do some testing. Thanks guys. |
| 14:29:14 | foodoo | xyproto: Thank you too :) I'll probably switch to the official repos once the next update comes around |
| 14:29:59 | xyproto | foodoo: cool, cool :) |
| 14:30:11 | * | BitPufiin joined #nimrod |
| 14:34:12 | EXetoC | xyproto: ok well apparently niminst is invoked like this: "./tools/niminst/niminst --var:version=0.9.4 scripts compiler/nimrod.ini" |
| 14:34:50 | xyproto | foodoo: btw, gcc 4.9 has recently been pushed to [testing]. Would you mind installing gcc from testing and see if nimrod still works as it should? I get an error when compiling hallo.nim here, but I'm unsure if there are other reasons. |
| 14:35:21 | xyproto | EXetoC: nice, I'll try that! |
| 14:38:50 | EXetoC | Ill also try with the latest GCC. first time using testing |
| 14:39:07 | EXetoC | but I haven't heard about that many issues when using testing |
| 14:39:30 | foodoo | xyproto: should I first try to compile it with the current GCC to check that it's really an issue with GCC? |
| 14:39:44 | foodoo | current -> currently installed on my system |
| 14:40:49 | xyproto | foodoo: yes please, that would be great |
| 14:41:24 | xyproto | EXetoC: ok, cool. No, me neither, GCC 4.9 seems to work mostly fine, but gdc breaks. |
| 14:41:52 | foodoo | xyproto: do you also package D stuff for Arch? |
| 14:42:50 | xyproto | foodoo: no, just registered that GCC 4.9 was not flawless in combination with less popular programming languages :) |
| 14:43:47 | xyproto | foodoo: I package a few other languages, though, like clojure, go, chicken, julia and prolog |
| 14:44:11 | xyproto | swi-prolog, that is :P |
| 14:44:39 | foodoo | xyproto: oh, I didn't know we had julia in the official repos. Will uninstall the AUR version at once :) |
| 14:45:02 | xyproto | I think nimrod is exciting because it may cover a few things that Go and Rust could have covered better. Also the Android support looks interesting. |
| 14:45:52 | foodoo | gcc 4.8.2 20140206 (prerelease) compiles nimrod-git without errors |
| 14:46:27 | xyproto | ok, good. Hope it works with gcc 4.9 too. |
| 14:47:33 | foodoo | xyproto: okay, I need to activate testing first... |
| 14:47:58 | * | isenmann quit (Quit: Leaving.) |
| 14:53:44 | xyproto | foodoo: yeah, as you probably know, just two lines needs to be uncomment in /etc/pacman.conf, then pacman -Sy. |
| 14:54:18 | EXetoC | "lib/system/inclrtl.nim(25, 7) Error: undeclared identifier: 'appType'" |
| 14:54:29 | foodoo | xyproto: I also uncommented the SigLevel lines |
| 14:54:45 | xyproto | foodoo: yeah, that should work as well :) |
| 14:55:32 | xyproto | EXetoC: ajaj, that's different from the errors I got here! I got errors that starts with this: /tmp/nimcache/stdlib_system.o: In function `nimUnloadLibrary': |
| 14:55:50 | xyproto | EXetoC: (when compiling hallo.nim in /tmp with nimrod c hallo.nim) |
| 14:56:36 | xyproto | might be that upstream Nimrod developers has to look at the nimrod+gcc4.9 problems if you also experience this |
| 14:56:44 | foodoo | xyproto: nimrod-git from the AUR also compiles fine with gcc 4.9.0 |
| 14:56:53 | EXetoC | :o |
| 14:56:55 | xyproto | foodoo: cool. But does compiling stuff works afterwards? |
| 14:57:11 | xyproto | foodoo: like hallo.nim from the examples |
| 14:57:20 | * | [1]Endy joined #nimrod |
| 14:58:05 | foodoo | xyproto: echo "Hello world!" #works |
| 14:58:51 | Skrylar | nevermind. i thought the png header would be better than jpeg |
| 14:58:57 | Skrylar | the png header is a wonderland of stupid |
| 14:59:28 | EXetoC | c(:) |
| 15:00:57 | * | [2]Endy quit (Ping timeout: 250 seconds) |
| 15:02:37 | xyproto | foodoo: ok, then there's something wonky here. I'll try the git version as well. :) |
| 15:03:25 | xyproto | foodoo: I'll probably end up doing things the same way as nimrod-git, since that seems to work for you. Thanks for testing! |
| 15:03:35 | xyproto | EXetoC: thanks for testing too :) |
| 15:04:07 | EXetoC | np. trying again now |
| 15:04:52 | foodoo | xyproto: what's the error that you get? |
| 15:06:29 | xyproto | foodoo: this is the output http://ix.io/c3N |
| 15:07:06 | xyproto | foodoo: I am yet to narrow down which package or variation causes this, but I'll try the nimrod-git packaage from AUR now. |
| 15:07:13 | EXetoC | it worked the second time, so it must've used some existing files, and then failed because of some incompatibility |
| 15:09:00 | xyproto | AHA. Compiling stuff with nimrod creates a "nimcache" folder and this one interfers with later compilations! |
| 15:09:52 | EXetoC | I wonder where it ends up in this case then |
| 15:09:55 | xyproto | Nimrod does not detect that the version of gcc is different from last time. |
| 15:10:15 | foodoo | xyproto: And that is why you get linking errors? |
| 15:10:25 | xyproto | nope, still get the same errors after removing "nimcache" :( |
| 15:10:43 | xyproto | This is with gcc 4.9 and the currently official nimrod package |
| 15:10:49 | xyproto | weirdness |
| 15:10:56 | EXetoC | ok we're referring to slightly different issues. nevermind |
| 15:12:15 | xyproto | foodoo: released a new version of julia right now, btw. Uses a later commit that fixes an issue that one user had. |
| 15:12:27 | xyproto | foodoo: if you use Julia |
| 15:13:15 | foodoo | xyproto: just exchanges the AUR package for yours |
| 15:13:22 | foodoo | -s+d |
| 15:16:13 | * | bjz_ quit (Ping timeout: 245 seconds) |
| 15:16:43 | EXetoC | xyproto: so 'which nimrod' refers to the right exe? |
| 15:17:51 | * | [2]Endy joined #nimrod |
| 15:19:35 | foodoo | xyproto: and also: pacman -Qo $(which nimrod) |
| 15:21:18 | * | [1]Endy quit (Ping timeout: 240 seconds) |
| 15:22:21 | EXetoC | I forgot about that. pkgfile doesn't work for AUR packages |
| 15:23:30 | xyproto | Building the AUR package now, will test it. Assuming it will work fine. If it does, I'll package that one. |
| 15:25:16 | * | [1]Endy joined #nimrod |
| 15:28:09 | * | [2]Endy quit (Ping timeout: 252 seconds) |
| 15:29:56 | xyproto | yes, nimrod-git works great |
| 15:29:59 | xyproto | with gcc 4.9 |
| 15:30:08 | foodoo | \o/ |
| 15:30:18 | xyproto | will follow the same pattern and update the official package |
| 15:37:14 | foodoo | will the official package be called nimrod or nimrod-git? |
| 15:44:43 | * | [2]Endy joined #nimrod |
| 15:44:47 | xyproto | nimrod, even though it will be pretty similar to nimrod-git. Because, I assume it's only a matter of time before there will be a release of nimrod that differs from the very latest git release? |
| 15:45:10 | xyproto | If not, the official package should be named either nimrod or nimrod-git, and there should only be one. |
| 15:47:56 | * | [1]Endy quit (Ping timeout: 276 seconds) |
| 15:48:19 | EXetoC | similar yes, but more stable obviously. but releases don't mean all that much yet as others have pointed out |
| 15:52:27 | xyproto | right |
| 15:53:48 | EXetoC | for the majority of the people anyway |
| 15:54:52 | xyproto | rlease tags seems to be an increasingly common way of releasing projects. Might be an idea for Nimrod too? |
| 15:54:58 | * | skyfex quit (Quit: Computer has gone to sleep.) |
| 15:55:34 | * | skyfex joined #nimrod |
| 15:55:39 | EXetoC | we do have git tags |
| 15:57:03 | xyproto | EXetoC: yes, they are present at github "v0.9.4" etc |
| 15:59:17 | * | foodoo quit (Remote host closed the connection) |
| 16:00:42 | * | untitaker quit (Ping timeout: 240 seconds) |
| 16:05:20 | * | [1]Endy joined #nimrod |
| 16:07:44 | * | untitaker joined #nimrod |
| 16:07:58 | * | [2]Endy quit (Ping timeout: 240 seconds) |
| 16:20:44 | * | [2]Endy joined #nimrod |
| 16:23:30 | * | [1]Endy quit (Ping timeout: 240 seconds) |
| 16:41:14 | * | [1]Endy joined #nimrod |
| 16:41:24 | * | brechtm joined #nimrod |
| 16:44:08 | * | [2]Endy quit (Ping timeout: 252 seconds) |
| 16:53:41 | * | DAddYE joined #nimrod |
| 17:00:33 | * | [2]Endy joined #nimrod |
| 17:03:59 | * | [1]Endy quit (Ping timeout: 276 seconds) |
| 17:09:43 | brechtm | Is it possible to convert a ptr to a ref? |
| 17:10:04 | brechtm | (so hand over memory management for that pointer to the GC) |
| 17:18:55 | * | q66 joined #nimrod |
| 17:18:55 | * | q66 quit (Changing host) |
| 17:18:56 | * | q66 joined #nimrod |
| 17:22:43 | * | sebaseba joined #nimrod |
| 17:25:42 | EXetoC | ok so what do we do about the name conflict of the babel exe? |
| 17:26:36 | brechtm | var cwindow_size: ptr csize = cast[ptr csize](alloc(sizeof(csize))) |
| 17:26:51 | brechtm | surely there must be more compact way? |
| 17:27:36 | brechtm | ah, unsafeNew? |
| 17:28:18 | brechtm | no |
| 17:28:25 | dom96 | you don't need the ': ptr csize' |
| 17:28:50 | EXetoC | also, type-based versions have been added. you might be able to spot them in the reference |
| 17:30:56 | brechtm | should I use int and int32 instead of csize and cint BTW? |
| 17:31:18 | fowl | brechtm, no, use the closes thing to c |
| 17:31:31 | fowl | if its size_t in c, use csize |
| 17:31:44 | EXetoC | usually you don't have to allocate in this case |
| 17:32:09 | EXetoC | if a pointer is expected then you can just pass the address of a stack-allocated var |
| 17:32:15 | brechtm | EXetoC: pass the address of a ref instead? |
| 17:32:19 | brechtm | ah :) |
| 17:32:38 | fowl | var windWidth, winHeight: csize; get_window_size(window, winWidth.addr, winHeight.addr) |
| 17:32:43 | brechtm | EXetoC: that should clean up things alot |
| 17:33:01 | brechtm | thanks guys |
| 17:33:15 | EXetoC | there's create(csize) though, but yeah |
| 17:33:31 | fowl | whats that |
| 17:33:48 | fowl | oh i see |
| 17:34:25 | fowl | proc create[](T: typedesc; size = 1.Positive): ptr T:type {.inline, gcsafe.} |
| 17:35:15 | fowl | weird looking signature |
| 17:35:16 | EXetoC | see how bleeding-edge I am by using ranges and everything |
| 17:35:31 | EXetoC | ok |
| 17:36:13 | EXetoC | dunno what [] and T:type is doing there, but what's weird? |
| 17:36:53 | fowl | just that |
| 17:37:03 | fowl | here's the line from system.nim |
| 17:37:10 | fowl | proc create*(T: typedesc, size = 1.Positive): ptr T {.inline, gcsafe.} = |
| 17:37:41 | EXetoC | yeah looking at the generated documentation now |
| 17:42:25 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 17:44:02 | EXetoC | reported |
| 17:44:14 | * | [1]Endy joined #nimrod |
| 17:48:11 | * | [2]Endy quit (Ping timeout: 276 seconds) |
| 18:08:52 | Araq | hi xyproto welcome (back?) |
| 18:14:43 | EXetoC | I guess we just rename the babel exe |
| 18:18:25 | EXetoC | nimbab? nimbabel? nimb? |
| 18:22:08 | Araq | what does the other babel.exe do? |
| 18:22:33 | EXetoC | it's for Open Babel, which is a chemical expert system |
| 18:24:30 | Araq | they should rename their babel.exe ours is more popular :P |
| 18:25:30 | njoejoe | LOL |
| 18:26:25 | dom96 | EXetoC: Do you use this chemical expert system? |
| 18:27:27 | EXetoC | no |
| 18:27:32 | dom96 | then what's the problem? |
| 18:27:40 | EXetoC | I don't know why it was even installed at some point |
| 18:27:50 | EXetoC | because someone else might. what then? |
| 18:28:57 | brechtm | how to logical-or enum types? |
| 18:29:14 | dom96 | I'm sure there is a LOT of packages with the same problem and somehow things work just fine. |
| 18:29:28 | * | noam_ joined #nimrod |
| 18:29:43 | EXetoC | I don't know how it can work just fine. |
| 18:30:01 | dom96 | You simply remove one of the packages. |
| 18:31:22 | * | noam quit (Ping timeout: 255 seconds) |
| 18:35:38 | brechtm | mmm, need to convert to cint to be able to or |
| 18:42:45 | EXetoC | or some other TInteger |
| 18:45:40 | brechtm | EXetoC: any particular reason directly orring enums is not supported? |
| 18:47:33 | fowl | enums are not just special identifiers like c |
| 18:47:46 | fowl | if nimrod was c, we'd call it c |
| 18:48:11 | EXetoC | chances are you'll end up with an invalid value. it might make more sense to use a set instead |
| 18:48:12 | fowl | e to the t to the c |
| 18:48:57 | EXetoC | doStuff({abcFoo, abcBar}) |
| 18:50:04 | brechtm | are there more nimrod-y abstractions built on top of some of the C lib wrappers? |
| 18:50:25 | EXetoC | in some cases |
| 18:54:01 | EXetoC | what do you have in mind? |
| 18:58:53 | * | BitPufiin quit (Ping timeout: 252 seconds) |
| 18:59:42 | Araq | so how do I find out CPU utilization in Linux? parsing procfs can't be the only way |
| 19:00:11 | fowl | i use htop |
| 19:01:52 | Araq | what is it with Unix and its absurd hatred for APIs? |
| 19:02:29 | Araq | int get_cpu_usage(); how hard can it be? |
| 19:09:39 | brechtm | EXetoC: nothing in particular, just want to look at some example code |
| 19:11:27 | * | [2]Endy joined #nimrod |
| 19:12:21 | * | io2 joined #nimrod |
| 19:13:18 | * | menscrem quit (Ping timeout: 240 seconds) |
| 19:14:23 | * | [1]Endy quit (Ping timeout: 252 seconds) |
| 19:14:26 | njoejoe | Araq: this reads /proc/stat: https://github.com/fho/code_snippets/blob/master/c/getusage.c |
| 19:16:08 | EXetoC | he did say procfs so he probably meant that |
| 19:17:52 | EXetoC | "The proc filesystem is the API" :-) |
| 19:18:02 | * | Jehan_ joined #nimrod |
| 19:18:41 | Araq | njoejoe: thanks |
| 19:19:21 | Jehan_ | I found an interesting application for templates. |
| 19:19:34 | Jehan_ | Partially unroll and inline a recursive search. |
| 19:20:04 | Araq | Jehan_: thinking about it, it seems quite easy to do: if spawn doesn't find a free thread, it should query the OS for the CPU load |
| 19:20:25 | Araq | and if it's not 100% load, it can create an additional thread for processing |
| 19:20:44 | Araq | or perhaps 90% or whatever |
| 19:21:08 | Araq | Jehan_: iterators can also perform partial unrolling very easily |
| 19:21:09 | Jehan_ | Hmm. I think I'd just create a pool with K*N workers, where N is the number of cores and K a useful constant. |
| 19:21:23 | Araq | yes, but that sucks ;-) |
| 19:21:28 | Jehan_ | Extra threads rarely hurt, except for startup time, but that doesn't matter with a pool. |
| 19:21:39 | Jehan_ | iterators and recursion don't mix so well, though. |
| 19:21:45 | Araq | because K is application dependent |
| 19:21:52 | * | [1]Endy joined #nimrod |
| 19:22:19 | Jehan_ | Yup. Let the user set it. :) |
| 19:22:21 | EXetoC | 42 |
| 19:22:31 | Jehan_ | And provide a reasonable default. |
| 19:22:34 | Araq | plus it's really cool to send the source code to some benchmark guy and tell him to not worry, it will adapt to his particular CPU |
| 19:23:04 | Jehan_ | That's true, but you could mostly achieve that with just being able to query the hardware. |
| 19:23:23 | Jehan_ | Also, as I said, you can easily crash and burn on NUMA architectures with certain workloads. |
| 19:23:56 | Jehan_ | I've built workloads that get slower with more threads on those even. :) |
| 19:24:38 | * | [2]Endy quit (Ping timeout: 240 seconds) |
| 19:24:56 | Jehan_ | And by more threads, I mean more than those that fit on a single node. |
| 19:25:39 | Jehan_ | If I fiddle with thread affinity, I can even make two threads slower than the single threaded solution even where they don't contend for locks. |
| 19:27:13 | Araq | Jehan_: well we already have osproc.countProcessors |
| 19:27:27 | Araq | not sure how to determine the topology |
| 19:27:35 | Jehan_ | The problem is that most NUMA architectures are actually a distributed architectures that only give the illusion of shared memory. |
| 19:28:07 | Jehan_ | A specific problem is that concurrent GCs that aren't specifically tuned for this case tend to crash and burn. |
| 19:28:17 | Jehan_ | But it's a problem for a lot of other workloads that contend for memory accesses. |
| 19:29:44 | Jehan_ | It's a rather persistent problem for me, since any architecture that I realistically need for HPC is either NUMA or actually distributed (whether a cheap AMD rig or a Cray). |
| 19:30:21 | Jehan_ | This means that I generally need a mix of multiprocessing and multithreading for max performance for my use cases. |
| 19:30:40 | Jehan_ | And usually a handcrafted setup that knows the topology. |
| 19:30:52 | Araq | yeah well I'm sorry I'm not designing my 'spawn' for you :P |
| 19:31:02 | Jehan_ | Oh, I'm not complaining! |
| 19:32:00 | Jehan_ | Not at you, I mean, I'm obviously venting some frustration, but that's with hardware designers. And the laws of nature. :) |
| 19:32:34 | Jehan_ | Still, you probably want to at least consider those architectures if you want Nimrod to scale beyond desktop machines. |
| 19:35:34 | Araq | that's easily solvable with a tweakable max number of threads that the thread pool will use |
| 19:36:00 | Jehan_ | What I keep saying. :) |
| 19:36:37 | Araq | but still creating new threads at runtime depending on the load seems to be the way to go |
| 19:37:14 | Jehan_ | Depends on how precise the load information is. |
| 19:38:13 | Araq | more precise than K*N :P |
| 19:38:17 | Jehan_ | But yeah, this is also why Apple did Grand Central. Unfortunately, hidden behind a proprietary design. |
| 19:39:21 | Jehan_ | I like OS X for desktop use, but interacting with the OS facilities as a programmer can be frustrating. |
| 19:40:30 | Jehan_ | "We don't think you need efficient thread-local storage. We don't think you need anonymous semaphores. Etc." |
| 19:41:25 | Araq | "We think uname should return the bitwidth of the CPU when *booting* " |
| 19:41:37 | Araq | (fixed by now though) |
| 19:42:23 | * | [2]Endy joined #nimrod |
| 19:45:10 | * | [1]Endy quit (Ping timeout: 240 seconds) |
| 19:45:24 | brechtm | babel uses the git executable, I assume? |
| 19:45:44 | Araq | right |
| 19:58:14 | njoejoe | I use this little library called nori: https://github.com/savonrb/nori which parses xml into a hash. like o = parse(xml); puts o["head"]["data"]. Is there anything similar for nimrod, or is it even possible? it sure makes things simple when dealing with the nightmare called SOAP. |
| 20:02:54 | * | [1]Endy joined #nimrod |
| 20:05:59 | * | [2]Endy quit (Ping timeout: 252 seconds) |
| 20:09:59 | Araq | njoejoe: the xmltree module is not too far off that, I think |
| 20:15:31 | njoejoe | thanks Araq I will give xmltree a spin |
| 20:15:46 | * | Jesin joined #nimrod |
| 20:19:39 | * | Demos joined #nimrod |
| 20:19:48 | Demos | ugh I hate building software on windows |
| 20:22:24 | brechtm | a proc's pragma list can start on the next line, right? |
| 20:23:29 | * | [2]Endy joined #nimrod |
| 20:23:43 | Demos | like I would really like to have all the dynamic versions of stuff linked with MSVCRXXX.dll and the static versions linked with LIBCMT.lib but that is nontrivial in the build systems people use |
| 20:24:29 | EXetoC | brechtm: yes |
| 20:26:20 | * | [1]Endy quit (Ping timeout: 252 seconds) |
| 20:33:04 | * | flaviu joined #nimrod |
| 20:34:23 | Varriount | Demos: LibCMT? |
| 20:34:44 | Demos | the multi-threaded c standard library |
| 20:35:25 | Varriount | brechtm: Yes. It can. |
| 20:38:07 | EXetoC | we need a third opinion |
| 20:38:31 | EXetoC | that's good enough for statistical purposes |
| 20:38:53 | brechtm | :) |
| 20:39:08 | * | brechtm is waiting |
| 20:40:43 | EXetoC | your opinion would count |
| 20:41:52 | brechtm | is 2 out of three enough BTW? |
| 20:43:10 | EXetoC | yeah sure |
| 20:43:20 | Araq | opinion about what? |
| 20:43:36 | brechtm | EXetoC: then it's already decided |
| 20:43:56 | * | [1]Endy joined #nimrod |
| 20:44:32 | * | ehaliewicz joined #nimrod |
| 20:45:23 | flaviu | Varriount: Is http://gameprogrammingpatterns.com/bytecode.html helpful? |
| 20:46:05 | flaviu | Also, the lua VM has excellent documentation IIRC |
| 20:46:24 | brechtm | need more automation if I want to wrap all of libgit2 |
| 20:46:33 | EXetoC | Araq: jk |
| 20:46:38 | * | [2]Endy quit (Ping timeout: 240 seconds) |
| 20:46:48 | fowl | help |
| 20:46:54 | fowl | i need better operators for my combinator |
| 20:47:51 | dom96 | fowl: Have you considered: (╯°□°）╯︵ ┻━┻ ? :P |
| 20:47:59 | Varriount | Araq: Regarding thread pools and such, I'd rather have a low level interface that you can get down and dirty with, and a high level interface built off of that. After all, nimrod *is* supposed to be a systems programming language, and thus must provide a way to work around the idiosyncracies of a unique system. |
| 20:48:05 | EXetoC | “µº‘º’©®¢ŁıŒ®©Ł¢©łß©đœþł€®→y pick |
| 20:48:17 | Varriount | (I'm looking through the log) |
| 20:48:20 | fowl | chr('A')&chr('B')|chr('C') #=> (chr(A) & (chr(B) | chr(C))) |
| 20:48:43 | fowl | i need the or op to be lower.. maybe i should just use and and or |
| 20:49:02 | flaviu | ┬──┬◡ﾉ(° -°ﾉ) |
| 20:49:19 | Varriount | flaviu: I'd like something a bit more high level. Like, say, a guided tour on classical VM architecture, with a comparison of register VS stack based VMs |
| 20:49:42 | Araq | Varriount: createThread exists and is not going away |
| 20:49:47 | flaviu | I came across something like that, maybe I have it bookmarked |
| 20:50:01 | njoejoe | ¯\_(ツ)_/¯ |
| 20:50:16 | Araq | Varriount: I don't think you'll find that on the internet. better ask me ... :P |
| 20:50:52 | Varriount | Araq: What is the context for that talk about thread pooling, hueristics, etc that you had with Jehan_ |
| 20:51:09 | xyproto | Araq: hi, thanks :) Think I've been visiting before, yes. Nice work on Nimrod. |
| 20:51:22 | Araq | Varriount: the high level interface |
| 20:51:30 | fowl | dom96, EXetoC unicode operators arent easy to type |
| 20:51:39 | Varriount | Araq: High level interface for...? |
| 20:51:54 | dom96 | fowl: It's ok, we'll build a new keyboard, we have the technology! |
| 20:52:08 | Araq | for concurrency and parallelism |
| 20:52:27 | Araq | I'm mostly focussing on parallelism these days fyi |
| 20:52:41 | Varriount | Araq: Like python's 'concurrent' module? |
| 20:53:08 | Araq | I don't know python's concurrent module |
| 20:53:37 | Varriount | "The concurrent.futures module provides a high-level interface for asynchronously executing callables. |
| 20:53:38 | Varriount | The asynchronous execution can be performed with threads, using ThreadPoolExecutor, or separate processes, using ProcessPoolExecutor. Both implement the same interface, which is defined by the abstract Executor class." |
| 20:53:55 | Varriount | (Python documentation) |
| 20:54:00 | EXetoC | dom96: you don't need that many keys either |
| 20:54:08 | Araq | ok, well I'm not working on "futures" |
| 20:54:18 | EXetoC | just have an icon on each corner of a key and some more meta keys |
| 20:54:22 | dom96 | EXetoC: You don't need keys! Touch screen baby! |
| 20:54:23 | Araq | but on the "ThreadPoolExecutor" |
| 20:54:52 | dom96 | EXetoC: Then you can have all the unicode symbols display on the screen, with some clever modifiers. Maybe. |
| 20:56:54 | brechtm | what type should time_t be mapped to? |
| 20:57:04 | Araq | brechtm: times.TTime |
| 20:57:27 | Araq | and yes we'll get rid of the type prefixes, spare me :P |
| 20:58:23 | brechtm | Araq: I was trying to not share my opinion before giving nimrod some time first :) |
| 20:58:39 | brechtm | but since you bring it up... ;) |
| 20:59:18 | brechtm | Araq: will "var bla = Bla()" be possible? |
| 20:59:42 | Varriount | brechtm: It already is, to some extent. |
| 20:59:58 | Varriount | brechtm: The nimrod compiler has case sensitivity options. |
| 21:00:20 | brechtm | Initially I was all "eeek" when reading about the case/underscore-sensitivity, but I think I might even appreciate it |
| 21:00:40 | brechtm | Varriount: interesting |
| 21:00:43 | Varriount | Although, I can't remember if the option can be made module-specific with the use of the push and pop pragmas. |
| 21:00:59 | Araq | Varriount: no it's a global setting |
| 21:01:00 | Jehan_ | Both case-sensitivity and case-insensitivity have advantages and disadvantages. |
| 21:01:13 | * | Demos quit (Ping timeout: 245 seconds) |
| 21:01:17 | Varriount | Araq: Aw, what a shame. |
| 21:01:50 | * | Matthias247 joined #nimrod |
| 21:02:00 | Araq | Varriount: it's very hard to implement otherwise and even not obvious what it should do |
| 21:02:07 | Varriount | Though I can imagine how complex making such an option non-global would be. |
| 21:02:33 | Araq | If module A turns it on and exports Foo and foo and module B turns it off and imports module A ... what happens? |
| 21:03:04 | Varriount | Yeah. It would probably cause massive confusion. (If not for other developers, then for you.) |
| 21:04:27 | * | [2]Endy joined #nimrod |
| 21:07:35 | brechtm | I'm a bit worried about making many of these things configurable though |
| 21:07:44 | * | [1]Endy quit (Ping timeout: 276 seconds) |
| 21:07:59 | Araq | brechtm: it's only configurable for a transition period |
| 21:08:02 | brechtm | Makes it possible to write code in wildly different styles, harming readability |
| 21:08:26 | EXetoC | that's what's allowed currently |
| 21:08:40 | EXetoC | the style is fairly uniform though |
| 21:08:56 | brechtm | I read the forum thread about enforcing camelCase and CamelCase for different things... I would like that |
| 21:09:10 | brechtm | but you'd never reach agreement on what style to use, of course :/ |
| 21:09:47 | brechtm | Araq: transition to enforced style? |
| 21:10:28 | Araq | brechtm: no transition to get your code case consistent |
| 21:11:07 | Araq | but I don't know, there is now quite a lot of code out there |
| 21:11:33 | Araq | and --cs:partial creates more problems than it solves, IMO |
| 21:11:48 | Araq | I think I'll come up with something even crazier like |
| 21:12:25 | reactormonk | Araq, so what problems? |
| 21:12:55 | Araq | "if different identifiers are imported into the same scope, casing disambiguates" |
| 21:13:24 | Araq | var foo: Foo # ok, foo and Foo distinct in this scope |
| 21:13:43 | brechtm | wouldn't that make errors hard to spot? |
| 21:14:09 | Araq | what errors? we have a type system to catch errors |
| 21:14:54 | brechtm | Araq: if you import a module exporting "foo", and one exporting "Foo" |
| 21:15:50 | Araq | reactormonk: the problem that people can't use this_style_everywhere and pretend uppercase letters don't exist. ;-) |
| 21:15:50 | brechtm | possible objects of the same type |
| 21:16:28 | Araq | brechtm: hmm I dunno |
| 21:16:44 | njoejoe | what if you just did: var foo and if no type, it becomes var foo: Tfoo behind the scenes... probably dumb. |
| 21:16:49 | brechtm | I personally like the Python style: lowercase_with_underscores for functions UpperCamelCase for classes |
| 21:17:03 | brechtm | might as well enforce that, but that's just me |
| 21:17:13 | Araq | yeah. I don't like that at all. |
| 21:17:28 | brechtm | ahh, opinions suck |
| 21:17:31 | Araq | underscores are arachaic |
| 21:17:47 | brechtm | I think they're easier to read |
| 21:18:14 | Araq | I think they're harder to read |
| 21:18:31 | brechtm | but because of discussions like these, I'm not so much against the case/underscore insensitvity |
| 21:18:37 | Araq | makes tokenizing much harder |
| 21:18:39 | brechtm | as long as the compiler / IDE provides good support |
| 21:19:05 | Araq | which is more important than the subterms the identifier consists of |
| 21:19:27 | brechtm | And it's not bad to explicitly label value/ref types with T/P |
| 21:19:27 | Jehan_ | brechtm: That's also my preference. I think it depends largely on what you grow up with. |
| 21:19:48 | Jehan_ | The Python/Ruby style of using camel case vs. underscores, I mean. |
| 21:20:18 | brechtm | Araq: tokenizing? |
| 21:20:55 | Araq | spot where_the things_begin and end; |
| 21:21:03 | brechtm | I see |
| 21:21:55 | brechtm | Araq: the syntax coloring scheme should make it clear in most (all?) cases |
| 21:22:07 | Araq | horrible. F# went from underscores to camelCase afaik for these reasons |
| 21:22:33 | Araq | brechtm: syntax coloring can patch over every bad syntax |
| 21:22:37 | brechtm | Araq: should we stick to plain old text files even? |
| 21:23:08 | brechtm | that will fuck up working with a lot of dev tools though (diff, vcs) |
| 21:23:16 | Araq | yup |
| 21:23:33 | brechtm | but it could also lead to a more powerful diff tool |
| 21:23:42 | brechtm | one that is aware of semantics |
| 21:23:57 | Araq | plain old text files are stupid but it's easy to do worse and hard to do better |
| 21:23:59 | brechtm | and as a result automatic merging |
| 21:24:36 | Araq | and btw code is NOT a tree. It is a graph. |
| 21:24:57 | * | [1]Endy joined #nimrod |
| 21:24:58 | * | DAddYE quit (Remote host closed the connection) |
| 21:25:10 | brechtm | but I probably wouldn't dare to say "no more plain text source code for you"... that'll be impossible to sell |
| 21:26:37 | brechtm | enough bikeshedding? |
| 21:28:32 | * | [2]Endy quit (Ping timeout: 276 seconds) |
| 21:29:32 | Araq | brechtm: what do you think about our "strong spaces" feature? |
| 21:30:11 | brechtm | I'm not sure what that feature encompasses... link? |
| 21:30:29 | brechtm | Araq: to force operator precedence? |
| 21:30:59 | Varriount | brechtm: The feature causes the compiler to use spaces between idents as a clue for operator precedence. |
| 21:31:08 | brechtm | Araq: if that, I don't think I like it much (but I always surround operators with whitespace) |
| 21:31:50 | Varriount | brechtm: But do you really? Do you surround your '.' with whitespace? |
| 21:32:32 | EXetoC | :E |
| 21:33:28 | brechtm | Araq: similar to your argument about the underscores, no whitespace around operators hampers readability |
| 21:33:34 | brechtm | Varriount: no, not that one :) |
| 21:33:51 | brechtm | Varriount: it's ... special |
| 21:33:54 | Varriount | brechtm: There are certain cases that significant whitespace solves. |
| 21:34:05 | brechtm | Varriount: I'm sure of that |
| 21:34:16 | renesac | brechtm, but you would be against it being on by default? |
| 21:34:22 | Araq | brechtm: not really _ is special because it's ugly as fuck |
| 21:34:38 | Varriount | brechtm: http://forum.nimrod-lang.org/t/385 |
| 21:34:54 | brechtm | This might sound very conservative, but it might not be a good idea to introduce too many "innovative" features to nimrod all at once |
| 21:34:58 | renesac | if you don't want to use it, just use parenthesis and do not left unbalanced spaces around operators |
| 21:35:34 | brechtm | I understand many people are horrified by the significant indentation in Python |
| 21:35:43 | Araq | brechtm: too late, we're already ahead of anything else by 2 decades ... :P |
| 21:35:45 | Varriount | brechtm: It's completely optional. You have to explicitly enable it with a syntax filter. |
| 21:35:51 | brechtm | you might want to build a userbase first |
| 21:36:38 | brechtm | Varriount: I'm aso a bit unsure about offering too many switches, as I said before |
| 21:37:09 | Varriount | brechtm: It's not a switch... not a command line one, at least. |
| 21:37:13 | brechtm | that said, Nimrod is by far the most interesting language I've come across |
| 21:38:01 | brechtm | significant whitespace was an absolute requirement for me.... I can't understand why you *woulnd't* in the post-Python era |
| 21:38:21 | Varriount | brechtm: http://forum.nimrod-lang.org/t/209/3 |
| 21:38:32 | Araq | brechtm: ha. :-) |
| 21:39:15 | * | brechtm tries to catch up |
| 21:39:20 | Varriount | brechtm: I still don't understand why languages require mandatory semicolons. It's easy enough to make them optional. |
| 21:39:33 | * | flaviu quit (Read error: Connection reset by peer) |
| 21:40:09 | brechtm | Varriount: because typing those semicolons are the easy part of programming? :) |
| 21:40:41 | brechtm | renesac: I guess so... but never say never :) |
| 21:40:49 | Varriount | brechtm: Not when you're trying to teach those who are new to programming. Not when you're doing refactoring or code writing without an IDE. |
| 21:41:44 | Varriount | "Syntax Error: Missing Semicolon on line 33" <- If you know a semicolon is missing at that place, why not act like there's one there anyway and move on? |
| 21:42:54 | brechtm | Varriount: most compilers hardly ever pinpoint where the semicolon is missing unfortunately |
| 21:42:55 | dom96 | I fear 90% of people will have a negative reaction to strong spaces |
| 21:43:02 | Araq | Varriount: you could say the same about "missing )" though |
| 21:43:27 | Varriount | brechtm: Javac does. |
| 21:43:34 | dom96 | Araq: That is why you should write a blog post about it and gauge reddit's feedback before implementing it |
| 21:43:35 | brechtm | dom96: I agree... it will be difficult enough to gain momentum even without many disputable features |
| 21:44:19 | brechtm | Araq: I have to say "echo $variable" confused me a lot the first time though |
| 21:44:29 | Araq | dom96: that's crazy talk |
| 21:44:40 | Varriount | dom96, brechtm: Remember that the feature is optional, and turned off by default? |
| 21:44:48 | dom96 | Varriount: For now. |
| 21:44:49 | Araq | by that logic we'll get a compiled JavaScript |
| 21:44:58 | Araq | or something worse |
| 21:45:07 | Varriount | Compiled PHP? |
| 21:45:13 | Varriount | *shudder* |
| 21:45:28 | * | [2]Endy joined #nimrod |
| 21:46:29 | brechtm | Varriount: but what if people start using it!? :) |
| 21:46:42 | dom96 | If we had a corporate backer like Google or Mozilla we could spend our time writing lots of blog articles convincing people just how much better style insensitivity is |
| 21:47:15 | dom96 | Just the Google/Mozilla logo would make the reader's brains switch off and accept whatever we tell them ;) |
| 21:47:27 | brechtm | dom96: and Nimrod even has exceptions ;) |
| 21:47:30 | Varriount | Aren't there public grants we could apply for to get funding? |
| 21:47:57 | brechtm | Varriount: yes, you might want to inform with the PyPy crew about that |
| 21:48:01 | Varriount | (Also, where's the donation button on the website)? |
| 21:48:09 | dom96 | (Community tab) |
| 21:48:17 | * | [1]Endy quit (Ping timeout: 250 seconds) |
| 21:48:51 | Araq | hi [2]Endy . fix your connection please. |
| 21:50:29 | Araq | or I could finally write that blog post that explains the average nimrod code is far easier to reason about than Java, C# or Golang. |
| 21:51:45 | dom96 | or someone should create something commercially viable in Nimrod |
| 21:51:53 | dom96 | and create a startup around it |
| 21:52:08 | * | [2]Endy quit (Ping timeout: 252 seconds) |
| 21:52:38 | EXetoC | I think that's a common IRC client problem. temp ban if you want :> |
| 21:52:48 | brechtm | Are there plans for a Nimrod interpreter BTW? |
| 21:52:50 | reactormonk | Varriount, tried messing a bit with the idetools, got a new issue :-/ |
| 21:53:10 | brechtm | that's one area where I would still prefer Python, very easy to deploy |
| 21:53:29 | brechtm | dom96: someone, how about yourself? :) |
| 21:53:36 | Araq | brechtm: we have register based interpreter ... |
| 21:54:02 | Araq | we don't expose its API yet though |
| 21:54:12 | brechtm | Araq: that's the one used in "nimrod i" ? |
| 21:54:20 | Araq | yeah |
| 21:54:32 | reactormonk | and it kinda sucks |
| 21:54:40 | dom96 | brechtm: well, I don't want to jinx it. So let's just say I have thought about it :P |
| 21:54:41 | brechtm | good to hear that's on the horizon though |
| 21:55:00 | brechtm | dom96: :) |
| 21:55:07 | Araq | reactormonk: it also empowers our macro system ... |
| 21:55:26 | Araq | "nimrod i" always has been a step child |
| 21:55:44 | reactormonk | you don't really like step childs, do you :-P |
| 21:55:57 | Araq | in retrospect it would have been better not to provide it at all |
| 21:56:40 | dom96 | we all still want a REPL |
| 21:56:46 | reactormonk | REPL REPL REPL |
| 21:57:02 | brechtm | make it so! |
| 21:57:21 | reactormonk | But I gotta say I'd prefer for the idetools to be working over a REPL... REPL is good for trying out stuff, but completion is more awesome |
| 21:58:36 | EXetoC | I can try out stuff just fine without it, especially with nimrod.vim |
| 21:58:46 | dom96 | reactormonk: fix the ide tools! |
| 21:58:47 | * | flaviu joined #nimrod |
| 21:58:49 | brechtm | Araq: why not? I appreciated it taking my very first nimrod steps |
| 21:59:04 | reactormonk | dom96, tried yesterday, now they crash earlier than before :-/ |
| 21:59:10 | reactormonk | and without backtrace :-( |
| 21:59:15 | dom96 | reactormonk: :( |
| 21:59:37 | EXetoC | brechtm: because it has been a broken feature all this time I think |
| 21:59:48 | flaviu | Araq: `nimrod i` is a big deal, even if only it helps debug the VM |
| 22:00:23 | Araq | as long as the average terminal gui is abysmal I can't see why people use REPLs |
| 22:00:44 | reactormonk | did you just use terminal and GUI in the same sentence? |
| 22:01:01 | dom96 | Araq: I'll tell you why. It's more convenient than opening a new tab in Aporia. |
| 22:01:01 | Araq | python's at least comes with its own UI on windows so that copy and pasting works |
| 22:01:09 | flaviu | Araq: You can embed the terminal REPL into a GUI if you're on windows or a java programmer |
| 22:01:10 | EXetoC | I often need to edit some preceding function or something and that is a pain in the ass |
| 22:01:23 | Araq | dom96: no, it's not. |
| 22:01:26 | dom96 | I don't have to reimport things constantly |
| 22:01:37 | dom96 | or reintroduce state |
| 22:01:38 | flaviu | EXetoC: I can think of several ways to mitigate that |
| 22:01:40 | Araq | include prelude |
| 22:01:41 | reactormonk | Araq, ah, windows. urxvt works quite well and you can even copy/paste rectangular regions |
| 22:01:43 | Matthias247 | never understood the sense of REPLs :) |
| 22:01:52 | dom96 | Araq: ehh, that doesn't fix anything |
| 22:02:00 | reactormonk | Matthias247, I started coding with ruby, and I still like my repl |
| 22:02:02 | Matthias247 | typing in an editor is soo much easier |
| 22:02:03 | dom96 | Araq: the point is I need to *type* "import whatever" |
| 22:02:31 | Araq | dom96: so implement a "scratchpad" for aporia |
| 22:02:36 | reactormonk | Matthias247, emacs repl >;) |
| 22:02:43 | brechtm | dom96: you could add a feature to create a tab that automatically saves to a random file under /tmp |
| 22:02:57 | dom96 | brechtm: Aporia already does that ;) |
| 22:03:06 | dom96 | Araq: That's simply not the same. |
| 22:03:06 | brechtm | dom96: doh, now you tell me :) |
| 22:03:31 | brechtm | dom96: I'm running 0.1.3, old? |
| 22:03:31 | dom96 | brechtm: You simply create a new file, and when you compile it it will get saved in /tmp |
| 22:03:37 | EXetoC | I don't like the instance limit |
| 22:03:51 | brechtm | dom96: ah, very nice :) |
| 22:03:58 | Matthias247 | reactormonk: an editor or an IDE. Not something for what you need a thick user manual ;) |
| 22:04:05 | EXetoC | but that's partially because there are no bookmarks or anything yet |
| 22:04:20 | dom96 | brechtm: It is irritating sometimes, because I like pressing Ctrl + S a lot so when I am writing code in a new temp tab the file browse dialog will open and annoy me |
| 22:04:24 | reactormonk | Matthias247, you're a coder. You're expected to RTFM one time or another |
| 22:04:30 | dom96 | No time to improve this sadly... |
| 22:04:50 | * | Araq thinks a REPL only works for mathematica |
| 22:04:53 | Matthias247 | reactormonk: yes. But on the things that really bother me. And not on all kinds of tools |
| 22:05:12 | reactormonk | Araq, how do I tickle a stacktrace out in situations like https://github.com/Araq/Nimrod/issues/1163 ? |
| 22:05:29 | reactormonk | Matthias247, so be it. |
| 22:05:40 | dom96 | Araq: I asked for a REPL when I started using Nimrod which was like what, 4 years ago? |
| 22:05:56 | dom96 | I still want it. Just stop trying to convince me otherwise :P |
| 22:06:05 | Matthias247 | Araq: ah yes. At university we used one in Maple and Matlab too :) |
| 22:06:25 | Matthias247 | but those are all totally different normal programming |
| 22:06:28 | fowl | dom96, there is nimrepl |
| 22:06:33 | fowl | it compiles and runs :D |
| 22:06:44 | Araq | dom96: you also asked for threads, closures, ... |
| 22:06:44 | reactormonk | Araq, ... or something that helps me |
| 22:07:04 | Araq | reactormonk: compile the compiler in debug mode? |
| 22:07:13 | dom96 | fowl: Isn't that the first gtk app I built? lol |
| 22:07:27 | EXetoC | (./koch temp) |
| 22:07:38 | dom96 | Araq: True. And you argued that I didn't need them at the time. |
| 22:07:39 | EXetoC | generates bin/nimrod_temp |
| 22:07:44 | dom96 | Gave me lots of workarounds |
| 22:07:46 | dom96 | which I respected |
| 22:07:47 | reactormonk | Araq, ok... |
| 22:08:14 | dom96 | Like I am currently respecting aporia as a workaround. |
| 22:08:19 | fowl | dom96, i cant find it now.. :/ |
| 22:08:22 | dom96 | but I certainly want to see a REPL in the future |
| 22:08:43 | reactormonk | semmacrosanity <- whut? |
| 22:08:48 | dom96 | Another reason I want a REPL is because I want to create a tryhaskell-like site for Nimrod |
| 22:08:56 | fowl | dom96, i was thinking about making a little window area in babel to run code in dumptree: |
| 22:09:00 | flaviu | reactormonk: Semantic checking for macros it sounds like |
| 22:09:13 | flaviu | semantic macro sainity? |
| 22:09:23 | brechtm | dom96: what's the difference between 'nimrod i' and a REPL? |
| 22:09:33 | dom96 | brechtm: FFI support |
| 22:09:57 | reactormonk | http://lpaste.net/1631892499360382976 <- hm. I issue a compile command. What is it doing in suggestSym? |
| 22:10:17 | flaviu | Thats why I advocate LLVM. FFI is taken care of, as is JIT and undefined behavior |
| 22:10:53 | dom96 | Generating code for LLVM sounds like a fun project. |
| 22:11:02 | dom96 | How come nobody is working on it? |
| 22:11:09 | Araq | dom96: eventually the LLVM guys will give me void runC(char* code); and then you'll have your repl |
| 22:11:11 | dom96 | Does everyone have a life these days?! |
| 22:11:30 | fowl | dom96, i tried an llvm wrapper and it just didnt work >_> |
| 22:11:34 | EXetoC | dom96: not really |
| 22:11:38 | Araq | generating llvm code is not necessary at all |
| 22:11:48 | flaviu | dom96: I've been investigating it... |
| 22:12:15 | flaviu | It really does sound fun, the IR is straightforward is the docs are great |
| 22:12:40 | reactormonk | ## misnamed: should be 'symDeclared' |
| 22:12:42 | brechtm | dom96: no, everyone is wasting time on IRC |
| 22:12:44 | reactormonk | huh |
| 22:12:52 | dom96 | brechtm: so true |
| 22:14:27 | reactormonk | is it just me or are stacktraces off by one sometimes? |
| 22:14:29 | reactormonk | main.nim(74) commandCompileToC |
| 22:14:31 | reactormonk | modules.nim(193) compileProject |
| 22:14:44 | reactormonk | eh, wait. |
| 22:14:46 | reactormonk | I'm off by one here. |
| 22:15:35 | reactormonk | SimiluateCaasMemReset <- I think I found one bug |
| 22:17:41 | NimBot | Araq/Nimrod devel 3adceb3 Simon Hafner [+0 ±1 -0]: fixed constant typo (SimulateCaasMemReset) |
| 22:18:33 | brechtm | I'm off... thanks for all the help. Managed to wrap some of libgit2's headers. Might be back, even :) |
| 22:18:53 | * | brechtm quit () |
| 22:20:03 | reactormonk | Araq, ping, I think I found something |
| 22:20:55 | Araq | well? |
| 22:21:09 | reactormonk | not sure how to solve it. suggest.nim:325 markUsed calls suggestSym which adds it to a source map in suggetSym if isServing... also when you're asking it to compile |
| 22:21:12 | OrionPK | i miss not having a life |
| 22:21:15 | OrionPK | so much more free time |
| 22:21:42 | OrionPK | i dont think i'll have a life this weekend though! maybe i'll code :D |
| 22:21:49 | reactormonk | is it a) just create a source map because it can be cached or b) it should not add when compiling |
| 22:22:17 | reactormonk | suggest.nim(323) suggestSym |
| 22:22:22 | reactormonk | the last line in the stacktrace |
| 22:23:50 | reactormonk | I added an echo statement right in front of it, let's see if that triggers it as well |
| 22:24:28 | reactormonk | yup, n.info is apparently the segfault |
| 22:26:35 | flaviu | Jehan_: You might be able to get better performance on the xorshift if you use a bigger seed |
| 22:26:59 | Jehan_ | Hmm? |
| 22:27:05 | Jehan_ | Do you mean better randomness? |
| 22:27:13 | flaviu | Apparently the processor can pipeline it better |
| 22:27:16 | flaviu | http://xorshift.di.unimi.it/ |
| 22:27:49 | Jehan_ | Honestly, I don't need better performance, I'm pretty sure that I'm already faster than everyone else. :) |
| 22:28:18 | Jehan_ | I get the same speedup as the C++ solution on half the cores. |
| 22:28:55 | flaviu | You should include the speedup in the title, everyone else is doing so |
| 22:29:49 | Jehan_ | Well, I'm not everybody else, I'm afraid. :) |
| 22:30:00 | Jehan_ | Right now I'm working on the followup problem, anyway. |
| 22:31:27 | reactormonk | Araq, tl; dr: at some point, n is nil |
| 22:31:52 | reactormonk | a lot of times, n is not nil. |
| 22:34:04 | Araq | reactormonk: so add a nil check or fix the root cause |
| 22:35:05 | reactormonk | Araq, going back up the stack trace |
| 22:35:26 | * | DAddYE joined #nimrod |
| 22:35:30 | reactormonk | except now it's dead slow -.- |
| 22:35:55 | Araq | dude learn how to debug the compiler |
| 22:36:25 | reactormonk | I'm on it |
| 22:38:27 | reactormonk | any special defines for when the compiler is compiling itself? |
| 22:38:39 | Araq | -d:booting |
| 22:39:00 | Araq | you shouldn't bootstrap btw, use "koch temp" |
| 22:39:17 | dom96 | koch temp!? that exists? |
| 22:39:20 | dom96 | what does it do? |
| 22:39:40 | flaviu | dom96: creates an `nimrod_temp` executable |
| 22:39:48 | Araq | and then learn to use ?? and the ID mechanism and about 'debug' and 'renderTree' |
| 22:39:50 | * | dom96 was manually running nimrod c compiler/nimrod && compiler/nimrod c mytest |
| 22:39:58 | flaviu | add that to your path and you don't mess up your regular compiler |
| 22:40:26 | dom96 | TIL |
| 22:40:41 | flaviu | Araq: Why do we have IDs on the AST objects? |
| 22:41:02 | Araq | because pointers suck, they change their value from run to run |
| 22:41:15 | flaviu | How about hashes? |
| 22:41:29 | flaviu | 64 bit of course, collisions would suck more |
| 22:41:56 | Araq | How about skip lists? what do you mean "that doesn't make sense"?! |
| 22:42:53 | flaviu | sorry, I didn't mean to sound condescending |
| 22:43:19 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 22:44:06 | Araq | don't worry |
| 22:44:37 | Araq | well hashing the pointer doesn't solve anything obviously. hashing the whole *tree* might work but is too slow |
| 22:46:27 | Araq | Varriount: how come we still lack GetCurrentProcess in winlean.nim? |
| 22:48:20 | flaviu | The tree could be hashed such that each node has the hash of its sons incorporated into itself. The hash would be cached, same as the ID, so performance would be about equal |
| 22:48:34 | reactormonk | Araq, where's information about ?? ? |
| 22:49:12 | Araq | if n.info ?? "fileToTest": ... |
| 22:49:45 | reactormonk | I'm testing nimrod serve here |
| 22:50:12 | Araq | flaviu: in theory that works. In practice it's not clear when the node can be sealed and its hash computed |
| 22:50:51 | Araq | flaviu: also the AST only has IDs when some flag is defined |
| 22:53:17 | reactormonk | Araq, looks slightly uglier than expected... the `nil' is explicitly passed at semtypes.nim:1055, and it afterwards in liftGenericParam it is markUsed with genericParams as argument, which is always nil called from this direction |
| 22:54:28 | reactormonk | this problem also seems to propagate to cmdPretty, because the nil is also passed there |
| 22:59:03 | * | xenagi joined #nimrod |
| 23:00:18 | reactormonk | I could just add a nilguard, but I'm not sure this doesn't hide a bigger problem |
| 23:24:10 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 23:24:13 | * | darkf joined #nimrod |
| 23:27:31 | * | Demos joined #nimrod |
| 23:35:41 | flaviu | 0xFFi8 looks correct, right? |
| 23:36:18 | flaviu | Ok, it works with 0xFF'i8, so its a bug |
| 23:40:19 | fowl | LLVM wrapper https://gist.github.com/fowlmouth/42d869b555e3fc879c77 |
| 23:41:16 | flaviu | fowl: Awesome! |
| 23:41:47 | flaviu | Can you make a repo and also submit to babel? |
| 23:43:05 | * | Demos quit (Read error: Connection reset by peer) |
| 23:44:03 | fowl | not sure if i want to get rid of all the llvm prefixes first |
| 23:47:38 | EXetoC | they're unnecessary. making some adaptions is reasonable |
| 23:49:16 | flaviu | fowl: Once you do, ping me. I can fix formatting and clean it up |
| 23:53:38 | * | Demos joined #nimrod |
| 23:59:25 | Jehan_ | http://codegolf.stackexchange.com/questions/26459/how-high-can-you-go-a-codingalgorithms-challenge/26528#26528 for people who are interested in this kind of stuff. |