| 00:12:04 | * | mhitza joined #nimrod |
| 00:19:33 | * | brson quit (Ping timeout: 240 seconds) |
| 00:41:57 | * | q66 quit (Quit: Leaving) |
| 00:42:38 | * | askatasuna quit (Ping timeout: 240 seconds) |
| 01:05:26 | * | ics joined #nimrod |
| 01:26:40 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 01:33:49 | * | nande quit (Read error: Connection reset by peer) |
| 01:35:43 | * | AMorpork joined #nimrod |
| 01:49:53 | adoniscik | why is "it" considered undeclared here? result = zip(@x, @y).mapIt(float, it[0] + it[1]) |
| 01:50:18 | adoniscik | if I've imported sequtils |
| 01:52:09 | * | nande joined #nimrod |
| 01:59:00 | def- | adoniscik: probably because you have some generic variables around |
| 02:00:42 | adoniscik | x and y are openarrays, and the proc is seq |
| 02:00:52 | adoniscik | which of them is the generic, def- ? |
| 02:01:09 | def- | show me the full code and I can tell you |
| 02:05:19 | mhitza | if I where to look for manual memory management and C interop, what is the best place to start? (google didn't really help) |
| 02:05:26 | * | BlameStross quit (Quit: BlameStross) |
| 02:07:19 | def- | mhitza: for manual memory management you would use the alloc* procs in http://nimrod-lang.org/system.html |
| 02:08:13 | def- | mhitza: for C interop I wrote a few examples on rosetta code: |
| 02:08:15 | def- | http://rosettacode.org/wiki/Call_a_foreign-language_function#Nimrod |
| 02:08:18 | def- | http://rosettacode.org/wiki/Call_a_function_in_a_shared_library#Nimrod |
| 02:08:22 | def- | http://rosettacode.org/wiki/Use_another_language_to_call_a_function#Nimrod |
| 02:08:41 | def- | And for semi-automatic conversion of c-headers: http://nimrod-lang.org/c2nim.html |
| 02:17:35 | * | kshlm quit (Quit: Konversation terminated!) |
| 02:19:57 | * | adoniscik quit (Ping timeout: 250 seconds) |
| 02:23:39 | * | BlameStross joined #nimrod |
| 02:35:48 | mhitza | def-, thanks I will have a look at those |
| 02:42:30 | * | saml_ joined #nimrod |
| 02:56:24 | * | bjz joined #nimrod |
| 03:00:53 | def- | Yay, bigints finally kind of seem to work, this (correctly) calculates as many digits of pi as you want and takes about 4 times as long as the C GMP version: https://github.com/def-/bigints/blob/master/pidigits.nim |
| 03:11:49 | saml_ | that's amazing |
| 03:12:49 | def- | got another speedup, only 3 times as slow as GMP now |
| 03:18:19 | * | adoniscik joined #nimrod |
| 03:41:16 | flaviu | def-: I want to have some fun too! Can you push? I get a OOB |
| 03:42:16 | flaviu | Oh, nm |
| 03:51:37 | def- | flaviu: pull again, it's a bit nicer now, without the bigint constants |
| 03:51:40 | def- | and good night |
| 03:52:00 | def- | oh, and here's the C if you want to compare: http://benchmarksgame.alioth.debian.org/u64/program.php?test=pidigits&lang=gcc&id=1 |
| 03:56:58 | * | ics joined #nimrod |
| 04:04:21 | flaviu | def-: Still here? Try copy-pasting multiplication from https://github.com/blamestross/nimrod-BigInt/blob/master/bigints.nim |
| 04:04:30 | flaviu | Short, elegant, and moves the bottleneck to newSeq |
| 04:06:05 | BlameStross | def-: Be carefull, we might have different endian-ness and chunk-size |
| 04:06:22 | BlameStross | def-: And the rest of the code is a bit crap. |
| 04:06:26 | flaviu | Does endianness matter here? |
| 04:06:31 | BlameStross | sorta |
| 04:06:35 | flaviu | No messing around with bytes |
| 04:07:01 | BlameStross | yeah, but what if my high bits or at the 0 of the seq versus the end of the seq |
| 04:07:22 | flaviu | Shr/shl doesn't care about endian from what I've heard |
| 04:09:23 | BlameStross | s/or/are |
| 04:10:43 | * | xenagi quit (Quit: Leaving) |
| 04:10:46 | BlameStross | never assume somebody who has no idea what you they are doing will order and arrange things in a pattern that seems natural to you. |
| 04:11:00 | BlameStross | I learned that grading undergrad assigments. |
| 04:12:28 | flaviu | Have you seen kcachegrind? |
| 04:12:42 | flaviu | I think I've mentioned it |
| 04:13:28 | flaviu | Anyway, it gives a graphical overview of the output of callgrind, and it can be configured to give you the nimrod source line! |
| 04:18:46 | flaviu | BlameStross: Does shl work in your code? |
| 04:20:01 | flaviu | Things seem to have gotten into an infinate loop, seems not |
| 04:20:09 | flaviu | Anyway, its time for me to sleep |
| 04:20:26 | * | kshlm joined #nimrod |
| 04:20:37 | * | flaviu quit (Quit: Leaving.) |
| 04:24:45 | Varriount | Meep. |
| 04:24:53 | Varriount | Hi kshlm |
| 04:45:15 | adoniscik | why does this not work? http://pastebin.com/B9wcYS9j |
| 04:48:55 | fowl | adoniscik, try float(it[0] + it[1]) |
| 04:51:15 | adoniscik | no dice, but echo zip(@[-3.0,4.0,0.0], @[1.0,2.0,3.0]).mapIt(float, it[0] + it[1]) works |
| 04:51:33 | adoniscik | it seems to be the proc signature? |
| 04:52:31 | fowl | well read the error message |
| 04:52:33 | fowl | and share it |
| 04:52:45 | adoniscik | undeclared identifier: 'it' |
| 04:53:08 | adoniscik | referring to the line 5: result ... |
| 04:56:02 | fowl | adoniscik, something is broken |
| 04:56:32 | adoniscik | do you get the same error? |
| 04:56:34 | fowl | the example in the documentation for mapit works, this should too |
| 04:56:45 | fowl | yea |
| 04:57:11 | fowl | you should submit an issue for it |
| 04:57:31 | adoniscik | I can't get it to work with => in future either: http://nimrod-lang.org/future.html |
| 04:57:36 | adoniscik | maybe you'd like totake a crack at that |
| 05:00:08 | fowl | the overload inference is not quite right for => yet, to use it with map you have to specify the type like numbers.map((n:int) => $n) |
| 05:00:49 | fowl | (n) => $n wont work here |
| 05:02:42 | adoniscik | echo zip(@[-3.0,4.0,0.0], @[1.0,2.0,3.0]).map do (t: tuple) -> float : t[0] + t[1] also worked |
| 05:04:12 | * | Varriount_ joined #nimrod |
| 05:04:14 | adoniscik | but not inside the function :( |
| 05:04:28 | fowl | adoniscik, make an issue for the mapIt bug please |
| 05:04:37 | fowl | good night |
| 05:04:44 | adoniscik | I will as soon as I get somethng working! good night |
| 05:05:07 | adoniscik | I can't tell the bugs from my mistakes yet |
| 05:05:19 | fowl | i suggest the do syntax (the last one you showed) |
| 05:05:39 | fowl | looks the nicest imo |
| 05:05:46 | fowl | gn |
| 05:05:49 | adoniscik | byer |
| 05:07:47 | * | Varriount quit (Ping timeout: 264 seconds) |
| 05:08:31 | * | Varriount_ is now known as Varriount |
| 05:08:49 | Varriount | adoniscik: Just an fyi, I'm still here. |
| 05:09:13 | adoniscik | that's nice, so am I :) |
| 05:11:08 | adoniscik | well the function definition passes the compiler, but I get a type expected error when I try to invoke it with echo [-3.0,4.0,0.0] + [1.0,2.0,3.0] |
| 05:11:58 | adoniscik | so it doesn't match proc `+`[T] (x, y: openarray[T])? |
| 05:12:15 | Varriount | Hm. Possibly. Let me try something. |
| 05:12:49 | adoniscik | how can I get the signature of a statement? |
| 05:12:56 | adoniscik | if it's possible, of course |
| 05:13:27 | Varriount | Well, you could trying forcing calling the procedure |
| 05:13:54 | adoniscik | would that be echo `+`([-3.0,4.0,0.0], [1.0,2.0,3.0])? |
| 05:14:19 | * | saml_ quit (Quit: Leaving) |
| 05:14:25 | adoniscik | okay without the ` |
| 05:14:28 | Varriount | I think. Or you could just rename the procedure to not be an operator. |
| 05:15:00 | adoniscik | good idea. Error: type mismatch: got (proc (seq[S], seq[T]): seq[tuple[a: S, b: T]]) |
| 05:15:40 | adoniscik | wait a minute, I thought [1,2,3] was an array, not seq? |
| 05:15:46 | Varriount | adoniscik: Could you gist the current version of your code? |
| 05:16:48 | adoniscik | http://pastebin.com/fvLLECit |
| 05:18:00 | adoniscik | why two generics, S and T? maybe that's it |
| 05:20:31 | Varriount | Zip takes two unique sequences, and returns a tuple with an item from those sequences. |
| 05:21:05 | adoniscik | great? |
| 05:23:56 | adoniscik | recall that both echo zip(@[-3.0,4.0,0.0], @[1.0,2.0,3.0]).map do (t: tuple) -> float : t[0] + t[1] and echo zip(@[-3,4,0], @[1,2,3]).mapIt(int, it[0] + it[1]) work |
| 05:24:13 | adoniscik | it's just the function that doesn't, for some reason |
| 05:26:14 | * | Ven joined #nimrod |
| 05:27:47 | adoniscik | arg, a typo: @ in front of zip |
| 05:28:07 | Varriount | I thought that was intentional? |
| 05:28:30 | adoniscik | @zip does something? |
| 05:28:44 | Varriount | *shrug* |
| 05:28:47 | adoniscik | zip already returns a seq |
| 05:29:10 | adoniscik | and I thought @ is the seq operator |
| 05:29:14 | adoniscik | but I might be mistaken about that |
| 05:29:20 | Varriount | No, it is. |
| 05:29:51 | Varriount | I was under the erroneous impression that zip was an iterator, and the @ operator was to turn it into a sequence. |
| 05:29:52 | * | Ven quit (Client Quit) |
| 05:30:12 | adoniscik | If I get this working I'll be interested in the iterated version :) |
| 05:31:27 | adoniscik | now i just get Error: ambiguous call; both system.+(x: float, y: float): float and system.+(x: float, y: float): float match for: (float, float) |
| 05:31:40 | adoniscik | but these are the same things so what's the problem?! |
| 05:31:51 | adoniscik | that really looks like a bug |
| 05:33:37 | adoniscik | so I'll let it rest until somebody else takes a look |
| 05:33:51 | adoniscik | two bugs for one night's good work! |
| 05:34:12 | Varriount | adoniscik: Two? What was the first? |
| 05:35:11 | Varriount | adoniscik: Let me see if I can modify the compiler to shine a bit more light on things... |
| 05:36:08 | adoniscik | the other was the error: undeclared identifier: 'it', when you replace the proc with result = zip(@x, @y).mapIt(int, it[0] + it[1]) |
| 05:36:51 | adoniscik | yet mapIt works without the function, just like the other cases... |
| 05:37:06 | adoniscik | something gets screwed up in the proc |
| 05:37:11 | adoniscik | thanks |
| 05:37:36 | Varriount | adoniscik: Generics are tricky to compute, since their scoping rules are different from regular procs. |
| 05:42:16 | Varriount | adoniscik: It looks like a bug in semcall.resolveOverloads |
| 05:47:49 | * | dushan42 joined #nimrod |
| 05:51:16 | adoniscik | awesome that you have an idea where the bug is; I'm just a user. Give me a working compiler and I'll write the libraries :) |
| 06:01:17 | Varriount | adoniscik: To be honest, the compiler is quite a complex beast. I'm much more succesful with stdlib errors, since those are usually much, much simpler to fix. |
| 06:02:15 | Varriount | I'm just guessing that's where the bug is, since that's the location in the compiler code the ambiguity error is thrown. |
| 06:11:02 | Skrylar | i'm fairly useless in that i don't fix core bugs, i just write nimrod code :F |
| 06:11:17 | Skrylar | actually i was considering bringing over some random number generators |
| 06:32:38 | * | adoniscik quit (Ping timeout: 240 seconds) |
| 06:32:51 | * | kunev quit (Ping timeout: 256 seconds) |
| 06:33:27 | Skrylar | hah. i just thought about how one could abuse the siphash routine i ported to be an RNG |
| 06:33:50 | Skrylar | just toss the seed through siphash and take bits out of the returned hash, recycle the hash back through siphash |
| 06:33:56 | Skrylar | its already a cryptographic function |
| 06:43:13 | * | Demos quit (Read error: Connection reset by peer) |
| 07:12:22 | * | io2 joined #nimrod |
| 07:20:15 | * | kemet joined #nimrod |
| 07:21:39 | * | kemet quit (Client Quit) |
| 07:23:32 | * | kemet joined #nimrod |
| 07:42:05 | * | Trustable joined #nimrod |
| 07:44:40 | * | nande quit (Remote host closed the connection) |
| 07:45:15 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 07:56:35 | * | ics quit (Ping timeout: 240 seconds) |
| 07:56:56 | * | kemet quit (Remote host closed the connection) |
| 07:59:06 | * | ics joined #nimrod |
| 08:20:33 | * | q66 joined #nimrod |
| 08:20:40 | * | kunev joined #nimrod |
| 08:41:48 | * | adoniscik joined #nimrod |
| 09:06:49 | * | Matthias247 joined #nimrod |
| 09:08:23 | * | Fr4n quit (Ping timeout: 264 seconds) |
| 09:11:44 | * | BitPuffin quit (Ping timeout: 250 seconds) |
| 09:19:00 | * | caribou| joined #nimrod |
| 09:19:47 | adoniscik | what is the signature for a proc that accepts two openarrays and returns a seq? |
| 09:21:59 | * | Fr4n joined #nimrod |
| 09:28:17 | * | BitPuffin joined #nimrod |
| 09:28:38 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 09:32:42 | * | BitPuffin quit (Ping timeout: 245 seconds) |
| 09:50:46 | * | mhitza quit (Remote host closed the connection) |
| 10:04:03 | def- | adoniscik: proc[T](x, y: openarray[T]): seq[T] |
| 10:04:23 | adoniscik | right, what I had. I discovered something interesting |
| 10:05:29 | adoniscik | check this out: http://pastebin.com/RTVKaHEE |
| 10:07:01 | adoniscik | this fails with cannot instantiate: 'T' |
| 10:07:03 | adoniscik | why is that? |
| 10:08:26 | adoniscik | and if you remove the parentheses around the arrays it fails with type expected |
| 10:08:49 | def- | well, you can't remove the parantheses |
| 10:09:27 | adoniscik | I can live with that, but not the generics |
| 10:09:32 | adoniscik | or rather, without the generics |
| 10:09:53 | def- | result = zip(@x, @y).map(proc (a: tuple[a, b: T]): T = a[0] + a[1]) |
| 10:10:20 | adoniscik | hah |
| 10:11:20 | adoniscik | thanks, def- , now I can sleep well :) |
| 10:11:46 | def- | this also works: |
| 10:11:47 | def- | result = zip(@x, @y).map do (c: tuple[a, b: T]) -> T: c[0] + c[1] |
| 10:11:59 | def- | you're welcome |
| 10:12:14 | adoniscik | yeah weird. why c and not a and b? |
| 10:12:17 | adoniscik | I did not understand that |
| 10:12:25 | adoniscik | I thought c was the function |
| 10:12:31 | def- | hm? |
| 10:12:41 | def- | c is a tuple containing values a and b |
| 10:12:46 | def- | for c[0] you can also write c.a |
| 10:12:50 | def- | for c[1] c.b |
| 10:13:17 | adoniscik | aha, got it. clarity achieved! |
| 10:13:37 | adoniscik | bye for now |
| 10:13:49 | adoniscik | one more thing |
| 10:13:57 | adoniscik | why did you need the parentheses for echo again? |
| 10:14:08 | adoniscik | echo 1+2 works, after all |
| 10:14:49 | def- | i guess otherwise it means (echo a) + b |
| 10:15:19 | def- | i don't know, the square brackets might change something there |
| 10:15:34 | def- | I always find it difficult to know when i can write something without brackets and when not |
| 10:15:54 | adoniscik | echo 1+2 does not mean (echo 1)+2 so something else is going on. maybe the brackets, like you said |
| 10:22:55 | * | adoniscik quit (Ping timeout: 256 seconds) |
| 10:29:18 | * | kshlm quit (Ping timeout: 250 seconds) |
| 10:32:59 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 11:26:05 | * | Matthias247 joined #nimrod |
| 11:27:38 | * | jez0990_ quit (Quit: No Ping reply in 180 seconds.) |
| 11:27:54 | * | jez0990 joined #nimrod |
| 11:53:41 | * | Araq_ joined #nimrod |
| 11:55:04 | Araq_ | hmm looks like the mapIt bug/language design problem should get some high priority |
| 12:00:44 | io2 | offtopic right now, but is anybody working on the website? |
| 12:01:31 | io2 | looks like we could be having some nicer layout; the eye needs its part after all |
| 12:05:50 | * | saml_ joined #nimrod |
| 12:08:22 | Araq_ | io2: er ... the website is really nice now |
| 12:08:25 | Araq_ | what |
| 12:08:31 | Araq_ | is wrong with it? |
| 12:09:14 | io2 | if you think it is ok, I guess I shouldn't bring about the subject that it is really dull to look at |
| 12:09:25 | io2 | I am seeing sites for other languages |
| 12:09:29 | io2 | like scala-lang.org |
| 12:09:44 | io2 | most stuff is bootstrap based anyway |
| 12:10:06 | io2 | which means that there isn't much trouble in skinning them in a visually appealing way, but I digress. |
| 12:16:12 | Araq_ | Varriount: can you please go through the list of bugs and close the closure related bugs that work now? |
| 12:33:05 | * | untitaker quit (Ping timeout: 240 seconds) |
| 12:35:04 | * | q66_ joined #nimrod |
| 12:35:58 | * | q66 quit (Ping timeout: 240 seconds) |
| 12:37:19 | woodgiraffe | I have to say that I find these constant religious denotations very offputting, I mean nimrod I can live with, but babel package manager? |
| 12:38:58 | * | saml_ quit (Quit: Leaving) |
| 12:39:21 | * | untitaker joined #nimrod |
| 12:40:18 | * | q66_ quit (Ping timeout: 240 seconds) |
| 12:42:28 | * | q66_ joined #nimrod |
| 12:42:48 | * | q66_ is now known as q66 |
| 12:47:14 | OrionPK | lol |
| 12:47:46 | OrionPK | you just missed the channel's daily call to prayer woodgiraffe |
| 12:48:00 | woodgiraffe | OrionPK: I wouldn't be surprised |
| 12:49:30 | Araq_ | well ... if it helps you ... I |
| 12:49:38 | Araq_ | am not religious |
| 12:58:47 | flyx | woodgiraffe: it's just names from some story. the language could as well be named Mithrandir |
| 13:03:00 | * | xenagi joined #nimrod |
| 13:07:48 | * | BitPuffin joined #nimrod |
| 13:14:58 | woodgiraffe | If you make it a tradition to name your projects from the hebrew bible, you shouldn't be surprised when people expect religious intent - if you're not religious, then I find it strategically clumsy, because you're unnecessarily bringing religious/cultural connotations into the equation. |
| 13:17:24 | woodgiraffe | And really, I mean... babel package manager |
| 13:18:33 | skroll | and what's the deal with airline food? |
| 13:19:27 | woodgiraffe | Try calling it mecca package manager and try arguing the same case |
| 13:19:53 | woodgiraffe | And then I guess you call your language Muhammad :) |
| 13:22:17 | flyx | woodgiraffe: you do realize that babel isn't exactly a holy place in the hebrew bible, and nimrod is not exactly a holy man? |
| 13:24:33 | woodgiraffe | flyx: Well, still they're just names from some story right? |
| 13:24:55 | * | darkf quit (Quit: Leaving) |
| 13:26:14 | flyx | yes, and they are not names whose name would be considered heretic by anyone who believes in the bible |
| 13:26:31 | flyx | *usage |
| 13:40:10 | * | leru joined #nimrod |
| 13:50:19 | * | [1]Endy joined #nimrod |
| 13:52:19 | flyx | even if there was religious intent… it's not like the license tells you that you must believe in any god in order to use it. a language is a tool, it's up to you to decide what to use it for. |
| 13:52:52 | flyx | I don't really see that it could cause any problems |
| 13:53:47 | OrionPK | there's been talk of renaming the language to "nim" which im heavily in favor of, but not because nimrod is from the bible :P |
| 13:54:31 | flyx | then for what reasons? |
| 14:00:59 | Araq_ | flyx: it sounds better and is not a common english term |
| 14:01:15 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 29.0/20140421221237]) |
| 14:02:00 | flyx | well, as long as it's not too short for Google to index it… why not |
| 14:03:45 | woodgiraffe | I'd absolutely contribute to the Chimpsky package manager :) |
| 14:16:55 | * | X-Scale quit (Ping timeout: 272 seconds) |
| 14:18:57 | * | BitPuffin quit (Ping timeout: 245 seconds) |
| 14:31:38 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 14:36:20 | * | Mat3 joined #nimrod |
| 14:36:22 | Mat3 | hello |
| 14:39:23 | * | BitPuffin joined #nimrod |
| 15:27:23 | * | bjz joined #nimrod |
| 15:30:06 | * | Mat3 quit (Quit: Verlassend) |
| 15:31:45 | * | bjz quit (Client Quit) |
| 15:47:06 | * | Matthias247 quit (Ping timeout: 240 seconds) |
| 15:52:45 | * | Matthias247 joined #nimrod |
| 15:53:17 | * | mwbrown joined #nimrod |
| 15:59:01 | * | cariboo joined #nimrod |
| 16:02:33 | * | caribou| quit (Ping timeout: 255 seconds) |
| 16:06:44 | * | X-Scale joined #nimrod |
| 16:07:18 | * | kunev quit (Ping timeout: 250 seconds) |
| 16:07:29 | * | Jesin quit (Quit: Leaving) |
| 16:07:58 | * | [1]Endy quit (Quit: HydraIRC -> http://www.hydrairc.com <-) |
| 16:08:16 | * | [1]Endy joined #nimrod |
| 16:08:29 | * | saml joined #nimrod |
| 16:16:17 | * | Jehan_ joined #nimrod |
| 16:16:37 | * | Jesin joined #nimrod |
| 16:18:41 | * | flaviu joined #nimrod |
| 16:24:42 | saml | gonna learn nimrod |
| 16:26:26 | flaviu | Someone once talked about naming it N |
| 16:26:35 | flaviu | Somehow that name isn't taken |
| 16:27:12 | saml | okay i installed nimrod |
| 16:31:01 | Jehan_ | flaviu: That was me, and I was making a joke. :) |
| 16:31:16 | flaviu | Well, I'm serious |
| 16:32:19 | flaviu | We can also snag A |
| 16:32:55 | Jehan_ | flaviu: Let me be the first to point out that this would be horrible for search engines. :) |
| 16:33:07 | flaviu | Alang |
| 16:33:19 | flaviu | oh, indian town |
| 16:33:19 | Jehan_ | Though it might inflate the Tiobe index. |
| 16:34:10 | flaviu | nlang is just some obscure word, it'd work |
| 16:35:37 | flaviu | Anyway, with nimrod, google thinks I'm a conspiracy theorist by the results that show up |
| 16:36:49 | Jehan_ | What brought up that debate, anyway? Let me look at the log ... |
| 16:37:00 | * | BitPuffin quit (Quit: See you on the dark side of the moon!) |
| 16:37:51 | Jehan_ | Oh, renaming Nimrod to Nim. Hmm. I wouldn't have a problem with it, but don't really care much either way. |
| 16:38:31 | * | BitPuffin joined #nimrod |
| 16:40:48 | * | Demos joined #nimrod |
| 16:41:09 | * | [1]Endy left #nimrod (#nimrod) |
| 16:50:30 | * | Ven joined #nimrod |
| 16:55:40 | * | vendethiel joined #nimrod |
| 17:05:25 | * | ics joined #nimrod |
| 17:06:00 | * | adoniscik joined #nimrod |
| 17:14:41 | * | bjz joined #nimrod |
| 17:16:39 | * | q66 quit (Quit: Leaving) |
| 17:17:01 | * | q66 joined #nimrod |
| 17:24:51 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 17:25:46 | * | Jehan_ quit (Quit: Leaving) |
| 17:35:13 | * | leru quit (Ping timeout: 246 seconds) |
| 17:36:47 | * | wan joined #nimrod |
| 17:54:43 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 17:56:52 | Araq | dom96! |
| 17:58:38 | mwbrown | flaviu: that nimrod by example website is brilliant btw |
| 17:58:42 | mwbrown | much easier to follow |
| 17:59:36 | flaviu | Thanks, but I'm going to have to reorganize it significantly, some concepts are spread throughout. |
| 18:19:02 | * | brson joined #nimrod |
| 18:26:43 | dom96 | Araq! |
| 18:27:04 | Araq | dom96: I had the idea of the millenium |
| 18:27:30 | Araq | we rename nimrod to nim and babel to "babe" ;-) |
| 18:28:34 | * | brson quit (Ping timeout: 250 seconds) |
| 18:30:10 | * | silasm joined #nimrod |
| 18:30:37 | adoniscik | or ble, so you get nim ble :) |
| 18:30:46 | adoniscik | bel also works |
| 18:33:01 | dom96 | what's wrong with 'babel'? |
| 18:33:26 | adoniscik | nothing! is there a way to get sequtils proc like zip to return iterators? |
| 18:33:30 | flaviu | dom96: Biblical connotations |
| 18:34:23 | adoniscik | I mean generators |
| 18:34:46 | adoniscik | so the entire data structure is not created |
| 19:19:31 | * | NimBot joined #nimrod |
| 19:21:47 | * | q66 quit (Quit: Leaving) |
| 19:23:07 | * | q66 joined #nimrod |
| 19:27:16 | * | q66 quit (Read error: Connection reset by peer) |
| 19:45:58 | * | ics quit (Ping timeout: 240 seconds) |
| 19:48:00 | * | ics joined #nimrod |
| 19:55:09 | * | xenagi quit (*.net *.split) |
| 19:55:09 | * | betawaffle quit (*.net *.split) |
| 19:55:19 | * | Demos quit (*.net *.split) |
| 19:55:20 | * | Skrylar quit (*.net *.split) |
| 19:55:27 | * | xenagi joined #nimrod |
| 19:55:39 | * | Demos joined #nimrod |
| 19:55:45 | * | Skrylar joined #nimrod |
| 19:56:06 | * | Jesin quit (Ping timeout: 250 seconds) |
| 19:56:29 | * | Johz joined #nimrod |
| 19:56:55 | * | betawaffle joined #nimrod |
| 19:57:34 | * | q66 joined #nimrod |
| 20:05:56 | * | Jesin joined #nimrod |
| 20:20:18 | * | goobles joined #nimrod |
| 20:20:50 | dom96 | flaviu: Why is https://github.com/flaviut/nimrod-by-example/issues/14 unexpected behaviour? |
| 20:21:08 | flaviu | Because the last element output is a 0 |
| 20:21:36 | dom96 | oh |
| 20:21:54 | flaviu | BTW, did you see the cosmic event or whatever here: https://app.wercker.com/#buildstep/53c974ad8e1c00643000f1c7 ? |
| 20:22:17 | flaviu | It failed to build for no reason |
| 20:22:45 | dom96 | solar radiation? |
| 20:23:00 | flaviu | I dunno, thats my best guess |
| 20:23:03 | dom96 | More likely explanation is something else lol |
| 20:23:25 | flaviu | But look at the diff: https://github.com/flaviut/nimrod-by-example/commit/8a5e62db02d64d0aa65718f9832be84f0b1b98d0 |
| 20:23:30 | flaviu | Perfectly harmless |
| 20:23:47 | * | Fx00F joined #nimrod |
| 20:24:20 | * | q66 quit (Quit: Leaving) |
| 20:24:45 | * | q66 joined #nimrod |
| 20:24:48 | flaviu | Even if its unlikely, I choose to believe that since its the most exciting explanation :P |
| 20:24:54 | dom96 | flaviu: I think that is the expected iterator behaviour |
| 20:25:07 | dom96 | It returns default(T) to signify that it finished |
| 20:25:38 | flaviu | Expected behavior should be crashing |
| 20:25:44 | dom96 | Why? |
| 20:26:15 | flaviu | There isn't any reason you would intentionally use an expired iterator. Fail fast, don't give it a chance to mess more things up |
| 20:26:26 | dom96 | There is a reason behind this behaviour. |
| 20:26:32 | dom96 | If you have statements after the last yield |
| 20:26:40 | dom96 | The iterator has to return something |
| 20:27:30 | dom96 | Which is what happens in your code. |
| 20:27:31 | flaviu | Make statements after the last yield illegal then |
| 20:27:38 | dom96 | You have an 'inc' |
| 20:28:33 | flaviu | But why should that be run? |
| 20:28:40 | dom96 | side effects |
| 20:29:24 | dom96 | It's just one extra iteration anyway |
| 20:29:27 | dom96 | It won't kill anyone. |
| 20:29:45 | dom96 | wooh. 74. New user total record! |
| 20:30:02 | flaviu | Still not happy, I'm sure there's a better solution. |
| 20:40:48 | def- | flaviu: when i compile nimrod-by-example by hand using nanoc i don't get an error |
| 20:41:17 | flaviu | def-: the error happened randomly, without reason |
| 20:41:24 | def- | yeah, weird |
| 20:41:46 | flaviu | I like to think it was a cosmic ray flipping a bit :D |
| 20:59:54 | * | Ven joined #nimrod |
| 21:03:25 | * | vbtt joined #nimrod |
| 21:04:20 | vbtt | hello friends |
| 21:05:08 | vbtt | flaviu:going thru the nimrod-by-example in detail now. it's great. |
| 21:05:13 | vbtt | learning some things myself :) |
| 21:05:35 | vbtt | btw, is the 'T' prefix for types still the encouraged convention? |
| 21:06:53 | dom96 | I don't think so. |
| 21:06:57 | dom96 | But I still use them |
| 21:07:24 | vbtt | perhaps nimrod-by-example should use the recommended styles :) |
| 21:08:44 | vbtt | flaviu:first example in http://nimrod-by-example.github.io/for_iterators/ shows pairs being used but not items? why not? |
| 21:09:15 | flaviu | vbtt: items is being used, look inside pairs |
| 21:09:46 | Jehan_ | vbtt: The T/P prefixes are going to become obsolete at some point. |
| 21:09:47 | vbtt | flaviu:you are right :) |
| 21:10:17 | vbtt | maybe comments on the lines invoking the iterators would help (# calls items()) |
| 21:10:28 | flaviu | vbtt: Good idea |
| 21:10:30 | vbtt | Sorry, I meant Jehan_ |
| 21:11:19 | Jehan_ | My understanding is that what's holding this up (aside from the time to do it) is a planned and still missing "obsolete" pragma (that allows old names to still be used, just with warnings). |
| 21:13:37 | vbtt | The closure iterators example output line #2 doesn't show spaces like I would expect as per the code: http://nimrod-by-example.github.io/for_iterators/ |
| 21:13:53 | flaviu | vbtt: Thanks, forgot to edit that |
| 21:14:16 | flaviu | That's buggy right now btw, I'm waiting for Araq to appear so I can bug him about it |
| 21:14:35 | vbtt | wat? closure iterators still don't work :( |
| 21:14:45 | flaviu | No, it works, just in a weird way |
| 21:15:21 | vbtt | what's weird? |
| 21:16:04 | flaviu | https://github.com/flaviut/nimrod-by-example/issues/14 |
| 21:18:02 | * | saml quit (Quit: Leaving) |
| 21:18:36 | vbtt | ok it's weird |
| 21:19:15 | Jehan_ | It may be intended. |
| 21:19:34 | flaviu | It is intended, but it is also weird and horrible |
| 21:19:40 | Jehan_ | This is where I'd really like to have a "repeat … until/do … while" style of loop. |
| 21:19:59 | * | io2 joined #nimrod |
| 21:20:09 | Jehan_ | Hmm, nevermind, that wouldn't help in this particular case. |
| 21:20:23 | flaviu | Jehan_: That isn't the problem, the problem is that the loop executes one more time than it should |
| 21:20:23 | vbtt | well using 'for' is the most natural with iterators |
| 21:20:38 | Jehan_ | flaviu: A loop with an exit in the middle solves it. |
| 21:20:42 | flaviu | And gives bogus values on the extra execution, making it super-easy to create bugs |
| 21:21:21 | vbtt | this is why next() raises an exception in Python, when the generator is exhausted. |
| 21:21:49 | Jehan_ | flaviu: It looks to me as though it's intended to be used on a call-then-test basis rather than a test-then-call basis. |
| 21:21:50 | flaviu | An exception like that is exactly what I'd expect |
| 21:22:42 | Varriount | Meep |
| 21:23:32 | Varriount | Nimrod has a (draft) style-guide. |
| 21:23:34 | * | shodan45 joined #nimrod |
| 21:23:35 | flaviu | Jehan_: regardless, its too easy to cause bugs with it. |
| 21:24:03 | Varriount | https://github.com/Araq/Nimrod/wiki/NEP-1 |
| 21:24:53 | Jehan_ | flaviu: Is that because of a design flaw or because of an expectation/implementation mismatch? |
| 21:24:58 | flaviu | > manual alignment and re-alignment can be quite time consuming |
| 21:24:58 | flaviu | And messes up diffs |
| 21:25:50 | flaviu | Jehan_: I'd say its both. The design flaw is that the expectation and implementation don't match |
| 21:26:21 | vbtt | Jehan_:the point is it's easy to have unnoticed/hard-to-find bugs in code because it will compile and run. |
| 21:26:44 | * | X-Scale quit (Ping timeout: 240 seconds) |
| 21:26:46 | flaviu | Ideally, the code that someone totally new comes up with should work flawlessly, people shouldn't have to remember idiosyncrasies of the language |
| 21:26:47 | Jehan_ | But where does the expectation come from? Is it just how iterators in, say, Java are done, or because there's something inherently right about the expectation? |
| 21:27:07 | Jehan_ | … because of how ... |
| 21:29:14 | Jehan_ | I'm asking, I'm not certain myself. |
| 21:29:16 | vbtt | Jehan_: the pattern test-then-call is very, very common. |
| 21:29:30 | Jehan_ | vbtt: Yeah, but not universal. |
| 21:29:35 | vbtt | it seems obvious given the available functions (finished, call(), etc.) |
| 21:29:45 | flaviu | Jehan_: When something is done the same way in every conceivable language, I think that the expectation is inherently right |
| 21:29:51 | Jehan_ | Example: repeat read-line-from-stdin until input-is-valid |
| 21:29:53 | vbtt | The semantics do nothing to warn the user or indicate differently. |
| 21:30:30 | flaviu | Also, Design Patterns does it like `while !done(): next()` |
| 21:30:38 | vbtt | Jehan_: there you are testing the input itself to see if it is valid. you don't do x = stdin.read(); if (was_stdin_valid(stdin) {user x;} else {discard x; |
| 21:31:13 | vbtt | In fact, I can't think of an example where you test the source of a value, after you get the value, to see if the value you got should be used or not. |
| 21:31:43 | * | brson joined #nimrod |
| 21:31:48 | Araq | flaviu: there is no easy solution |
| 21:31:50 | vbtt | The point is the useless value should not be returned. Either raise and exception or return a different type (T | Exhausted) |
| 21:32:11 | Araq | er ... again: This is a hard problem |
| 21:32:20 | flaviu | Araq: Sure there is. Require that a close() method be run when expired |
| 21:32:20 | Araq | Lua does it this way too fwiw |
| 21:32:21 | dom96 | *Something* has to be returned |
| 21:32:25 | dom96 | and it shouldn't be an exception |
| 21:32:30 | Jehan_ | I'd look at other languages that had iterators before. E.g., Icon, CLU, Sather. |
| 21:32:34 | dom96 | You cannot return a different type. |
| 21:32:41 | Varriount | Araq: For once, I'm conscious after work. What issues should I work on? |
| 21:32:46 | Araq | flaviu: what?! |
| 21:32:49 | vbtt | dom96:why can't you return a different type? |
| 21:33:02 | Araq | Varriount: go through the list of bugs |
| 21:33:09 | Araq | vbtt: static typing. |
| 21:33:12 | dom96 | ^^ |
| 21:33:30 | vbtt | Araq:but we have sum types, aka variants, no? |
| 21:33:49 | vbtt | Araq:this would only be used by while loops or explicit invocation. for loops would hide it of course. |
| 21:34:05 | Araq | Varriount: we didn't mark the closure related bugs with a tag so ... more fun for you |
| 21:34:05 | vbtt | it requires the caller to ensure that they got a correct value. |
| 21:34:08 | flaviu | Araq: while not finished(myIterator):( myIterator()) close(myIterator) |
| 21:34:09 | dom96 | vbtt: Checking for the type would be a lot more tedious. |
| 21:34:25 | vbtt | dom96:but you have to check for finished anyway, checking types is more tedious? |
| 21:34:39 | Araq | flaviu: what makes you think that I didn't come up with this solution before the solution that's been implemented now? |
| 21:34:40 | dom96 | vbtt: yes |
| 21:35:29 | flaviu | Araq: I hadn't thought of that, but I think the current solution isn't good at all |
| 21:35:35 | vbtt | I don't think close is a good idea, btw. it should just run the remainder of the code and exit. |
| 21:35:36 | flaviu | Its too easy to make a mistake |
| 21:35:52 | vbtt | to be fair, iterators are used mostly with for loops and no bugs there. |
| 21:36:13 | vbtt | we're talking about explicitly calling and iterator, for each iteration. |
| 21:36:58 | Araq | flaviu: transform a closure iterator into these 3 methods that you just gave. I'm sure you can do it. It's such an easy transformation... |
| 21:37:49 | Varriount | Anyone have objections to this PR? https://github.com/Araq/Nimrod/pull/1372 |
| 21:37:53 | flaviu | The problem is that its hard to explain why an iterator would work so counter-intuitively |
| 21:38:09 | Araq | no it isn't |
| 21:38:23 | Araq | it is transformed into a state machine. |
| 21:38:26 | Araq | so there. |
| 21:38:27 | vbtt | returning the last bogus value is a wart |
| 21:38:30 | Araq | one sentence |
| 21:38:46 | vbtt | it should return something distinguishable from a valid value. |
| 21:38:56 | vbtt | so the two options imo are - sum types or exceptions. |
| 21:39:05 | vbtt | can variants be used in a case statement? |
| 21:39:10 | vbtt | (can't find an example of that) |
| 21:39:35 | NimBot | Araq/Nimrod devel 5a3c88d Grzegorz Adam Hankiewicz [+0 ±1 -0]: Mentions countLines() may return unexpected values. |
| 21:39:35 | NimBot | Araq/Nimrod devel 7f276fa Grzegorz Adam Hankiewicz [+0 ±1 -0]: Homogenizes docstrings for strutils module.... 4 more lines |
| 21:39:35 | NimBot | Araq/Nimrod devel 81d287f Varriount [+0 ±1 -0]: Merge pull request #1372 from gradha/pr_strutils_docstrings... 2 more lines |
| 21:39:59 | flaviu | vbtt: Only manually, you have to extract the discriminator yourself |
| 21:40:07 | Araq | vbtt: I decided against sum types for performance reasons |
| 21:40:19 | Araq | same reason for exceptions |
| 21:41:30 | vbtt | would sum types really be that much slower? |
| 21:41:45 | vbtt | remember you don't have to call finished() if a sum type is returned. |
| 21:41:48 | dom96 | vbtt: You can always wrap your type inside of a variant type. |
| 21:41:51 | vbtt | so thas the saving. |
| 21:41:54 | dom96 | Problem solved. |
| 21:42:08 | Araq | vbtt: finished is *cheap* |
| 21:42:12 | vbtt | dom96: true, maybe nimrod should provide a next() method that iterates safely over an interator |
| 21:42:21 | flaviu | Araq: Why didn't close() work out? |
| 21:42:44 | vbtt | flaviu: firstly, how would you know when to call close()? |
| 21:43:06 | vbtt | flaviu:it assumes the iterator knows it's about to exit before it actually runs the code till the end. |
| 21:43:08 | flaviu | When finished() returns false |
| 21:43:24 | vbtt | oh |
| 21:43:33 | * | Johz quit (Ping timeout: 240 seconds) |
| 21:43:34 | * | BitPuffin quit (Ping timeout: 250 seconds) |
| 21:44:01 | vbtt | flaviu: the question still is - what happens when you call the iterator and it has no more values? it has to run till the end to determine that it has no more values. |
| 21:44:02 | Araq | what's the problem again? that you can't call it manually without consulting the manual? how is this different from Python then? |
| 21:44:20 | flaviu | Actually, close isn't even needed! |
| 21:44:41 | flaviu | Just have finished() also have the side effect of finishing off the iterator |
| 21:44:46 | vbtt | Araq:the problem is just that it is error prone, and looks ugly. |
| 21:45:17 | vbtt | there were things in Python that were in the manual (except A, B comes to mind) but people still made the mistate over and over and over. It's just hard to remember to do it right. |
| 21:45:29 | vbtt | Then they changed the syntax to `except A as b` |
| 21:46:24 | vbtt | Returning a bogus value just seems wrong. Can it return two values? (success, value) |
| 21:46:33 | vbtt | same thing as variant, but encoded in the multiple values. |
| 21:46:50 | Araq | it does return 2 values... |
| 21:47:10 | Araq | 'success' can be accessed with 'finished' ... |
| 21:48:15 | Varriount | What exactly is being discussed here? Methods of checking if an iterator is finished? |
| 21:48:27 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 21:48:50 | vbtt | Varriount:yes, and it's error prone-ness |
| 21:49:02 | flaviu | Varriount: https://github.com/flaviut/nimrod-by-example/issues/14 |
| 21:49:24 | dom96 | Araq: skype? |
| 21:49:24 | vbtt | If the signature requires me to do `success, value = iter()` then I can't accidentally do 'value = iter()` and go along without realizing it. |
| 21:50:20 | Jehan_ | proc iterate[T](it: iterator(): T {.closure.}): tuple[more:bool, value:T] = |
| 21:50:20 | Jehan_ | result.value = it() |
| 21:50:20 | Jehan_ | result.more = not finished(it) |
| 21:50:22 | * | xenagi quit (Quit: Leaving) |
| 21:50:34 | Varriount | vbtt: Yes, but then you have to do (success, value) everywhere. |
| 21:50:43 | flaviu | just get `finished` to deal with all that |
| 21:50:54 | Varriount | dom96: Oo, is this a skype I can join in with? |
| 21:51:15 | Jehan_ | Varriount: Well, you'll always need both in practice. |
| 21:51:17 | vbtt | Varriount: yes, only when you call the iterator explicitly. Not in for loops. |
| 21:51:23 | flaviu | Make it inline to prevent any inefficiency, two branches will be merged into one |
| 21:52:16 | Varriount | So the complaint is that an iterator must be called an extra time to mark it as finished? |
| 21:52:26 | vbtt | Varriount:what's the issue with doing success, item everywhere? |
| 21:52:28 | flaviu | Varriount: Did you see the bug report? |
| 21:52:39 | Varriount | flaviu: Yes. But it's long. |
| 21:52:55 | flaviu | Here is my countup iterator results: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 |
| 21:53:16 | vbtt | Note the last '0' |
| 21:54:33 | * | Fx00F quit (Ping timeout: 240 seconds) |
| 21:54:38 | vbtt | Anyway, another option is to add a function next(iter, out x) which returns true or false |
| 21:54:46 | vbtt | while (next(iter, out x)) {..} |
| 21:54:52 | vbtt | maybe out should be var, not sure about syntax. |
| 21:55:20 | vbtt | so next() set's the value in x, and returns true if iterator is still running |
| 21:55:37 | Varriount | vbtt: Wouldn't that only work with iterators that don't take parameters? |
| 21:55:38 | vbtt | Just makes it so much easier to use in a while loops. |
| 21:56:01 | vbtt | Varriount:yeah i guess |
| 21:56:21 | vbtt | get(var x, iter, params..) |
| 21:56:29 | * | Fx00F joined #nimrod |
| 21:59:02 | vbtt | but yeah, not very pretty |
| 21:59:59 | Araq | so write some helper and call it a day |
| 22:00:03 | Araq | but again |
| 22:00:20 | Varriount | Araq would probably have an aneurism if someone hacked nimrod to use pythons method (eg, use exceptions) |
| 22:00:21 | Araq | there are very good reasons it is done this way |
| 22:00:51 | vbtt | ok |
| 22:02:07 | vbtt | flaviu:I think the example should be fixed to do (if finished(..) break;) in a while true loop |
| 22:02:16 | vbtt | i.e. do the right thing. |
| 22:02:53 | flaviu | vbtt: Yeah, not really happy with that, but ok |
| 22:03:21 | vbtt | flaviu:but it should show the right way to use iterators. |
| 22:04:09 | vbtt | flaviu:any other solution (exception, different return value) also requires a check after the iterator call or a try/except block anyway. |
| 22:05:20 | flaviu | vbtt: I mean I'm not really happy with the decision to make integer semantics this way |
| 22:05:25 | flaviu | *iterator |
| 22:05:59 | vbtt | flaviu:incomplete text here: http://nimrod-by-example.github.io/procvars/ |
| 22:06:33 | flaviu | vbtt: Ok, I'll fix it soon |
| 22:07:10 | vbtt | flaviu:re iterators, they'll mostly be used with 'for' anyway. |
| 22:07:26 | vbtt | you don't need finished() there, right? |
| 22:08:41 | flaviu | vbtt: What? |
| 22:09:26 | vbtt | flaviu:I'm saying in the majority of cases you don't have to worry about low level iterator semantics because you use 'for' |
| 22:09:48 | Araq | vbtt: exactly. |
| 22:10:13 | flaviu | Yes, but in the other cases, you do have to be very careful because its very easy to do things the wrong way |
| 22:10:51 | vbtt | flaviu: in practice, i rarely use the low level iterator interface in python. I should say 'vast majority' uses 'for' |
| 22:11:13 | vbtt | the manual can point out the 'gotcha' when using the low level semantics. |
| 22:11:27 | vbtt | It's not my preferred choice either, but i can live with it. |
| 22:13:08 | flaviu | I can live with it to, I'm just not happy that I have to accept sub-perfect semantics |
| 22:15:26 | Araq | flaviu: the funny thing is: your "perfect semantics" are unsound |
| 22:15:34 | vbtt | flaviu:do you cover tuples in your tutorial? |
| 22:16:00 | flaviu | vbtt: I don't remember, but I don't think I've gotten there yet |
| 22:16:12 | vbtt | would be good to add |
| 22:16:59 | flaviu | Also, I don't understand why finished can't be implemented as `if finishedCheck: \n if lastNotExecuted: executeLast()\n return true else: return false` |
| 22:17:01 | vbtt | Araq:what is unsound about a sum type to represent two possible conditions? Basically a Maybe type? |
| 22:17:11 | NimBot | Araq/Nimrod devel 5a29950 Varriount [+0 ±1 -0]: Update nimrod.ini |
| 22:18:00 | Araq | vbtt: that's not the problem. the problem is that he thinks he can tell when the iterator finished before it finished ;-) |
| 22:18:10 | vbtt | flaviu: you can never know if the iterator will end without actually running it? |
| 22:18:59 | vbtt | flaviu: you have to run the iterator until you hit a yield or fall off the end of the function, only then you know that you have a value, or are actually done. |
| 22:19:23 | vbtt | you can't foresee that - it's theoretically impossible. |
| 22:19:33 | flaviu | Araq: huh, thats a good point |
| 22:19:58 | * | Matthias247 joined #nimrod |
| 22:21:22 | vbtt | basically you can't have a goingToFinish() function, only alreadyFinished(). Which means the problem of the last return value remains. |
| 22:21:24 | flaviu | haskell has these things easy :( |
| 22:21:38 | Araq | vbtt: exactly. |
| 22:21:50 | Araq | I tried 2x to do better btw |
| 22:22:47 | Araq | then I figured it's not possible and noted Lua does it the same way |
| 22:23:09 | vbtt | heh, you tried to solve the halting problem? ;) |
| 22:23:18 | flaviu | Araq: What if we get rid of indefinate while loops? |
| 22:23:25 | flaviu | and recursion |
| 22:23:41 | vbtt | I think this is equivalent to the halting problem. |
| 22:23:48 | flaviu | vbtt: I think so too |
| 22:24:14 | flaviu | But the language doesn't have to be turing complete :P |
| 22:24:22 | vbtt | what fun is that? |
| 22:24:28 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 22:24:34 | flaviu | Anyway, I consider the halting problem a sufficient excuse for ugly semantics |
| 22:25:06 | Jehan_ | Araq: That problem is solvable. |
| 22:25:30 | Jehan_ | Execute an iterator step upon iterator creation. Store value. |
| 22:25:44 | Jehan_ | Upon call, do that again and return previously stored value. |
| 22:25:47 | vbtt | So you're pre-running. |
| 22:25:51 | flaviu | Jehan_: This isn't haskell |
| 22:26:01 | Jehan_ | vbtt: Yup. Which has its own potential issues, of course. |
| 22:26:03 | flaviu | Its going to cause weird issues |
| 22:26:13 | vbtt | Different semantics, not always desireable. At least I know nothing runs on iterator creation, I think that's better. |
| 22:26:14 | Jehan_ | flaviu: Only if the iterator has side effects. |
| 22:26:46 | flaviu | Jehan_: But unfortunately, this isn't haskell, and I don't think its a good idea to have two types of closure iterators |
| 22:26:53 | Jehan_ | vbtt: Semantics are the same, aside from side effects (and finished() working differently). |
| 22:27:04 | Jehan_ | flaviu: Not sure what Haskell has to do with that, to be honest. |
| 22:27:16 | flaviu | Isn't Haskell supposed to be pure? |
| 22:27:32 | flaviu | without any side effects anywhere? |
| 22:27:34 | vbtt | Jehan_:right, side effects and time taken. |
| 22:27:48 | Jehan_ | flaviu: Yeah, but if you have side effects in an iterator that depend on precisely those semantics, your code has problems. |
| 22:27:57 | vbtt | so, IMO, not the same semantics. i |
| 22:28:39 | Jehan_ | vbtt: Time taken only with respect to when code is executed. Total time taken should be the same (except for a constant factor to deal with the different execution model). |
| 22:29:04 | vbtt | Jehan_:I can choose to not run an iterator or not resume it (i.e. break) |
| 22:29:24 | vbtt | In practice, you could have db lookups etc in there which will unnecessarily run. |
| 22:29:37 | Jehan_ | vbtt: Yes, but you'll be executing it the same number of times in either model. |
| 22:29:48 | vbtt | In pure computations, it's all good (except the time taken) but I don't think it's good in practice to pre-run. |
| 22:30:03 | vbtt | Jehan_:no, not if I break or decide not to iterate. |
| 22:30:27 | Jehan_ | vbtt: Yeah, but only in select situations. |
| 22:30:29 | vbtt | I guess it's a different set of tradeoffs. |
| 22:30:40 | flaviu | Jehan_: I'm 100% sure thats going to create problems that are harder to explain than the current problems |
| 22:30:41 | vbtt | You can always wrap the current one to make it pre-running. |
| 22:30:44 | vbtt | And vice versa. |
| 22:30:48 | Jehan_ | I do find it fascinating how everybody is defending Araq's implementation choice now against me. :) |
| 22:31:13 | vbtt | I didn't know haskell pre-runs the iterators. |
| 22:31:26 | vbtt | You also need a place to store it. |
| 22:31:32 | vbtt | Can't go on the stack anymore. |
| 22:31:33 | flaviu | Jehan_: Because Araq pointed out that it is even theoretically impossible to solve this problem |
| 22:31:42 | Jehan_ | Not sure if you can call it "pre-running" in a lazy language. |
| 22:32:17 | Jehan_ | Note also that you could do it lazily in Nimrod, too. |
| 22:32:37 | Jehan_ | I.e. if either finished(iter) or iter() is called. |
| 22:32:54 | Jehan_ | Obviously, that would be extra overhead. |
| 22:33:28 | vbtt | Jehan_:not sure what you mean 'lazily' |
| 22:34:04 | flaviu | vbtt: Calculate iter.next() when finished() is called and cache it somewhere |
| 22:34:16 | Jehan_ | vbtt: On demand. |
| 22:35:01 | Jehan_ | Closure iterators need an environment anyway, so that's where you can store it. |
| 22:35:36 | Jehan_ | Anyhow, I think the easiest solution would be to have an iterate() proc that does the test and evaluation in one single step. |
| 22:36:17 | vbtt | evaluation, then test :) |
| 22:36:25 | Jehan_ | E.g.: |
| 22:36:36 | Jehan_ | proc iterate[T](it: iterator(): T {.closure.}): tuple[more:bool, value:T] = |
| 22:36:36 | Jehan_ | result.value = it() |
| 22:36:36 | Jehan_ | result.more = not finished(it) |
| 22:36:36 | Jehan_ | proc iterate[T](it: iterator(): T {.closure.}, value: var T): bool = |
| 22:36:36 | Jehan_ | value = it() |
| 22:36:37 | Jehan_ | result = not finished(it) |
| 22:36:52 | vbtt | why should finished() run the iterator? I think that behavior is unintuitive |
| 22:36:59 | vbtt | finished() should just return the state, not affect it. |
| 22:37:27 | flaviu | because there is no other way to figure out if it is really finished |
| 22:37:40 | flaviu | Static analysis won't work because of the halting problem |
| 22:38:12 | vbtt | actually there's a simple way to prove static analysis can't work. If (random() > .5) yield else return |
| 22:38:45 | vbtt | oh i see what you mean. |
| 22:39:01 | vbtt | but I think it's nice that finished doesn't resume the iterator, but calling it does. |
| 22:39:20 | vbtt | nimrod has a side-effects - I want to know when what code runs. |
| 22:40:01 | flaviu | vbtt: If you have the seed to random, you can prove that |
| 22:42:05 | Varriount | Hm.. I could try to optimize this piece of code, or I could not go insane... |
| 22:42:32 | flaviu | Varriount: What code? |
| 22:42:51 | flaviu | If its WinAPI, just walk away :P |
| 22:42:52 | Varriount | flaviu: Second try at file event notification code. |
| 22:43:09 | flaviu | Its good enough, just stress test it a bit |
| 22:43:14 | Varriount | If you'll recall, to monitor a specific file for events, you have to have a custom filter. |
| 22:44:03 | Varriount | flaviu: Essentially, I'm wondering if I can hand-tail-call-optimize this complicated procedure (and if it's worth it) |
| 22:44:08 | flaviu | I think you've spent enough time on that, optimize it when someone complains |
| 22:44:12 | vbtt | moving on. if i had to write a biggish project (5k-10k lines), using networking, filesystem etc. would you recommend nimrod as production ready or should I wait for 1.0? |
| 22:44:28 | flaviu | I don't know how async networking works |
| 22:44:31 | vbtt | I'm concerned about incompatible changes and bugs. |
| 22:44:55 | Varriount | vbtt: How low level are you willing to go, and how many fancy syntax tricks will you be pulling? |
| 22:45:00 | flaviu | dom96 or Matthias247 would be the ones to ask about networking |
| 22:45:44 | vbtt | Varriount: I want to stay as high level as I can. But not too many fancy syntax tricks. |
| 22:46:01 | vbtt | I don't need metaprogramming, I may use some small macros, not sure. |
| 22:46:08 | vbtt | why? |
| 22:46:23 | flaviu | because macros tend to be buggy |
| 22:46:24 | Varriount | vbtt: Compilers are 90% corner cases. |
| 22:46:29 | flaviu | less so recently though |
| 22:46:52 | Varriount | vbtt: Using fancy features tend to mean eating more corners. |
| 22:46:59 | Jehan_ | vbtt: The Pascal + generics subset of Nimrod is pretty solid. No idea how well the standard library meets your needs (depends on OS and exact application domain). |
| 22:47:45 | vbtt | actually async stuff would be nice but I belive that's not stable. |
| 22:47:48 | Jehan_ | And what flaviu said about macros being still very much an "under development" thing. |
| 22:48:17 | vbtt | interesting, I thought macros and templates were old, mature features. |
| 22:48:27 | flaviu | templates yes, macros not so much |
| 22:48:27 | vbtt | isn't a lot of nimrod itself using metaprogramming? |
| 22:48:31 | vbtt | I see. |
| 22:48:33 | Jehan_ | I mostly use the aforementioned Pascal + generics subset and have had very few problems recently. |
| 22:48:36 | vbtt | ok, I'll stick to templates then. |
| 22:49:06 | flaviu | You can use macros, but its going to be 50% implementing stuff, 50% debugging the compiler |
| 22:49:30 | vbtt | don't want to do that :p |
| 22:49:31 | Jehan_ | Only problem with templates is sometimes when you try to do fancy stuff with type inference. |
| 22:50:06 | * | mwbrown quit (Ping timeout: 240 seconds) |
| 22:50:12 | vbtt | I see. |
| 22:50:34 | vbtt | thanks guys. |
| 22:50:39 | Araq | hey |
| 22:50:48 | Araq | macros are pretty stable ... *cough* |
| 22:51:18 | Araq | well ... most things are regressions because I thought it would be good idea to create a new VM from scratch |
| 22:51:29 | Jehan_ | Heh. :) |
| 22:51:41 | vbtt | Araq:did the new vm pay off? |
| 22:51:59 | flaviu | vbtt: Its pretty fast if thats what you're looking for |
| 22:52:05 | Jehan_ | Araq: The last time I needed a VM in a running program, I was lazy and compiled to Lua. :) |
| 22:52:24 | flaviu | Jehan_: There is a half-done Lua backend |
| 22:53:12 | vbtt | I think he means the compile time VM. |
| 22:53:20 | Jehan_ | vbtt: Yup. |
| 22:53:21 | vbtt | a VM that executes nimrod code, is that right? |
| 22:53:29 | Varriount | flaviu: Stop giving advice that will lead to Jehan_ being eaten by rabid gerbils. |
| 22:53:40 | Araq | vbtt: I had reports that compile times went from minutes to seconds |
| 22:53:45 | Araq | for macro heavy code |
| 22:53:48 | vbtt | nice |
| 22:54:04 | vbtt | who cares if it works, as long as it's fast ;) |
| 22:54:13 | Araq | but I wouldn't do it again ... |
| 22:54:13 | flaviu | Varriount: What gerbils? I don't have any! |
| 22:55:00 | Araq | vbtt: well the old evaluation engine had its bugs too |
| 22:55:09 | dom96 | vbtt: You should definitely use the async stuff. Me and Araq just spent some time hunting a bug in it and found it thankfully. |
| 22:55:10 | Araq | but in retrospect it was surprisingly stable |
| 22:55:46 | dom96 | vbtt: It may not be the last bug left but we'll get there. |
| 22:56:00 | flaviu | dom96: Great, good to know |
| 22:56:38 | * | Ven joined #nimrod |
| 22:57:49 | Jehan_ | For what it's worth, the language I was compiling to Lua was a Datalog dialect … I wonder how many people are familiar with that still. |
| 22:57:57 | Araq | Jehan_: well your solution didn't occur to me, but it looks like an awful transformation |
| 22:58:25 | Jehan_ | Araq: I had the advantage that I was compiling a pretty simple language. |
| 22:58:29 | Araq | and since we just found yet another bug in the "simple" transformation ... |
| 22:58:44 | Jehan_ | Or are you talking about iterators? |
| 22:58:50 | Araq | yes |
| 22:58:53 | Jehan_ | Gotcha. |
| 22:59:17 | * | superfunc quit (Ping timeout: 250 seconds) |
| 22:59:27 | Jehan_ | As I said, I'd put an `iterate` proc or two in system.nim (or some yet to be written itertools.nim) and tell people to use that. |
| 22:59:29 | * | BitPuffin joined #nimrod |
| 22:59:37 | flaviu | Araq: I haven't made any feature requests in the the last hour, so I'd like to be able to reuse names in variant types |
| 22:59:59 | flaviu | If they have the same types of course |
| 23:00:31 | flaviu | *10 miniutes |
| 23:01:32 | Araq | er ... pull it out of the case section into the common section? |
| 23:01:52 | flaviu | I want some of the type variants to have that name, but not all |
| 23:02:08 | flaviu | *field |
| 23:02:50 | Araq | ok, PRs welcome |
| 23:03:22 | Araq | :P |
| 23:03:49 | flaviu | Well, I guess I can try if thats the only way of getting it |
| 23:04:38 | Araq | it's an interesting problem how to lay out these fields in memory |
| 23:04:47 | Araq | unless you pick the easy solution |
| 23:04:57 | Araq | which is to pull them out of the 'case' |
| 23:05:16 | Araq | but generate a guard for every access like if they are in the case |
| 23:06:37 | * | darkf joined #nimrod |
| 23:06:37 | Araq | ML doesn't allow this btw, so it's likely wrong/unsound ;-) |
| 23:07:50 | flaviu | Well, I found a russian TAPL. Very useful |
| 23:08:06 | flaviu | Native PDF at least, not a scan :D |
| 23:10:22 | Araq | the syntax of typing rules sucks, no wonder people don't read type theory |
| 23:11:28 | dom96 | good night |
| 23:11:29 | Araq | so hard to read ... you never know how to parse it ... how hard can it be to use a few more () ? |
| 23:15:49 | Jehan_ | I think it's just as with math papers in general that type theory papers tend to be pretty dense and assume a fair amount of knowledge. |
| 23:16:43 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 23:16:50 | Jehan_ | It still baffles me how complicated the Haskell people can make a simple concept such as monads in their "guides". |
| 23:20:41 | Araq | Jehan_: no, the notation is explained perfectly fine |
| 23:20:57 | Araq | but it still sucks ;-) |
| 23:21:26 | Araq | IMHO math syntax is mediocre |
| 23:21:27 | Jehan_ | "explained perfectly fine" does not mean the same as "readable" and "doesn't assume a lot of prior knowledge". |
| 23:21:50 | Araq | lots of math's notations are superb |
| 23:21:57 | Jehan_ | Example: Try to debug a Turing machine. |
| 23:22:05 | Araq | and lots of math's notations are crap |
| 23:22:25 | Jehan_ | It's a matter of getting accustomed to it, honestly. |
| 23:22:49 | Jehan_ | Math notation generally makes heavy use of overloading, so to speak. |
| 23:23:06 | flaviu | Araq: Can you be more specific? |
| 23:23:50 | Jehan_ | But the same is true for most regular languages. |
| 23:24:16 | Jehan_ | Eh, with regular languages I mean English, French, and such, not regular languages in the Chomsky hierarchy sense. |
| 23:24:49 | Jehan_ | Come to think of it, I just gave a self-referential example of overloading in natural languages. :) |
| 23:25:24 | Araq | flaviu: fractions are very well done, it's easy to see valid and useful transformations |
| 23:25:56 | Araq | compare it to (x + 1) : 4 |
| 23:26:50 | Araq | in general the 2D layout helps |
| 23:27:22 | flaviu | That is a werider way of putting it, but its easy to translate that to (x+1)/4 |
| 23:28:17 | Araq | integrals are weird with the 'dx' suffix (yes I know about the substitution rules) |
| 23:28:59 | Fx00F | how about integrals with the 'dx' prefix? |
| 23:29:20 | * | Trustable quit (Quit: Leaving) |
| 23:29:25 | Araq | 'dx' itself is problematic, it could mean d*x |
| 23:29:30 | Araq | speaking of which |
| 23:29:37 | Araq | the implicit * sucks |
| 23:29:55 | flaviu | I'm not going to argue about dx's ambiguity, its weird |
| 23:30:01 | Araq | it means cos could also mean c*o*s |
| 23:30:30 | flaviu | Its rendered totally differently: $$\cos$$ $$cos$$ |
| 23:30:58 | flaviu | http://i.imgur.com/Ww3tpQy.png |
| 23:31:06 | Fx00F | you can think of the d as the \ in lambda calculus |
| 23:31:57 | Araq | | for "divides" sucks ... |
| 23:32:06 | Araq | |a| | 4 |
| 23:32:08 | flaviu | But I guess that doesn't matter when hand writing |
| 23:32:48 | Araq | flaviu: everybody writes math by hand |
| 23:33:03 | Jehan_ | Araq: As I said, math notation is much like a natural language in that context matters for meaning. |
| 23:33:16 | adoniscik | can you define generic procs so you can recognize proc(a:T, b:S) as well as proc(b:S, a:T) (commutativity) |
| 23:33:48 | flaviu | $$\text{Not everyone}$$ |
| 23:34:13 | Araq | Jehan_: yes, but that's a shitty foundation |
| 23:34:26 | flaviu | http://i.imgur.com/HIgWRM4.png |
| 23:34:43 | Jehan_ | Araq: Well, its a foundation that was created centuries ago. |
| 23:34:46 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 23:34:59 | Jehan_ | And you know how hard it can be to break backward compatibility. :) |
| 23:35:36 | Araq | the problem is that people need to acknowledge that it's a problem |
| 23:35:58 | Araq | and it is IMO |
| 23:36:05 | Araq | it hinders progress |
| 23:36:35 | Jehan_ | Araq: Does it? |
| 23:36:39 | flaviu | Araq: About the fancy variants: The compiler could scrample the names, that would work |
| 23:36:56 | Araq | flaviu: no it wouldn't |
| 23:37:05 | Jehan_ | You're not going to develop new mathematical theorems without immersing yourself first in math for years, at which point it becomes a minor problem. |
| 23:37:16 | Araq | obj.foo # foo is in 2 branches |
| 23:37:30 | Jehan_ | Downtranslating the concepts into normal human-speak is a different story, but that's usually not just a matter of notation. |
| 23:38:14 | flaviu | Araq: You're right. I forgot that variant branch isn't attached to the type |
| 23:38:41 | flaviu | Well, easiest solution is to make my own poor-man's variant with methods to actually check and fetch what is needed |
| 23:39:09 | Araq | Jehan_: many people could benefit from more math knowledge but reading math books simply is too hard. And that's not because it's not "english like" enough |
| 23:39:51 | Araq | it's because the syntax is cryptic |
| 23:39:55 | Araq | for instance |
| 23:40:29 | Araq | many people translate symbols into the corresponding *sounds* in their heads |
| 23:40:35 | flaviu | Jehan_: http://www.amazon.com/s/ref=nb_sb_noss_1?field-keywords=math%20for%20dummies |
| 23:40:55 | adoniscik | does nimrod have something equivalent to python's enumerate? |
| 23:40:56 | Araq | this stops working when you only see greek symbols and don't know them very well |
| 23:41:07 | def- | adoniscik: for i, x in xs: |
| 23:41:17 | def- | adoniscik: or what do you mean? |
| 23:41:19 | Araq | so yes, greek symbols really are harder to read than a-z |
| 23:41:58 | flaviu | Araq: remember how I kept bugging you about a and b in the VM? Math is the same |
| 23:42:23 | def- | adoniscik: pairs(), and it's automatically used when you do "for i, x in ..." |
| 23:42:28 | adoniscik | def-, let me try ! |
| 23:42:40 | flaviu | Its hard to read because of one-letter symbols with meaning, but once you're used to it, you don't see how other people could possibly have issues with it |
| 23:43:11 | flaviu | Not trying to bash on you, just trying to put more perspective here |
| 23:43:21 | Araq | flaviu: I am talking about a vs alpha (can't type it easily here) |
| 23:43:34 | flaviu | $$\alpha$$ |
| 23:44:29 | Araq | and alpha is widely known so it's a bad example |
| 23:45:22 | Jehan_ | import sequtils |
| 23:45:22 | Jehan_ | proc enumerate[T](s: seq[T]): seq[tuple[a: int, b: T]] = |
| 23:45:22 | Jehan_ | zip(toSeq(1..len(s)), s) |
| 23:45:22 | Jehan_ | echo enumerate(@["x", "y"]) |
| 23:46:02 | adoniscik | if you two openarrays and do something on them what should you return that's the same size since you can't return openarrays? |
| 23:46:04 | Araq | Jehan_: pairs does the trick |
| 23:46:11 | adoniscik | if you take... |
| 23:46:16 | Araq | adoniscik: seq |
| 23:46:38 | adoniscik | thanks, Araq. No performance hit over straight arrays? |
| 23:46:46 | adoniscik | or is that not a choice? |
| 23:47:01 | def- | adoniscik: if you know the size create it with newSeq[type](size) |
| 23:47:16 | def- | otherwise adding each element is slower |
| 23:47:36 | adoniscik | that's the thing; the proc knows the length when it gets them. |
| 23:47:43 | adoniscik | not at compile time |
| 23:47:49 | Jehan_ | Araq: Oops, misremembered what enumerate does. |
| 23:47:56 | flaviu | if you know the size and want to use .add, do newSeq[type](size); mySeq.setLen(0) |
| 23:48:28 | def- | flaviu: that should be called newSeqOfCap |
| 23:48:38 | flaviu | Doesn't exist last time I checked |
| 23:48:46 | Fx00F | def-: in that case, is it amortized time slower? |
| 23:48:47 | Araq | yeah but system.nim still lacks it |
| 23:48:53 | def- | yes, just saying |
| 23:49:50 | adoniscik | def-, the proc knows the length of the result and no adds will take place afterward. Is it possible to use array and somehow set the length parameter using generics? |
| 23:50:08 | def- | adoniscik: no |
| 23:50:14 | Araq | adoniscik: yes |
| 23:50:30 | flaviu | adoniscik: Sure, proc foo[I](in: bar): Array[I, whatever] |
| 23:50:31 | adoniscik | proc(x: openarray[T]) : array[foo, T] |
| 23:51:02 | adoniscik | where my foo = x.len or something |
| 23:51:08 | def- | ah, i thought you mean when you can get variable size arrays out |
| 23:51:23 | Araq | proc foo[Idx, T](x: array[Idx, T]): array[Idx, T] |
| 23:51:25 | adoniscik | it is variable, because x.len is |
| 23:51:29 | def- | Fx00F: hi again. what makes it slower are the new memory allocations on resize |
| 23:51:42 | Araq | but not with openArray, adoniscik |
| 23:51:50 | adoniscik | I see, let me try it that way. thanks guys |
| 23:55:11 | * | untitaker quit (Quit: ZNC - http://znc.in) |
| 23:56:21 | * | untitaker joined #nimrod |
| 23:59:07 | * | silasm quit (Quit: leaving) |
