| 00:00:17 | * | banister quit (Ping timeout: 250 seconds) |
| 00:04:01 | * | johnsoft joined #nim |
| 00:05:49 | Aszarsha | Hello everyone. I'm slowing introducing myself to Nim by using it for a few things at work. Can anyone tell me if this code (https://gist.github.com/Aszarsha/32c68e654d384e363c59) is idiomatic ? If not, what should I change ? Thank you. |
| 00:08:07 | dom96 | Aszarsha: don't put spaces after ( and before ) |
| 00:08:47 | dom96 | var files: seq[File] = @[] |
| 00:09:05 | dom96 | do put spaces before and after & |
| 00:09:47 | Aszarsha | Ho, yes, those spaces. They have been my personal signature for years :) |
| 00:09:47 | Aszarsha | Thank you ! |
| 00:10:03 | dom96 | I think the rest is fine. |
| 00:10:25 | epichero | haha FASTA, i think nim is a good choice for that actually |
| 00:11:50 | * | reem_ quit (Remote host closed the connection) |
| 00:12:00 | Aszarsha | One thing that I tried, is using the "for index, value" idiom for the lines and tokens, but was unable to do so. I guess it works for lists but not generator ? Is there a generator that does it ? I read the last few days of talk and at some point the case for return type overload was made. I think this overload (value vs. index,value) in for loop is a good candidate. |
| 00:12:11 | * | irrequietus quit () |
| 00:12:23 | def- | Aszarsha: by making "let inToken = split(...)" you create a seq, if you do "for token in split(...)" instead it's an iterator, which will take less memory and be faster |
| 00:13:19 | Aszarsha | def-: Yes, this is what I though, but then I lose the automatic index in the for loop, which is one more point of error... |
| 00:13:52 | Aszarsha | I searched for an generator/iterator withCount (or something similar) that would return the pair index,value but couldn't find it. |
| 00:14:13 | Aszarsha | Neither could I find a generator/iterator for the lines of the file |
| 00:14:31 | def- | pairs and lines iterators in system |
| 00:14:39 | def- | but pairs only works with seqs and related, not iterators |
| 00:15:54 | * | banister joined #nim |
| 00:16:13 | def- | i guess a pairs iterator that wraps other iterators would be a good idea |
| 00:16:34 | Aszarsha | def-: ha ! I'll try to write one then :) |
| 00:17:28 | Aszarsha | Is "pairs" really a good name though ? Somehow, it doesn't look obvious that pairs would return the index |
| 00:17:34 | * | reem joined #nim |
| 00:18:29 | * | johnsoft quit (Ping timeout: 250 seconds) |
| 00:18:47 | * | johnsoft joined #nim |
| 00:21:27 | EXetoC | "for i, x in stuff" invokes pairs. you need to invoke it explicitly? |
| 00:26:05 | * | epichero quit () |
| 00:26:06 | * | reem quit (Remote host closed the connection) |
| 00:26:19 | * | epichero joined #nim |
| 00:27:58 | flaviu | I like python's "enumerate" btw |
| 00:29:57 | * | arnetheduck joined #nim |
| 00:30:24 | * | reem joined #nim |
| 00:44:03 | Aszarsha | EXetoC: If I don't, I get: "Error: wrong number of variables" |
| 00:45:15 | flaviu | yep, invoking an iterator directly vs invoking it explicitly. |
| 00:45:26 | flaviu | err, implicitly |
| 00:45:32 | Aszarsha | This is weird... |
| 00:45:33 | Aszarsha | for line in file.lines(): works |
| 00:45:33 | Aszarsha | for lineNum, line in file.lines(): Error: wrong number of variables |
| 00:45:33 | Aszarsha | for lineNum, line in pairs( file.lines() ): Error: undeclared identifier: 'lines' |
| 00:47:04 | flaviu | for line in file.lines() invokes the lines() iterator, which returns "string". |
| 00:47:40 | flaviu | for lineNum, line in file.lines() invokes the lines operator, which returns "string". The for loop is asking for a "tuple[a:..., b: ...]" |
| 00:48:07 | Aszarsha | Well, I guess the problem is that there is no pairs( var it: iterator ) right (I'm not sure of the syntax) ? In that case, the error message is weird, no ? |
| 00:48:13 | flaviu | I'm not sure why "for lineNum, line in pairs( file.lines() )" gives that error, it'd expect "Error: undeclared identifier: 'pairs'" |
| 00:49:22 | flaviu | Yes, there is no pairs that takes an iterator. |
| 00:49:53 | flaviu | I'm not really sure of the syntax myself. |
| 00:51:55 | EXetoC | just count manually then |
| 00:52:13 | Aszarsha | Well, this is what I've been doing. :) |
| 00:55:16 | def- | the error with "undeclared identifier: 'lines'" is indeed weird |
| 00:56:34 | flaviu | .eval let iter = lines("/etc/passwd") |
| 00:56:38 | Mimbus | flaviu: eval.nim(3, 16) Error: expression 'lines' cannot be called |
| 00:56:46 | flaviu | right, that's an old compiler. |
| 01:02:44 | flaviu | .eval let iter = lines("/etc/passwd") |
| 01:02:44 | Mimbus | flaviu: /bin/sh: nim: command not found |
| 01:04:39 | * | saml_ joined #nim |
| 01:04:50 | flaviu | .eval let iter = lines("/etc/passwd") |
| 01:04:51 | Mimbus | flaviu: eval.nim(3, 16) Error: undeclared identifier: 'lines' |
| 01:04:52 | * | chrisheller quit (Remote host closed the connection) |
| 01:09:20 | Aszarsha | https://gist.github.com/Aszarsha/32c68e654d384e363c59 I can't get it to compile. nimrod.vim + syntastic tells me "internal error: transformVarSection" (but I expect nimrod.vim to be based on an old version of the compiler ?). the compiler (devel) still tells me "Error: undeclared identifier: 'lines'" |
| 01:13:07 | EXetoC | it uses whichever version is installed |
| 01:15:49 | * | banister quit (Ping timeout: 264 seconds) |
| 01:15:52 | Aszarsha | well, I get two different outputs from the command line compiler and nimrod.vim |
| 01:16:07 | flaviu | Aszarsha: nimrod.vim tells the compiler not to stop when it hits an error. |
| 01:16:24 | Aszarsha | I could make the program to compile by specifying {.inline.} for the parameter iterator |
| 01:17:32 | Aszarsha | flaviu: but the compiler failed at a line 14 while nimrod.vim reported an internal error at line 6 |
| 01:18:01 | Aszarsha | is the parsing multi-pass ? |
| 01:18:24 | flaviu | No, but there's a lot more to a compiler than parsing. |
| 01:18:31 | Aszarsha | sure |
| 01:19:07 | reactormonk | Aszarsha, I'm not sure if iterators are first-class yet |
| 01:19:40 | flaviu | they are first class, but they are confusing to use (also somewhat buggy) |
| 01:19:43 | Aszarsha | reactormonk: the manual says closure iterator are, while inline iterator can only be passed to other inline ones |
| 01:20:39 | Aszarsha | is there a way to specify inline and closure iterator for a parameter, something like {.inline. || .closure.} ? |
| 01:21:21 | Aszarsha | I can understand that an inline iterator can only be passed to another inline iterator, but there is no such restriction for a clorure iterator, right ? |
| 01:21:36 | flaviu | well, you can separate pragmas by a comma, but you can't change code you don't control (the stdlib in this case) |
| 01:22:32 | Aszarsha | well, I'll make a pull request for pairs(it: iterator) and mpairs(it: iterator) at least :) |
| 01:23:08 | flaviu | Did you get it to work? |
| 01:23:14 | reactormonk | Aszarsha, if it works, sure. Don't forget tests in tests/system/ |
| 01:23:43 | Aszarsha | yes it does, with {.inline.} parameter at least, I'll try with a {.closure.} one |
| 01:24:08 | reactormonk | Aszarsha, also if it works, you can kick the other pairs iterators if you yours is more general and also works for these cases |
| 01:24:16 | reactormonk | might not for all of them though |
| 01:25:56 | Aszarsha | I see pairs (and mpairs) for openArray, array, seq, string, and cstring in lib/system.nim. Are any of those auto convertible to iterator ? Is there such auto conversion in the first place ? |
| 01:26:32 | reactormonk | they are an iterator |
| 01:29:08 | Aszarsha | https://gist.github.com/Aszarsha/548ad265c2bed02fb675 All iterators have exactly the same code as the first, but the one for array. Is there any reason ? |
| 01:29:35 | * | darkf joined #nim |
| 01:29:56 | reactormonk | Aszarsha, what's different in the array? |
| 01:32:22 | * | gsingh93 quit (Ping timeout: 240 seconds) |
| 01:33:33 | Aszarsha | reactormonk: the use of low and high, but the infinite loop and break looks overkill. wouldn't for i < len(a); suffice with index being i+low(a) ? |
| 01:39:27 | reactormonk | Aszarsha, high(IX) can be statically determined, and is simpler on the type system than len(a) |
| 01:41:01 | EXetoC | if it's an array then surely len will be statically known |
| 01:42:16 | Aszarsha | Anyway, the code works, I better not touch it since it would need to be different (i+low(IX)) anyway :) Thank you for the help |
| 01:44:50 | reactormonk | Aszarsha, you only need the items iterator for pairs? |
| 01:47:10 | * | MyMind joined #nim |
| 01:47:51 | * | szatz joined #nim |
| 01:47:56 | * | gsingh93 joined #nim |
| 01:47:57 | * | BlaXpirit_ quit (Quit: Quit Konversation) |
| 01:48:34 | EXetoC | Aszarsha: I think high is just for convenience, and low is necessary because the index might not start at 0 for arrays |
| 01:48:59 | * | Sembei quit (Ping timeout: 245 seconds) |
| 01:50:37 | Aszarsha | Well, indices not starting a 0 is very... Let just say that Dijkstra would disagree :) |
| 01:52:22 | EXetoC | the user gets to decide for arrays, but the occurrence of non-zero indexing is probably rare |
| 01:53:56 | EXetoC | it's only for arrays so it's statically known |
| 01:54:11 | szatz | Hey, all. Not at all familiar with nim but I decided to browse the source a little. I'm not confident enough to send a PR myself (or know if this is really a problem), but line 36 of the following seems to be missing a comma after "T": https://github.com/Araq/Nim/blob/devel/compiler/canonicalizer.nim |
| 01:54:28 | Varriount | Meep |
| 01:57:36 | flaviu | szatz: Good catch, I have no idea how that got in. It doesn't even compile! |
| 01:57:41 | Aszarsha | The test suite fails for tdialogs.nim [reNimcCrash], twalker.nim [reNimcCrash], trecinca.nim [reMsgsDiffer], trecincb.nim [reMsgsDiffer], tfailedassert.nim [reOutputsDiffer], main.nim [reNimcCrash], trawsockets.nim [reNimcCrash], it is still running, and a few of them are [reIgnored]. Is this expected ? This is devel from 15 minutes ago (2f44729). |
| 01:58:12 | flaviu | unfortunately the test suite is in poor shape. |
| 01:58:28 | * | rzzz quit (Ping timeout: 255 seconds) |
| 02:00:31 | szatz | flaviu: No sweat. Pure chance that I saw it at all. |
| 02:05:24 | * | chrisheller joined #nim |
| 02:09:57 | * | chrisheller quit (Ping timeout: 252 seconds) |
| 02:18:04 | Aszarsha | I extract the exact pairs function that enabled me be compile my program and put it in lib/system.nim. Recompiled the compiler. And I get the same error as before: Error: undeclared identifier: 'lines'. If I put my function at the top of my program, it works. What am I doing wrong ? |
| 02:27:35 | flaviu | what happens when you add {.closure.} to the lines iterator? |
| 02:29:08 | * | mal`` quit (Ping timeout: 245 seconds) |
| 02:36:41 | * | mal`` joined #nim |
| 02:38:43 | * | szatz quit (Quit: Page closed) |
| 02:41:05 | * | rzzz joined #nim |
| 02:41:40 | * | Menche left #nim ("Leaving") |
| 02:41:43 | * | banister joined #nim |
| 02:44:18 | * | chemist69_ joined #nim |
| 02:47:21 | * | gsingh93 quit (Ping timeout: 252 seconds) |
| 02:47:21 | * | chemist69 quit (Ping timeout: 252 seconds) |
| 02:56:36 | Aszarsha | flaviu: I'll try that tomorrow, thank you |
| 02:57:08 | Aszarsha | good night all, thanks for your help |
| 03:06:38 | reactormonk | Araq, canonizer? |
| 03:06:51 | * | chrisheller joined #nim |
| 03:07:34 | reactormonk | https://en.wikipedia.org/wiki/Graph_canonization <- that stuff? |
| 03:11:11 | * | chrisheller quit (Ping timeout: 252 seconds) |
| 03:13:43 | * | pregressive joined #nim |
| 03:13:46 | * | chrisheller joined #nim |
| 03:31:22 | * | arnetheduck quit (Ping timeout: 240 seconds) |
| 04:07:20 | * | pregressive quit (Remote host closed the connection) |
| 04:12:49 | * | gsingh93 joined #nim |
| 04:15:43 | * | chrisheller quit (Ping timeout: 252 seconds) |
| 04:34:07 | * | chrisheller joined #nim |
| 04:45:57 | * | chrisheller quit () |
| 05:05:45 | * | TEttinger quit (Quit: Leaving) |
| 05:13:35 | * | reem quit (Ping timeout: 246 seconds) |
| 05:16:23 | * | bitcraft__ joined #nim |
| 05:19:37 | * | bitcraft_ quit (Ping timeout: 264 seconds) |
| 05:25:03 | * | reem joined #nim |
| 05:25:32 | * | Varriount quit (Read error: Connection reset by peer) |
| 05:31:31 | * | saml_ quit (Quit: Leaving) |
| 05:47:22 | * | gsingh93 quit (Ping timeout: 245 seconds) |
| 06:00:34 | * | banister quit (Ping timeout: 256 seconds) |
| 06:08:36 | * | reem quit (Remote host closed the connection) |
| 06:16:29 | * | reem joined #nim |
| 06:17:02 | * | gsingh93 joined #nim |
| 06:30:05 | * | TEttinger joined #nim |
| 06:45:11 | * | reem quit (Remote host closed the connection) |
| 06:45:49 | * | reem joined #nim |
| 07:10:17 | * | reem quit (Remote host closed the connection) |
| 07:15:51 | * | reem joined #nim |
| 07:25:42 | * | untitaker quit (Ping timeout: 245 seconds) |
| 07:25:45 | * | reem quit (Remote host closed the connection) |
| 07:26:17 | * | reem joined #nim |
| 07:31:09 | * | untitaker joined #nim |
| 07:36:20 | * | reem quit (Remote host closed the connection) |
| 07:39:04 | * | gsingh93 quit (Ping timeout: 265 seconds) |
| 07:49:19 | * | epichero quit () |
| 08:05:51 | * | reem joined #nim |
| 08:06:23 | * | epichero joined #nim |
| 08:18:57 | * | BlaXpirit joined #nim |
| 08:25:40 | * | epichero quit (Read error: Connection reset by peer) |
| 08:26:16 | * | epichero joined #nim |
| 08:34:48 | * | epichero quit (Read error: Connection reset by peer) |
| 08:35:15 | * | epichero joined #nim |
| 08:40:54 | Araq | szatz, reactormonk this file is not yet part of the compiler ;-) |
| 08:41:02 | Araq | Nim would have caught this typo |
| 08:43:40 | * | epichero quit (Remote host closed the connection) |
| 08:43:58 | * | epichero joined #nim |
| 08:51:46 | ekarlso | dom96: nope, that crashes too :( |
| 08:55:05 | * | ^aurora^ joined #nim |
| 09:04:43 | * | reem quit (Remote host closed the connection) |
| 09:17:11 | * | reem joined #nim |
| 09:18:47 | * | gokr quit (Quit: Leaving.) |
| 09:24:04 | * | davidhq joined #nim |
| 09:30:08 | * | xificurC joined #nim |
| 09:35:31 | * | BlaXpirit_ joined #nim |
| 09:35:39 | * | epichero quit (Remote host closed the connection) |
| 09:37:11 | * | rzzz quit (Ping timeout: 246 seconds) |
| 09:37:17 | * | BlaXpirit quit (Ping timeout: 252 seconds) |
| 09:52:59 | * | reem quit (Remote host closed the connection) |
| 09:59:52 | * | Matthias247 joined #nim |
| 10:02:16 | * | reem joined #nim |
| 10:02:44 | * | bcinman quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 10:07:24 | * | reem quit (Remote host closed the connection) |
| 10:08:32 | * | reem joined #nim |
| 10:09:00 | * | rzzz joined #nim |
| 10:13:27 | * | rzzz quit (Ping timeout: 250 seconds) |
| 10:17:21 | * | reem quit (Remote host closed the connection) |
| 10:19:52 | * | reem joined #nim |
| 10:21:16 | * | reem quit (Remote host closed the connection) |
| 10:27:45 | * | reem joined #nim |
| 10:36:32 | * | epichero joined #nim |
| 10:39:13 | * | rzzz joined #nim |
| 10:41:22 | * | epichero quit (Ping timeout: 255 seconds) |
| 10:43:38 | * | rzzz quit (Ping timeout: 246 seconds) |
| 10:43:51 | * | reem quit (Remote host closed the connection) |
| 10:51:08 | * | reem joined #nim |
| 11:10:59 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 11:32:53 | * | reem quit (Remote host closed the connection) |
| 11:39:21 | * | rzzz joined #nim |
| 11:43:47 | * | rzzz quit (Ping timeout: 252 seconds) |
| 11:44:19 | * | Trustable joined #nim |
| 12:07:13 | * | epichero joined #nim |
| 12:12:01 | * | epichero quit (Ping timeout: 252 seconds) |
| 12:18:00 | Aszarsha | hi everyone. ok, so my problem remains, I added a function to lib/system.nim, recompiled nim, and I still can't use the function (it's as if it did not exists). any idea ? |
| 12:18:21 | Araq | add a star? |
| 12:18:44 | Araq | (an "export marker") |
| 12:19:19 | ekarlso | Araq: is there goroutines or so in nim ? |
| 12:19:52 | Araq | ekarlso: we have spawn and coroutines in the form of "closure iterators" |
| 12:20:15 | ekarlso | Araq: spawn does a new thread I guess ? |
| 12:20:21 | Araq | no, it doesn't |
| 12:20:34 | Aszarsha | Araq: it's there already (I'm trying to write a pairs function for iterators, and basically copyed the pairs function that were already there) |
| 12:20:36 | Araq | it uses the thread pool |
| 12:20:47 | dom96 | ekarlso: try to figure out why it crashes |
| 12:20:57 | ekarlso | dom96: meh, I did :/ |
| 12:21:06 | ekarlso | dom96: should I try in gdb ? |
| 12:21:12 | dom96 | perhaps |
| 12:21:26 | ekarlso | lemme give it a shot ! |
| 12:25:00 | ekarlso | dom96: so, how to get useful info again in gdb :D |
| 12:25:47 | dom96 | hrm, it would be nice if you could reproduce it outside your app |
| 12:25:54 | dom96 | i.e. in asyncproc's isMainModule section |
| 12:25:58 | dom96 | then I could take a look |
| 12:26:14 | ekarlso | dom96: tmate + vim ?: ) |
| 12:27:16 | dom96 | would prefer to have it running on my PC :P |
| 12:27:22 | ekarlso | dom96: :p |
| 12:27:24 | ekarlso | sureo k |
| 12:27:31 | * | arnetheduck joined #nim |
| 12:28:15 | def- | ekarlso: compile with --debuginfo --linedir:on |
| 12:28:42 | def- | Aszarsha: i tried that as well, i think there's another problem there. |
| 12:29:41 | * | Etheco quit (Read error: Connection reset by peer) |
| 12:30:52 | Aszarsha | https://gist.github.com/Aszarsha/32c68e654d384e363c59 I described what I did exactly as comments in there |
| 12:32:03 | def- | i guess it's a problem with lines or inline iterators, i don't know |
| 12:33:03 | ekarlso | meh dom96 I can't get it to blow up using just asyncproc outside there :/ |
| 12:34:39 | Araq | Aszarsha: you cannot use inline iterators like this (and the compiler is way to lax about that for now) |
| 12:34:50 | Araq | they are inline, you cannot pass them around |
| 12:34:54 | ekarlso | dom96: tmate ? :d |
| 12:37:04 | Aszarsha | Araq: The manual says: "Inline iterators are second class citizens; They can be passed as parameters only to other inlining code facilities like templates, macros and other inline iterators." Even if lines is not inline, the only (documented) restriction if for passing inline iterator around, not closure one (which lines is, right ?) |
| 12:37:07 | dom96 | ekarlso: ok |
| 12:37:50 | Aszarsha | is it an error in the doc then ? I hope not, because the use case pairs(lines) seems pretty frequent to me |
| 12:39:20 | * | rzzz joined #nim |
| 12:39:54 | Aszarsha | furthermore, split (which I use a few lines below) is also a closure iterator (well, default type anyway) and it works there |
| 12:41:44 | * | ^aurora^ quit (Quit: Leaving.) |
| 12:41:49 | Araq | Aszarsha: I don't know yet if these bugs are easy enough to fix or I'll change the manual |
| 12:43:52 | * | rzzz quit (Ping timeout: 240 seconds) |
| 12:44:32 | Aszarsha | Araq: but the weirdest thing, really, is that if I declare those functions (inline pairs and mpairs for inline iterators) at the top of my extractFasta.nim file, everything works then! it doesn't only when I put them in lib/system.nim |
| 12:46:12 | Aszarsha | which is even weirder considering that I declare them as taking an inline iterator and neither lines nor split are... |
| 12:52:12 | ekarlso | tmate is so nice : p |
| 12:58:49 | dom96 | agreed |
| 13:01:52 | dom96 | Araq: It seems that threads have a bug when it comes to handling exceptions |
| 13:12:48 | * | rzzz joined #nim |
| 13:21:35 | * | banister joined #nim |
| 13:24:48 | Araq | dom96: maybe, but did you read the manual? |
| 13:25:03 | Araq | an uncaught exception shuts down the whole process |
| 13:25:20 | dom96 | well, the exception is caught |
| 13:25:40 | dom96 | it's doing something strange in the except block though |
| 13:25:52 | dom96 | it crashes after it is executed AFAICS |
| 13:29:04 | Araq | dom96: well report it then. :P |
| 13:29:21 | dom96 | Guess I need to try to reproduce it first |
| 13:39:18 | * | banister quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 13:51:08 | * | zipR4ND joined #nim |
| 13:51:36 | * | banister joined #nim |
| 13:53:15 | dom96 | I think it's more likely that I am doing something dangerous with threads |
| 13:53:20 | dom96 | because threadanalysis complains |
| 13:53:47 | dom96 | Araq: thoughts? https://gist.github.com/dom96/f208a9dc34fd6c1909c3 |
| 13:54:03 | dom96 | Am I allowed to put channels inside an array? |
| 13:58:17 | * | banister_ joined #nim |
| 13:58:52 | * | banister quit (Ping timeout: 252 seconds) |
| 13:59:30 | * | banister joined #nim |
| 14:02:30 | Araq | yeah but the compiler has a bug |
| 14:02:50 | * | banister_ quit (Ping timeout: 246 seconds) |
| 14:06:27 | dom96 | ahh ok |
| 14:06:37 | dom96 | well then I don't know why there is a crash when an exception happens in that thread |
| 14:09:33 | Araq | AsyncExecutor* = ref object |
| 14:09:35 | Araq | threads: array[1024, TThread[int]] # seriously? |
| 14:11:55 | * | zipR4ND quit (Ping timeout: 252 seconds) |
| 14:12:52 | dom96 | Araq: :P |
| 14:12:59 | EXetoC | strength in numbers |
| 14:14:54 | dom96 | Araq: care to give an alternative implementation? |
| 14:16:18 | Araq | don't put it into a 'ref' |
| 14:17:06 | dom96 | Is TThread required to be on the stack? |
| 14:18:04 | Araq | no, in a global |
| 14:20:47 | dom96 | ok |
| 14:20:50 | dom96 | ekarlso: ^ |
| 14:21:29 | ekarlso | what's wrong with that ? :/ |
| 14:24:27 | dom96 | there are too many of these little things which the compiler does not enforce at all for threads |
| 14:25:12 | * | zipR4ND1 joined #nim |
| 14:27:09 | Araq | well in theory TThread is allowed in a 'ref' but it has never been tested |
| 14:27:53 | Araq | and we created 'spawn' to get rid of explicit TThread creation |
| 14:28:01 | ekarlso | Araq: hmm, would it be possible to add like infinite loop check to the compiler ? :D |
| 14:28:07 | ekarlso | like rust has :P |
| 14:28:35 | Araq | ekarlso: sure, it's not hard |
| 14:28:47 | ekarlso | it would be nice to have for the playsite |
| 14:28:55 | ekarlso | the loop protection stuff is weird |
| 14:28:59 | Araq | but it doesn't solve your problem |
| 14:29:11 | ekarlso | Araq: what is my problem then ? multiple users ? |
| 14:29:14 | Araq | you need proper sandboxing as provided by the OS anyway |
| 14:29:25 | ekarlso | Araq: I got that with playpen |
| 14:29:41 | Araq | what's the problem then? |
| 14:29:52 | ekarlso | but for some weirdo reason the timeout set gets ignored or whatever when there's a while loop |
| 14:30:02 | ekarlso | dunno if it's due to too much output or what :/ |
| 14:30:46 | Araq | well I'm not willing to work on features only required to workaround playpen's bugs |
| 14:30:55 | ekarlso | Araq: meh-,,- |
| 14:31:10 | ekarlso | i tried to remedy that by killing the playpen process when output exceeds a maximum of lines but the compiler process is still left :p |
| 14:31:57 | ekarlso | wondering if LXC would be better :/ |
| 14:32:42 | ekarlso | Araq: any suggestions ? :p |
| 14:33:35 | * | reem joined #nim |
| 14:36:17 | * | pregressive joined #nim |
| 14:38:04 | * | reem quit (Ping timeout: 255 seconds) |
| 14:38:57 | Araq | just write a script that kills any process named 'nim_<id>' after 5 minutes |
| 14:39:53 | ekarlso | Araq: hmmm |
| 14:40:11 | ekarlso | I guess I could register a async thing no that runs every n seconds or smth ? :D |
| 14:43:31 | * | rkj-b joined #nim |
| 14:45:49 | Araq | I never expected to say this but: |
| 14:46:00 | Araq | stop doing *everything* in Nim |
| 14:46:13 | EXetoC | ekarlso: and you? do you write nim code for $$ yet? |
| 14:46:17 | Araq | in particular a watchdog HAS to be in separate process |
| 14:46:26 | Araq | stop with async and threads |
| 14:46:50 | Araq | it's pointless anyway since you need to run *processes* anyway |
| 14:47:24 | Araq | use a decent server that supports scgi or cgi and then keep it simple |
| 14:49:05 | Araq | again, serving more than a single user is a solved problem. Even the CGI protcol that's been invented right after the byte can do that. |
| 14:50:32 | Araq | use apache or nginx or *any* server out there and call it day please |
| 14:50:59 | * | banister_ joined #nim |
| 14:51:03 | * | banister_ quit (Max SendQ exceeded) |
| 14:51:12 | EXetoC | what does the program do? |
| 14:52:07 | * | banister quit (Read error: Connection reset by peer) |
| 14:52:07 | * | banister_ joined #nim |
| 14:52:11 | * | banister_ quit (Max SendQ exceeded) |
| 14:52:21 | Araq | EXetoC: it takes a Nim snippet and compiles and runs it via the nim compiler |
| 14:53:59 | * | banister joined #nim |
| 14:54:11 | * | banister quit (Max SendQ exceeded) |
| 15:00:56 | dom96 | Araq: CGI is old and deprecated |
| 15:01:32 | dom96 | what we need is a proper asyncproc implementation |
| 15:01:40 | flaviu | dom96: I see no mention of "deprecated" on http://en.wikipedia.org/wiki/Common_Gateway_Interface |
| 15:06:17 | Araq | dom96: we don't need a proper asyncproc implementation for ekarlso's use case |
| 15:06:31 | * | banister joined #nim |
| 15:07:02 | * | ^aurora^ joined #nim |
| 15:07:06 | Araq | threads and async are about removing the overhead of multi-processing |
| 15:07:27 | Araq | but that's what he cannot avoid at all |
| 15:07:29 | dom96 | ekarlso will need to rewrite quite a lot of things to use CGI |
| 15:07:47 | dom96 | but sure. It may work better. |
| 15:08:01 | * | epichero joined #nim |
| 15:09:11 | dom96 | I still think the threading issues deserve further investigation though |
| 15:11:35 | ekarlso | EXetoC: nope :( |
| 15:11:46 | EXetoC | that sucks |
| 15:12:26 | * | epichero quit (Ping timeout: 246 seconds) |
| 15:13:00 | * | matkuki joined #nim |
| 15:13:54 | NhanH | In procedure, did the behaviour that return the `result` variable by default changed? |
| 15:14:06 | NhanH | right now, it seems like without explicitly return, the result variable isn't returned |
| 15:15:27 | dom96 | NhanH: nope, that didn't change. |
| 15:15:28 | * | yibter joined #nim |
| 15:15:49 | flaviu | NhanH: Are you shadowing result? |
| 15:16:07 | flaviu | only the compiler-generated result gets impciltly returned. |
| 15:16:37 | NhanH | here is the gist for the proc: https://gist.github.com/anonymous/a1037b563d3dd381cf15 |
| 15:16:40 | NhanH | is that shadowing? |
| 15:16:51 | ekarlso | Araq: still I wonder how that would help with playpen issues ... |
| 15:16:54 | ekarlso | for isolation |
| 15:17:03 | flaviu | NhanH: Yep. Just delete line 2 completely. |
| 15:17:12 | NhanH | flaviu: okay thanks! |
| 15:17:44 | flaviu | NhanH: Also, I don't think those type parameters are doing what you expect. |
| 15:17:46 | fowl | Araq, if i have a when block inside an object def it causes getType to return an empty tree |
| 15:18:11 | flaviu | do s/, float]/]/ |
| 15:19:15 | NhanH | yeah the first float is redundant |
| 15:19:29 | NhanH | originally it was proc `*`* [r, T] (a,b : array[r,T]): T |
| 15:19:48 | * | gokr joined #nim |
| 15:19:54 | NhanH | but I then need to initialized the generic result somehow ... and I don't know how yet, so I changed it to float |
| 15:20:01 | flaviu | yes, but using "float" instead of "T" makes no difference. |
| 15:20:34 | flaviu | you're just using a generic named "float" |
| 15:20:39 | * | banister quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 15:20:44 | NhanH | yeah that's true |
| 15:21:11 | EXetoC | is shadowing result supposed to be allowed? |
| 15:21:31 | flaviu | EXetoC: Yes, but it's a warning in the latest devel. |
| 15:21:52 | EXetoC | that's good enough |
| 15:22:27 | fowl | should be an error imo |
| 15:24:13 | EXetoC | I'd prefer that actually |
| 15:27:07 | EXetoC | fowl: you asked me some time ago about creating a new project, right? a game was it? |
| 15:29:06 | * | darkf quit (Quit: Leaving) |
| 15:29:24 | Aszarsha | if I were to take a look at this issue: https://github.com/Araq/Nim/issues/2212, where should I start looking ? |
| 15:30:33 | Araq | Aszarsha: name mangling for the C(++) backend is done in compiler/ccgutils.nim |
| 15:30:45 | Aszarsha | Araq: ok, thank you :) |
| 15:31:10 | reactormonk | Aszarsha, I guess both variables are mangled to lowercase, gotta change that |
| 15:32:21 | dom96 | fowl: as long as there is a way to override that error |
| 15:32:23 | EXetoC | has anyone attempted to bind Qt yet? |
| 15:32:28 | dom96 | some code depends on this shadowing |
| 15:33:07 | EXetoC | deprecate that functionality then |
| 15:33:24 | def- | EXetoC: I've only seen the qml stuff |
| 15:33:24 | fowl | since it has to be returned manually i dont believe that |
| 15:33:47 | EXetoC | def-: can one do with just qml? |
| 15:33:53 | def- | http://forum.nim-lang.org/t/692 |
| 15:34:06 | EXetoC | and the associated initialization routines of course |
| 15:35:26 | EXetoC | hopefully it'll be stable somewhere around 1.0 |
| 15:36:18 | EXetoC | is the realistic ETA < 2016? :-) |
| 15:37:48 | ekarlso | :P |
| 15:40:02 | * | epichero joined #nim |
| 15:40:16 | Araq | fowl: want to write a 'print' macro that is as close to python as reasonable? |
| 15:40:52 | dom96 | Araq: isn't that just echo but with spaces between params? |
| 15:40:53 | EXetoC | I hope I'm not annoying anyone. I'm not that impatient actually :p |
| 15:41:51 | Araq | EXetoC: hrm? |
| 15:42:10 | Araq | dom96: python's print is full of special syntax |
| 15:42:21 | Araq | but I guess they removed all that for python 3 |
| 15:42:24 | BlaXpirit_ | you mean "was"? |
| 15:42:35 | dom96 | Araq: example? |
| 15:42:52 | Araq | print >>stderr, foo, endl=" " |
| 15:42:59 | EXetoC | gradha's string interpolation macro would come in handy too |
| 15:43:04 | Araq | or similar, never used it |
| 15:43:37 | BlaXpirit_ | there is no reason to use it |
| 15:44:13 | dom96 | somebody should finish this printf macro https://github.com/Araq/Nim/issues/1152 |
| 15:44:30 | BlaXpirit_ | why? |
| 15:44:46 | EXetoC | echof? |
| 15:44:47 | BlaXpirit_ | just get good string formatting |
| 15:44:58 | BlaXpirit_ | and there does seem to be a good library |
| 15:45:00 | def- | I also think that we need a nice way of printing complex data, but i'm not sure if we need to emulate C or Python |
| 15:45:16 | EXetoC | strfmt? |
| 15:45:20 | BlaXpirit_ | strfmt |
| 15:45:32 | def- | *in the standard library |
| 15:45:33 | Araq | BlaXpirit_: btw I plan a -d:progress switch. if enabled negative slices fail at compiletime or we cannot detect that, at runtime |
| 15:45:40 | * | ChrisMAN quit (Remote host closed the connection) |
| 15:45:42 | Araq | *or if |
| 15:45:51 | BlaXpirit_ | what does "progress" stand for? o.o |
| 15:46:10 | Araq | progress in Nim's design |
| 15:46:13 | Araq | ;-) |
| 15:46:20 | BlaXpirit_ | i'd rather have a "stagnation" switch |
| 15:46:31 | BlaXpirit_ | cuz nobody's gonna use this flag and fall for all the problems anyway |
| 15:46:35 | dom96 | what? |
| 15:46:41 | Araq | well you need to enable it for 0.10.4 |
| 15:46:42 | dom96 | s[5 .. -1] will stop working? |
| 15:46:52 | Araq | it will be default for the version after that |
| 15:46:56 | BlaXpirit_ | cool |
| 15:47:01 | Araq | and will be removed the version after that |
| 15:47:21 | Araq | dom96: yes |
| 15:47:30 | BlaXpirit_ | much like python, but i still think these compiler switches need to be available for each file separately |
| 15:47:36 | BlaXpirit_ | i.e. exactly like python does it :| |
| 15:47:51 | Araq | BlaXpirit_: but it's affecting the runtime |
| 15:48:03 | BlaXpirit_ | i imagine it's damn difficult or impossible |
| 15:48:03 | dom96 | Araq: Why? |
| 15:48:07 | dom96 | Araq: Most of my code uses this. |
| 15:48:30 | BlaXpirit_ | well then it's probably bugged |
| 15:48:47 | BlaXpirit_ | at least somewhere |
| 15:49:15 | Araq | dom96: I plan something like s[5 .. ^1] |
| 15:49:24 | Araq | that you can use instead |
| 15:49:32 | dom96 | Araq: I'm tired of changing hundreds of lines of code. |
| 15:49:50 | dom96 | what does this gain us? |
| 15:49:58 | BlaXpirit_ | dom96, are u serious... |
| 15:50:04 | BlaXpirit_ | i explained the bug enough times |
| 15:50:27 | * | ekarlso quit (Changing host) |
| 15:50:27 | * | ekarlso joined #nim |
| 15:50:37 | BlaXpirit_ | not a bug in some particular place, but a bug that will be common, recurring if current design stays |
| 15:50:45 | BlaXpirit_ | in people's code, that is |
| 15:51:08 | EXetoC | yeah, why have a print clone? |
| 15:51:27 | BlaXpirit_ | there is no need for any print functions |
| 15:51:36 | BlaXpirit_ | except one |
| 15:51:49 | BlaXpirit_ | that allows you to just output a string you give it |
| 15:52:02 | EXetoC | and I'd rather build a string than call stdout.write multiple times |
| 15:52:23 | dom96 | This is the relevant issue right? https://github.com/Araq/Nim/issues/1979 |
| 15:52:29 | BlaXpirit_ | yes |
| 15:52:53 | dom96 | Then why is there no mention of this decision there? |
| 15:53:23 | BlaXpirit_ | because discussion is scattered across multiple places, of course |
| 15:54:09 | * | ChrisMAN joined #nim |
| 15:54:18 | BlaXpirit_ | the decision was likely made on 17 january |
| 15:54:28 | BlaXpirit_ | or 18 |
| 15:55:59 | dom96 | ahh. So the discussion on the relevant issue was completely ignored. Nice. |
| 15:56:28 | Araq | I'm only a human being, I'm not perfect, sometimes I make up my mind and don't tell github |
| 15:56:34 | EXetoC | including IRC of course, where things get lost |
| 15:56:43 | BlaXpirit_ | this was 95% irc |
| 15:56:45 | ekarlso | Araq: you're Araq the compiler writing machine :p |
| 15:56:53 | EXetoC | well there you go |
| 15:57:23 | * | yibter quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 15:57:46 | BlaXpirit_ | EXetoC, why are you asking about Qt? any ideas? news? |
| 15:58:25 | Araq | dom96: in addition to being bug prone, negative indexing is also a pita to support for the 'parallel' statement |
| 15:58:40 | Araq | and I never really liked it tbh |
| 16:00:15 | dom96 | I think you should implement proper slicing instead |
| 16:00:16 | EXetoC | the -1 exception seemed reasonable because of how indexing in nim works |
| 16:00:26 | dom96 | ala python |
| 16:01:03 | Aszarsha | Araq: what was the rational behind lowercasing the variable names ? |
| 16:01:17 | EXetoC | and if that's the only change then won't some things become less convenient? I'll re-read the discussions though and hope that all the relevant information is there |
| 16:01:23 | * | Matthias247 joined #nim |
| 16:01:58 | EXetoC | BlaXpirit_: I just wanted to know what was new, since I hadn't been active for some time |
| 16:03:30 | dom96 | Araq: can we have both `..` and `...`? |
| 16:03:45 | EXetoC | x[-1 .. -1] will throw? assuming that they are runtime values |
| 16:04:10 | BlaXpirit_ | dom96, do you mean a different type of slices? |
| 16:04:29 | dom96 | yes |
| 16:04:55 | BlaXpirit_ | first of all, it's a ton of useless work to duplicate every operation on slices |
| 16:05:00 | BlaXpirit_ | and it doesn't gain you much anyway, because all standard library uses inclusive indices |
| 16:05:26 | dom96 | It gains me tons of expressivity when working with strings. |
| 16:05:45 | BlaXpirit_ | well currently you mustn't use slices on strings |
| 16:05:56 | BlaXpirit_ | because of what we just mentioned |
| 16:06:09 | dom96 | yeah, which is why I recommend we introduce `...` which will work differently. |
| 16:06:16 | BlaXpirit_ | but then you'll want to use a some method on strings |
| 16:06:20 | BlaXpirit_ | and get confused as heck |
| 16:06:32 | dom96 | what? |
| 16:06:41 | dom96 | You mean use `..`? |
| 16:07:09 | dom96 | We can do what Araq already wants to do and disallow negative indices for that. |
| 16:08:43 | BlaXpirit_ | hm actually there are not as many functions that use indices as i thought |
| 16:09:00 | EXetoC | so, must an if/else pair be used if one wants to possibly yield an empty slice? |
| 16:09:07 | * | Jesin joined #nim |
| 16:09:10 | BlaXpirit_ | but look, after this change you can trivially make a ... or ..< or whatever you want |
| 16:09:18 | BlaXpirit_ | EXetoC, yeah |
| 16:10:44 | dom96 | Well. I want it to work the same way as Pythons `:`. |
| 16:10:54 | EXetoC | and you did not approve of x[-1 .. -1] -> []? |
| 16:10:59 | dom96 | So [1,2,3,4][0 ..] should yield the full list. |
| 16:12:05 | dom96 | implementing that will need compiler support I think |
| 16:12:13 | EXetoC | x[x.low .. x.find(y)] |
| 16:12:44 | BlaXpirit_ | EXetoC pls |
| 16:13:53 | BlaXpirit_ | dom96, you might be able convince Araq to make "^" be len just as "^1" is len-1 |
| 16:14:08 | BlaXpirit_ | then [0 .. ^] is not so bad |
| 16:14:17 | * | ^aurora^ quit (Quit: Leaving.) |
| 16:14:23 | * | arnetheduck quit (Ping timeout: 252 seconds) |
| 16:14:26 | BlaXpirit_ | and [.. n] is prefix so it's doable |
| 16:14:39 | BlaXpirit_ | but it's just rambling, i dont actually think this is important enough |
| 16:14:54 | Aszarsha | on the subject of ranges, Dijkstra was very clear that the only reasonable way to express them is [0, n[. it sure is a strong opinion, but he gives very good arguments imho: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html |
| 16:14:56 | dom96 | I guess that could work. |
| 16:15:15 | EXetoC | it's weird to me because of the fact that 'low' might yield -1 |
| 16:15:28 | EXetoC | I'm sure you'll be able to agree on a solution that doesn't suck. later |
| 16:15:40 | * | gokr quit (Quit: Leaving.) |
| 16:18:04 | * | saml_ joined #nim |
| 16:18:14 | * | comex quit (Quit: WeeChat 0.4.3) |
| 16:18:37 | * | comex joined #nim |
| 16:18:45 | * | banister joined #nim |
| 16:19:02 | * | BlaXpirit joined #nim |
| 16:19:47 | * | comex left #nim (#nim) |
| 16:23:43 | * | rkj-b quit (Quit: ChatZilla 0.9.91.1 [Firefox 36.0.1/20150305021524]) |
| 16:23:50 | EXetoC | did we not have quote buttons in the forum at some point? |
| 16:26:47 | dom96 | nope |
| 16:29:21 | * | epichero quit (Remote host closed the connection) |
| 16:30:37 | * | epichero joined #nim |
| 16:35:13 | * | epichero quit (Ping timeout: 264 seconds) |
| 16:37:16 | * | Trustable quit (Remote host closed the connection) |
| 16:47:09 | BlaXpirit | pascal has qt bindings |
| 16:47:14 | BlaXpirit | this gives hope |
| 16:47:28 | BlaXpirit | i dont understand how they evaded moc |
| 16:48:52 | EXetoC | do I only have write access to certain repos? If so, can I get write access to all bindings and such in nim-lang? |
| 16:49:11 | * | matkuki quit (Quit: ChatZilla 0.9.91.1 [Firefox 35.0.1/20150122214805]) |
| 16:58:37 | * | bcinman joined #nim |
| 16:59:15 | EXetoC | or just cairo |
| 17:08:23 | * | ^aurora^ joined #nim |
| 17:11:20 | Araq | Aszarsha: not that again. Dijkstra was wrong. get over it. |
| 17:11:42 | Araq | exlusive bounds only work when you have a last element that you don't care about |
| 17:17:24 | reactormonk | EXetoC, you ask the owners of the repo |
| 17:23:13 | * | pregressive quit (Ping timeout: 264 seconds) |
| 17:26:58 | * | pregressive joined #nim |
| 17:27:06 | * | gmpreussner|work quit (Read error: Connection reset by peer) |
| 17:27:52 | * | gmpreussner|work joined #nim |
| 17:29:39 | * | saml_ quit (Ping timeout: 244 seconds) |
| 17:30:03 | * | MyMind quit (Max SendQ exceeded) |
| 17:30:05 | * | saml_ joined #nim |
| 17:31:13 | * | MyMind joined #nim |
| 17:31:26 | * | epichero joined #nim |
| 17:32:08 | EXetoC | Araq: do you think that "x[0 .. -1] -> []" would make sense? |
| 17:32:22 | EXetoC | I do, because of how iterating through a slice works |
| 17:32:48 | Araq | EXetoC: it makes some sense but people expect it to mean "all of x" |
| 17:34:32 | * | BlaXpirit quit (Ping timeout: 246 seconds) |
| 17:35:10 | Aszarsha | Araq: fair enough |
| 17:35:20 | * | banister quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 17:35:56 | * | epichero quit (Ping timeout: 246 seconds) |
| 17:39:00 | * | epichero joined #nim |
| 17:41:04 | flaviu | Araq: Have you seen the first remark in that paper? Dijkstra also has a bit of experimental evidence. |
| 17:41:33 | Araq | flaviu: he completely ignores the fact that Pascal and Ada have strong type systems |
| 17:41:46 | Araq | where enum is not an int |
| 17:45:26 | * | epichero quit (Remote host closed the connection) |
| 17:45:27 | flaviu | I don't understand how enums not being ints is related here. |
| 17:46:01 | flaviu | Also, Mesa *seems* to have enums |
| 17:46:29 | Araq | well Mesa also has all 4 interval types |
| 17:46:43 | Araq | he's simply wrong about this issue. |
| 17:46:52 | Araq | even a Dijkstra can be wrong. |
| 17:47:05 | flaviu | "Extensive experience with Mesa has shown that the use of the other three conventions has been a constant source of clumsiness and mistakes, and on account of that experience Mesa programmers are now strongly advised not to use the latter three available features" |
| 17:47:35 | Araq | so you think Mesa programmers are encouraged to use the equivlent: |
| 17:48:05 | Araq | for i in low(enum).. < enum(high(enum).ord + 1) ? |
| 17:48:15 | Araq | whom are you kidding here |
| 17:49:14 | Araq | btw the above might not even be defined and trigger a compiletime or runtime error |
| 17:49:30 | Araq | as the enum clearly has no element beyond its last element |
| 17:54:28 | Araq | EXetoC: btw I did use the mongo wrapper. so I don't think it should be deleted. |
| 17:54:59 | Araq | I didn't use every feature of the wrapper, but it used to work well enough. cannot speak about its current state though |
| 17:55:16 | Araq | but either way it seems wrong to hide it |
| 17:55:31 | Araq | somebody will come along and clone and maintain it |
| 17:55:44 | Araq | er I mean "fork", not clone |
| 17:56:27 | EXetoC | I assume you mean the one that was in the standard distribution, which was broken |
| 17:57:16 | EXetoC | it'd just be nice if the libs were held to high standards, but it's up to you |
| 17:57:36 | EXetoC | I'll try to work on it, but I've said that many times already |
| 17:58:24 | Araq | just make a note in its description that you like some other guy to take over |
| 17:59:00 | * | gsingh93 joined #nim |
| 18:01:29 | flaviu | hmm, Mesa seems somewhat similar to Nim. |
| 18:03:11 | EXetoC | I think dom96 agreed that it was outside the scope of the organization anyway, but I'll do that if I haven't bothered to fix it within a few days |
| 18:07:30 | * | saml_ quit (Quit: Leaving) |
| 18:10:59 | flaviu | Araq: If I understand the Mesa spec correctly, `for i in myenum do` should work. |
| 18:11:53 | Aszarsha | Araq: in the compiler, I see code like "result.add(name[0])" but also "add(result, c)". what is the convention you'd better see respected when making changes ? |
| 18:16:56 | * | banister joined #nim |
| 18:17:07 | * | banister quit (Max SendQ exceeded) |
| 18:17:38 | Aszarsha | my question is applicable to anyone used to work with the compiler code too :) |
| 18:18:54 | * | reem joined #nim |
| 18:20:11 | * | vendethiel quit (Quit: q+) |
| 18:22:43 | flaviu | Aszarsha: I haven't done much on the compiler, but much of the code that you see is machine-converted from pascal to Nim |
| 18:26:08 | Aszarsha | flaviu: I'm sorry, I don't know Pascal that well. how does it help me with this question ? :) |
| 18:29:31 | flaviu | Machine-generated code is not usually idiomatic code. The best guess I have for "add(result, c)" is that the conversion program didn't bother use prefix notation. |
| 18:32:42 | Araq | Aszarsha: flaviu is right, use result.add(c) if you feel like it |
| 18:33:15 | EXetoC | or "result.add c" |
| 18:33:28 | EXetoC | "add result, c" :p |
| 18:33:41 | Araq | flaviu: that doesn't really solve the problem: for x in someValue..high(enum), for x in 'A'..'Z' etc. |
| 18:34:57 | flaviu | Araq: that'd be `for x in [someValue..LAST[Enum] do` and `for x in ['A..'Z] do` |
| 18:35:16 | flaviu | oops, forgot a closing bracket on LAST[Enum] |
| 18:35:26 | Aszarsha | actually, I prefer add(result, c) myself, I don't fancy much universal calling syntax, but it might be because I'm not used to it. anyway, this is why I asked |
| 18:35:41 | Araq | flaviu: oh come on now. you argue only [a..b) is required |
| 18:35:57 | Araq | and that [a..b) should be used universally in Mesa |
| 18:36:06 | Araq | but that's clearly wrong. |
| 18:36:54 | Araq | there is a point when you have to accept that even geniuses can be wrong at times |
| 18:38:01 | * | goobles joined #nim |
| 18:38:47 | Aszarsha | What about specifying the bounds, with [0, n-1] and [0, n[ or [0, n) (replace ',' with '..' if better) ? it's more verbose, but the intent is clear |
| 18:39:05 | EXetoC | Aszarsha: I think it improves readability when calls are chained |
| 18:39:38 | flaviu | I suppose my opinion is somewhat more pragmatic than Dijkstra's. I think it's best when exclusive upper bounds are used, but I'm not really against using inclusive upper bounds if the problem calls for it. |
| 18:39:53 | Aszarsha | EXetoC: sure, actually I like the minimalist of Lua, and even they added the ':' syntax for "method call" :) |
| 18:41:02 | EXetoC | that's nice too |
| 18:41:44 | EXetoC | I just use moonscript nowadays |
| 18:42:37 | * | johnsoft quit (Ping timeout: 250 seconds) |
| 18:43:57 | * | johnsoft joined #nim |
| 18:44:04 | Araq | Aszarsha: well simplicity demands to use one version universally. And **only** [a..b] is universally usable. |
| 18:44:32 | Araq | so there, Dijkstra is right in a way but he picked the wrong interval type |
| 18:44:50 | Araq | as [a..b) doesn't work |
| 18:44:55 | flaviu | Araq: What if I want 0 elements? |
| 18:45:12 | Araq | flaviu: a..a-1 ? |
| 18:46:16 | * | epichero joined #nim |
| 18:46:25 | flaviu | But then there's the whole problem with -1 meaning last element. |
| 18:47:23 | EXetoC | ? |
| 18:47:42 | EXetoC | at the moment you mean? |
| 18:49:16 | * | Demon_Fox joined #nim |
| 18:50:03 | Aszarsha | Araq: well, you two (Dijkstra and youself) have strong opinions at least, that's for sure ;) |
| 18:50:53 | * | epichero quit (Ping timeout: 246 seconds) |
| 18:51:21 | Araq | flaviu: that's completely natural. |
| 18:51:39 | Araq | var i = 0 |
| 18:51:46 | Araq | while i <= -1: |
| 18:51:49 | Aszarsha | Araq: quite frankly, a..a-1 looks like a hack to me, at the very minimum an ad hoc solution. |
| 18:51:53 | Araq | iterates 0 times. |
| 18:52:13 | Araq | Aszarsha: see above. it's how math works. |
| 18:53:04 | Araq | if it were a hack, it would require special casing |
| 18:53:08 | Araq | but it doesn't |
| 18:53:23 | BlaXpirit_ | (actually, currently it does) |
| 18:53:29 | Aszarsha | Araq: I still have to see one math paper that would define such an ill defined set [b, a], a<b... |
| 18:53:59 | Araq | Aszarsha: so? I still have to see one math paper that sums from 0 to N but exclusively. |
| 18:54:07 | EXetoC | x.high |
| 18:54:08 | Araq | they all do from 0 to N-1 |
| 18:54:16 | Araq | or from 1 to N. |
| 18:55:21 | Aszarsha | Araq: you're right, and it seems to me that it basically invalidates the "it's how math works" argument. |
| 18:57:20 | * | ^aurora^ quit (Quit: Leaving.) |
| 18:58:28 | dom96 | Araq: what do you think about my proposal? |
| 18:58:58 | Aszarsha | I initially thought that [0, n) was universal enough, but you have very good arguments why it's not. It seems to me that there are equally good arguments why [0, n] wouldn't be enough either. |
| 18:59:14 | flaviu | Why not have both! |
| 18:59:57 | BlaXpirit_ | let me tell you why |
| 19:00:08 | EXetoC | here we go |
| 19:00:14 | BlaXpirit_ | because libraries will pick an arbitrary behavior for the functions |
| 19:01:01 | flaviu | BlaXpirit_: type a, b: int, inclusiveUpper: bool |
| 19:01:14 | BlaXpirit_ | whenever using slices doesn't make sense and you pass just one index, one library will make it an inclusive index, and the other will make it an exclusive index |
| 19:01:41 | BlaXpirit_ | (not that this isn't what's already happening, because sensible libraries pick sensible exclusive index over consistency with the language) |
| 19:02:00 | EXetoC | that's not the author's fault? |
| 19:02:11 | * | epichero joined #nim |
| 19:02:40 | Aszarsha | BlaXpirit_: a 'range' type actually solves the problem and is actually give the exact intent |
| 19:02:46 | * | vendethiel joined #nim |
| 19:02:56 | BlaXpirit_ | it solves the problem when there is a start and an end |
| 19:03:18 | BlaXpirit_ | what if a function is only concerned with the end |
| 19:03:34 | BlaXpirit_ | you make a slice garbage..end? |
| 19:03:38 | dom96 | then the function will assume what the start is |
| 19:03:49 | * | TEttinger quit (Ping timeout: 264 seconds) |
| 19:03:50 | Aszarsha | well, len( array ) is there, isn't it ? |
| 19:04:16 | dom96 | the idea of a 'range' type is a good one |
| 19:04:21 | Aszarsha | furthermore, either you require a range on which you can iterate, or a specific index |
| 19:04:28 | dom96 | we already have a range type in Nim though |
| 19:04:46 | Aszarsha | it seems that this is two semantically different cases |
| 19:07:56 | BlaXpirit_ | gee, i'm having such hard time coming up with an example that it really starts to seem like what I just said is unimportant |
| 19:17:50 | Aszarsha | dom96: if your suggestion is about having '..' and '...', from a notation standpoint it's very error prone imho |
| 19:18:28 | dom96 | Aszarsha: I agree. I would prefer going full Python and using ':' instead but I doubt Araq would like that. |
| 19:18:45 | flaviu | Why not just have [) and []? |
| 19:19:11 | flaviu | "abc"[0,1) |
| 19:19:19 | Aszarsha | flaviu: i think it's the best :) |
| 19:19:20 | flaviu | err, "abc"[[0,1)] |
| 19:19:21 | EXetoC | does that not break the context-insensitivity? |
| 19:20:04 | dom96 | that looks weird |
| 19:20:20 | Aszarsha | flaviu: why the double indexing ? |
| 19:20:25 | BlaXpirit_ | messing with brackets like this has so many disadvantages |
| 19:20:25 | dom96 | too many brackets |
| 19:20:57 | flaviu | Aszarsha: It's a subscript operator with a range inside it. |
| 19:21:16 | BlaXpirit_ | looks bad too |
| 19:21:34 | Aszarsha | yes, but a sequence followed by a range doesn't make any other sence that "index the sequence with the range" |
| 19:21:46 | Aszarsha | There is no ambiguity from a parsing standpoint |
| 19:22:07 | Aszarsha | It's true that it include an implicit subscript call |
| 19:22:34 | flaviu | I'm not a big fan of implicitly doing things. |
| 19:23:06 | flaviu | https://gist.github.com/dadca9f19629fa075091 is what I'm thinking for the BNF. |
| 19:23:38 | * | Trustable joined #nim |
| 19:23:58 | * | TEttinger joined #nim |
| 19:24:04 | dom96 | I would prefer to introduce "abc"[0:1] instead. |
| 19:24:07 | Araq | oh come on, are you stupid? we already have .. < and it works really well |
| 19:24:19 | Araq | a[0.. < N] |
| 19:24:30 | Araq | clear, concise, and scales to libraries |
| 19:24:36 | Araq | foo(a, i, < N) |
| 19:24:51 | flaviu | Again, the whole -1 == end of slice thing. |
| 19:25:23 | dom96 | Araq: Let's not resort to ad hominem attacks. |
| 19:25:47 | * | Matthias247 quit (Quit: Matthias247) |
| 19:25:51 | Araq | well that's there is to say about this topic. I'm out. |
| 19:26:29 | dom96 | Araq: What are your thoughts about copying Python's syntax and semantics? |
| 19:26:44 | EXetoC | get it on the record if it's worth saying by contributing to the thread |
| 19:26:53 | BlaXpirit_ | he just said all the thoughts |
| 19:26:57 | flaviu | .eval import macros; dumpTree:; "123"[1:-2] |
| 19:26:59 | Mimbus | flaviu: StmtList |
| 19:27:18 | flaviu | .eval import macros; dumpLisp:; "123"[1:-2] |
| 19:27:19 | Mimbus | flaviu: StmtList(BracketExpr(StrLit(123), Infix(Ident(!":-"), IntLit(1), IntLit(2)))) |
| 19:27:29 | EXetoC | and then someone starts arguing again and some things have to be repeated |
| 19:28:03 | flaviu | Python's syntax seems good, although whatever macro does it is going to have to do some parse rewriting. |
| 19:28:15 | dom96 | .eval import macros; dumpTree:; "123"[1:] |
| 19:28:16 | Mimbus | dom96: eval.nim(5, 10) Error: expression expected, but found ']' |
| 19:28:25 | dom96 | The compiler will need to be modified for it. |
| 19:28:57 | * | Matthias247 joined #nim |
| 19:29:27 | BlaXpirit_ | is this what we're gonna get? "123"[1 .. < ^1] |
| 19:30:37 | flaviu | .eval import macros; dumpLisp:; "123"[1 .. < ^2] |
| 19:30:37 | * | goobles quit (Ping timeout: 246 seconds) |
| 19:30:38 | Mimbus | flaviu: StmtList(BracketExpr(StrLit(123), Infix(Ident(!".."), IntLit(1), Prefix(Ident(!"<"), Prefix(Ident(!"^"), IntLit(2)))))) |
| 19:30:51 | flaviu | wow, that works! |
| 19:31:05 | EXetoC | such elegance :p |
| 19:31:41 | flaviu | .eval import macros; dumpLisp:; "123"[1 .. ^2] |
| 19:31:42 | Mimbus | flaviu: StmtList(BracketExpr(StrLit(123), Infix(Ident(!".."), IntLit(1), Prefix(Ident(!"^"), IntLit(2))))) |
| 19:32:11 | BlaXpirit_ | this is what is actually going to be present, according to Araq |
| 19:32:23 | flaviu | EXetoC: Well, the AST makes sense. Whatever macro does this isn't going to have to rewrite the parse. |
| 19:32:43 | flaviu | Does this even need a macro? |
| 19:33:05 | BlaXpirit_ | well yes because ^ can't magically know the length of the container |
| 19:34:22 | flaviu | sure it can. type AwesomeRange = object; a, b: tuple[v: int, exclusive, backwards: bool] |
| 19:35:16 | BlaXpirit_ | more like BloatedRange |
| 19:35:46 | BlaXpirit_ | i am 100% sure this is not going to be considered |
| 19:36:05 | flaviu | If scoped imports were possible, it would be possible to only have `^` available inside a range expression. |
| 19:36:52 | flaviu | ie, template `..`(...): BloatedRange {.dirty.} =; import reversed_range; ... |
| 19:37:14 | flaviu | but that might overly confusing. |
| 19:37:27 | BlaXpirit_ | i don't see a reason why we need different slices |
| 19:38:04 | flaviu | So the container knows exactly what the intentions of the range passed to it are. |
| 19:38:42 | BlaXpirit_ | range is always inclusive |
| 19:38:47 | BlaXpirit_ | you know the intention |
| 19:39:15 | flaviu | But I *don't* want my ranges to always be inclusive. |
| 19:39:28 | * | pregressive quit (Remote host closed the connection) |
| 19:40:02 | * | pregressive joined #nim |
| 19:42:06 | * | Asz joined #nim |
| 19:43:22 | EXetoC | so be it |
| 19:44:12 | BlaXpirit_ | so do you want every function to manually implement behavior for inclusive, non inclusive, reverse, whatever ranges? |
| 19:44:33 | EXetoC | I want consistency and lack of redundancy |
| 19:44:39 | * | pregressive quit (Ping timeout: 256 seconds) |
| 19:45:00 | BlaXpirit_ | the only redundancy here is -1 everywhere |
| 19:45:29 | flaviu | BlaXpirit_: I want every indexable collection to provide a common API, so that handling range complications only needs to be handled once. |
| 19:45:54 | BlaXpirit_ | why even introduce any complications? |
| 19:46:50 | flaviu | Because it makes things easier for the API clients, which is what the goal of a library is. |
| 19:48:14 | BlaXpirit_ | no, it is important to make implementing collections easier |
| 19:48:32 | EXetoC | it's redundant to have all these things surely |
| 19:48:44 | BlaXpirit_ | because I expect Nim's standard library will not be taken seriously, and if it gains any popularity, alternative collections of modules will spring up |
| 19:49:20 | flaviu | BlaXpirit_: Yes, that's an important goal. The collection author should provide a `[]`(self, int), and the stdlib should handle the rest. |
| 19:49:46 | BlaXpirit_ | ok |
| 19:49:52 | BlaXpirit_ | so that limits the implementation |
| 19:50:28 | flaviu | How does that limit the implementation? The collection author always has the option to override the stdlib's implementation. |
| 19:50:40 | BlaXpirit_ | do you realize that it is possible to implement a slice more optimally than just enumerating each of the elements separately from scratch? |
| 19:51:04 | * | TEttinger quit (Ping timeout: 245 seconds) |
| 19:51:16 | flaviu | Sure. If a collection author wants that, they can write their own `[]`(self, BloatedSlice). |
| 19:51:20 | BlaXpirit_ | i mean not generally speaking but for some collection type that doesn't just store all its items blah blah |
| 19:51:43 | BlaXpirit_ | well then they're left with implementing all the branches and corner cases |
| 19:51:57 | BlaXpirit_ | not to mention BloatedSlice is a big object to pass around |
| 19:52:32 | flaviu | 4 extra bytes isn't that much |
| 19:53:13 | BlaXpirit_ | don't forget performance too |
| 19:53:40 | BlaXpirit_ | this al just so that users can use exclusive slices |
| 19:53:47 | flaviu | test for fast paths before starting iteration. |
| 19:53:54 | flaviu | and reverse slices. |
| 19:54:09 | BlaXpirit_ | reverse slices you mean like what negative indices do now? |
| 19:54:29 | flaviu | yep |
| 19:54:45 | BlaXpirit_ | the current idea is to not have them at all |
| 19:55:39 | EXetoC | it's an odd shortcut |
| 19:56:21 | BlaXpirit_ | my idea, and what Araq seems to think as well, is to have this "^" be just a syntactic sugar for len or high |
| 19:56:36 | BlaXpirit_ | (talking about this x[a .. ^1] |
| 19:56:54 | flaviu | I really hate special cases and magic in the compiler. It has enough problems because of it already. |
| 19:56:58 | EXetoC | um |
| 19:57:14 | EXetoC | what's the succeeding number for then? |
| 19:57:33 | BlaXpirit_ | -1 -> ^1 -> x.len-1 |
| 19:58:10 | Aszarsha | BlaXpirit_: actually, if you're doing it right, the range type should only be a compile time thingy and the for loop is generated accordingly. I did it that way in a toy language of mine a few years ago. Their is one disadvantage: it only works for whole program compilation (which is the case for Nim I think!) and you have to choose one scheme for FFI (and C is king here, and in C ranges are exclusives). |
| 19:58:27 | EXetoC | and when you want to add instead you.. don't use ^ anymore? |
| 19:58:58 | BlaXpirit_ | well it very rarely makes sense to go above len |
| 19:59:15 | BlaXpirit_ | and if you do want that, i dont see a problem with ^-1 working |
| 19:59:18 | EXetoC | that's true |
| 19:59:24 | BlaXpirit_ | but my initial idea was ^-1 and not just ^1 |
| 19:59:31 | flaviu | Aszarsha: With macros, it's not even necessary for the compiler to be aware about how ranges work. |
| 19:59:36 | BlaXpirit_ | making ^ an ordinary expression |
| 20:00:00 | Aszarsha | flaviu: well, great then, I guess... ? :) |
| 20:00:34 | Aszarsha | it seems to me that it's one more argument for having both kinds of range |
| 20:01:08 | EXetoC | it really should mean high then, unless I've missed something |
| 20:01:22 | BlaXpirit_ | len is not a safe choice, yeah |
| 20:01:43 | BlaXpirit_ | we talk about len because -2 would be replaced by len-2 |
| 20:02:00 | BlaXpirit_ | and it's not so direct when you use high |
| 20:02:52 | EXetoC | well, I assume that it's more common to specify up to the last element |
| 20:13:54 | * | reem quit (Remote host closed the connection) |
| 20:17:56 | * | reem joined #nim |
| 20:27:46 | * | TEttinger joined #nim |
| 20:39:31 | * | reem quit (Remote host closed the connection) |
| 20:43:42 | * | jholland joined #nim |
| 20:46:42 | EXetoC | Aszarsha: it's not just about for loops is it? |
| 20:49:06 | Aszarsha | EXetoC: no, of course not, thought range usually serve only two purposes in the end: iterating over their elements or knowing its lenght when not infinite |
| 20:50:33 | * | epichero quit () |
| 20:51:26 | Aszarsha | and they shouldn't be limited to range of indices neither, and need to be properly defined for any partially ordered set |
| 20:54:29 | EXetoC | by range you mean slice? I don't like how the term slice is used, but we already have a range type used for another purpose |
| 20:55:03 | Aszarsha | actually, a sequence of T is itself a range, it's a set of T for which the order of insertion define an ordering. on this subject the works of A. Stepanov (Elements of Programming) and of A. Alexandrescu (D2.0 stdlib) are really great |
| 20:57:26 | Aszarsha | the best collections library is by far the one from D2.0 |
| 20:57:45 | Aszarsha | because of this whole formal ranges concept |
| 20:58:12 | EXetoC | I don't know why this is relevant. anyway, traits are broken so it'll be difficult to implement something like that now |
| 20:59:37 | EXetoC | or maybe not. errors would be triggered inside the function bodies though |
| 21:07:44 | Aszarsha | EXetoC: I sure hope not, if the langage prohibit this kind library, while advertising itself as expressive, something is wrong :) |
| 21:08:05 | flaviu | Aszarsha: D2.0? |
| 21:08:34 | flaviu | Ah, Phobos. |
| 21:12:15 | Aszarsha | http://dlang.org/phobos/std_range.html |
| 21:14:40 | Aszarsha | conceptually, slicing is a form of range compisition, a[0..5] is subrange( a.range, 0, 5 ) |
| 21:21:22 | EXetoC | Aszarsha: broken as in buggy implementation |
| 21:22:11 | EXetoC | Aszarsha: yes, that's different from our slices |
| 21:22:29 | * | reem joined #nim |
| 21:22:30 | EXetoC | var a = b .. c |
| 21:22:40 | Aszarsha | EXetoC: Ho! I though your sentence meant "now that traits are broken, it'll be difficult to implement something like that from now on", my bad |
| 21:25:38 | * | epichero joined #nim |
| 21:26:05 | sdw | is slicing by reference on the todo list? |
| 21:26:08 | * | fizzbooze joined #nim |
| 21:34:54 | Aszarsha | EXetoC: what do you mean "our slices" ? slicing is a very well defined operation: http://en.wikipedia.org/wiki/Array_slicing |
| 21:44:52 | * | gsingh93 quit (Ping timeout: 240 seconds) |
| 21:53:12 | EXetoC | there are slice operations, but there's also the Slice type (or is it still TSlice)? the code that I posted creates such a slice |
| 21:53:38 | * | saml_ joined #nim |
| 21:53:51 | EXetoC | odd terminology as I said |
| 21:55:48 | EXetoC | .eval var x = TSlice[int](a: 0, b: 1); x = 1 .. 2; echo x |
| 21:55:49 | Mimbus | EXetoC: (a: 1, b: 2) |
| 22:00:17 | EXetoC | sdw: I haven't heard of such plans, but some library has that |
| 22:02:24 | * | flaviu quit (Remote host closed the connection) |
| 22:03:15 | EXetoC | https://github.com/AdrianV/nimrod-tools/blob/master/seqslices.nim |
| 22:04:03 | * | irrequietus joined #nim |
| 22:06:19 | * | xificurC quit (Ping timeout: 256 seconds) |
| 22:08:33 | * | topon joined #nim |
| 22:14:26 | * | davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 22:14:32 | * | topon left #nim (#nim) |
| 22:21:07 | * | zipR4ND1 quit (Ping timeout: 245 seconds) |
| 22:45:28 | * | MagusOTB joined #nim |
| 22:55:14 | * | Jesin quit (Quit: Leaving) |
| 22:56:10 | * | banister joined #nim |
| 22:57:32 | * | pregressive joined #nim |
| 22:58:39 | * | jsudlow__ joined #nim |
| 22:59:35 | * | TEttinger quit (Ping timeout: 256 seconds) |
| 23:00:26 | * | jsudlow quit (Ping timeout: 246 seconds) |
| 23:10:01 | * | irrequietus quit () |
| 23:12:52 | * | fizzbooze quit (Ping timeout: 265 seconds) |
| 23:57:10 | * | fizzbooze joined #nim |
| 23:59:03 | * | brson joined #nim |