| 00:00:48 | flaviu | Yep, signal handlers are non-ideal. I want to be able to do dynamic memory allocation in them. |
| 00:01:15 | flaviu | I'm looking to see if I can convince clang or Nim to insert null deference checks. |
| 00:02:54 | Mat4 | flaviu: I think recovering from segfaults is at least operating-system dependent |
| 00:03:02 | def- | flaviu: from what google tells me posix doesn't guarantee recovery, but people have written linux-only libraries: https://code.google.com/p/segvcatch/ |
| 00:03:26 | Jehan_ | flaviu: Doesn't Nim already check for dereferencing nil? |
| 00:03:49 | flaviu | Jehan_: Nope, I'm looking at cgen.rdLoc right now. |
| 00:03:59 | flaviu | (*$1) |
| 00:04:28 | Jehan_ | flaviu: It does install a segv handler which aborts and prints a traceback. |
| 00:05:12 | flaviu | Yes, but I don't want the abort, I want to raise an exception and continue. Unfortunately, I think it's impossible to do that in a thread-safe way. |
| 00:05:18 | Jehan_ | *nod* |
| 00:05:45 | Mat4 | there is a pitfall here: Limux seem to reset the signal vector after each call |
| 00:05:47 | Jehan_ | I think the best solution would be to have the code generator actually insert an explicit nil check (probably as an option). |
| 00:05:52 | Mat4 | ^Linux |
| 00:06:30 | Mat4 | so the handler routine is called only once |
| 00:09:57 | * | JinShil joined #nim |
| 00:12:47 | * | nande joined #nim |
| 00:13:21 | * | Mat4 quit (Quit: Verlassend) |
| 00:26:29 | * | Trustable quit (Quit: Leaving) |
| 00:33:12 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:40:09 | * | davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 00:51:22 | * | gokr_ quit (Quit: IRC for Sailfish 0.9) |
| 01:00:32 | Araq | yup, Jehan_ is right. patch the codegen instead |
| 01:00:46 | Araq | it's some feature request already |
| 01:01:04 | Araq | and there is already --nilChecks:on|off |
| 01:01:21 | * | BitPuffin quit (Ping timeout: 245 seconds) |
| 01:05:04 | Jehan_ | I was thinking more of having two ways of doing nil checks, one as an explicit check, one via signals (since the latter is cheaper). |
| 01:05:37 | Araq | well --nilChecks:off still produces the signal handler |
| 01:07:23 | Jehan_ | Huh. Didn't realize that. |
| 01:09:28 | Araq | -d:noSignalHandler removes it |
| 01:10:25 | Jehan_ | Duly noted. :) |
| 01:12:03 | * | dv- quit (Ping timeout: 245 seconds) |
| 01:13:36 | * | sillesta quit (Ping timeout: 265 seconds) |
| 01:13:52 | * | dv- joined #nim |
| 01:18:25 | * | vendethiel quit (Ping timeout: 265 seconds) |
| 01:23:13 | * | vendethiel joined #nim |
| 01:26:23 | flaviu | Doing some hackish stuff in cgen.nim, and I wish there was some way to tell C to stop typechecking at a point. |
| 01:27:25 | Araq | I wish C would actually perform some typechecking that deserves that name |
| 01:29:11 | ldlework | http://arrdem.com/2015/01/27/ox:_some_motivation/ |
| 01:33:03 | Araq | "The GHC team has a "3% rule", in that if a change improves the language or the type checker and comes at a cost of less than a 3% slowdown it has a high probability of being accepted and acceptance/rejection is publicly debated ala LKML" wtf? |
| 01:33:20 | Araq | 3% slowdown is quite a lot |
| 01:33:31 | Araq | and these add up quickly |
| 01:33:52 | Araq | since the next 3% then refer to the *former* slower compiler |
| 01:34:18 | Araq | so you get some nice exponential slowdown |
| 01:34:20 | ldlework | This article is probably not flawless. |
| 01:34:24 | Jehan_ | I don't think that's a hard-and-fast rule. |
| 01:34:44 | Jehan_ | I suspect that they'd be wary of cumulative performance degradation. |
| 01:34:44 | flaviu | Araq: I'm doing some completely unrelated research, but apparently haskell has had "rewrite rules"/term rewriting macros since at least 2002. |
| 01:34:45 | ldlework | I just think he has some good rooting in first-motivations |
| 01:35:17 | flaviu | That's not an argument against term rewriting macros btw, just a remark. |
| 01:35:23 | Araq | flaviu: yeah, but we have some side effect and alias analysis constraints |
| 01:35:53 | Araq | and afaik these are new, nobody has them except Nim |
| 01:36:07 | flaviu | Haskell has the same side effect stuff, they just call it Monands or something |
| 01:36:19 | ldlework | flaviu: hehe |
| 01:36:42 | Araq | these are very similar but not identical |
| 01:36:52 | Jehan_ | Ugh, I also need to write a response to the options thread, but the hashtable debate is exhausting me. |
| 01:37:00 | ldlework | one uses the type system, another uses the pragma system? |
| 01:37:15 | flaviu | I guess so. |
| 01:37:35 | Araq | ldlework: that's one way of putting it, but the real difference is that E[T] is not the same as (T, E) |
| 01:37:42 | flaviu | noalias is awfully hard to prove. |
| 01:39:18 | Araq | flaviu: it's easier when you have value based datatypes |
| 01:39:55 | flaviu | Right, I was thinking of pointers. |
| 01:44:24 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 01:46:36 | * | vendethiel joined #nim |
| 01:50:04 | drewsrem | Trying to use a nim lib which uses dynlib pragma in its codebase to import a shared library on Linux, the example compiles fine but when I try to run it it says "could not load: *libname*.so", I got that this error message is from nims code-gen, is there any additional debug information I can access? |
| 01:50:55 | * | sampwing quit (Ping timeout: 252 seconds) |
| 01:51:01 | def- | you have *libname*.so on your system? |
| 01:51:16 | drewsrem | def-, yes, it's in /usr/lib |
| 01:52:21 | def- | in the correct architecture? (x86_64 vs x86) |
| 01:52:34 | def- | and i think this error also appears when a depenency of *libname*.so is missing, which is confusing |
| 01:53:37 | drewsrem | def-, correct architecture? |
| 01:54:11 | def- | if you compile your program for x86_64 and the library is for x86 it won't work |
| 01:55:00 | drewsrem | ah, no the lib should be compiled x86_64, as I guess nim does per default on a x86_64 system? |
| 01:55:08 | def- | yes |
| 01:55:20 | drewsrem | right |
| 01:55:25 | drewsrem | your second point tho might be it |
| 01:55:33 | Araq | hrm the codegen for 'growObj' is completely wrong, lol |
| 01:56:17 | def- | drewsrem: I would also like to know if there is a way to find out which library exactly is missing |
| 01:56:31 | Araq | that will be an ugly fix, creating lots of new problems |
| 01:57:13 | * | Angry joined #nim |
| 02:04:30 | * | darkf joined #nim |
| 02:09:23 | * | Demon_Fox quit (Ping timeout: 246 seconds) |
| 02:09:35 | * | vendethiel quit (Ping timeout: 244 seconds) |
| 02:09:56 | * | Demon_Fox joined #nim |
| 02:11:03 | Araq | good night |
| 02:14:10 | * | vendethiel joined #nim |
| 02:23:15 | * | Jehan_ quit (Quit: Leaving) |
| 02:23:33 | flaviu | def-: $ ldd myexecutable |
| 02:24:18 | * | Puffin joined #nim |
| 02:26:29 | * | EXetoC quit (Ping timeout: 252 seconds) |
| 02:35:06 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 02:36:38 | * | chemist70 joined #nim |
| 02:39:50 | * | chemist69 quit (Ping timeout: 246 seconds) |
| 02:40:07 | * | kapil__ joined #nim |
| 02:42:18 | * | VinceAddons quit (Read error: Connection reset by peer) |
| 02:44:41 | * | Demon_Fox quit (Ping timeout: 245 seconds) |
| 02:44:51 | * | vendethiel joined #nim |
| 02:45:47 | * | Demon_Fox joined #nim |
| 02:49:52 | * | Demon_Fox quit (Ping timeout: 240 seconds) |
| 02:50:26 | * | Demon_Fox joined #nim |
| 02:58:42 | * | tschmid joined #nim |
| 03:02:10 | drewsrem | flaviu, ldd doesn't show the shared-library in my problem |
| 03:05:04 | * | Demos joined #nim |
| 03:08:49 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 03:10:51 | * | vendethiel joined #nim |
| 03:10:55 | * | Puffin quit (Ping timeout: 255 seconds) |
| 03:22:08 | * | gunn_ joined #nim |
| 03:23:49 | * | gunn quit (Ping timeout: 264 seconds) |
| 03:29:13 | tschmid | test |
| 03:32:51 | tschmid | Is there any particular reason why case syntax is `case expr |of expr: |else:` instead of `case expr of |expr: |else:`? The repetitive use of the of keyword and the apparent stylistic standard of not indenting each case make it quite hard to read. |
| 03:34:58 | dtscode | because its easier to find the cases in it since they are prefixed with "of" |
| 03:35:09 | dtscode | im guessing |
| 03:35:23 | tschmid | which is what indentation is for |
| 03:35:48 | tschmid | having it not indented makes it much harder to read for mw. |
| 03:35:57 | dtscode | you can indent it... |
| 03:36:01 | dtscode | case foo: |
| 03:36:05 | dtscode | of bar: |
| 03:36:30 | tschmid | still, the repeated use of `of` seems wasteful |
| 03:37:02 | tschmid | and having nonindentation as part of the official style? |
| 03:37:04 | dtscode | thats really a design opinion. i personally like it. makes it easier to mark out cases |
| 03:38:58 | tschmid | indentation blocks are used everywhere else, so why not in this case? |
| 03:39:22 | dtscode | ..................... |
| 03:39:25 | dtscode | they are... |
| 03:39:32 | dtscode | i just said they are... |
| 03:39:35 | * | drewsrem quit (Quit: Leaving) |
| 03:39:54 | tschmid | okay |
| 03:40:03 | tschmid | then my main issue is the official style not being indented |
| 03:40:06 | tschmid | that's just weird |
| 03:40:19 | dtscode | not weird. i like it. like i said its a design opinion |
| 03:40:46 | tschmid | it's visually ambiguous. |
| 03:41:05 | dtscode | not really... |
| 03:41:07 | tschmid | it looks like a list of statements, not a block of cases |
| 03:41:17 | dtscode | it is a list of statements |
| 03:41:27 | tschmid | ... |
| 03:42:14 | tschmid | it's in a different semantic scope |
| 03:42:27 | dtscode | ok. and? |
| 03:42:48 | tschmid | so that should be denoted, not left as an exercise for the reader. |
| 03:42:58 | dtscode | it is denoted... with an of |
| 03:43:01 | dtscode | ............ |
| 03:43:08 | tschmid | good job |
| 03:43:14 | tschmid | you win |
| 03:43:16 | tschmid | bye |
| 03:43:29 | dtscode | i really dont see your point here... do you actually know what you are talking about? |
| 03:47:20 | tschmid | okay |
| 03:47:27 | tschmid | of is one letter away from if |
| 03:47:44 | dtscode | alright. and? |
| 03:48:00 | dtscode | its also a letter away from oh |
| 03:48:10 | tschmid | are you trolling? |
| 03:48:29 | dtscode | are you? cause you are just running in circles with no point |
| 03:48:35 | tschmid | it is not easy to tell from looking at a segment of code that you're inside a case statement. |
| 03:49:56 | tschmid | there is no indentation, which provides both a visual denotation of scope and a way to see the head of the statement. |
| 03:50:43 | * | brson quit (Quit: leaving) |
| 03:51:15 | tschmid | `of` is not sufficiently different from `if` for me to tell that it denotes a case statement without reading the line and looking up to find the case keyword. |
| 03:52:44 | tschmid | it's visually ambiguous, and you're trolling. |
| 03:56:10 | tschmid | your argument is that you think it looks good. |
| 03:57:37 | dtscode | sorry laptop crapped out |
| 03:58:12 | dtscode | anyways tschmid thats not the fault of nim if you cant tell when you are in a switch block |
| 03:58:35 | tschmid | good. now to attack my reading comprehension. |
| 03:59:16 | dtscode | not attacking anything. just pointing out there is nothing wrong with the language |
| 03:59:44 | tschmid | i'm not saying there's anything wrong with the language, i'm saying the official style can be improved. |
| 04:00:00 | tschmid | in what way is it not an objective improvement? |
| 04:00:17 | dtscode | ... |
| 04:00:25 | dtscode | ok now i am attacking your reading comprehension |
| 04:00:43 | dtscode | because ive told you exactly why its good and why it would be bad to not have of |
| 04:00:46 | tschmid | you're being condescending but you haven't actually given me any arguments. |
| 04:00:50 | tschmid | i moved on |
| 04:00:55 | tschmid | i'm talking about indentation |
| 04:01:08 | tschmid | should we discuss your reading comprehension now? |
| 04:01:32 | Triplefox | Argument has gone on for one half hour |
| 04:01:38 | tschmid | joy |
| 04:01:48 | dtscode | i have actually, which is why im talking about your reading comprehension. and we never actually switched topics ;) im fairly convinced your trolling now |
| 04:02:19 | tschmid | 20:39 < tschmid> then my main issue is the official style not being indented |
| 04:03:27 | tschmid | you're being either intentionally or unintentionally obtuse, so i'm going to stop replying to you. |
| 04:03:40 | tschmid | as i should have thirty minutes ago. |
| 04:04:00 | Triplefox | Is the official style documented somewhere, i think I went looking at some point but gave up |
| 04:04:26 | Triplefox | Or just forgot to actually look |
| 04:04:43 | dtscode | good. because youve been ignoring what i was saying this whole time :D good luck not knowing your stuff! gotta put you on ignore now though. real stuff to do than bitch about not being able to find case statements |
| 04:06:18 | tschmid | boy, that's not good for my blood pressure |
| 04:11:19 | tschmid | Luckily, nonindented case statements aren't part of the official guide, but all of the nim source I've seen has their case statements non-indented. It's probably an unspoken rule, but if a nimfmt ever gets around to being built, it could become a problem. |
| 04:11:23 | tschmid | https://github.com/Araq/Nim/wiki/Style-Guide-for-Nim-Code |
| 04:12:36 | Demos | nonindented case statements are quite common in C as well |
| 04:12:53 | Demos | although that is probably because case statements do not open a new scope as far as I know |
| 04:12:55 | tschmid | yeah, and they have braces to make up for it. |
| 04:13:00 | Demos | I don't know if they do in nim either |
| 04:13:07 | dtscode | they dont in c/c++ |
| 04:13:12 | dtscode | not sure about nim |
| 04:13:20 | tschmid | by semantic scope, I mean the valid keywords change. |
| 04:13:33 | Demos | tschmid, lets not even go there |
| 04:13:43 | tschmid | what braces vs indentation? |
| 04:13:51 | Demos | no "semantic scope" |
| 04:13:56 | tschmid | o...kay |
| 04:14:40 | Demos | like tons of stuff changes the available keywords. |
| 04:15:09 | tschmid | okay? |
| 04:15:16 | tschmid | it's all deterministic |
| 04:15:16 | Demos | and we don't really use indentation to deal with it, I would actually agree that switches perhaps should be indented if they open a new block |
| 04:15:27 | Demos | huh |
| 04:15:37 | Demos | I mean it has to be deterministic |
| 04:16:07 | tschmid | you can't leave a case statement without using the of keyword, can you? |
| 04:16:46 | tschmid | regardless, that doesn't really matter. |
| 04:18:22 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 04:20:02 | Demos | I think you can only use the else portion |
| 04:20:06 | Demos | but it is a noop then |
| 04:20:11 | Demos | or the case is |
| 04:24:00 | Triplefox | If I'm understanding it correctly, we can style case blocks differently but we can't accidentally change the meaning? |
| 04:25:34 | * | lws_ joined #nim |
| 04:25:40 | tschmid | ? |
| 04:27:20 | * | vendethiel joined #nim |
| 04:28:23 | * | lws quit (Ping timeout: 272 seconds) |
| 04:44:00 | * | gunn_ quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 04:46:27 | * | brson joined #nim |
| 05:06:25 | * | ARCADIVS joined #nim |
| 05:19:23 | dtscode | would pythons socket.bind == nim's sockets.bindAddr? |
| 05:21:55 | * | darkf_ joined #nim |
| 05:23:51 | dtscode | also, what would be the same as pythons socket.accept()? |
| 05:24:58 | * | darkf quit (Ping timeout: 245 seconds) |
| 05:25:47 | * | brson quit (Ping timeout: 252 seconds) |
| 05:28:43 | * | gunn joined #nim |
| 05:28:50 | * | gunn quit (Max SendQ exceeded) |
| 05:28:53 | * | darkf_ is now known as darkf |
| 05:29:29 | * | gunn joined #nim |
| 05:31:35 | * | JinShil quit (Quit: Konversation terminated!) |
| 05:40:49 | * | johnsoft quit (Ping timeout: 252 seconds) |
| 05:40:58 | * | johnsoft joined #nim |
| 05:44:47 | * | nande quit (Remote host closed the connection) |
| 05:51:25 | * | brson joined #nim |
| 05:55:39 | fowlmouth | this library is neat, lots of use of recursive templates https://github.com/MasonMcGill/tuples |
| 05:59:17 | dtscode | ooo i like this |
| 06:07:23 | * | Puffin joined #nim |
| 06:11:53 | * | Puffin quit (Ping timeout: 250 seconds) |
| 06:23:11 | * | akiradeveloper joined #nim |
| 06:24:44 | akiradeveloper | https://gist.github.com/akiradeveloper/aa86259905ca01982d44 |
| 06:25:35 | fowlmouth | akiradeveloper, whats the problem? |
| 06:26:06 | akiradeveloper | if we use case 1 the len(c) is 0 but we expect it 1000 |
| 06:26:29 | akiradeveloper | case 2, it somehow ends in out of memory |
| 06:26:37 | fowlmouth | .eval echo(len(newseq[char](1000))) |
| 06:26:41 | Mimbus | fowlmouth: 1000 |
| 06:27:24 | fowlmouth | akiradeveloper, you should cast p to ptr seq[char] |
| 06:27:24 | akiradeveloper | yes. but after casting the seq is gone |
| 06:29:15 | akiradeveloper | what's the difference between addr(s) and addr(s[0]) |
| 06:29:24 | akiradeveloper | fowlmouth: it works for case 2 |
| 06:30:31 | fowlmouth | addr s is the address of variable s, addr s[0] is the address of the first member stored in the sequence (the sequence also has length and capacity fields) |
| 06:31:23 | akiradeveloper | I see. so it's not simply an array |
| 06:33:21 | fowlmouth | its not the same as c's arrays or pointers |
| 06:38:31 | akiradeveloper | well, I need some redesigning on my nim-fuse... |
| 06:38:39 | akiradeveloper | thanks |
| 06:40:43 | fowlmouth | no problem |
| 06:47:51 | * | brson quit (Ping timeout: 250 seconds) |
| 06:48:46 | dtscode | why would my server not be recieving anything from telnet dtscode.io 80? https://bpaste.net/show/724df58db281 |
| 06:55:13 | * | gunn quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 06:56:08 | akiradeveloper | Some way to make a sequence from (pointer, len:int)? |
| 06:56:55 | * | brson joined #nim |
| 06:57:15 | dtscode | loop over the pointer maybe? |
| 07:00:51 | akiradeveloper | I don't like copying |
| 07:01:23 | dtscode | maybe something in system? |
| 07:04:33 | * | sillesta joined #nim |
| 07:10:54 | * | gunn joined #nim |
| 07:27:39 | * | Angry quit (Ping timeout: 264 seconds) |
| 07:36:22 | * | dv- quit (Changing host) |
| 07:36:22 | * | dv- joined #nim |
| 07:47:16 | Demos | that sounds really unsafe akiradeveloper |
| 07:47:41 | Demos | I could maybe see being able to make it an openarray |
| 07:48:14 | akiradeveloper | makes an openarray from (pointer, size)? |
| 07:48:33 | Demos | I mean I could see it being a safe thing to do |
| 07:49:06 | fowlmouth | akiradeveloper, if you dont want to copy you can just define a type for it, same interface as seq but uses pointer arithmetic |
| 07:49:12 | Demos | you can cast the pointer to an array[0..2^48] or something |
| 07:49:15 | * | chemist70 quit (Quit: leaving) |
| 07:49:43 | * | chemist69 joined #nim |
| 07:49:48 | Demos | there is a special pragma that disables bounds checking for a particular variable as well |
| 07:49:59 | Demos | instead of making the size something insane |
| 07:50:10 | akiradeveloper | ok. nim doesn't want normal users go that way |
| 07:50:42 | Demos | wrapping C code (I assume that is what you are doing) is not really "normal" and it can not be totally clean |
| 07:50:45 | fowlmouth | eh just use this https://github.com/fowlmouth/nimlibs/blob/master/fowltek/pointer_arithm.nim |
| 07:50:56 | akiradeveloper | As a guy from C, it's natural for me to do unsafe cast |
| 07:51:13 | Demos | right, but you gotta realize that seq is garbage collected memory |
| 07:51:34 | Demos | so if you do that cast the GC will free the memory when that seq becomes unreachable |
| 07:51:47 | Demos | the correct thing to cast to is the array |
| 07:52:03 | fowlmouth | akira you have to also be mindful of that memory, should it be freed after use? if so you can wrap it in a ref type |
| 07:53:22 | Demos | erm, only if it was allocated by nim's GC. I mean you can use destructors but it really depends on what you are doing |
| 07:54:05 | fowlmouth | Demos, he's writing a high level interface to fuse |
| 07:54:16 | Demos | oh |
| 07:54:17 | akiradeveloper | My nim code often cause SEGV that's maybe because my nim code is terrible |
| 07:54:19 | Demos | thanks |
| 07:55:14 | Demos | yeah, I would go for an interface that casts to an array internally and then uses runtime bounds checking. One may already exist and if not I think it would be a decent thing to have in the standard library |
| 07:55:44 | fowlmouth | akiradeveloper, i have a fuse wrapper but i couldnt even get a basic example running |
| 07:56:05 | akiradeveloper | my nim-wrapper start to say hello |
| 07:56:40 | akiradeveloper | but not stable. I don't think other guys want to use this kind of toy |
| 07:57:18 | fowlmouth | it would be cool to have something as high level as ruby's fuse wrapper, https://github.com/lwoggardner/rfusefs#the-hello-world-filesystem-in-14-loc |
| 07:57:32 | akiradeveloper | I think I, as a nim layman, should first go with the cleaner way. Pointer arithmetic is not natural in Nim |
| 07:58:02 | akiradeveloper | oh really really great |
| 07:58:40 | Demos | does fuse give you the array in question as a return value or an out parameter? |
| 07:58:44 | akiradeveloper | for now, my nim-wrapper is a porting of rust-fuse |
| 07:59:35 | akiradeveloper | Yes. I need to talk with fuse's kernel part via a single buffer |
| 07:59:46 | Demos | I meant which one |
| 08:00:47 | akiradeveloper | maybe the latter. I prepare a buffer and the kernel part write his request in the buffer and nim part handles it. |
| 08:01:05 | Demos | you can just pass a seq in as the buffer |
| 08:01:10 | Demos | just make sure it is the right size |
| 08:01:21 | akiradeveloper | yes. I use seq as the buffer |
| 08:01:38 | akiradeveloper | precisely, a buffer class that wraps seq |
| 08:04:10 | akiradeveloper | But I think if I write cleaner code, I remove all memory errors (out of memory, SEGV, ... really makes me annoying |
| 08:04:30 | akiradeveloper | ruby's binding is really nice. I can learn from this |
| 08:13:34 | * | JinShil joined #nim |
| 08:15:59 | * | Demon_Fox quit (Quit: Leaving) |
| 08:17:19 | * | dumdum joined #nim |
| 08:19:13 | * | kuzy000_ joined #nim |
| 08:19:22 | * | Demos quit (Read error: Connection reset by peer) |
| 08:19:30 | * | Trustable joined #nim |
| 08:23:49 | * | brson quit (Ping timeout: 256 seconds) |
| 08:24:21 | fowlmouth | akiradeveloper, rusts fuse looks good |
| 08:27:20 | * | akiradeveloper quit () |
| 08:28:32 | fowlmouth | gn |
| 08:29:21 | * | JinShil quit (Quit: Konversation terminated!) |
| 08:42:05 | * | ARCADIVS quit (Quit: ARCADIVS) |
| 08:46:57 | * | sillesta quit (Ping timeout: 245 seconds) |
| 09:03:25 | * | gunn quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 09:04:48 | * | akiradeveloper joined #nim |
| 09:07:59 | Araq | tschmid: the indentation of 'of' follows the logic of 'if ... elif ... elif .. else' |
| 09:09:18 | gokr | Araq: Morning! |
| 09:09:55 | Araq | or ' try ... except except finally' |
| 09:10:26 | * | sillesta joined #nim |
| 09:20:49 | * | kapil__ quit (Quit: Connection closed for inactivity) |
| 09:26:01 | * | johnsoft quit (Ping timeout: 250 seconds) |
| 09:47:24 | * | gunn joined #nim |
| 09:52:15 | * | bjz joined #nim |
| 10:04:01 | * | tschmid quit (Ping timeout: 255 seconds) |
| 10:08:26 | dtscode | oh i see how it is gokr. no good morning for me :D |
| 10:08:37 | gokr | dtscode: Nope ;) |
| 10:08:42 | dtscode | :( |
| 10:08:51 | dtscode | i may have legitimately found a bug |
| 10:09:04 | gokr | No, we don't have legit bugs. |
| 10:09:17 | dtscode | i may have unlegitimately found a bug** |
| 10:09:18 | dtscode | my mistake |
| 10:09:23 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 10:09:25 | * | VinceAddons joined #nim |
| 10:09:41 | * | MajorWork joined #nim |
| 10:09:54 | dtscode | or are you secretly nikki and going to tell me that nim has no bugs? |
| 10:10:11 | gokr | Hehe |
| 10:10:20 | gokr | Did she actually ever pop up here? |
| 10:10:20 | darkf | it doesn't have bugs, just happy little features |
| 10:10:38 | gokr | The bugs are simply exercises for the community. |
| 10:10:45 | dtscode | XD gokr dont think she did |
| 10:10:59 | * | MajorWork quit (Changing host) |
| 10:10:59 | * | MajorWork joined #nim |
| 10:11:10 | darkf | it's just a test of faith |
| 10:11:19 | gokr | But I do think she is a she - one of the posts implied it. Or someone pretending of course. |
| 10:11:52 | darkf | or you could just say 'it' or 'he' |
| 10:12:09 | darkf | (or 'they') |
| 10:12:29 | dtscode | meh. its easier to call nikki a she. thats what the general theory was iirc |
| 10:12:35 | Araq | ekarlso: try --gc:markAndSweep as a workaround. I have a proper fix, but it requires way more testing. |
| 10:13:05 | darkf | dtscode: did you ask about / file the socket error stuff? |
| 10:13:19 | dtscode | i havent documented it yet |
| 10:13:26 | darkf | well get on it |
| 10:13:26 | darkf | :D |
| 10:13:47 | dtscode | remind me to do it in the morning? i was going to go to bed after this criminal minds episode |
| 10:16:42 | * | BlaXpirit joined #nim |
| 10:20:16 | * | codmajik joined #nim |
| 10:27:50 | * | bjz joined #nim |
| 10:37:31 | * | gsingh93 quit (Quit: Connection closed for inactivity) |
| 11:03:24 | * | akiradeveloper quit (Remote host closed the connection) |
| 11:03:58 | * | akiradeveloper joined #nim |
| 11:08:32 | * | akiradeveloper quit (Ping timeout: 264 seconds) |
| 11:08:40 | * | JinShil joined #nim |
| 11:16:24 | * | davidhq joined #nim |
| 11:27:13 | * | akiradeveloper joined #nim |
| 11:30:58 | * | gunn quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 11:38:50 | * | JinShil quit (Quit: Konversation terminated!) |
| 11:41:01 | * | dumdum quit (Ping timeout: 256 seconds) |
| 11:55:30 | * | dumdum joined #nim |
| 13:19:09 | * | EXetoC joined #nim |
| 13:20:55 | * | Jehan_ joined #nim |
| 13:30:26 | akiradeveloper | openarray isn't covariant |
| 13:32:17 | * | novist` is now known as novist |
| 13:43:11 | * | gokr quit (Quit: Leaving.) |
| 13:46:54 | * | Puffin joined #nim |
| 13:48:07 | * | titaniumone^ quit (Ping timeout: 255 seconds) |
| 13:48:09 | * | Puffin is now known as BitPuffin |
| 13:52:19 | * | gmoore joined #nim |
| 13:52:26 | * | akiradeveloper quit () |
| 13:53:20 | Araq | er ... arrays are not covariant in general |
| 13:54:41 | Araq | goto BeforeRet; |
| 13:54:56 | Araq | tcell45546* c = usrtocell_49446(p); |
| 13:55:05 | Araq | BeforeRet: ; |
| 13:55:48 | Araq | --> jump to label BeforeRet crosses initialization of 'c' |
| 13:55:57 | Araq | what the ...? |
| 13:58:54 | Araq | "there is no place for a lower level language than C++" my ass |
| 13:59:07 | wtw | is this a specific bug or are you complaining about c in general? |
| 13:59:09 | wtw | ah i see :D |
| 13:59:41 | Araq | C++'s spec assumes no dataflow analysis is done in compilers |
| 14:00:14 | Araq | that's false for every commercial C++ compiler out there |
| 14:00:33 | Araq | seriously what the fuck. How should a C++ codegen then work? |
| 14:00:57 | Araq | I can't emit 'break' as that is defective in a 'switch' statement |
| 14:01:06 | Araq | I can't emit 'return' either |
| 14:01:56 | Araq | and I already pass -fpermissive |
| 14:02:29 | wtw | could you emit _asm something? ;) (out of interest, not considering it'd be non-portable, ugly etc) |
| 14:02:54 | wtw | well, probably the compiler would catch that also... |
| 14:03:00 | def- | Araq: put everything inbetween the goto and destination into a scope with {}? |
| 14:08:30 | Jehan_ | Araq: I'm sort of missing the context here? |
| 14:08:57 | Araq | Jehan_: my improved C++ codegen works with VS but fails with GCC |
| 14:09:21 | Araq | and I don't see how to generate C++ code that adheres to the spec |
| 14:09:27 | Jehan_ | What's the issue? I can only vaguely guess at it from the fragment above? |
| 14:09:43 | Jehan_ | Does gcc emit an error/warning for it? |
| 14:09:52 | Araq | http://stackoverflow.com/questions/11578936/getting-a-bunch-of-crosses-initialization-error |
| 14:10:02 | Araq | an error. warning wouldn't matter |
| 14:10:14 | * | BlaXpirit quit (Read error: Connection reset by peer) |
| 14:10:19 | * | ramnes quit (Ping timeout: 265 seconds) |
| 14:10:39 | * | ramnes joined #nim |
| 14:10:40 | Araq | If you have |
| 14:10:42 | Araq | goto err_exit; |
| 14:10:43 | Araq | int a = 1; |
| 14:10:45 | Araq | it complains. |
| 14:10:46 | Araq | Add -fpermissive to your command line, and substitute: |
| 14:10:48 | Araq | goto err_exit; |
| 14:10:49 | Araq | int a; |
| 14:10:51 | Araq | a = 1; |
| 14:10:52 | Araq | no complaints. |
| 14:10:56 | * | BlaXpirit joined #nim |
| 14:11:17 | * | Gonzih quit (Ping timeout: 265 seconds) |
| 14:11:25 | Jehan_ | Hmm. It looks like you have to hoist the declaration out of the block and generate the assignment separately from the declaration? |
| 14:11:34 | * | Gonzih joined #nim |
| 14:11:37 | Araq | oh well, let's try that |
| 14:11:59 | Araq | Jehan_: note that 'int' is a POD. |
| 14:12:20 | Araq | so that's clearly an issue with the c++ spec |
| 14:12:44 | Araq | I can see the reasons for these restrictions when you have destructors |
| 14:12:54 | Araq | but for plain 'int'? come on. |
| 14:13:23 | Jehan_ | Araq: I guess they did it in order to not make the spec even bigger than it already is. :) |
| 14:13:39 | Araq | and how hard is it to determine 'a' is not read before it's written in spite of the 'goto label'? |
| 14:13:58 | Jehan_ | Someone could offer me a million Euros to write a spec-compliant C++ compiler and I wouldn't take the job. :) |
| 14:14:51 | Araq | also ... I now map 'var T' to '&T' |
| 14:15:13 | Araq | but guess what, posix.nim uses 'var' instead of 'ptr' ... so this breaks all code |
| 14:15:31 | Jehan_ | Oh dear. |
| 14:15:46 | Araq | so now we get a " 'var' in 'importc' " special case |
| 14:17:19 | Jehan_ | Or enhance importc so that it can take code templates rather than just names? |
| 14:17:24 | * | lws_ quit (Remote host closed the connection) |
| 14:17:45 | Araq | that doesn't solve it, code breakage is bad |
| 14:17:55 | Araq | btw we got that feature for 'importcpp' |
| 14:17:56 | Jehan_ | This would also allow for the importc of operators. |
| 14:18:01 | * | lws joined #nim |
| 14:18:15 | Jehan_ | Oh, I see. |
| 14:18:18 | EXetoC | Jehan_: not much for challenges, eh? |
| 14:18:30 | Jehan_ | EXetoC: Que? |
| 14:19:01 | ekarlso | dom96: you around ? |
| 14:23:00 | Araq | def-: interesting. pointless {} work |
| 14:24:13 | Jehan_ | Araq: Would it be possible to make "x.foo y" work similar to how function calls don't need parentheses? |
| 14:24:13 | * | plopsmcgee joined #nim |
| 14:24:28 | Jehan_ | If there's only a single argument etc., I mean. |
| 14:24:49 | Jehan_ | (Nothing that's important to me, just something I wondered about.) |
| 14:24:52 | Araq | doesn't it work like this already? |
| 14:25:10 | Araq | hi plopsmcgee welcome |
| 14:25:12 | Jehan_ | Hmm. I tried it earlier and it didn't, but I may have screwed up the code. |
| 14:26:02 | Jehan_ | Oh, nevermind, it does. |
| 14:26:05 | def- | Jehan_: i think it works, but not if the function has a return type? |
| 14:26:12 | plopsmcgee | thanks Araq :) |
| 14:26:45 | Jehan_ | Ah, it breaks inside parentheses. |
| 14:26:57 | Jehan_ | E.g. "f(1.op 2)" |
| 14:27:09 | Jehan_ | Anyhow, I have to be off for a talk. Talk to you folks later. |
| 14:27:15 | * | lws quit (Remote host closed the connection) |
| 14:27:18 | * | Jehan_ quit (Quit: Leaving) |
| 14:27:50 | * | lws joined #nim |
| 14:30:42 | ekarlso | dom96: you gotten any time to look at the nimble stuff ? |
| 14:49:22 | * | gokr joined #nim |
| 15:01:27 | * | mwbrown joined #nim |
| 15:02:56 | * | tschmid joined #nim |
| 15:03:51 | * | gokr quit (Quit: Leaving.) |
| 15:10:01 | * | BlaXpirit quit (Read error: Connection reset by peer) |
| 15:10:11 | * | BlaXpirit joined #nim |
| 15:16:10 | * | Angry joined #nim |
| 15:22:23 | * | johnsoft joined #nim |
| 15:28:57 | reactormonk | Araq, hlists in nim would be hilarious. |
| 15:29:12 | Araq | hlists? |
| 15:32:13 | * | dumdum quit (Ping timeout: 256 seconds) |
| 15:35:13 | reactormonk | Araq, a heterogeneous list |
| 15:35:44 | reactormonk | a list with different types in it. Enabled by typeclasses. |
| 15:36:01 | EXetoC | object variants? |
| 15:36:22 | reactormonk | EXetoC, no, entirely different types |
| 15:36:59 | reactormonk | Araq, and what is a concept exactly? |
| 15:37:36 | Araq | reactormonk: nobody knows. that's the beauty of the term :P |
| 15:37:47 | reactormonk | Araq, -.- why not just typeclass? |
| 15:39:34 | * | darkf quit (Quit: Leaving) |
| 15:40:59 | Araq | because it's longer |
| 15:41:23 | Araq | I like "concept" better |
| 15:41:33 | Araq | type Iterable = concept ... |
| 15:41:42 | Araq | type Iterable = typeclass .. |
| 15:42:13 | Araq | and I'm sure it's different enough from Haskell's typeclasses anyway |
| 15:42:34 | reactormonk | I only know scala's typeclasses... |
| 15:42:39 | Araq | so the academics will scream "that is not a typeclass! I will kill you!" |
| 15:43:24 | Araq | like my math teacher used to say |
| 15:43:46 | Araq | "That is not the inverse function! I will kill you!" |
| 15:47:46 | ekarlso | Araq: looked at the packages idea ? |
| 15:47:55 | ekarlso | or Iguess you are too busy :D |
| 15:48:53 | reactormonk | Araq, got an idea how to implement e.g. Read with the concepts/typeclasses? |
| 15:50:43 | * | gokr joined #nim |
| 16:02:23 | * | webskippa joined #nim |
| 16:03:09 | * | webskippa quit (Client Quit) |
| 16:04:16 | * | devalru joined #nim |
| 16:04:37 | devalru | hi |
| 16:06:01 | devalru | In installed the win x64 version but get this error when execute "nim compile": nimbase.h:385:13: error: size of array 'assert_numbits' is negative |
| 16:06:05 | * | Varriount|Mobile joined #nim |
| 16:06:57 | devalru | In addition I have no build64.bat like https://github.com/Araq/Nim/wiki/Unofficial-FAQ said |
| 16:07:07 | Varriount|Mobile | Araq: C++ bootstrapping is broken |
| 16:08:49 | Araq | Varriount|Mobile: I noticed |
| 16:09:14 | Araq | devalru: Nim ships with a version of GCC for a reason |
| 16:09:39 | Araq | also if you install, there is no need to run build64.bat |
| 16:11:15 | devalru | Target: i686-w64-mingw32 - I guess I have to set the env path ? (vagrant installed) |
| 16:11:34 | reactormonk | Araq, https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-630004.1 |
| 16:11:46 | Varriount|Mobile | devalru: yes |
| 16:12:40 | devalru | I suggest to add it to the start.bat |
| 16:13:18 | Varriount|Mobile | devalru: Are you using the compiler that comes with Nim? |
| 16:13:21 | devalru | because nimrod installs the mingw to dist/ the start.bat should use this installation. what you think ? |
| 16:13:31 | Varriount|Mobile | (The gcc compiler) |
| 16:13:37 | devalru | y |
| 16:15:04 | Varriount|Mobile | And is the Nim compiler actually using that compiler? |
| 16:17:35 | Varriount|Mobile | devalru: If it isn't, then there's a problem with the installer |
| 16:17:43 | devalru | mom |
| 16:17:51 | reactormonk | Araq, do we have return type overloading? Would be kinda cruical for e.g. the typeclass Read |
| 16:18:05 | Varriount|Mobile | reactormonk: No |
| 16:18:09 | reactormonk | pretty sure I've asked that one before. |
| 16:19:15 | devalru | Varriount: start.bat -> gcc -v -> gcc version 4.9.1 (x86_64-win32-seh-rev1, Built by MinGW-W64 project) |
| 16:19:33 | * | dumdum joined #nim |
| 16:23:47 | devalru | Varriount: PATH is set correctly to the dist/mingw/, so I don't know why nim compile fails than |
| 16:28:12 | Varriount|Mobile | devalru:The original error you got indicates that the Nim executable was built for one architecture, and GCC another |
| 16:28:16 | dom96 | ekarlso: I looked at it briefly and I would prefer if you moved package repo related stuff to a separate module. |
| 16:28:46 | Varriount|Mobile | devalru: You installed the 32 bit version of Nim? |
| 16:29:03 | Varriount|Mobile | Or the 64-bit version? |
| 16:29:19 | ekarlso | dom96: really why ? |
| 16:29:21 | devalru | Varriount: I have two installations, I think there is a conflict. When I start the start.bat and execute gcc -v AFTER nim compile the shell gives me the wrong mingw version. |
| 16:29:46 | dom96 | ekarlso: Because I like to keep things separated. |
| 16:30:50 | ekarlso | dom96: so you want to support both old and new ? |
| 16:31:17 | dom96 | ekarlso: Of course |
| 16:31:24 | ekarlso | :/ |
| 16:31:25 | Varriount|Mobile | devalru: Odd. |
| 16:32:12 | ekarlso | dom96: but how the crap you code around both ? |
| 16:34:25 | ekarlso | dom96: just seems there's alot of duplicate work then :/ |
| 16:38:09 | dom96 | make a PR and i'll make comments in the diff |
| 16:38:41 | Varriount|Mobile | devalru: If you can be on here in about 2 hours from now, I can give you more help, and also guide you through setting up two Nim installations |
| 16:39:00 | ekarlso | you dont have time to explain now dom96 ? |
| 16:39:23 | devalru | Varriount: First mingw (x32) is installed with vagrant and added to PATH. I think I have to update the PATH or remove vagrant. |
| 16:39:56 | devalru | Varriount: thank you for help but I try it tomorrow ;) |
| 16:40:46 | dom96 | ekarlso: it's simple, you put your 'register' function inside a nimregistry module |
| 16:41:16 | ekarlso | dom96: but why do you need to continue supporting package.json |
| 16:41:53 | dom96 | ekarlso: for backwards compatibility, your packages website still hasn't been tested. |
| 16:42:11 | dom96 | I also want to allow support for custom packages.json |
| 16:42:31 | ekarlso | custom how ? |
| 16:43:15 | dom96 | nimble update http://mywebsite.me/myOwnPackages.json |
| 16:43:18 | dom96 | works |
| 16:43:52 | ekarlso | ah hmmms |
| 16:45:17 | * | devalru quit () |
| 16:53:12 | * | superfunc joined #nim |
| 16:55:59 | ekarlso | dom96: suggestions for supporting both ? |
| 16:56:05 | ekarlso | I mean the list / install / search funtions |
| 17:03:49 | * | plopsmcgee quit (Ping timeout: 246 seconds) |
| 17:04:43 | codmajik | hi guys, is there anywhere I can find BNF version of http://nim-lang.org/manual.html#grammar |
| 17:05:03 | codmajik | before I go down converting back |
| 17:05:25 | codmajik | am working on an IntelliJ IDEA plugin |
| 17:05:46 | codmajik | their grammerkit only works with plain old BNF |
| 17:15:18 | gmpreussner|work | do we have a mechanism for declaring generic procs only for generic parameters that fulfill certain conditions? for example, in D i could use static_if within the class body. |
| 17:15:37 | gmpreussner|work | in Nim i can filter for equality, i.e. "proc cross[T](v: Vector[3, T]): Vector[3, T]" where N == 3, but what if i want to filter non-equality conditions, such as N < 5? |
| 17:15:41 | dom96 | ekarlso: Add an option in the config file to switch between them. |
| 17:16:13 | dom96 | gmpreussner|work: perhaps 'when' is what you want? |
| 17:16:43 | dom96 | codmajik: Don't think there is a BNF version. That grammar is pretty close though I think. |
| 17:17:36 | superfunc | shouldn't be too hard to convert it |
| 17:18:28 | gmpreussner|work | dom96: can 'when' filter on generic parameters inside its scope? i wouldn't expect that to work. i.e.: when N < 5: proc foobar[N](f: Foo[N]) = ... |
| 17:19:05 | dom96 | gmpreussner|work: I think it can. Perhaps you should put it inside the body of the proc. |
| 17:19:53 | gmpreussner|work | dom96: but if i put it inside, then what is the else condition? empty body? i would rather not have the proc be available at all if the condition is not fulfilled. |
| 17:20:57 | codmajik | dom96: yeah its close, would work on converting back |
| 17:21:13 | dom96 | gmpreussner|work: You can raise a compile-time error for example |
| 17:21:49 | codmajik | dom96: but I would probably want to run it by you so I don't miss something, since am a nim-noob |
| 17:22:35 | gmpreussner|work | dom96, i guess that would work, yes |
| 17:23:16 | codmajik | dom96: better still, is there a single source file that exercises all of nim's grammer I could use to verify |
| 17:24:27 | * | davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 17:25:16 | ekarlso | dom96: wondering if I should move out the "old" functions then kinda |
| 17:25:24 | ekarlso | into like legacy.nim or smth |
| 17:25:33 | ekarlso | and have nimble.nim have top level methods |
| 17:25:50 | * | davidhq joined #nim |
| 17:25:55 | dom96 | codmajik: no comprehensive one unfortunately. |
| 17:26:25 | dom96 | ekarlso: please don't |
| 17:26:37 | dom96 | ekarlso: make minimal changes to get your stuff working |
| 17:26:47 | ekarlso | dom96: it's not that easy.. |
| 17:26:51 | codmajik | dom96: cool. let you guys know what I come up with |
| 17:27:55 | ekarlso | dom96: would you like to help out on the nimble part ? |
| 17:29:06 | dom96 | ekarlso: I'm busy with other things currently. |
| 17:29:13 | * | sillesta quit (Remote host closed the connection) |
| 17:29:24 | ekarlso | yeye, then it'll have to wait, because doing it simpler then I have now I'm unsure of |
| 17:29:37 | ekarlso | but I guess it's fine with the ackages.json format atm |
| 17:29:38 | * | sillesta joined #nim |
| 17:31:07 | * | codmajik quit (Ping timeout: 246 seconds) |
| 17:33:50 | * | sampwing joined #nim |
| 17:34:02 | ekarlso | I just know that having a packages index is a nice thing to have for users and in general |
| 17:39:19 | * | davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 17:40:17 | * | dumdum quit (Ping timeout: 256 seconds) |
| 17:45:04 | * | Matthias247 joined #nim |
| 17:51:19 | * | Jehan_ joined #nim |
| 17:53:50 | * | MajorWork quit (Quit: Leaving) |
| 18:03:20 | * | gunn joined #nim |
| 18:04:10 | reactormonk | does the proc type have type arguments? |
| 18:04:25 | * | sampwing quit (Ping timeout: 252 seconds) |
| 18:09:09 | * | matkuki joined #nim |
| 18:10:17 | Jehan_ | reactormonk: What do you mean? |
| 18:10:36 | reactormonk | Jehan_, proc[int, bool] |
| 18:11:07 | Jehan_ | reactormonk: Still not sure what you mean by that? |
| 18:11:28 | reactormonk | Jehan_, as in, is `proc` a proper type by its own? |
| 18:11:54 | Jehan_ | proc is really a family of types. |
| 18:12:14 | Jehan_ | Dependent on arity, argument types, and return type, plus calling convention. |
| 18:13:10 | Jehan_ | You can do, for example: var a: proc(x: int): bool |
| 18:16:05 | * | sampwing joined #nim |
| 18:29:14 | ekarlso | dom96: how would you really want it organized then ? |
| 18:29:58 | * | codmajik joined #nim |
| 18:30:26 | * | davidhq joined #nim |
| 18:33:45 | * | sampwing quit (Ping timeout: 252 seconds) |
| 18:37:16 | * | sampwing joined #nim |
| 18:41:08 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 18:44:41 | matkuki | Is there an overhead for a types procedure attribute? Example: https://bpaste.net/show/7d0e829d95cd |
| 18:44:43 | matkuki | Is "power(12)" faster than "ObjProcType.AttribProc(12)" |
| 18:46:17 | Araq | no. |
| 18:46:30 | Araq | oh wait |
| 18:46:31 | matkuki | Great, thanks. |
| 18:46:41 | matkuki | Wait? |
| 18:46:47 | Araq | when you do it this way, there is an overhead, yup |
| 18:47:02 | matkuki | When is there no overhead? |
| 18:47:29 | Araq | when you do foo.bar(4) as syntactic sugar for bar(foo, 4) |
| 18:48:39 | matkuki | Is the overhead small or significant if used in loops? |
| 18:49:38 | Araq | usually measurable |
| 18:49:47 | matkuki | OK, thanks. |
| 18:50:16 | BlaXpirit | wat |
| 18:52:27 | * | sampwing quit (Ping timeout: 252 seconds) |
| 18:56:33 | * | alexruf joined #nim |
| 18:57:02 | * | sampwing joined #nim |
| 18:58:50 | matkuki | I was thinking of making types that would act as namespaces when instanciated, since there are no static classes. |
| 18:58:52 | matkuki | Then I could do "module.namespaceTypeInstance.namespaceProc", for example. |
| 18:59:56 | matkuki | Was hoping there was no overhead. |
| 19:00:12 | BlaXpirit | and that, Araq, is what you're gonna have people doing if there are no namespaces |
| 19:00:40 | BlaXpirit | matkuki, all i can tell you is... why don't you replace a dot with an underscore and call that a namespace |
| 19:01:24 | matkuki | BlaXpirit: Will try it, thanks for the suggestion. |
| 19:01:32 | Jehan_ | Umm, you want namespaces *within* a module? Why? |
| 19:02:05 | BlaXpirit | first of all, modules are very limiting |
| 19:02:18 | BlaXpirit | second, using them as namespaces very rarely works out |
| 19:02:30 | Jehan_ | You'll have to explain that. |
| 19:02:32 | BlaXpirit | (talking import nil and whatnot) |
| 19:02:55 | BlaXpirit | well, i've stated a few times that from ... import nil is almost always useless |
| 19:02:56 | Jehan_ | I mean, I'm not crazy about the "from x import nil" syntax myself, but that could be fixed. |
| 19:03:02 | BlaXpirit | because it doesn't import operators, methods, etc |
| 19:03:35 | Jehan_ | For purposes of generics/templates, you mean? |
| 19:03:43 | BlaXpirit | huh.. no? |
| 19:03:47 | EXetoC | the problem is not actually "modules as namespaces" then, is it? |
| 19:04:10 | Jehan_ | I'm also not sure how a namespace would fare better in that regard. |
| 19:04:29 | BlaXpirit | first of all, you could put these things outside the namespace |
| 19:04:44 | Jehan_ | Unless we're miscommunicating and you mean something by it that's different from what I think you mean. |
| 19:05:04 | BlaXpirit | nim basically doesn't have namespaces |
| 19:05:22 | BlaXpirit | all it has is one global namespace, with conflict resolution mechanism |
| 19:05:49 | Jehan_ | Umm … |
| 19:06:03 | Jehan_ | That strikes me as the mother of all overstatements. |
| 19:06:14 | * | bjz joined #nim |
| 19:06:33 | Jehan_ | I mean, at a very minimum, if I define a symbol in a module and do not export it, it's not visible anywhere else. |
| 19:07:00 | Jehan_ | Which is sort of the exact opposite of one global namespace. |
| 19:07:05 | BlaXpirit | that is not really about namespaces |
| 19:07:22 | BlaXpirit | but this does raise another dire problem |
| 19:07:45 | BlaXpirit | there is public and private, but no protected |
| 19:08:14 | Araq | it's called dot-aholic. People.who.are.only.happy.when.everything.is.separated.with.a.dot. |
| 19:08:20 | EXetoC | what you said is not about namespaces either |
| 19:08:29 | BlaXpirit | yup |
| 19:08:32 | Araq | it also has nothing to do with programming. |
| 19:08:36 | BlaXpirit | hence "another problem" |
| 19:08:48 | Jehan_ | So? Protected only really makes sense in the presence of inheritance, and even there it's arguable whether there's a point to having different private and protected visibility. |
| 19:09:23 | BlaXpirit | there is no point to having private and protected, but if there's private, there needs to be protected |
| 19:09:39 | ldlework | that seems self-contradictory |
| 19:09:42 | ldlework | did you word that wrongly? |
| 19:09:51 | EXetoC | omitting the namespace from symbols or not doing nil importing does not mean that there now is no namespace |
| 19:09:56 | Jehan_ | I'm not even sure what protected would mean without inheritance. |
| 19:10:17 | Araq | I'm out. |
| 19:10:19 | BlaXpirit | Jehan_, basically my concern is |
| 19:10:20 | Jehan_ | Unless it's supposed to have some different semantics from C++/Java/etc. |
| 19:10:32 | BlaXpirit | you can't improve on the implementation of something |
| 19:11:48 | BlaXpirit | i can't completely understand what I'm thinking, let alone explain it |
| 19:12:02 | BlaXpirit | so let's just go back to the lack of namespaces |
| 19:13:52 | EXetoC | again, what lack of namespaces? |
| 19:14:01 | BlaXpirit | Nim's lack of namespaces |
| 19:14:02 | Jehan_ | It sounds like you want some sort of inheritance scheme for modules. Where you want to import and modify a module and export the result. |
| 19:14:23 | BlaXpirit | no, Jehan_, I want inheritance for classes, across modules |
| 19:14:28 | EXetoC | did you just not say "modules as namespaces"? |
| 19:14:45 | BlaXpirit | you said that :| |
| 19:15:01 | BlaXpirit | well i did implicitly say that, ok |
| 19:15:19 | Jehan_ | I'm still not sure what a namespace would provide that a module does not. |
| 19:15:25 | EXetoC | you did, just that you worded it differently |
| 19:15:33 | EXetoC | right |
| 19:15:51 | ldlework | namespaces should be ethereal |
| 19:15:59 | ldlework | I can't wait until this opinion is more popular |
| 19:16:18 | ldlework | s/ethereal/transient |
| 19:16:40 | BlaXpirit | Jehan_, trivial namespaces indeed seem exactly the same as a module |
| 19:17:21 | BlaXpirit | and I haven't felt a huge need for namespaces per se |
| 19:17:27 | Jehan_ | Okay. What would non-trivial namespaces do that modules don't? |
| 19:17:55 | BlaXpirit | nesting |
| 19:18:15 | ldlework | Jehan_: namespaces spanning multiple files |
| 19:18:21 | BlaXpirit | but that's a different topic, this is not important |
| 19:18:30 | ldlework | or make modules not the same thing as files |
| 19:18:35 | BlaXpirit | ldlework, well, you can get that by importing everything in one file :| |
| 19:18:53 | ldlework | BlaXpirit: I know there are tons of stupid ways to get Nim to do what you expect to be able to do in 2015 |
| 19:18:57 | Jehan_ | That seems like what include is for? Unless you want multiple modules within the same file. |
| 19:19:14 | ldlework | Jehan_: include breaks the import contract |
| 19:19:22 | BlaXpirit | Jehan_, ever thought about importing part of a namespace |
| 19:19:44 | ldlework | I should be able to have a module/namespace made up of several files, each file of which is able to import just the things it needs from the other files. |
| 19:19:58 | BlaXpirit | I just realized one usecase for namespaces that i totally forgot I needed |
| 19:20:13 | BlaXpirit | C++ libraries tend to have classes with generic names |
| 19:20:22 | Jehan_ | BlaXpirit: No, not really. I think that would be a symptom of a poorly designed module. |
| 19:20:22 | ldlework | BlaXpirit: all libraries do |
| 19:20:24 | BlaXpirit | and that's OK, because they're in a namespace |
| 19:21:08 | BlaXpirit | that SFML library I've been rattling about |
| 19:21:24 | BlaXpirit | you are encouraged to always write sf::SomeClass |
| 19:21:37 | ldlework | We should just copy rust modules outright :/ |
| 19:21:44 | EXetoC | namespaces? check |
| 19:21:45 | BlaXpirit | uh probably |
| 19:22:30 | BlaXpirit | EXetoC, what does that mean |
| 19:23:32 | ldlework | In Rust all this module business is utterly decoupled from the filesystem/files |
| 19:23:42 | ldlework | And you're free to organize your project literally any way you wish |
| 19:23:56 | ldlework | And subsequently, build up and expose your module in any manner you wish |
| 19:24:01 | ldlework | Those idiots. |
| 19:24:10 | BlaXpirit | lel |
| 19:24:25 | * | JehanII joined #nim |
| 19:24:28 | BlaXpirit | well C++ has almost all of the same advantages |
| 19:24:34 | ldlework | And in nim we have |
| 19:24:46 | JehanII | Somedays I hate my ISP ... |
| 19:24:47 | ldlework | "Just use include" |
| 19:24:53 | EXetoC | you just have to convince the BDFL that hierarchies are good |
| 19:24:57 | * | Jehan_ quit (Ping timeout: 265 seconds) |
| 19:25:01 | codmajik | Araq: is there any reason why folders are not considered when generating c sources files |
| 19:25:03 | ldlework | EXetoC: impossible |
| 19:25:05 | JehanII | Let me just quickly catch up on the logs ... |
| 19:25:49 | * | JehanII is now known as Jehan_ |
| 19:26:26 | * | Angry quit (Ping timeout: 246 seconds) |
| 19:27:02 | Jehan_ | ldlework: I wouldn't mind having a module system decoupled from the file system, but I don't really see this making a big difference, one way or the other. |
| 19:27:20 | EXetoC | I don't really care much myself |
| 19:27:24 | Jehan_ | It's irritating in languages like Java and Eiffel with a one-class-per-file restriction. |
| 19:27:38 | BlaXpirit | just you wait until big corporations that write real code get to Nim |
| 19:27:42 | Jehan_ | But a Nim module is really a general enough container that it's not hugely critical. |
| 19:27:52 | BlaXpirit | oh wait, they won't, because they'll consider the language a joke |
| 19:27:52 | ldlework | Jehan_: you must not value freedom to organize your project how you see fit |
| 19:28:04 | ldlework | as much as I do, I mean |
| 19:28:17 | Jehan_ | ldlework: Eh, that's mostly determined by project guidelines. |
| 19:28:28 | ldlework | Jehan_: of which I am allowed to define most of the time |
| 19:28:38 | Jehan_ | What I would be very much in favor of is to clean up the module lookup semantics. |
| 19:28:54 | ldlework | And I plan to write tons of personal Nim, assuming we don't hard-line Nim's unsanded edges. |
| 19:29:36 | Jehan_ | But with respect to the module/file boundary: |
| 19:30:42 | Jehan_ | There are really two cases: One, multiple files making up a module (include handles that easily). Two, multiple modules in the same file. That would be annoying to do, but I haven't encountered much of a need for it. |
| 19:31:10 | * | fowlmouth left #nim ("Leaving") |
| 19:31:22 | Jehan_ | As I said, it's more of annoyance in languages where each class needs its own file. |
| 19:31:40 | BlaXpirit | as if there are so many of them |
| 19:31:51 | BlaXpirit | i can think of only one |
| 19:32:02 | ldlework | I don't need multiple modules per file |
| 19:32:11 | Jehan_ | Well, I hear that Java is sort of popular these days. :) |
| 19:32:54 | * | nande joined #nim |
| 19:33:07 | Jehan_ | Eiffel also pretty much enforces it (not per the language spec, which is OS-agnostic, but any actual implementation). |
| 19:33:46 | Jehan_ | And a number of other languages really discourage multiple classes per file, even where you can theoretically do it. But that's not really important. I just note that it can be an annoyance and that I don't like it. |
| 19:34:31 | ldlework | Jehan_: have you used Python much at all? |
| 19:34:41 | Jehan_ | What I'd find more interesting to discuss, honestly, is how modules are organized within directories, module lookup semantics, etc. I think there are some rough edges that could be filed off. |
| 19:34:51 | Jehan_ | ldlework: I used to use it a lot. |
| 19:35:06 | BlaXpirit | the module system really seems to have been "inspired" directly by Python |
| 19:35:08 | ldlework | Jehan_: I find its module system and its import semantics to be incredibly flexible |
| 19:35:17 | ldlework | BlaXpirit: except that we crippled it badly |
| 19:35:28 | ldlework | It 'looks' like python's import semantics but work nothing like them |
| 19:35:40 | BlaXpirit | ldlework, that was i was gonna say |
| 19:35:43 | ldlework | 'import foo' in python and nim are drastically different |
| 19:35:53 | Varriount | ldlework: How is it crippled? |
| 19:36:17 | ldlework | Varriount: Python's import semantics cover just about every case you might want |
| 19:36:17 | Varriount | (I'm not offended, just curious) |
| 19:36:21 | ldlework | We support one of those. |
| 19:36:23 | Jehan_ | ldlework: Hmm. The difference between Python and Nim (or other statically typed languages) is that Python can't disambiguate between entities with the same name, but different signatures (or classes vs. defs etc.). |
| 19:36:31 | BlaXpirit | Varriount, only "import x" syntax is any useful |
| 19:36:35 | ldlework | In python, you can import a namespace, import a name under a namespace, or import a name directly |
| 19:36:44 | ldlework | In Nim, you get everything, and fuck you. |
| 19:36:57 | ldlework | (not you Varriount) |
| 19:36:57 | BlaXpirit | yes |
| 19:37:16 | * | JehanII joined #nim |
| 19:37:18 | Varriount | What about 'from x import y' in Nim? |
| 19:37:27 | JehanII | So, Python has to be very careful with importing names into the current namespace, while statically typed languages do not have to be. |
| 19:37:33 | BlaXpirit | Varriount, it is useless |
| 19:37:42 | BlaXpirit | :03:00] <BlaXpirit> because it doesn't import operators, methods, etc |
| 19:37:50 | ldlework | JehanII: importing something that way also allows me to instantly discover where a name comes from |
| 19:38:14 | ldlework | I -want- to be careful |
| 19:38:44 | ldlework | Further more |
| 19:38:54 | EXetoC | just discuss it on the forum at some point. if you don't like the forum, then so be it |
| 19:38:57 | ldlework | I want to be able to import something, without it's owning module clobbering that name (how stupid!) |
| 19:39:16 | Varriount | Hm. I haven't actually looked at the Nim compiler module handling code yet. |
| 19:40:32 | matkuki | Just to make my idea clear, I don't care for inheritance, protected, ... All I was asking was, if there is a possibility to make blocks of statements grouped together in a namespaces inside a module. |
| 19:40:33 | matkuki | So they could be called either "mymodule.proc" or "mymodule.mynamespace.myproc", that's all. The namespace should NOT be exportable, inheritable, washable, ... |
| 19:40:35 | matkuki | I don't care if it's done by a macro or some other Nim magic. But if it's not possible, there's no problem. |
| 19:40:41 | JehanII | BlaXpirit: Not sure what you mean, but for me it does import operators and methods? |
| 19:40:54 | * | Jehan_ quit (Ping timeout: 265 seconds) |
| 19:41:27 | Varriount | JehanII: He means it doesn't import operators and methods related to a type |
| 19:41:48 | BlaXpirit | yes |
| 19:41:54 | JehanII | In any event, I think that whether the default is importing a name into a namespace or not is a matter of taste, where one is not objectively better or worse than the other. |
| 19:41:57 | BlaXpirit | if a type has 50 methods and 20 operators |
| 19:41:58 | JehanII | Varriount: Ah. |
| 19:42:03 | BlaXpirit | and you just import a type |
| 19:42:03 | EXetoC | ldlework: I'll just say again that most people are not bothered about that |
| 19:42:07 | BlaXpirit | you're left with just a useless shell |
| 19:42:11 | Varriount | Eg, 'from tables import Table' only imports the type, and not any of the procedures applicable to the type |
| 19:42:26 | BlaXpirit | and how is that ever useful |
| 19:42:29 | ldlework | EXetoC: "most people put up with this wart" is literally the weakest reasoning I can hear |
| 19:42:31 | ldlework | EXetoC: but ok |
| 19:42:37 | JehanII | I'd prefer Nim to have full OO support myself, but I think that ship has sailed. |
| 19:42:48 | EXetoC | you're the one who calls it a wart |
| 19:42:51 | * | JehanII is now known as Jehan_ |
| 19:43:13 | ldlework | EXetoC: because there is a potentially objectively more flexible option that exists as a superset of functionality |
| 19:43:17 | EXetoC | others might, but not many peopled have discussed it |
| 19:43:35 | ldlework | EXetoC: it is objectively a wart, regardless if other people don't worry about it because it is not fundamental to their experience |
| 19:43:45 | ldlework | Because that functional superset exists. |
| 19:43:48 | Jehan_ | One could probably write a "smart" "from x import …", though, as an approximation. |
| 19:43:57 | * | Mat4 joined #nim |
| 19:44:00 | Mat4 | hello |
| 19:44:01 | BlaXpirit | yes, that is my main wish in all this |
| 19:44:13 | BlaXpirit | dot-syntax could grab any associated functions |
| 19:44:21 | BlaXpirit | and operators could be grabbed as well |
| 19:44:51 | Jehan_ | The one problem I see with that is that (once you get the transitive closure), you might be grabbing a lot. |
| 19:45:17 | Jehan_ | At which point you can just import everything. :) |
| 19:45:29 | BlaXpirit | Jehan_, only dot-syntax would look globally |
| 19:45:58 | Varriount | BlaXpirit: Well, the importing code (compiler/importer.nim) doesn't look *too* complicated. It's mostly symbol lookup |
| 19:46:20 | matkuki | Mat4, you have joined what seems like a war zone :) |
| 19:47:18 | Mat4 | hi matkuki, it seems so |
| 19:47:20 | Varriount | BlaXpirit: You could implement the 'smart' import, and send a PR |
| 19:48:39 | BlaXpirit | no, i couldn't, i really couldn't |
| 19:48:57 | BlaXpirit | if i could, i would be making my own language |
| 19:55:48 | BlaXpirit | does this seem sane though? would be nice to state this clearly on github or somethin |
| 19:56:35 | EXetoC | yes, somewhere where it doesn't get as convoluted |
| 19:56:42 | Varriount | BlaXpirit: The key difference between Python and Nim, in this case, is symbol lookup |
| 19:57:07 | Varriount | BlaXpirit: Nim supports overloading/static dispatch |
| 19:57:35 | Varriount | Furthermore, modules aren't objects in Nim as they are in Python |
| 19:57:46 | Mat4 | I beg your pardon interrupting the discussion, have someone here an idea how to improve code-size optimization ? A simple program priniting 'hello world' compiles with -d:release --opt:size to ~26 kb (Linux, x86) at current |
| 19:59:13 | Varriount | Mat4: http://forum.nim-lang.org/t/679/1 |
| 20:00:19 | Jehan_ | Mat4: That seems reasonably small to me, given that this contains at the minimum the startup code and the garbage collector? |
| 20:02:14 | Varriount | BlaXpirit: To be succinct, I fear having a 'smart' import, while conveniant, would cause confusion. The only 'problem' I percieve that it solves is being explicit with what types you are using. Procedure names would still be implicitly imported |
| 20:02:14 | Mat4 | I plan to test some code for PIC32 MCU's running with RetroBSD. The PIC has 64 kb of ram avariable so each byte is important |
| 20:02:51 | Varriount | Mat4: --os:standalone and --gc:off ? |
| 20:03:22 | Varriount | (If you only have 64 kb of memory, you probably want to manually manage memory anyway) |
| 20:03:30 | * | dumdum joined #nim |
| 20:03:34 | Jehan_ | SHould be --gc:none. |
| 20:04:05 | Varriount | BlaXpirit: Also, |
| 20:04:54 | ldlework | from foo import Bar* |
| 20:05:18 | Varriount | 'smart' importing could get very... complex. What happens to procedures that operate on a type an imported type contains? What if I have procedures imported from a different module that act on the same type contained in a type from another module?? |
| 20:05:41 | ldlework | Varriount: that is already possible in both cases |
| 20:06:26 | Varriount | ldlework: Yes, I know. But having a 'smart' import complicates matters. How should it act in those cases? |
| 20:06:29 | BlaXpirit | Varriount, I am talking only about dot-syntax about operators |
| 20:06:36 | BlaXpirit | it should not import procedures at all |
| 20:06:42 | ldlework | o_O |
| 20:07:13 | ldlework | Varriount: it should just do what it is supposed to do, and the compiler will complain in each of those cases |
| 20:07:19 | ldlework | just as if you had manually done those imports yourself |
| 20:07:23 | Mat4 | -d:release --opt:size --gc:off --stackTrace:off --lineTrace:off -> 15kb (x64), ~25kb (MIPS32, PIC) |
| 20:08:27 | Jehan_ | Umm, not sure why that distinction between operators and procs. |
| 20:08:36 | ldlework | Me either |
| 20:08:43 | ldlework | an operator is a proc |
| 20:08:52 | reactormonk | Jehan_, there is none |
| 20:09:11 | reactormonk | Mat4, can you find out what takes how much space? |
| 20:09:11 | ldlework | reactormonk: read what BlaXpirit just said? |
| 20:09:14 | Jehan_ | ldlework: Yeah, exactly. |
| 20:09:40 | reactormonk | ldlework, not everything you read on the internet is true |
| 20:09:55 | ldlework | reactormonk: I think you're missing context or something |
| 20:10:00 | ldlework | or trolling |
| 20:10:12 | Varriount | Mat4: Have you stripped the executable? |
| 20:10:26 | reactormonk | ldlework, ok, lemme read some stuff |
| 20:10:39 | Varriount | Mat4: Also, this link might help: http://stackoverflow.com/questions/200292/process-for-reducing-the-size-of-a-executable |
| 20:10:45 | BlaXpirit | so, what do you think... the only change I suggest is, operators and methods called using dot should be looked up in all modules even if they were "imported nil" |
| 20:10:58 | ldlework | What?! |
| 20:11:03 | ldlework | Without even importing them?! |
| 20:11:29 | ldlework | Interrobang?! |
| 20:11:55 | BlaXpirit | i dunno, just suggesting |
| 20:12:42 | ldlework | import foo, from foo import Bar, from foo import Bar* |
| 20:12:46 | ldlework | all cases covered. |
| 20:12:54 | Varriount | Just checking, what exactly is this change supposed to fix/improve? |
| 20:13:04 | BlaXpirit | making from x import y useful at all |
| 20:13:10 | ldlework | yeah |
| 20:13:23 | Mat4 | reactormonk: not sure, seem to be code for debugging purposes ?!?? |
| 20:13:40 | reactormonk | ldlework, from what I see my point still stands. There is no difference between procs and ops |
| 20:14:07 | Mat4 | Varriount: strip helped, thanks. 11 kb (x86), ~20 kb (MIPS32) |
| 20:14:08 | ldlework | reactormonk: right, a statement I agreed with, Jehan agrees with |
| 20:14:09 | reactormonk | Mat4, huh. Can I take a look? Pastebin etc. |
| 20:14:26 | ldlework | reactormonk: Jehan_ wasn't asking "Seriously, what's the difference, tell me the different that exists but that I do not know" |
| 20:14:37 | ldlework | reactormonk: Jehan_ was asking "Is there really a difference?" |
| 20:14:47 | ldlework | reactormonk: I was asking you to look at the statement to which Jehan_ was replying |
| 20:14:56 | * | codmajik quit (Quit: Page closed) |
| 20:15:10 | Jehan_ | To be precise, I was asking why he wanted to treat operators and procs differently. |
| 20:15:14 | reactormonk | ldlework, ok. |
| 20:15:15 | ldlework | Which is that BlaXpirit was saying t.. yeah that |
| 20:15:43 | reactormonk | BlaXpirit, yeah, so we don't know how tod differentiate between ops and procs |
| 20:15:45 | Jehan_ | Since I didn't see the point. If it makes sense for operators, it also makes sense for procs. |
| 20:15:53 | ldlework | ie |
| 20:16:28 | Jehan_ | I guess you could do it by name. I.e. if the name is all operator characters, it's an operator. |
| 20:16:45 | Mat4 | reactormonk: uno momento |
| 20:17:26 | Jehan_ | My guess it's because operator syntax doesn't allow the operator to be qualified with a module name. |
| 20:17:29 | Varriount | Mat4: I wonder why the size difference is so drastic between platforms? |
| 20:17:40 | Jehan_ | So you'd have to do mod.`+`(x, y) or something like that. |
| 20:17:56 | reactormonk | Jehan_, so be it |
| 20:17:58 | Jehan_ | At the same time, this also holds for x.foo(y). |
| 20:18:11 | reactormonk | Jehan_, unified calling syntax etc. |
| 20:18:15 | Jehan_ | So I'm still not sure why there's a point in leaving out procs. |
| 20:18:31 | Mat4 | Varriount: MIPS32 has a typical RISC encoding with fixed opcode depth whereby x86 is 2x more compact (more or less) |
| 20:19:07 | reactormonk | Mat4, works |
| 20:21:39 | Varriount | Mat4: Ah, I see. (I actually just did a presentation on the x86 instruction set :D ) |
| 20:21:44 | ldlework | Jehan_: there is none, as he said he was just thinking outloud |
| 20:21:53 | ldlework | Varriount: is it online? |
| 20:22:57 | Varriount | ldlework: Yeah. It's not very good. It was for a basic comp-sci course. I had to... simplify things in order to make the information comprehensible to the class. |
| 20:23:13 | ldlework | I'd still love to watch it. |
| 20:23:16 | ldlework | I used to be... |
| 20:23:26 | ldlework | ahem, heavy into black-hat reverse engineering |
| 20:23:29 | ldlework | so nostalgia |
| 20:23:33 | Araq | Jehan_: this 'goto' stuff is killing me |
| 20:23:40 | * | shodan45 joined #nim |
| 20:23:55 | Varriount | ldlework: Well, the presentation itself wasn't recorded. I just have the paper and the slideshow |
| 20:23:59 | ldlework | oh |
| 20:24:00 | ldlework | okay |
| 20:24:17 | Araq | seems like I *really* need to avoid generating 'goto' for 'if' |
| 20:24:20 | Varriount | The slideshow was thrown together in about 15 minutes - I spent too much time researching |
| 20:24:54 | shodan45 | Araq: goto is bad, mmmkay? ;) |
| 20:24:57 | Jehan_ | Araq: C++ again? |
| 20:25:06 | Araq | yes |
| 20:25:29 | Araq | shodan45: so name a single instruction set that has no 'goto'. |
| 20:25:43 | Varriount | ldlework: For example, I simplified the reasons why a 32 bit processor could only address 4GB of memory. I left out things like lookup tables and memory maps. |
| 20:26:08 | shodan45 | Araq: HTML? :D |
| 20:26:09 | ldlework | shodan45: xu do kelci lo barduku |
| 20:26:10 | ldlework | shit |
| 20:26:14 | ldlework | shodan45: do you play go? |
| 20:26:47 | shodan45 | ldlework: no... |
| 20:27:11 | ldlework | shodan45: okay just checking 'shodan' is a rank there (I understand its a rank in other places too, was just checking) |
| 20:27:25 | shodan45 | ldlework: shodan == http://en.wikipedia.org/wiki/SHODAN |
| 20:27:55 | * | shodan45 contemplates switching to "SHODAN" |
| 20:28:23 | ldlework | http://en.wikipedia.org/wiki/Shodan_(rank) |
| 20:28:32 | shodan45 | ldlework: what language was that? |
| 20:28:47 | ldlework | lojban, sorry |
| 20:29:30 | ldlework | strange, the first time I've emitted it on accident without being aware of it |
| 20:31:32 | shodan45 | ldlework: my IRC font makes you look like "Idlework"... I was having fun trying to tab-complete your nick |
| 20:31:54 | * | ldlework writes down 'shodan45' next to the number 33294 |
| 20:32:05 | shodan45 | :P |
| 20:33:09 | shodan45 | is there a way to get a screen shot in nim? in linux/x11? |
| 20:33:26 | ldlework | shodan45: you can shell out to some system command |
| 20:33:42 | shodan45 | ldlework: yeah, trying to avoid that |
| 20:34:28 | ldlework | shodan45: https://github.com/nim-lang/x11 |
| 20:35:37 | shodan45 | hmm, bare x11? I've heard it's "fun" :) |
| 20:36:51 | ldlework | shodan45: how do you expect to do it without an external command otherwise? |
| 20:38:41 | ldlework | I mean |
| 20:38:47 | ldlework | you could use a different external lib |
| 20:38:53 | ldlework | ffmpeg, etc |
| 20:41:58 | * | Mat4 is now known as Mat4-backend_cod |
| 20:42:17 | * | Mat4-backend_cod is now known as Mat4-be_coding |
| 20:42:21 | * | alexruf quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 20:43:02 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 20:45:43 | matkuki | Hows the "mitems" iterator coming along? |
| 20:47:41 | BlaXpirit | shodan45, http://blaxpirit.github.io/nim-csfml/csfml_graphics.html#capture,RenderWindow |
| 20:47:49 | BlaXpirit | as usual blabbering about my lib |
| 20:48:35 | BlaXpirit | but it does do a lot |
| 20:49:31 | * | alexruf joined #nim |
| 20:50:54 | ldlework | BlaXpirit: I think he's asking for full screen capture |
| 20:51:19 | Araq | matkuki: nim devel has it in system.nim |
| 20:51:32 | matkuki | Yuhu, thanks. |
| 20:51:45 | BlaXpirit | ldlework, it is |
| 20:51:54 | Araq | ok I think I got it now. I simply need to emit *more* braces |
| 20:51:55 | ldlework | BlaXpirit: it sounds like it only captures what is in your csfml window? |
| 20:51:58 | BlaXpirit | wait, it's not |
| 20:52:00 | ldlework | :) |
| 20:52:07 | BlaXpirit | sorry |
| 20:52:36 | Mat4-be_coding | Araq: *lol* |
| 20:53:49 | * | bjz joined #nim |
| 21:00:52 | dtscode | Araq, when in doubt, use goto |
| 21:02:04 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 21:06:20 | * | brson joined #nim |
| 21:17:13 | Mat4-be_coding | if I have a procedure: 'proc pick (stackDepth : tStackDepth) : tMachineCode' |
| 21:17:53 | Mat4-be_coding | with tMachineCode -> |
| 21:17:56 | Mat4-be_coding | tMachineCode = object |
| 21:17:56 | Mat4-be_coding | aSequence : array [0..32] of uInt8 |
| 21:17:56 | Mat4-be_coding | nSequence : range [0..32] |
| 21:18:42 | Mat4-be_coding | can I write 'result.aSequence[0] = 0x48 ...' |
| 21:18:59 | Mat4-be_coding | ? |
| 21:19:18 | Mat4-be_coding | (a bit of tacit programming) |
| 21:19:59 | Araq | result.aSequence = [0x48u8, 0x8, ...] |
| 21:20:27 | Araq | only the very first array element needs the 'u8' suffix, I think. |
| 21:22:03 | * | zacts quit (Ping timeout: 245 seconds) |
| 21:22:04 | Mat4-be_coding | thanks |
| 21:25:35 | Mat4-be_coding | what's the reason for the 'u8' suffix ? |
| 21:26:20 | Araq | the compiler is too stupid to guess what you mean |
| 21:31:35 | * | sampwing quit (Ping timeout: 252 seconds) |
| 21:39:24 | * | kuzy000_ quit (Ping timeout: 245 seconds) |
| 21:52:38 | matkuki | Can someone help me with an import problem: https://bpaste.net/show/3b2c9f55a30e ? |
| 21:54:19 | matkuki | If the "collisions" import is deleted out of "objects.nim", the error dissapears. |
| 21:55:23 | matkuki | I only added the top lines of the modules! There is more code in them. |
| 22:03:33 | * | alexruf quit (Quit: Textual IRC Client: www.textualapp.com) |
| 22:07:11 | * | dumdum quit (Ping timeout: 256 seconds) |
| 22:08:22 | * | ARCADIVS joined #nim |
| 22:13:32 | dom96 | matkuki: I think that's because it becomes a circular dependency |
| 22:14:21 | matkuki | dom96: Oh, OK. Need to reshuffle a few proc's then. |
| 22:28:33 | shodan45 | aporia is still the recommended editor/IDE for nim? |
| 22:29:02 | Mat4-be_coding | yes |
| 22:29:07 | Mat4-be_coding | (as I know) |
| 22:29:23 | * | Angry joined #nim |
| 22:29:26 | shodan45 | because "nimble install aporia" failed for me :( |
| 22:30:03 | shodan45 | CustomStatusBar.nim(41, 24) Error: undeclared identifier: 'False' |
| 22:31:33 | EXetoC | try aporia#head |
| 22:31:33 | dom96 | shodan45: nimble install aporia@#head |
| 22:31:39 | EXetoC | oh right |
| 22:31:44 | EXetoC | new syntax |
| 22:31:54 | shodan45 | dom96: ok, will do |
| 22:32:09 | Mat4-be_coding | I'm a Vim user so haven't tried compiling the current Aporia sources |
| 22:32:22 | Mat4-be_coding | (yet) |
| 22:32:49 | shodan45 | dom96: yay, that worked :) |
| 22:40:08 | shodan45 | btw, how's the compile-to-javascript stuff going? |
| 22:41:14 | shodan45 | I saw that Scala.js announced that they're "production ready" |
| 22:43:58 | shodan45 | tbh, if scala compiled to native binaries instead of JVM bytecode, I'd be a lot less interested in nim |
| 22:50:03 | Angry | https://gcc.gnu.org/java/ |
| 22:50:19 | * | semperos joined #nim |
| 22:51:11 | flaviu | I think that scala uses modern bytecodes that GCJ doesn't support. |
| 22:52:09 | flaviu | And Java bytecode really is designed for a JIT. It wouldn't do well with native compilation where devirtualization isn't a common optimization. |
| 22:57:05 | Matthias247 | flaviu: android seems to think different about that recently ;) |
| 22:57:15 | dom96 | shodan45: We use it in production for http://nim-lang.org/lib.html#nimble |
| 22:57:23 | dom96 | It works well I think. |
| 22:57:25 | Matthias247 | but maybe the main reason for ahead-of-time is startup time for them |
| 23:00:02 | flaviu | Matthias247: Looks like android has devirtualization: https://android.googlesource.com/platform/art/+/e3cd2f0 |
| 23:00:31 | * | sampwing joined #nim |
| 23:01:34 | Matthias247 | "Rough statistics show that we devirtualize using this change around 2.5% of |
| 23:01:35 | Matthias247 | the time, whilst some apps like GMS core devirtualize over 3.4% of the time." |
| 23:01:49 | Matthias247 | Seems like a minor win |
| 23:05:10 | * | Jehan_ quit (Quit: Leaving) |
| 23:05:37 | shodan45 | dom96: that page could probably use a separated-out .css file..... most of the source is actually css o_O |
| 23:06:40 | dom96 | shodan45: But then you need to make sure you keep two files around when you want to share documentation. |
| 23:06:52 | shodan45 | hm, true |
| 23:07:08 | shodan45 | noooooo...... aporia just crashed on me |
| 23:08:22 | * | mwbrown quit (Ping timeout: 240 seconds) |
| 23:09:21 | shodan45 | dom96: (aporia:6273): GLib-CRITICAL **: Source ID 6368 was not found when attempting to remove it |
| 23:09:30 | shodan45 | if that helps |
| 23:09:49 | dom96 | what were you doing when that happened? |
| 23:11:21 | shodan45 | dom96: just typing a for loop... after typing the 2nd "." in "for x in 0..", I got a weird message about not finding the nim compiler |
| 23:11:31 | shodan45 | I just hit escape or something |
| 23:11:36 | shodan45 | the poof |
| 23:11:38 | shodan45 | then* |
| 23:11:54 | dom96 | have you got suggest enabled? |
| 23:12:32 | shodan45 | dom96: looks like it |
| 23:12:48 | dom96 | disabling it should help |
| 23:14:29 | shodan45 | ok |
| 23:14:43 | shodan45 | I'll also be saving my work frequently ;) |
| 23:16:35 | * | Mat4-be_coding is now known as Mat4 |
| 23:16:48 | Mat4 | ciao |
| 23:17:10 | * | Mat4 quit (Quit: Verlassend) |
| 23:18:22 | * | matkuki quit (Quit: ChatZilla 0.9.91.1 [Firefox 35.0.1/20150122214805]) |
| 23:18:37 | * | superfunc quit (Ping timeout: 245 seconds) |
| 23:26:28 | * | sillesta quit (Ping timeout: 264 seconds) |
| 23:28:55 | * | sampwing quit (Ping timeout: 252 seconds) |
| 23:35:25 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 23:36:58 | * | gsingh93 joined #nim |
| 23:39:06 | * | Varriount|Mobile quit (Read error: Connection reset by peer) |
| 23:39:11 | * | Var|Mobile joined #nim |
| 23:39:49 | * | semperos quit (Ping timeout: 245 seconds) |
| 23:43:35 | * | Var|Mobile quit (Ping timeout: 252 seconds) |
| 23:53:29 | * | sampwing joined #nim |
| 23:56:57 | * | JinShil joined #nim |