| 00:07:48 | * | Trustable quit (Remote host closed the connection) |
| 00:07:56 | * | bcinman joined #nim |
| 00:11:08 | * | Jehan_ quit (Quit: Leaving) |
| 00:12:15 | * | Jehan_ joined #nim |
| 00:26:18 | * | dtscode is now known as charmander |
| 00:30:26 | * | Jehan_ quit (Quit: Leaving) |
| 00:31:02 | * | Kingsquee joined #nim |
| 00:32:17 | * | charmander is now known as dtscode |
| 00:48:33 | * | mrkishi quit (Ping timeout: 244 seconds) |
| 00:53:30 | * | brson quit (Ping timeout: 264 seconds) |
| 01:05:00 | flaviu | I can't figure out how to use relative paths in --path |
| 01:05:20 | flaviu | It supposedly works, but I still get errors about undefined symbols. |
| 01:06:17 | * | drewsrem joined #nim |
| 01:09:57 | * | irrequietus quit () |
| 01:16:02 | gmpreussner|work | flaviu: it's relative to the module being compiled, i think |
| 01:16:38 | gmpreussner|work | erm, actually, im not sure |
| 01:16:54 | gmpreussner|work | it might be relative to the nim.cfg file |
| 01:16:58 | gmpreussner|work | hmm |
| 01:17:38 | gmpreussner|work | this is how i use it. it works for me: https://github.com/nimious/io-myo/blob/master/examples/nim.cfg |
| 01:19:59 | flaviu | That's what I did, dunno why it didn't work. I'll try again and see. |
| 01:25:51 | * | bcinman quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 01:30:02 | flaviu | https://i.imgur.com/DWx1Tr6.png |
| 01:30:03 | flaviu | pretty |
| 01:34:33 | * | drewsrem quit (Quit: Leaving) |
| 01:55:03 | * | jholland quit (Quit: Connection closed for inactivity) |
| 01:56:04 | * | davidhq joined #nim |
| 01:58:58 | * | a5i joined #nim |
| 02:23:10 | * | bcinman joined #nim |
| 02:24:34 | * | BitPuffin quit (Ping timeout: 255 seconds) |
| 02:26:11 | * | endragor joined #nim |
| 02:26:35 | * | saml_ quit (Quit: Leaving) |
| 02:34:36 | * | endragor_ joined #nim |
| 02:37:16 | * | endragor quit (Ping timeout: 240 seconds) |
| 02:43:43 | * | jefus_ quit (Quit: Leaving) |
| 02:45:53 | * | darkf joined #nim |
| 02:58:26 | * | endragor joined #nim |
| 03:01:04 | * | endragor_ quit (Ping timeout: 245 seconds) |
| 03:07:18 | * | davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 03:22:13 | * | davidhq joined #nim |
| 03:22:56 | * | davidhq quit (Client Quit) |
| 03:24:16 | * | Jehan_ joined #nim |
| 03:50:05 | * | Jehan_ quit (Quit: Leaving) |
| 03:50:33 | * | Jehan_ joined #nim |
| 03:52:30 | * | bcinman quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 04:02:08 | * | bcinman joined #nim |
| 04:03:13 | * | bcinman quit (Client Quit) |
| 04:07:18 | * | Jehan_ quit (Quit: Leaving) |
| 04:09:00 | * | Jehan_ joined #nim |
| 04:16:55 | * | Jehan_ quit (Quit: Leaving) |
| 04:20:52 | * | wb quit (Ping timeout: 252 seconds) |
| 04:21:39 | * | Jehan_ joined #nim |
| 04:25:24 | * | bcinman joined #nim |
| 04:48:48 | * | TEttinger joined #nim |
| 04:52:07 | * | Jehan_ quit (Quit: Leaving) |
| 04:53:26 | * | Jehan_ joined #nim |
| 05:03:08 | * | gever-gever joined #nim |
| 05:19:42 | * | Kingsquee quit (Quit: Konversation terminated!) |
| 05:20:58 | * | Kingsquee joined #nim |
| 05:29:34 | * | Jehan_ quit (Quit: Leaving) |
| 05:35:22 | * | Jehan_ joined #nim |
| 05:55:58 | * | Arrrrr joined #nim |
| 05:56:31 | Arrrrr | Hello Nimrod. |
| 05:57:03 | * | brson joined #nim |
| 05:58:11 | * | mpthrapp_ quit (Quit: No Ping reply in 180 seconds.) |
| 06:01:00 | * | mpthrapp joined #nim |
| 06:06:23 | * | mpthrapp quit (Quit: No Ping reply in 180 seconds.) |
| 06:07:43 | * | mpthrapp joined #nim |
| 06:09:57 | * | Jehan_ quit (Quit: Leaving) |
| 06:09:58 | reactormonk | Arrrrr, it's nim now. |
| 06:11:57 | * | Jehan_ joined #nim |
| 06:20:03 | * | mpthrapp quit (Quit: No Ping reply in 180 seconds.) |
| 06:22:48 | * | mpthrapp joined #nim |
| 06:25:37 | * | Jehan_ quit (Quit: Leaving) |
| 06:27:25 | * | Jehan_ joined #nim |
| 06:30:54 | * | Jehan_ quit (Client Quit) |
| 06:31:49 | * | Jehan_ joined #nim |
| 06:32:17 | Kingsquee | Rod++ |
| 06:40:16 | * | Jehan_ quit (Quit: Leaving) |
| 06:40:38 | reactormonk | Kingsquee, yeah, bad annotation. purely publicity |
| 06:42:00 | * | Jehan_ joined #nim |
| 06:44:49 | * | MagusOTB quit (Ping timeout: 252 seconds) |
| 06:48:56 | * | gsingh93 quit (Ping timeout: 240 seconds) |
| 06:49:26 | Arrrrr | Who wrote the tutorial? |
| 06:50:19 | * | mpthrapp quit (Ping timeout: 252 seconds) |
| 06:51:53 | * | mpthrapp joined #nim |
| 06:53:24 | * | repax joined #nim |
| 06:56:17 | * | Ven joined #nim |
| 06:56:20 | * | endragor quit (Ping timeout: 276 seconds) |
| 06:58:56 | * | mpthrapp quit (Ping timeout: 240 seconds) |
| 06:59:31 | * | mpthrapp joined #nim |
| 07:04:24 | * | johnsoft quit (Ping timeout: 252 seconds) |
| 07:05:49 | * | mpthrapp quit (Quit: No Ping reply in 180 seconds.) |
| 07:06:04 | * | Jehan_ quit (Quit: Leaving) |
| 07:06:44 | * | BlaXpirit joined #nim |
| 07:06:48 | * | xcombelle joined #nim |
| 07:07:25 | * | Jehan_ joined #nim |
| 07:07:46 | * | xcombelle quit (Client Quit) |
| 07:07:50 | * | xcombelle_ joined #nim |
| 07:07:52 | * | xcombelle_ quit (Remote host closed the connection) |
| 07:08:05 | * | xcombelle joined #nim |
| 07:12:29 | * | mpthrapp joined #nim |
| 07:15:16 | * | Jehan_ quit (Quit: Leaving) |
| 07:17:04 | * | Jehan_ joined #nim |
| 07:24:05 | * | HakanD__ joined #nim |
| 07:25:56 | * | mpthrapp quit (Ping timeout: 240 seconds) |
| 07:28:44 | * | mpthrapp joined #nim |
| 07:31:15 | xcombelle | hi |
| 07:33:24 | Arrrrr | hello friend |
| 07:35:51 | Arrrrr | Should i read the tutorial part II or directly jump into the manual? |
| 07:35:56 | * | mpthrapp quit (Quit: No Ping reply in 180 seconds.) |
| 07:36:03 | * | endragor joined #nim |
| 07:36:26 | reactormonk | Arrrrr, tutorial has lots of information that isn't in the manual |
| 07:36:51 | Arrrrr | Ok, i'm asking this because of this sentence: "Note that this document is somewhat obsolete as the manual contains many more examples of the advanced language features." |
| 07:36:55 | Arrrrr | I wasn't sure |
| 07:37:03 | reactormonk | Arrrrr, if you clone nim, git blame this file: https://github.com/Araq/Nim/blob/devel/doc/tut1.txt |
| 07:37:19 | reactormonk | Arrrrr, yeah, it's not really complete. IT's just a rough brush. |
| 07:37:19 | * | brson quit (Ping timeout: 245 seconds) |
| 07:37:22 | * | mpthrapp joined #nim |
| 07:37:48 | reactormonk | oh, you're reading II |
| 07:37:53 | reactormonk | yeah, might not be too informative |
| 07:38:22 | reactormonk | but it still ahs a few things |
| 07:38:55 | Arrrrr | The, do you recommend me to read it? or should i save my time and go for the manual |
| 07:40:27 | * | HakanD__ quit (Read error: Connection reset by peer) |
| 07:40:53 | * | HakanD__ joined #nim |
| 07:44:35 | reactormonk | skip it. |
| 07:45:05 | Arrrrr | Thanks. |
| 07:48:15 | * | endragor quit (Remote host closed the connection) |
| 07:50:31 | * | Ven quit (Read error: Connection reset by peer) |
| 07:50:47 | * | bjz joined #nim |
| 07:52:22 | BlaXpirit | i say reading the tutorials is necessary |
| 07:57:25 | * | mpthrapp quit (Ping timeout: 252 seconds) |
| 08:01:24 | * | Jehan_ quit (Quit: Leaving) |
| 08:01:41 | * | mpthrapp joined #nim |
| 08:03:15 | HakanD__ | I agree, there are some things better explained in tutorials, but there are some outdated things also, if you are using devel |
| 08:03:42 | HakanD__ | https://nim-by-example.github.io/ <-- this is great also, for basics |
| 08:04:15 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 08:06:36 | * | Jehan_ joined #nim |
| 08:08:30 | * | mpthrapp quit (Quit: No Ping reply in 180 seconds.) |
| 08:10:21 | * | coffeepot joined #nim |
| 08:10:22 | * | mpthrapp joined #nim |
| 08:11:25 | Arrrrr | Thanks for the link HakanD__ |
| 08:12:07 | * | mpthrapp_ joined #nim |
| 08:13:52 | Arrrrr | "arr.map proc(some: var int) = echo(some, " squared = ", some*some)" |
| 08:14:27 | Arrrrr | Could this be written simple as "arr.map (some) = echo(some, " squared = ", some*some)" ? |
| 08:14:36 | * | mpthrapp quit (Ping timeout: 240 seconds) |
| 08:14:37 | Arrrrr | or something like that |
| 08:18:00 | * | Sembei joined #nim |
| 08:21:31 | * | Jehan_ quit (Quit: Leaving) |
| 08:21:40 | * | Sembei quit (Excess Flood) |
| 08:22:56 | * | Sembei joined #nim |
| 08:26:07 | * | Ven joined #nim |
| 08:26:38 | * | Sembei quit (Excess Flood) |
| 08:27:50 | * | Sembei joined #nim |
| 08:31:07 | * | Sembei quit (Max SendQ exceeded) |
| 08:32:31 | * | Sembei joined #nim |
| 08:33:16 | Araq | Arrrrr: from furure import `=>` |
| 08:33:21 | Araq | *future |
| 08:33:36 | * | mpthrapp_ quit (Ping timeout: 240 seconds) |
| 08:34:17 | * | mpthrapp joined #nim |
| 08:35:43 | * | Sembei quit (Max SendQ exceeded) |
| 08:37:22 | * | Sembei joined #nim |
| 08:38:43 | * | mpthrapp quit (Ping timeout: 245 seconds) |
| 08:39:04 | * | mpthrapp joined #nim |
| 08:40:41 | * | Sembei quit (Max SendQ exceeded) |
| 08:41:59 | Arrrrr | it gives me an error http://pastebin.com/wZYUhexG |
| 08:43:34 | * | milosn quit (Ping timeout: 245 seconds) |
| 08:45:48 | * | mpthrapp quit (Ping timeout: 245 seconds) |
| 08:46:51 | fowl | arr.map((i:var int) => echo(i)) |
| 08:48:26 | Arrrrr | I got this: "futures.nim(4, 10) Error: cannot infer the return type of the proc" |
| 08:49:59 | * | mpthrapp joined #nim |
| 08:50:24 | HakanD__ | The fowl's example is working for me |
| 08:51:00 | Arrrrr | I'm using 0.10.2 |
| 08:51:04 | Arrrrr | Maybe is that |
| 08:51:10 | HakanD__ | Yup |
| 08:51:32 | Arrrrr | Ok, is nice to know it exists anyway |
| 08:51:46 | coffeepot | mostly best to use the devel branch of nim as there's a lot of fixes and stuff in there of late |
| 08:52:14 | Araq | "of late"? I cannot remember when that wasn't true :P |
| 08:52:20 | HakanD__ | (: |
| 08:52:22 | coffeepot | haha good point |
| 08:52:42 | Araq | it makes me wonder why we even have releases ... :-( |
| 08:52:54 | Araq | 0.10.4 will be the same |
| 08:53:01 | Araq | once out, already outdated |
| 08:53:01 | HakanD__ | Araq: do we have a timeline for 1.0? |
| 08:54:03 | coffeepot | well there's magnitudes to "out of date", the current release on the website seems to be particularly out of date |
| 08:54:47 | coffeepot | i don't think it's a bad thing that the language is moving quickly though, it's <1.0 after all |
| 08:55:47 | Araq | HakanD__: meh, certainly not before June |
| 08:55:50 | * | mpthrapp_ joined #nim |
| 08:56:02 | * | mpthrapp quit (Ping timeout: 250 seconds) |
| 08:56:26 | fowl | is this dumb or useful https://gist.github.com/fowlmouth/ac51baef7956af1ebdf8 |
| 08:57:28 | Araq | fowl: that is actually exactly what I hoped you would be working on |
| 08:57:58 | Araq | :D |
| 08:58:19 | fowl | Araq, i can expose the body of concept easily but i would like to instantiate it to capture the symbols mentioned instead of relying on memberF[T](globalFunctionName) |
| 08:58:45 | fowl | i think the best way to do that is put it in an inner function that doesnt get called |
| 08:59:42 | HakanD__ | man, that's exactly what I was trying to do for a few days, fighting with the complier |
| 09:02:39 | fowl | HakanD__, what trouble were you having? |
| 09:03:00 | * | mpthrapp_ quit (Ping timeout: 244 seconds) |
| 09:05:07 | * | mpthrapp joined #nim |
| 09:06:49 | HakanD__ | lots of silly things, I'm new to Nim, and new to statically typed, compiled languages, so I was probably trying to do dumb stuff |
| 09:07:11 | HakanD__ | than gave up and resorted to inheritance to do what i want, more or less |
| 09:10:03 | fowl | i added the macro i wrote for it to the bottom, i stopped when i got a strange error, the macro fails but if i copy&paste the output of it, it works |
| 09:10:10 | * | bjz joined #nim |
| 09:10:32 | * | repax quit (Remote host closed the connection) |
| 09:11:40 | Arrrrr | Are you a game dev? |
| 09:12:36 | * | mpthrapp quit (Ping timeout: 240 seconds) |
| 09:12:47 | fowl | i would be if i ever had any ideas |
| 09:13:59 | Arrrrr | Is not hard to have ideas when you have played a lot of games, which is not that hard. Is it hard to use opengl in nim? |
| 09:14:56 | * | mpthrapp joined #nim |
| 09:15:15 | fowl | no |
| 09:15:55 | fowl | there are also wrappers for sfml, sdl, allegro |
| 09:16:32 | HakanD__ | Arrrrr: check out https://github.com/BlaXpirit/nim-csfml |
| 09:16:51 | HakanD__ | there are examples in there to get your feet wet also |
| 09:17:21 | Arrrrr | Oh, that's cool. I'll keep it around, i will need it after finishing the tuts |
| 09:18:49 | coffeepot | nimble install opengl then check out the examples here https://github.com/nim-lang/opengl |
| 09:19:10 | * | mpthrapp quit (Client Quit) |
| 09:19:52 | Arrrrr | Thanks, is nimble installed with the compiler by default or where can i get it? Im in windows |
| 09:19:52 | * | Trustable joined #nim |
| 09:20:48 | * | bjz quit (Ping timeout: 252 seconds) |
| 09:21:08 | fowl | github.com/nim-lang/nimble |
| 09:21:35 | HakanD__ | https://github.com/nim-lang/nimble |
| 09:22:03 | Arrrrr | Thanks. Isn't opengl module? (i guess) included by default? |
| 09:22:34 | fowl | no its a package |
| 09:24:25 | coffeepot | there's also sdl2 ("nimble install sdl2") which has an opengl example |
| 09:25:55 | * | mpthrapp joined #nim |
| 09:29:21 | Arrrrr | I have seen in a tutorial i can actually use lambdas https://nim-by-example.github.io/procvars/ |
| 09:29:31 | Arrrrr | What is the difference between -> and future's => ? |
| 09:29:48 | LoneTech | is this the time to mention I got OpenGL in IUP working? |
| 09:30:10 | fowl | this is a game engine that runs with sdl2 or javascript, https://github.com/yglukhov/nimx |
| 09:30:25 | fowl | also ios/android^ |
| 09:31:05 | coffeepot | i keep forgetting nim compiles to javascript! :D |
| 09:31:30 | * | Matthias247 joined #nim |
| 09:32:02 | fowl | Arrrrr, -> used to be necessary for specifying return type |
| 09:32:17 | fowl | but now echo arr.map((i:int) => 1+2) works fine so its probably not needed |
| 09:32:47 | Arrrrr | Ah, i see |
| 09:32:54 | * | bcinman quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 09:33:02 | fowl | maybe now -> should return a type |
| 09:33:05 | coffeepot | btw are there still plans to provide return type overloading? |
| 09:33:13 | fowl | so you could say (int,int)->string for proc(a,b:int):string |
| 09:33:30 | LoneTech | the docs seem to imply you can |
| 09:33:38 | LoneTech | proc pass2(f: (float, float) -> float): float = |
| 09:34:19 | fowl | ahh |
| 09:34:36 | fowl | im tripping then |
| 09:35:49 | * | EastByte_ joined #nim |
| 09:35:49 | * | EastByte quit (Read error: Connection reset by peer) |
| 09:37:28 | * | Demon_Fox quit (Quit: Leaving) |
| 09:39:17 | * | EastByte_ is now known as EastByte |
| 09:41:22 | * | mpthrapp_ joined #nim |
| 09:43:36 | Araq | coffeepot: not for version 1.0 |
| 09:43:46 | * | mpthrapp quit (Ping timeout: 255 seconds) |
| 09:44:41 | * | milosn joined #nim |
| 09:45:31 | * | bjz joined #nim |
| 09:47:40 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 09:48:39 | Araq | renesac: there is also tests/generics/tconfusing_arrow.nim lol |
| 09:49:19 | * | milosn quit (Read error: Connection reset by peer) |
| 09:49:26 | coffeepot | fair enough, i just see it mentioned a lot :) |
| 09:49:44 | * | milosn joined #nim |
| 09:49:48 | coffeepot | mainly in that thread on the forums about constructors |
| 09:50:01 | coffeepot | which I must say has been quite enlightening |
| 09:50:21 | Araq | oh yeah these are really important because then I cannot write 'var f: Foo' anymore. |
| 09:50:23 | fowl | does that test pass now? |
| 09:50:32 | Araq | fowl: sure |
| 09:50:38 | Araq | most tests are green these days |
| 09:50:58 | fowl | (x, y: Deck) => .. should be (x:Deck, y:Deck) => .. |
| 09:51:04 | * | Jehan_ joined #nim |
| 09:51:05 | coffeepot | in reading it i've gone from "need constructors" to "constructors seem an arbitrary construct" |
| 09:51:38 | Araq | now the only problem is that I have yet to see a bug caused by 'var f: Foo' |
| 09:52:24 | Araq | fowl: perhaps but actually => should rewrite it *properly* |
| 09:52:27 | fowl | you mean mutability causing a bug? |
| 09:52:48 | Araq | no |
| 09:53:08 | Araq | I mean "this bug would have been prevented by a 'private constructor'" |
| 09:54:12 | fowl | ah |
| 09:55:07 | fowl | no that test shouldnt pass |
| 09:55:37 | fowl | i can make that change though |
| 09:55:49 | fowl | also -> is wrong, it returns generic procs |
| 09:55:51 | * | repax joined #nim |
| 09:56:14 | Araq | fowl: ok, great |
| 09:56:51 | * | HakanD__ quit (Quit: Be back later ...) |
| 10:00:09 | Araq | coffeepot: not necessarily "arbitrary" but C++ and Java and C# ended up with a "mini language" in the language dealing only with construction |
| 10:00:48 | Araq | with all sorts of syntactic or semantic rules, "don't write it in the {}, but after the colon" |
| 10:01:02 | * | repax quit (Read error: Connection reset by peer) |
| 10:01:05 | Araq | "write it in the {} but 'super' must be the first call" |
| 10:03:21 | * | repax joined #nim |
| 10:03:30 | Araq | the complexity vs benefit tradeoff is very poor for this feature. |
| 10:04:42 | * | HakanD__ joined #nim |
| 10:05:21 | * | endragor joined #nim |
| 10:05:52 | * | repax_ joined #nim |
| 10:12:18 | * | mpthrapp_ quit (Ping timeout: 250 seconds) |
| 10:13:00 | fowl | what kind of polymorphism does Interface implement? |
| 10:13:39 | * | davidhq joined #nim |
| 10:14:55 | * | mpthrapp joined #nim |
| 10:19:32 | * | repax_ quit (Read error: Connection reset by peer) |
| 10:19:33 | * | repax quit (Write error: Connection reset by peer) |
| 10:19:49 | * | repax joined #nim |
| 10:19:52 | * | mpthrapp_ joined #nim |
| 10:20:32 | Araq | fowl: runtime polymorphism of course |
| 10:21:08 | * | mpthrapp quit (Ping timeout: 272 seconds) |
| 10:21:17 | * | repax_ joined #nim |
| 10:23:55 | * | mpthrapp joined #nim |
| 10:26:20 | Araq | "It did work, actually. I've been using 0-dimensional arrays for the past couple months" ... -.- |
| 10:26:48 | * | davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 10:26:50 | * | mpthrapp_ quit (Ping timeout: 272 seconds) |
| 10:26:58 | Araq | https://github.com/Araq/Nim/issues/2498 |
| 10:27:18 | * | mpthrapp_ joined #nim |
| 10:27:43 | * | Sembei joined #nim |
| 10:27:48 | Arrrrr | Now you have to support it |
| 10:28:46 | * | mpthrapp quit (Ping timeout: 244 seconds) |
| 10:28:48 | Araq | surely looks like it |
| 10:29:02 | * | milosn quit (Read error: Connection reset by peer) |
| 10:29:05 | BlaXpirit | 0 length arrays are important |
| 10:29:10 | dom96 | Araq: Can I change the way symchoices are output for toStrLit, they cause a lot of noise. |
| 10:29:20 | dom96 | s/./?/ |
| 10:29:32 | * | milosn joined #nim |
| 10:29:55 | Araq | dom96: yeah I planned to do that too, but not sure I want to lose this information |
| 10:30:16 | dom96 | could we add a param for it? |
| 10:30:25 | * | Sembei quit (Max SendQ exceeded) |
| 10:30:33 | Araq | hell no |
| 10:30:52 | Araq | just make it sane instead |
| 10:32:03 | fowl | Araq, poke that guy to write a short paper on nim maybe caltech is notable enough for wikipedia |
| 10:32:12 | * | milosn quit (Read error: Connection reset by peer) |
| 10:32:16 | dom96 | Araq: where is the repr for NimNode implemented? |
| 10:32:49 | fowl | dom96, if its magic search mMagicName |
| 10:33:07 | * | Sembei joined #nim |
| 10:33:09 | * | MightyJoe quit (Ping timeout: 245 seconds) |
| 10:33:40 | Araq | fowl: ironically wikipedia itself is not notable for anything serious |
| 10:33:44 | * | MightyJoe joined #nim |
| 10:33:59 | BlaXpirit | wut |
| 10:34:10 | fowl | lol i was just wondering that |
| 10:34:31 | fowl | is wikipedia in any academic publications |
| 10:34:35 | * | milosn joined #nim |
| 10:34:58 | Araq | fowl: it is but generally the consensus is that it doesn't count ;-) |
| 10:36:44 | Arrrrr | Quick question: how to display text in console with different bg/fg colors ? |
| 10:36:49 | dom96 | argh, can't find it. |
| 10:36:53 | dom96 | Araq, any ideas? |
| 10:37:13 | dom96 | Arrrrr: terminal module |
| 10:37:16 | HakanD__ | today is the last day of the deletion talk it seems |
| 10:37:23 | Arrrrr | Thanks |
| 10:38:48 | * | milosn quit (Read error: Connection reset by peer) |
| 10:38:52 | * | mpthrapp_ quit (Ping timeout: 272 seconds) |
| 10:39:10 | * | repax quit (Read error: Connection reset by peer) |
| 10:39:10 | * | repax_ quit (Read error: Connection reset by peer) |
| 10:39:32 | * | repax joined #nim |
| 10:39:47 | * | repax quit (Read error: Connection reset by peer) |
| 10:40:08 | * | repax joined #nim |
| 10:42:22 | coffeepot | brainfuck has a wikipedia page but nim's is up for deletion, just makes no sense |
| 10:42:52 | * | repax_ joined #nim |
| 10:43:26 | coffeepot | if they delete it, it will only have to be readded later when nim gains further traction anyway |
| 10:44:35 | * | milosn joined #nim |
| 10:45:32 | HakanD__ | nim is at a gray area according to wikipedia standarts, and they can't make up their minds about which side it belongs |
| 10:46:59 | HakanD__ | no big deal IMHO, nim *will* have an article, sooner or later. |
| 10:47:03 | HakanD__ | well, sooner is better ofc |
| 10:47:19 | Arrrrr | Why this happen? http://i.imgur.com/3NL7pIy.png |
| 10:48:10 | * | JinShil joined #nim |
| 10:48:59 | Araq | Arrrrr: dunno, terminal control is a pita |
| 10:49:48 | dom96 | oh well, I guess i'll just write my own toStrLit |
| 10:54:09 | Arrrrr | http://i.imgur.com/rm3ybnS.png |
| 10:54:16 | * | repax quit (Read error: Connection reset by peer) |
| 10:54:16 | * | repax_ quit (Write error: Connection reset by peer) |
| 10:54:27 | * | Kingsquee quit (Quit: Konversation terminated!) |
| 10:54:48 | * | repax joined #nim |
| 10:55:34 | * | repax_ joined #nim |
| 10:56:23 | fowl | Arrrrr, try stdout.flush() after resetattributes |
| 10:56:56 | Arrrrr | which import |
| 10:57:07 | Arrrrr | consoles.nim(11, 6) Error: undeclared identifier: 'flush' |
| 10:57:28 | fowl | sry flushFile |
| 10:58:32 | Arrrrr | I don't notice any difference in the result |
| 10:59:29 | HakanD__ | is there a way to make an object type compatible with another object type, without inheritance? |
| 11:02:43 | Arrrrr | omg, i set the bg with bright black, displaying grey, and setting it again to non-bright black displays always grey |
| 11:03:32 | * | repax_ quit (Read error: Connection reset by peer) |
| 11:03:32 | * | repax quit (Read error: Connection reset by peer) |
| 11:04:08 | fowl | well Arrrrr tbh you are probably the first person to try terminal on windows in a long time, conio is pretty annoying to work with |
| 11:04:33 | Araq | fowl: actually nimgrep uses it and it works :P |
| 11:04:47 | Arrrrr | maybe because im with 0.10.2 ... |
| 11:05:28 | LoneTech | ah, the wonders of the platform where underline is blue, bright background causes foreground to blink, and bright black is a thing. |
| 11:06:16 | LoneTech | I fail to recall the actual order of black, bright black, white, and bright white |
| 11:06:17 | coffeepot | arrrr: definitely try updating to the devel version of nim |
| 11:06:21 | * | Arrrrrrrrrr joined #nim |
| 11:06:25 | coffeepot | arrrr: definitely try updating to the devel version of nim |
| 11:06:55 | Arrrrrrrrrr | It would take a lot to compile the source on my computer. |
| 11:07:17 | Arrrrrrrrrr | I can wait until the next release |
| 11:07:59 | coffeepot | I dunno I am running on an i7 here but my home computer is an old E6600 from like, 8 years ago and it took less than a minute to compile |
| 11:08:24 | Arrrrrrrrrr | Well, i'll give it a try. |
| 11:08:27 | * | untitaker quit (Ping timeout: 250 seconds) |
| 11:09:10 | * | Arrrrr quit (Ping timeout: 246 seconds) |
| 11:09:11 | coffeepot | if you do, just make sure you remove or rename the old nim folder (i didnt first time and made a mess of it haha) |
| 11:09:40 | * | wb joined #nim |
| 11:12:19 | * | milosn quit (Ping timeout: 245 seconds) |
| 11:13:42 | * | untitaker joined #nim |
| 11:15:33 | * | davidhq joined #nim |
| 11:23:32 | Arrrrrrrrrr | well, build.bat is doing its magic, let's cross fingers |
| 11:25:47 | HakanD__ | regarding my previous question; https://gist.github.com/hakanderyal/0c5a0c4b02b60c40dac1 can someone point me to the right direction with that? |
| 11:26:55 | Araq | HakanD__: no, use inheritance here |
| 11:28:38 | HakanD__ | Araq: hmm, any chance we can get multiple inheritance in nim |
| 11:28:47 | Araq | no way |
| 11:29:04 | * | milosn joined #nim |
| 11:31:30 | * | milosn quit (Read error: Connection reset by peer) |
| 11:33:42 | Arrrrrrrrrr | ok, now it works as intended! thanks for your help coffeepot. |
| 11:33:58 | Arrrrrrrrrr | I'm using 0.10.3, is this the lastest? |
| 11:34:29 | fowl | from git, devel branch? |
| 11:36:08 | coffeepot | well it's thanks to Araq & co - they did the fixes! :D |
| 11:36:11 | * | repax joined #nim |
| 11:36:52 | Arrrrrrrrrr | I think i got master |
| 11:37:25 | fowl | devel is the default branch so if you didnt explicitly say master then you should have devel |
| 11:37:57 | repax | That should be easy to check |
| 11:38:04 | Arrrrrrrrrr | then i have devel |
| 11:39:10 | * | milosn joined #nim |
| 11:39:12 | Arrrrrrrrrr | yes, devel |
| 11:39:42 | dom96 | Araq: Is this returning true a bug? echo(8'i8 is int32) |
| 11:40:24 | Araq | yes it is |
| 11:40:36 | dom96 | known bug or should I report it? |
| 11:40:52 | Araq | known bug but I don't know the bug number |
| 11:40:53 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 11:40:56 | dom96 | k |
| 11:41:02 | Araq | report it, it's actually a showstopper I think |
| 11:41:10 | dom96 | ok |
| 11:41:46 | * | milosn quit (Read error: Connection reset by peer) |
| 11:44:07 | * | milosn joined #nim |
| 11:46:24 | * | drewsrem joined #nim |
| 11:46:26 | Araq | def-: can you look into https://github.com/Araq/Nim/issues/2477 ? |
| 11:48:34 | Arrrrrrrrrr | I made more test and the bug is still there. It happens when i leave an empty line. Then, the problem persists even removing that empty line. |
| 11:49:07 | HakanD__ | Araq: thanks |
| 11:50:57 | Arrrrrrrrrr | nope, is not because of that. But still i have seen the problem. I'll try to reproduce it. |
| 11:52:41 | Arrrrrrrrrr | it simply happens after compiling and executing the program 7 times lol |
| 11:53:55 | Arrrrrrrrrr | *8 |
| 11:54:07 | pigmej | Arrrrrrrrrr: maybe stupid windows console has bug? |
| 11:54:11 | Arrrrrrrrrr | How is this even posible? |
| 11:54:21 | pigmej | that windows console ignores some signals ? |
| 11:54:24 | pigmej | quite frequent |
| 11:54:44 | pigmej | does it happen on clear/fresh windows console? |
| 11:54:47 | Arrrrrrrrrr | Maybe. But with 0.10.2 i had always that bug. Now it happens only when compiling and running |
| 11:54:53 | Arrrrrrrrrr | not just executing the bin |
| 11:55:16 | Araq | dom96: https://github.com/Araq/Nim/pull/2437 only works because your tests uses global variable _'s |
| 11:55:31 | Araq | as these are mangled with their IDs |
| 11:56:06 | dom96 | so setting sfGenSym on them will fix it? |
| 12:00:45 | Araq | it should |
| 12:00:56 | Araq | and it's the proper way to do it anyway |
| 12:02:16 | * | HakanD___ joined #nim |
| 12:03:43 | dom96 | ok |
| 12:04:58 | Araq | undefined reference to `_imp___lock_file' |
| 12:05:16 | Araq | ha I knew it wouldn't work out of the box on windows |
| 12:05:54 | * | HakanD__ quit (Ping timeout: 244 seconds) |
| 12:12:43 | * | BlaXpirit_ joined #nim |
| 12:13:32 | * | Ven joined #nim |
| 12:13:59 | * | lyro quit (Quit: WeeChat 0.4.3) |
| 12:14:01 | * | milosn quit (Read error: Connection reset by peer) |
| 12:14:18 | * | lyro joined #nim |
| 12:14:49 | * | milosn joined #nim |
| 12:15:37 | * | BlaXpirit quit (Ping timeout: 250 seconds) |
| 12:15:43 | * | BlaXpirit_ quit (Client Quit) |
| 12:15:57 | * | dhasenan quit (Remote host closed the connection) |
| 12:16:01 | * | BlaXpirit joined #nim |
| 12:17:03 | * | milosn quit (Read error: Connection reset by peer) |
| 12:19:50 | * | milosn joined #nim |
| 12:20:34 | Arrrrrrrrrr | I have to go, thanks everyone for your help and for making Nimrod a big language. Keep up the work. |
| 12:20:39 | * | Arrrrrrrrrr quit (Quit: Page closed) |
| 12:25:01 | * | milosn quit (Ping timeout: 265 seconds) |
| 12:28:42 | * | BitPuffin joined #nim |
| 12:31:31 | * | Jehan_ quit (Quit: Leaving) |
| 12:31:43 | endragor | How does seq capacity reallocation works when add() is called and the current capacity is not enough? |
| 12:31:57 | * | jefus joined #nim |
| 12:32:28 | * | xcombelle quit (Ping timeout: 245 seconds) |
| 12:36:17 | Araq | endragor: it multiplies by 1.5 like it should. |
| 12:37:45 | Araq | you don't need to point us to facebook's most recent "discovery" that 2 is a bad factor, we usually know a few things about algorithms |
| 12:38:32 | endragor | eh.. didn't even think about doing that |
| 12:38:40 | endragor | thanks for the answer |
| 12:45:28 | * | xcombelle joined #nim |
| 12:46:11 | Araq | hrm the 'is' operator has 3 different implemenations in the compiler |
| 12:46:35 | Araq | no wonder it's buggy |
| 12:48:14 | Araq | and all 3 implementations get it wrong ... *sigh* |
| 12:48:56 | Araq | ah and it's one foundation for 'concept' |
| 12:49:05 | Araq | yay ... |
| 12:49:13 | fowl | wow this is useful http://referencesource.microsoft.com/#mscorlib/system/console.cs,4a0c30310351cd9d |
| 12:50:13 | fowl | for all of .net |
| 12:53:15 | * | a5i quit (Quit: Connection closed for inactivity) |
| 12:58:26 | BlaXpirit | Araq, will you accept updated PCRE so nre can use pcre from stdlib? It is also backwards-compatible with current stdlib pcre https://github.com/BlaXpirit/nre/blob/for-stdlib/src/private/pcre.nim |
| 12:59:00 | Araq | BlaXpirit: sounds very good |
| 13:00:23 | Araq | ha! got it. but ugh, fixing this properly is hard |
| 13:00:37 | BlaXpirit | but i'm not sure what needs to be changed on Windows, the bundled DLL may need to be changed |
| 13:00:59 | Araq | BlaXpirit: I don't think so |
| 13:01:15 | Araq | .deadCodeElim usually mitigates these pains |
| 13:01:21 | BlaXpirit | well this wrapper is for newer version of pcre |
| 13:01:45 | BlaXpirit | maybe nre uses some new feature and hmmm |
| 13:01:45 | Araq | for version 10? |
| 13:02:07 | BlaXpirit | 8 36 |
| 13:02:11 | BlaXpirit | 2014-09-26 |
| 13:06:32 | * | johnsoft joined #nim |
| 13:08:51 | * | milosn joined #nim |
| 13:12:51 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 13:15:40 | * | Ven joined #nim |
| 13:24:23 | BlaXpirit | "Update and improve PCRE wrapper" https://github.com/Araq/Nim/pull/2506 comments welcome |
| 13:29:32 | Araq | "there is an argument ptr cuchar that used to be cstring" which one? |
| 13:31:09 | BlaXpirit | ctrl+f ptr cuchar |
| 13:31:26 | BlaXpirit | tables*: ptr cuchar tableptr: ptr cuchar |
| 13:32:14 | * | Ven_ joined #nim |
| 13:32:56 | BlaXpirit | i suppose it should indeed be cstring |
| 13:33:10 | BlaXpirit | but why is it unsigned |
| 13:34:34 | BlaXpirit | there are other normal char*s but these ones are unsigned char* |
| 13:34:40 | * | Ven quit (Ping timeout: 250 seconds) |
| 13:35:35 | BlaXpirit | or maybe this was old c2nim and it turned this into cstring without thinking |
| 13:46:00 | * | dhasenan joined #nim |
| 13:48:53 | * | xcombelle quit (Remote host closed the connection) |
| 13:49:34 | Araq | BlaXpirit: just make it 'pointer'. it's opaque. |
| 13:50:18 | BlaXpirit | are you sure? |
| 13:50:26 | BlaXpirit | Araq, ptr ptr cuchar -> pointer too? |
| 13:50:43 | Araq | yeah |
| 13:50:44 | BlaXpirit | also i replied on the pull page |
| 13:50:54 | * | milosn quit (Read error: Connection reset by peer) |
| 13:51:58 | * | milosn joined #nim |
| 13:52:08 | * | JinShil quit (Quit: Konversation terminated!) |
| 14:01:28 | Araq | BlaXpirit: is that PR finished for you? |
| 14:01:45 | BlaXpirit | i may look at changes in function arguments some more |
| 14:01:46 | BlaXpirit | but yeah |
| 14:03:36 | * | milosn quit (Read error: Connection reset by peer) |
| 14:04:21 | * | milosn joined #nim |
| 14:07:04 | BlaXpirit | found one |
| 14:10:00 | * | a5i joined #nim |
| 14:12:38 | Araq | found what? |
| 14:13:01 | * | milosn quit (Ping timeout: 264 seconds) |
| 14:13:08 | BlaXpirit | Araq, https://github.com/Araq/Nim/pull/2506#discussion_r28146588 |
| 14:14:39 | * | darkf quit (Quit: Leaving) |
| 14:16:24 | fowl | BlaXpirit, just use cstring instead of pointer |
| 14:16:55 | * | Sembei quit (Ping timeout: 252 seconds) |
| 14:16:59 | BlaXpirit | Arаq already consulted me about this and told to use pointer |
| 14:22:16 | * | saml joined #nim |
| 14:24:33 | * | Jehan_ joined #nim |
| 14:27:22 | fowl | This branch is 104 commits behind Araq:devel ... authored 14 days ago |
| 14:27:45 | fowl | thats pretty good |
| 14:28:35 | * | milosn joined #nim |
| 14:29:03 | BlaXpirit | fowl, whatcha talking about |
| 14:29:25 | fowl | 104 commits in 14 days |
| 14:29:45 | BlaXpirit | ah, cool. |
| 14:31:56 | Jehan_ | fowl: Well, it helps getting actually paid to work on a project rather than having to do it in your spare time, I imagine. :) |
| 14:32:50 | * | lyro left #nim ("ERC (IRC client for Emacs 25.0.50.3)") |
| 14:34:16 | Araq | nah, we have awesome hard-working contributors ;-) |
| 14:35:50 | * | mpthrapp joined #nim |
| 14:37:31 | drewsrem | ^ |
| 14:37:48 | Jehan_ | Well, that too. Definitively a positive feedback loop. |
| 14:38:31 | * | lyro joined #nim |
| 14:38:42 | Jehan_ | I am mostly happy that the changes tend to break very little of my code (if at all). |
| 14:39:16 | Jehan_ | The last major hiccup was the change in the do: notation. |
| 14:39:48 | * | jefus quit (Ping timeout: 276 seconds) |
| 14:39:57 | BlaXpirit | well my code broke often |
| 14:40:07 | BlaXpirit | living on the bleeding edge |
| 14:40:24 | BlaXpirit | well maybe not often, but a few times |
| 14:40:38 | BlaXpirit | and it was experimental features anyway |
| 14:40:41 | Jehan_ | Well, I tend to restrict myself to a rather safe subset of Nim. |
| 14:40:56 | Jehan_ | Very little metaprogramming, for example. |
| 14:41:23 | Jehan_ | What I essentially need out of Nim is a statically typed language with garbage collection. |
| 14:41:33 | * | Arrrrr joined #nim |
| 14:41:42 | Arrrrr | Hello Nimrod |
| 14:41:57 | drewsrem | Metaprogramming in Nim is _so_ delicious |
| 14:42:03 | repax | Arrrr you a pirate? |
| 14:42:15 | Araq | repax: lol |
| 14:42:21 | HakanD___ | Arrrrr: It's Nim btw |
| 14:42:38 | BlaXpirit | Araq, the `when not defined(pcreDll):` part is unchanged |
| 14:42:55 | Jehan_ | drewsrem: The metaprogramming facilities are nice, but I'm not sure how stable they are (feature-wise) for production code, which is what I need. |
| 14:43:17 | Araq | BlaXpirit: good point, wtf |
| 14:43:57 | drewsrem | Jehan_, I'm not here for the stability, I don't mind things breaking |
| 14:44:17 | Araq | BlaXpirit: make it when not defined(usePcreHeader) |
| 14:44:39 | HakanD___ | Jehan_: thank you for your detailed, educational posts on forums, learned a lot from them |
| 14:44:45 | BlaXpirit | Araq, wut https://github.com/Araq/Nim/commit/5f0d685 |
| 14:45:02 | BlaXpirit | this needs some thought |
| 14:45:03 | repax | I can't imagine the meta-programming features disappearing. Perhaps a syntax change or so. That's not a problem |
| 14:45:19 | renesac | Jehan_: I like the generics parts a lot, but I'm now restricting myself to the safer subset of Nim and I like it more when I'm not fighting the compiler |
| 14:45:32 | renesac | well, nim became more stable too |
| 14:45:34 | Jehan_ | HakanD___: Thankee. :) I try. :) |
| 14:45:39 | BlaXpirit | https://github.com/Araq/Nim/blame/devel/lib/wrappers/pcre.nim#L40 |
| 14:46:15 | Jehan_ | renesac: Generics (as in parameterized types/procedures) are pretty safe, as long as you don't mean the experimental keyword generic. |
| 14:46:21 | Araq | BlaXpirit: that's just because I suck at code reviews, I'm rather merge happy |
| 14:46:53 | renesac | Jehan_: well, that and static, and some template usage, etc |
| 14:47:24 | Araq | BlaXpirit: I told you what it really should look like |
| 14:47:28 | BlaXpirit | ok |
| 14:47:50 | Jehan_ | renesac: static[T] is something I still mostly avoid (granted, because I don't need it). Templates are mostly fine, too, if you don't do outlandish stuff with them. |
| 14:48:51 | renesac | I will update my pull request latter today |
| 14:50:39 | Araq | Jehan_: afaict most breaking changes are actually bugfixes, not feature changes... which sucks a bit. |
| 14:50:58 | * | HakanD___ quit (Quit: Be back later ...) |
| 14:51:00 | Jehan_ | Araq: Yeah, which may be why I'm not getting hit by them. :) |
| 14:51:13 | Jehan_ | Or at least only rarely. :) |
| 14:53:22 | * | milosn quit (Ping timeout: 252 seconds) |
| 14:53:37 | BlaXpirit | dang it, i closed the pull request |
| 14:53:48 | * | jholland joined #nim |
| 14:54:25 | * | jefus joined #nim |
| 14:54:55 | Araq | also I know how to make static[T] and 'concept' stable ... I wish I could say the same for the VM |
| 14:54:57 | Jehan_ | Araq: What I always wanted to ask: is there a reason why a return type of auto doesn't work when the return type is void? |
| 14:55:21 | BlaXpirit | Jehan_, doesn't it? |
| 14:55:21 | Araq | hrm, I fixed some bugs wrt that. could work now |
| 14:55:34 | BlaXpirit | i'm sure it worked for me, at least in one instance |
| 14:55:37 | Jehan_ | Hmm, I just tried and it didn't work. |
| 14:55:53 | Jehan_ | Specifically: let f = (proc(x: string): auto = echo x) |
| 14:56:07 | Jehan_ | Let me check if I'm using the correct Nim version. |
| 14:56:30 | Jehan_ | Ugh, nevermind. That was an old one. |
| 14:56:34 | Jehan_ | It works now. Thanks! |
| 14:56:51 | Arrrrr | How does auto work? it seems interesting. |
| 14:56:56 | * | HakanD___ joined #nim |
| 14:57:08 | Araq | Arrrrr: it takes the type of the proc's returning expression |
| 14:57:24 | Araq | nothing interesting really |
| 14:57:51 | Arrrrr | So, is like when you declare a var like "var a = 1" ? |
| 14:58:07 | Araq | yeah |
| 14:58:26 | BlaXpirit | Araq, reopen that pull request please :| |
| 14:58:47 | Arrrrr | Ok, i thought it was more like making it returning different values depending on the returning value expected |
| 14:58:52 | Jehan_ | And in particular, the following works now cleanly: |
| 14:58:53 | BlaXpirit | Araq, so how about we add a message in docs of 're' to tell people to use 'nre', and after 0.10.4 talk about replacing 're' with that wrapper around 'nre' |
| 14:58:57 | Jehan_ | import future |
| 14:58:57 | Jehan_ | let f = (x: string) => echo x |
| 15:00:06 | BlaXpirit | ah. that's good. |
| 15:00:10 | Araq | BlaXpirit: add a message to mention 'nre' but I don't want to deprecate 're' yet |
| 15:00:37 | Araq | and I fail to see the point of your nre port now that the most offending re bugs have been fixed |
| 15:00:37 | BlaXpirit | we can't deprecate it before nre is in stdlib, of course |
| 15:00:48 | * | bcinman joined #nim |
| 15:01:11 | BlaXpirit | Araq, i can resume digging for bugs in re |
| 15:01:52 | BlaXpirit | after examining nre i see just how smart it needs to be, especially when unicode is involved |
| 15:02:20 | Araq | BlaXpirit: if you need to dig that means these are rather unimportant bugs :P |
| 15:02:35 | BlaXpirit | i'm sure some of the stuff i mentioned on forums is still broken |
| 15:03:45 | Araq | BlaXpirit: I'm sure "Perl compatible regular expressions" is not a well defined problem statement to begin with :P |
| 15:06:32 | Jehan_ | Random aside: one thing that might possibly be useful is a "batteries" pack for Nim, which gives you a kitchen sink of useful packages as a single install. |
| 15:07:24 | BlaXpirit | don't put 'random' aside :p that's the first candidate for such a pack |
| 15:08:12 | HakanD___ | is it normal for compiler to segfault on funky code? |
| 15:08:15 | Jehan_ | Well, yeah. :) |
| 15:08:34 | Jehan_ | Umm. That was a response to BlaXpirit. |
| 15:08:40 | BlaXpirit | HakanD___, segfault is ideally never supposed to happen |
| 15:09:07 | Jehan_ | HakanD___: it shouldn't, but sometimes it can. I've gotten the compiler to crash before. |
| 15:10:33 | HakanD___ | meh, that's fun (: I've got a hanging compiler, stack overflowing compiler, and now segfaulting compiler in the last few days. |
| 15:10:39 | HakanD___ | should I report these on github? |
| 15:10:40 | BlaXpirit | yes |
| 15:11:02 | BlaXpirit | if you aren't sure, before going to github you can use a pastebin and show people in irc |
| 15:11:17 | HakanD___ | I've no idea if the code is valid or not tho |
| 15:11:25 | HakanD___ | i've no idea what i'm doing (: |
| 15:11:31 | BlaXpirit | [:11:02] <BlaXpirit> if you aren't sure, before going to github you can use a pastebin and show people in irc |
| 15:12:12 | Jehan_ | HakanD___: Doesn't matter, invalid code shouldn't crash the compiler, either. |
| 15:12:26 | Jehan_ | In fact, if you get it to crash, it's usually invalid code. |
| 15:12:36 | HakanD___ | I'm guessing so |
| 15:14:22 | Jehan_ | It can be helpful to have a version of the compiler compiled without -d:release, by the way. This way you get a stacktrace instead of a crash. |
| 15:15:49 | Araq | Jehan_: if you're up for a challenge look at this please: https://github.com/Araq/Nim/issues/2477 |
| 15:16:02 | * | gmpreussner|work quit (Ping timeout: 244 seconds) |
| 15:16:21 | Jehan_ | Araq: Already had, but I've never once used OpenGL before. |
| 15:16:37 | HakanD___ | https://gist.github.com/hakanderyal/4ea07011b0c95d4acfcf <-- segfault |
| 15:17:01 | * | gmpreussner|work joined #nim |
| 15:17:18 | Jehan_ | And on my Mac it works fine. |
| 15:18:09 | Jehan_ | HakanD___: Can reproduce the crash, let me see. |
| 15:20:04 | Jehan_ | As usual, it works if you split the ref object in an object type and a ref to that type. |
| 15:20:22 | Jehan_ | E.g.: |
| 15:20:25 | Jehan_ | GenericNodeObjInner[T] = object |
| 15:20:25 | Jehan_ | obj: T |
| 15:20:25 | Jehan_ | GenericNodeObj[T] = ref GenericNodeObjInner[T] |
| 15:21:55 | * | mwbrown joined #nim |
| 15:22:07 | HakanD___ | https://gist.github.com/hakanderyal/4ea07011b0c95d4acfcf <-- added a second file, it's mostly the same code, but this time compiler hangs, or gives stack overflow if i compile the compiler without -d: release |
| 15:22:39 | HakanD___ | Jehan_: thanks, I will continue to mess aronud (: |
| 15:22:57 | Jehan_ | It's still a bug, checking right now what causes it. |
| 15:23:25 | Jehan_ | But it's not the first time that Foo[T] = ref object … has caused problems. |
| 15:23:46 | HakanD___ | also look at the second file I just added to gist, it's almost the same code |
| 15:25:18 | * | Matthias247 joined #nim |
| 15:28:10 | Jehan_ | HakanD___: Probably has the same issue with the compiler barfing on the …[T] = ref object … stuff. |
| 15:28:36 | * | TEttinger quit (Ping timeout: 240 seconds) |
| 15:29:05 | * | endragor_ joined #nim |
| 15:30:18 | HakanD___ | Jehan_: tried it with your fix, it still hangs |
| 15:30:28 | Jehan_ | HakanD___: Huh. Hmm. |
| 15:30:36 | * | Sembei joined #nim |
| 15:30:46 | Jehan_ | Give me a few minutes, I'm in the middle of looking through the compiler. |
| 15:30:46 | * | endragor quit (Ping timeout: 252 seconds) |
| 15:35:12 | * | Ven_ quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 15:36:30 | * | endragor_ quit (Remote host closed the connection) |
| 15:37:26 | HakanD___ | Jehan_: tried it with your fix, it still hangs |
| 15:37:34 | HakanD___ | sorry, wrong button (: |
| 15:37:37 | Jehan_ | :) |
| 15:38:19 | * | endragor joined #nim |
| 15:39:15 | Araq | HakanD___: you instantiate GenericNodeObj too early |
| 15:39:24 | Araq | split it into 2 type sections and it should work |
| 15:40:06 | Jehan_ | I just checked, and it worked with my suggestion. That's with the most recent version of the devel branch, though. |
| 15:40:44 | def- | Jehan_, Araq: doesn't work for me, even with two type sections and most recent devel |
| 15:41:04 | Jehan_ | def-: Huh. |
| 15:41:30 | HakanD___ | segfault example works with Jehan's fix, hang example still doesn't work |
| 15:41:42 | def- | oh right, I'm looking at the hang example |
| 15:42:03 | * | endragor quit (Remote host closed the connection) |
| 15:42:49 | def- | the segfault one is fine |
| 15:42:57 | Jehan_ | HakanD___: Both pieces of code look identical? |
| 15:43:14 | Jehan_ | At least diff says they are. |
| 15:43:23 | def- | Jehan_: the segfault example is further down |
| 15:43:41 | HakanD___ | there are two files at the gist, check line 10 for difference |
| 15:45:11 | Jehan_ | Okay, got it now. |
| 15:45:52 | Jehan_ | That code is incorrect, though, since GenericNodeObj does need a type parameter. |
| 15:46:13 | * | Sembei quit (Ping timeout: 256 seconds) |
| 15:46:27 | Araq | what's the hanging example? |
| 15:46:40 | Araq | fixed the crash |
| 15:46:43 | def- | https://gist.github.com/hakanderyal/4ea07011b0c95d4acfcf hang.nim here |
| 15:46:46 | Jehan_ | The one without an [int] after GenericNodeObj. |
| 15:47:11 | * | endragor joined #nim |
| 15:48:06 | * | Ven joined #nim |
| 15:48:07 | * | endragor quit (Remote host closed the connection) |
| 15:48:23 | HakanD___ | it gives a stack overflow with compiler compiled with -d: release |
| 15:52:03 | HakanD___ | it gives a stack overflow with compiler compiled with -d: release |
| 15:52:23 | HakanD___ | meh, I should disable alt-tab for irc |
| 15:56:07 | Jehan_ | Heh. :) |
| 15:56:51 | Jehan_ | Araq: Incidentally, I have come to really like the new template behavior. |
| 15:57:22 | * | fowl quit (Quit: Leaving) |
| 15:57:43 | * | fowl joined #nim |
| 15:59:12 | HakanD___ | anyways, filed 2 issues on github regarding them. |
| 15:59:24 | Araq | # In order to prevent endless recursions, we must remember |
| 15:59:25 | Araq | # this bad lookup and replace it with errorType everywhere. |
| 15:59:26 | HakanD___ | thanks all for help |
| 15:59:39 | Araq | Hrm this doesn't seem to work too well |
| 16:00:41 | * | HakanD___ quit (Quit: Be back later ...) |
| 16:10:17 | * | pregressive joined #nim |
| 16:10:53 | flaviu | Hmm, I wonder what API makes sense for gradual tree construction. |
| 16:14:52 | * | gsingh93 joined #nim |
| 16:15:34 | coffeepot | Have a nice weekend guys! :) |
| 16:15:40 | coffeepot | Imma off :) |
| 16:15:52 | * | coffeepot left #nim (#nim) |
| 16:16:37 | * | milosn joined #nim |
| 16:17:27 | * | endragor joined #nim |
| 16:20:32 | * | Sembei joined #nim |
| 16:21:15 | * | endragor quit (Remote host closed the connection) |
| 16:21:28 | Arrrrr | Is exception handling in nim as slow as seen in other langs such as Java? |
| 16:21:44 | BlaXpirit | i'd guess "as slow as in C++" |
| 16:22:33 | BlaXpirit | except it can't be called slow when there is no way to make it faster |
| 16:22:33 | flaviu | Arrrrr: Slower actually. Nim doesn't use zero-overhead exception handing in the C backend. |
| 16:22:43 | BlaXpirit | oh really. sorry then. |
| 16:22:54 | flaviu | In java, exception only have cost when they are thrown. |
| 16:23:13 | BlaXpirit | I've heard that about C++ |
| 16:23:23 | flaviu | Same with C++, but with the C backend, a try except has cost even when it never catches anything. |
| 16:23:29 | Arrrrr | So, whenever you enter inside a try/except block, is gonna be slow regardless of what happens there |
| 16:23:39 | drewsrem | "slow" |
| 16:23:45 | flaviu | Arrrrr: Yep, but even slower if an exception comes along. |
| 16:24:28 | flaviu | So it's generally a good idea to keep the try block outside of hot loops. |
| 16:24:51 | federico3 | Nim on HN again: https://news.ycombinator.com/item?id=9353749 |
| 16:25:49 | flaviu | That website is really bad. |
| 16:26:02 | BlaXpirit | if i saw this, i'd be scared of both languages for life |
| 16:26:10 | * | Sembei quit (Max SendQ exceeded) |
| 16:26:33 | federico3 | HN? yep |
| 16:27:00 | flaviu | federico3: No, the link there. Code highlighting is really bad, and the webpage is buggy. |
| 16:27:03 | federico3 | or alhur.es? That's just disfunctional |
| 16:27:09 | flaviu | yrp |
| 16:27:12 | flaviu | *yep |
| 16:27:28 | * | Sembei joined #nim |
| 16:27:40 | drewsrem | My chromium apparently can't handle it |
| 16:29:13 | drewsrem | flaviu, is the cost of try blocks something that may be optimized away in the future in Nim? |
| 16:29:24 | Matthias247 | BlaXpirit: there are different types of exception handling implementations in C++. In that classical way try/catch always has an overhead. In the other way only thrown exceptions cost something |
| 16:29:31 | flaviu | drewsrem: If you use the C++ backend, it doesn't apply. |
| 16:29:40 | drewsrem | flaviu, I see |
| 16:29:50 | flaviu | drewsrem: But AFAIK, it's unavoidable with setjmp longjmp. |
| 16:30:14 | * | brson joined #nim |
| 16:30:28 | emilsp | the page sucks http://i.imgur.com/zA7Zi3a.png |
| 16:30:40 | drewsrem | emilsp, looks the same on my end |
| 16:30:54 | Arrrrr | How does java avoid this and why is different in c/c++ ? |
| 16:31:11 | federico3 | however, it's nice to see Nim getting attention |
| 16:31:32 | flaviu | Arrrrr: C++ also has the fast exception handling. http://mortoray.com/2013/09/12/the-true-cost-of-zero-cost-exceptions/ |
| 16:35:48 | Matthias247 | one thing that also makes c++ complex is that you can throw everything - there's no exception base class. You can throw any kind of value. You can catch it by value or reference, ... |
| 16:36:00 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 16:37:32 | * | Sembei quit (Ping timeout: 250 seconds) |
| 16:40:04 | flaviu | But that has nothing to do with the overhead of exceptions. |
| 16:49:43 | * | endragor joined #nim |
| 16:50:27 | * | endragor quit (Remote host closed the connection) |
| 16:55:50 | * | Trustable quit (Remote host closed the connection) |
| 16:56:44 | Jehan_ | drewsrem: In principle, one could use libunwind for this. |
| 16:57:10 | Jehan_ | Arrrrr: The problem is that C does not have portable exception handling. It only has setjmp/longjmp. |
| 16:58:02 | Arrrrr | That is, in order to have a faster exception handling, someone must program it for nim? |
| 16:59:51 | drewsrem | What are practical implications between the c and c++ backend of Nim besides different platform support? |
| 17:03:06 | * | Sembei joined #nim |
| 17:03:55 | drewsrem | Does the c++ backend generally trail behind for new features? |
| 17:04:03 | def- | drewsrem: C++ seems to compile slower, has a few bugs, and you can bind to C++ libraries |
| 17:04:35 | def- | drewsrem: no, it shouldn't |
| 17:04:42 | drewsrem | def-, ty |
| 17:18:53 | Arrrrr | The same link on reddit http://www.reddit.com/r/programming/comments/323lk6/sidebyside_nim_and_go/ downvoted to hell it seems |
| 17:20:31 | * | wink-s joined #nim |
| 17:20:32 | flaviu | Arrrrr: And you should downvote it too. It's a bad website, and a comparison of rosetta code code is pointless. |
| 17:21:30 | Arrrrr | Yes |
| 17:22:14 | * | Sembei quit (Ping timeout: 250 seconds) |
| 17:22:18 | fowl | i couldn't even see any nim code when it finally loaded |
| 17:23:36 | wink-s | fowl: I saw you mentioned interfaces earlier today and referenced (https://gist.github.com/fowlmouth/ac51baef7956af1ebdf8). Is this the same as similar to go interfaces: https://golang.org/doc/effective_go.html#interfaces ? |
| 17:28:19 | * | drewsrem quit (Quit: Leaving) |
| 17:29:58 | * | wink-s quit (Ping timeout: 246 seconds) |
| 17:33:55 | fowl | wink-s, its similar but these examples could use concepts in nim, except for interface{} which is more like nim's TAny (could be implemented as a typeid and pointer) |
| 17:39:03 | fowl | well after reading this they are actually really similar :D http://research.swtch.com/interfaces |
| 17:41:45 | Jehan_ | What flaviu said. :) |
| 17:42:20 | Arrrrr | "Objects that have no ancestor are implicitly final and thus have no hidden type field." What does it mean by 'hidden type field' ? |
| 17:43:14 | fowl | Arrrrr, its a hidden field that has the object type, makes polymorphism possible |
| 17:43:20 | Jehan_ | Arrrrr: In order to support inheritance, objects require a hidden field that lets the runtime know what their actual type is. |
| 17:43:46 | Jehan_ | Polymorphism means that an object variable of type T can actually also contain objects of a subtype of T. |
| 17:44:12 | Jehan_ | Without that type field, the runtime wouldn't be able to tell which method to actually use for dynamic dispatch. |
| 17:44:17 | Jehan_ | (And also for the "of" operator.) |
| 17:44:30 | * | wink-s joined #nim |
| 17:44:44 | Arrrrr | Ok ok. And are object constructors public? Can i control how certain objects are created? |
| 17:45:01 | Arrrrr | Can i force one way to create them? |
| 17:45:43 | fowl | wink-s, wb |
| 17:46:05 | fowl | <fowl> wink-s, its similar but these examples could use concepts in nim, except for interface{} which is more like nim's TAny (could be implemented as a typeid and pointer) <fowl> well after reading this they are actually really similar :D http://research.swtch.com/interfaces |
| 17:46:19 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 17:49:31 | fowl | Jehan_, do you know if there is a typeid I can keep in the interface to test against later? |
| 17:49:52 | Jehan_ | fowl: What do you mean? |
| 17:50:59 | fowl | ehh im looking for runtime type info so i can do a go-like switch statement |
| 17:52:16 | wink-s | fowl: Good to hear, the concept that if you implement the method signatures of an interface than you implement the interface is good, at least that's my interpretation of Go interfaces |
| 17:58:16 | Jehan_ | fowl: Define go-like switch statement in this context? |
| 18:00:22 | * | elbow_jason quit (Read error: Connection reset by peer) |
| 18:00:38 | * | elbow_jason joined #nim |
| 18:01:13 | fowl | Jehan_, it looks like this where obj is an interface{}: switch obj.(type){ case int: .. case SomeTrait: .. } |
| 18:01:59 | Jehan_ | if obj of T1: … elif obj og T2: ... |
| 18:02:48 | Jehan_ | I'm skeptical that it has any use that you can't get through a method definition, though. |
| 18:06:07 | fowl | PNimType is what i need |
| 18:09:53 | Joe-T | does nim have optional, to not != nil? |
| 18:11:23 | BlaXpirit | Joe-T, no. https://github.com/flaviut/optional_t |
| 18:11:45 | Joe-T | ah ok, thanks |
| 18:12:56 | * | endragor joined #nim |
| 18:13:07 | Jehan_ | Personally, I use (bool, T) most of the time. |
| 18:13:52 | Jehan_ | Now that tuples can be declared this way. |
| 18:14:58 | * | wink-s quit (Quit: Page closed) |
| 18:16:32 | * | brson quit (Quit: leaving) |
| 18:17:57 | fowl | boxing is not good enough performance |
| 18:18:29 | fowl | for pointers nil should represent None |
| 18:19:29 | fowl | i'm happy with Nullable = generic x; isNil(x) is bool; converter toBool(some:Nullable): bool = not isNil(some) |
| 18:20:43 | * | endragor quit (Remote host closed the connection) |
| 18:20:45 | * | wb quit (Ping timeout: 265 seconds) |
| 18:21:42 | BlaXpirit | assuming ref |
| 18:21:59 | fowl | assuming it can be nil |
| 18:22:19 | fowl | you can define a nil state for your object types too |
| 18:25:50 | BlaXpirit | o.o |
| 18:25:57 | BlaXpirit | never heard that |
| 18:26:16 | BlaXpirit | oooh |
| 18:26:28 | BlaXpirit | that's cute. |
| 18:27:23 | BlaXpirit | flaviu, check this out |
| 18:28:05 | flaviu | ? |
| 18:28:34 | BlaXpirit | instead of wrapping in Option one can just define isNil |
| 18:29:19 | flaviu | BlaXpirit: But then what is my None state? |
| 18:29:28 | BlaXpirit | isNil |
| 18:29:45 | BlaXpirit | distinct Slice isNil: a<0 |
| 18:29:45 | flaviu | Don't I have to have my own flag then? |
| 18:30:09 | flaviu | Does it auto-deref? |
| 18:30:45 | * | jefus quit (Quit: Leaving) |
| 18:30:49 | BlaXpirit | there is no ref |
| 18:30:57 | * | brson joined #nim |
| 18:31:02 | * | jefus joined #nim |
| 18:31:06 | BlaXpirit | instead of returning None you return -1 .. 0 or something |
| 18:31:34 | BlaXpirit | proc isNil(that distinct slice): bool = a<0 |
| 18:31:44 | flaviu | But what if someone reads it when it's in the invalid state? |
| 18:31:52 | * | wb joined #nim |
| 18:31:58 | flaviu | Does it throw an exception? |
| 18:32:01 | BlaXpirit | no |
| 18:32:22 | BlaXpirit | although that is possible too by defining proc a |
| 18:33:36 | flaviu | I don't see the point. Option encapsulates all that into one thing. |
| 18:34:00 | * | xcombelle joined #nim |
| 18:34:30 | BlaXpirit | and adds overhead |
| 18:34:46 | BlaXpirit | memory, performance and usage |
| 18:35:45 | Arrrrr | But arent value objects fast? |
| 18:36:08 | BlaXpirit | it might be possible that there is no performance overhead, i'm not sure |
| 18:36:44 | flaviu | BlaXpirit: One byte stack allocation overhead, no performance overhead. |
| 18:36:45 | Arrrrr | returning an optional inside the stack should not (as far as i know) be a problem memory and performance wise |
| 18:37:06 | * | endragor joined #nim |
| 18:37:19 | * | xcombelle quit (Read error: Connection reset by peer) |
| 18:37:34 | BlaXpirit | that doesn't change the fact that Arаq doesn't want optional_t :s |
| 18:38:38 | flaviu | I'm not going to reimplement option for each type that requires that behavior. |
| 18:38:40 | Arrrrr | For most operations make sense if they don't add sensible overhead. |
| 18:42:02 | * | endragor quit (Remote host closed the connection) |
| 18:42:15 | * | endragor joined #nim |
| 18:46:43 | * | wink-s joined #nim |
| 18:47:27 | Arrrrr | Quick question, is it possible in nim to serialize lambdas? |
| 18:48:10 | * | endragor quit (Remote host closed the connection) |
| 18:48:42 | BlaXpirit | good question, even though at first this seemed completely crazy |
| 18:49:03 | BlaXpirit | by lambda u mean proc? |
| 18:49:27 | Araq | very good question, not really. you can access the environment as an untyped pointer though and hack around it via 'cast' |
| 18:49:32 | Arrrrr | by lambda i mean (i: int) -> i + 5 for example |
| 18:49:47 | Araq | but this requires lots of internal knowledge |
| 18:49:47 | dom96 | BlaXpirit: flaviu: are you guys discussing Option[T] usage in nre? |
| 18:49:52 | BlaXpirit | dom96, yes |
| 18:50:24 | Araq | BlaXpirit: I don't like Option[T] but it's inevitable |
| 18:50:28 | dom96 | BlaXpirit: I just read your proposal (#2511). Thank you for writing it. |
| 18:50:32 | Araq | and I don't fight the inevitable |
| 18:50:38 | BlaXpirit | thank you for reading it :> |
| 18:50:41 | dom96 | Why is Option[T] inevitable? |
| 18:50:54 | flaviu | Araq: In this case, how would you write the nre api without option? |
| 18:51:01 | Araq | because people are like "la la la function programming, la la la" |
| 18:51:03 | dom96 | Would a 'bool' return type + 'var T' param work instead? |
| 18:51:27 | flaviu | Not sarcastic in any way, I'm genuinely curious. |
| 18:51:50 | BlaXpirit | dom96, that's one instance |
| 18:52:03 | BlaXpirit | the other instance is each of the sub-captures can be "nil" |
| 18:52:23 | Arrrrr | in aoptional you can pass a function that will be evaluated if the result is inside, is not the same as a pair with a bool and the result |
| 18:52:26 | BlaXpirit | "(a)|(b)" match "a" the captures here are "a" nil |
| 18:52:35 | dom96 | hrm |
| 18:52:49 | BlaXpirit | so there is basically an array of option[slice] |
| 18:52:51 | Araq | dom96: using a product type (tuple) when it's actually a sum type is also not really elegant |
| 18:53:10 | flaviu | dom96: That proposal is ridiculous. It's easy to accidentally ignore the return code, and there isn't an easy way to transform that pair into an exception. |
| 18:53:15 | dom96 | Perhaps it is time to adopt Option[T], and more functional constructs. |
| 18:53:35 | Araq | flaviu: via 'nil' or '-1' depending on the type |
| 18:53:50 | repax | If there are to be an Option[T] I'd like it to be in the form of an interface, so that you can implement it for your type at hand. Say that T is a pointer: A good implementation could use nil as None, and any other value as Option having that value. |
| 18:54:16 | flaviu | dom96: myOption.unwrap() is much more concise than var foo: stuff; if ...: # dostuff else: raise newException(...) |
| 18:54:18 | Araq | repax: that's not an interface, that's a specialization within Option[T] |
| 18:54:20 | BlaXpirit | repax, that is an amazing idea |
| 18:54:26 | dom96 | repax: That's a good idea. |
| 18:54:32 | fowl | repax, this is why i suggest the Nullable concept |
| 18:54:41 | repax | Araq: sorry, wrong word |
| 18:55:27 | fowl | some data type can be nil if any of its members are nullable and is nil (or some other logic, just implement isNil(T): bool) |
| 18:55:35 | * | banister joined #nim |
| 18:55:36 | dom96 | I think the nre-specific Option[T] should be renamed to RegexMatch |
| 18:56:11 | Araq | dom96: I don't see where we need to adopt it. we only *really* need it in the stdlib asap to prevent an interop desaster where everybody imports a different Nimble package just to get option[T] |
| 18:56:14 | BlaXpirit | dom96, nre doesn't roll with its own Option[T], it's just https://github.com/flaviut/optional_t |
| 18:56:18 | flaviu | Araq: Option is more concise then returning -1. You have to use an if to check the -1, when with option you can simply use unwrap() and throw an exception there. |
| 18:56:23 | BlaXpirit | Araq, true dat |
| 18:56:40 | dom96 | Araq: true |
| 18:56:53 | Arrrrr | haha |
| 18:56:57 | dom96 | Araq: We should think about adopting it where it makes sense though. |
| 18:57:03 | fowl | flaviu, distinct T holmes |
| 18:57:17 | Araq | dom96: I argued that it's annoying everywhere :P |
| 18:57:47 | flaviu | dom96: That's not a good way to do that. Every library will have it's own shitty pseudo-option types, and it'll be worse than simply using option. |
| 18:57:47 | Araq | flaviu: I can imagine an unwrap that checks for -1 |
| 18:57:54 | dom96 | Araq: I agree. Let's hope people don't start complaining about the inconsistencies. |
| 18:58:01 | Araq | muhaha |
| 18:58:16 | flaviu | Araq: But then we get to my point at :57. |
| 18:58:16 | BlaXpirit | flaviu, consider repax's idea again |
| 18:58:35 | repax | BlaXpirit: or fowl's Nullable? |
| 18:58:38 | BlaXpirit | which is what fowl said but in a different context |
| 18:58:41 | dom96 | flaviu: It would be an extension to repax'x interface idea. |
| 18:58:44 | dom96 | *repax's |
| 18:59:02 | flaviu | repax: I'm sorry to tell you fowl already came up with that idea a few months ago :P It didn't work because of bugs. |
| 18:59:10 | repax | I see |
| 18:59:10 | flaviu | err, bugs with type classes. |
| 18:59:24 | BlaXpirit | but they're good now |
| 18:59:25 | Jehan_ | I am looking at optional_t right now and … I don't really see why it doesn't use (bool, T) as the underlying representation? |
| 18:59:32 | dom96 | I think that in order for Option[T] to be used effectivelly we definitely do need pattern matching. |
| 18:59:45 | Arrrrr | yes! |
| 18:59:52 | BlaXpirit | Jehan_, i was repulsed by this but then amazed |
| 19:00:05 | fowl | flaviu, the object type doesnt work, if you were to use Maybe[T: Nullable] = distinct T you would be fine |
| 19:00:36 | Jehan_ | I mean, there's no point in defining a 2-element enum that's isomorphic to bool. |
| 19:00:44 | flaviu | Jehan_: It has the same binary layout as (bool, T). OptionType is basically bool, I just gave it a name to make my code clearer.. |
| 19:00:47 | fowl | Jehan_, your tuple has been in my stdlib fowltek/maybe_t for years :p |
| 19:01:06 | dom96 | Jehan_: flaviu: IMO it should be an object variant. |
| 19:01:39 | Jehan_ | dom96: If the underlying implementation is hidden (and it is, since the fields are not accessible), there's no real point to it. |
| 19:01:50 | flaviu | dom96: yep, what Jehan_ said. |
| 19:01:58 | dom96 | Jehan_: flaviu: would it not save memory? |
| 19:02:07 | flaviu | dom96: Nope. |
| 19:02:09 | Jehan_ | dom96: No. |
| 19:02:15 | Jehan_ | It would make the code slower, though. |
| 19:02:47 | Jehan_ | Whenever you don't turn checks off. |
| 19:03:00 | Araq | that's actually a good point |
| 19:03:14 | flaviu | dom96: Think about arrays of Options. If Option is variable length, how would indexing work? |
| 19:03:47 | BlaXpirit | can't different instances of generic types have different size? |
| 19:04:36 | flaviu | BlaXpirit: Yes, they can. But then and Some None would need to be encoded in the type signature, and we'd have invented rust. |
| 19:04:38 | dom96 | flaviu: You could have an array of pointers to the objects. |
| 19:04:41 | BlaXpirit | or.. make a template that returns different types |
| 19:04:57 | BlaXpirit | dom96, pointers are already worse than optional_t |
| 19:05:24 | flaviu | dom96: Yes, you could. You'd lose memory that way though. 8 bytes pointer, 8 bytes header. Plus think of the poor GC! |
| 19:05:30 | dom96 | BlaXpirit: That wasn't a suggestion for a replacement to Option[T]. |
| 19:05:49 | BlaXpirit | https://github.com/fowlmouth/nimlibs/blob/master/fowltek/maybe_t.nim looks much more exciting to me than optional_t |
| 19:06:26 | fowl | Araq, can typetraits be implemented with the compiler package now? do things like that still require magic? |
| 19:06:31 | repax | Option[T] as a specialization removes the bool if it's possible to represent nullable within the type |
| 19:06:37 | flaviu | I really dislike operator abuse. |
| 19:07:07 | BlaXpirit | essential utility types need short syntax |
| 19:07:11 | dom96 | I think we should copy Haskell in regards to Option[T] rather than Rust, so I agree, Maybe[T] please. |
| 19:07:19 | BlaXpirit | otherwise you get Rust :p |
| 19:07:21 | Jehan_ | dom96: Why? |
| 19:07:33 | dom96 | Jehan_: Because Haskell is cooler :P |
| 19:07:38 | BlaXpirit | i like names Option, Some, None |
| 19:07:44 | repax | I like Maybe[T] better than Option[T] for the name |
| 19:07:46 | Jehan_ | dom96: Umm .... |
| 19:07:48 | flaviu | BlaXpirit: The problem in rust isn't that there's option types. The problem is that there are no exceptions. |
| 19:08:03 | BlaXpirit | talking about verbose syntax this time |
| 19:08:03 | Arrrrr | why not Opt[T] |
| 19:08:09 | BlaXpirit | Why not O[T] |
| 19:08:28 | Araq | fowl: dunno |
| 19:08:29 | flaviu | You can unpack options without checking their contents, and there would be no problem but that the process would die. |
| 19:08:50 | flaviu | Am I the only one here who doesn't mind typing? |
| 19:08:55 | BlaXpirit | yes |
| 19:09:41 | flaviu | Sounds like some people need to learn to use autocomplete :P |
| 19:09:52 | dom96 | In all seriousness, I don't really care about the name, as long as I can write: case foo: of (Some x): echo x |
| 19:09:53 | Jehan_ | For what it's worth, I like Cond[T]. :) |
| 19:10:08 | fowl | Araq, do you think its worth exploring? |
| 19:10:24 | Jehan_ | dom96: if foo: echo foo.value |
| 19:10:25 | fowl | condaleeza[t] |
| 19:10:50 | repax | I always use exceptions for exceptional return values. That's what they are for. I'd not like to see Nim move to the mess (pardon me) of Go with tuple returns everywhere |
| 19:10:51 | Jehan_ | Pattern matching is overkill for Option[T]. |
| 19:10:52 | dom96 | Kondycja[T] # Let's translate it to every language! |
| 19:11:30 | dom96 | Jehan_: I want to pattern match on object variants too ;) |
| 19:11:55 | Jehan_ | dom96: Yeah, but that's a different story then. |
| 19:12:01 | flaviu | repax: I'd just like to point out that there are good reasons for option in some cases. Think about regex: Some captures do not match, and you don't want to throw an exception because one capture didn't match. |
| 19:12:12 | repax | flaviu: I agree. |
| 19:12:39 | dom96 | flaviu: I definitely agree with you there, I have had many moments where I thought: "An Option type would be perfect here". |
| 19:12:40 | flaviu | One of my goals with optional_t is to make it easy to turn an option into an exception. |
| 19:13:20 | * | endragor joined #nim |
| 19:13:27 | * | endragor quit (Remote host closed the connection) |
| 19:13:31 | repax | I think we should have a standard Option/Maybe |
| 19:13:46 | BlaXpirit | we all agree on that |
| 19:13:50 | BlaXpirit | not on implementation |
| 19:14:00 | repax | Preferably one that doesn't require a tuple |
| 19:14:05 | fowl | BlaXpirit, maybe we could agree on an API then :p |
| 19:14:20 | fowl | nah |
| 19:14:26 | dom96 | Shall we put it to a vote? |
| 19:14:29 | BlaXpirit | we pretty much have to radically different apis presented by flaviu and fowl |
| 19:14:35 | BlaXpirit | two* |
| 19:14:54 | dom96 | or let the BDFL decide? :P |
| 19:15:02 | fowl | i dont want to present that maybe[t] its old |
| 19:15:33 | * | HakanD___ joined #nim |
| 19:15:35 | BlaXpirit | i like flaviu's lib with some operator sugar a la fowl, plus fowl/repax's idea is cool |
| 19:16:55 | fowl | i would use Maybe[T:Nullable] = distinct T now, maybe get() that throws an exception and unsafeGet() |
| 19:17:04 | BlaXpirit | yes |
| 19:17:22 | Jehan_ | repax: In situations where you need a faster implementation, you can always substitute a specialized one. |
| 19:17:23 | dom96 | I think it's a good idea to have both operator sugar and good old long identifiers. |
| 19:18:04 | Jehan_ | I'm personally still not sure if anything other than (bool, T) plus some convenience templates/procs is needed. |
| 19:18:31 | repax | Jehan_: why not aim for perfection? |
| 19:18:50 | Jehan_ | repax: Define perfection? |
| 19:19:10 | repax | Something that is both efficient by default and expressive |
| 19:19:21 | fowl | also `?`(t:typedesc):typedesc = Maybe[t] |
| 19:19:34 | Jehan_ | fowl: What if you want Option[T], where T is nullable and nil is also a valid value? |
| 19:20:02 | fowl | Jehan_, then you are using it incorrectly |
| 19:20:13 | Jehan_ | repax: A tuple/object is efficient and expressive. |
| 19:20:17 | Jehan_ | fowl: Why? |
| 19:20:45 | repax | Jehan_: would it perhaps be possible with a default implementation of (bool, T) that can be further specialized? |
| 19:20:45 | fowl | because the design says that nil is the anti-value |
| 19:21:13 | repax | Jehan_: in the case that T is Nullable |
| 19:21:14 | Jehan_ | It is not uncommon to have nil represent a bottom value, for example, which is different from it being undefined. |
| 19:21:42 | fowl | bottom value is an error right |
| 19:21:49 | Jehan_ | fowl: No. |
| 19:22:01 | Jehan_ | It can, for example, be the minimum value in a semi-lattice. |
| 19:22:08 | BlaXpirit | wat |
| 19:23:14 | Jehan_ | For example, in the Nim compiler, nil represents the empty string for ropes. |
| 19:23:51 | Jehan_ | You could work around that, but then you'd introduce inefficiencies in order to make Option[PRope] faster, even where Option isn't being used. |
| 19:24:26 | Jehan_ | I.e. in order to force Option compatibility, you restrict what representation underlying types can have. |
| 19:24:51 | Jehan_ | Which introduces overhead where Option isn't used. |
| 19:25:46 | fowl | Jehan_, i dont see the problem, PRope can still be nil |
| 19:26:32 | Jehan_ | fowl: You can't use the "optimized" representation for Option[PRope] if you do that. |
| 19:26:35 | fowl | the maybe[T] is distinct T so theres no overhead in converting it to T |
| 19:27:06 | Jehan_ | The problem is that you can't represent Some(nil) in that. |
| 19:27:57 | repax | I don't see that as a problem |
| 19:28:05 | repax | Some(nil) is None |
| 19:28:19 | repax | or should be |
| 19:28:57 | Jehan_ | I just explained why it can't be. |
| 19:28:59 | fowl | Jehan_, well you're telling me the interface already works with nil, if you shove maybe into it should still work lol you just have to accept None as a valid value (thats what you want) |
| 19:29:42 | fowl | if a function can return a nil PRope for "" then it really cant fail, why is maybe used here? |
| 19:29:46 | Jehan_ | fowl: No. I mean that Some(nil) != None is something that you have to support. |
| 19:30:16 | Jehan_ | That's when you have a function return Option[PRope]. |
| 19:30:32 | Jehan_ | If it returns None, that indicates failure. If it returns Some(nil), that's the empty string. |
| 19:32:29 | repax | Well, Option[Option[PRope]] would certainly be wierd |
| 19:32:32 | Jehan_ | You can get rid of nil as a special value, but only if you say that you don't care about performance that much. But in that case, I'm not sure why the performance matters for Option[T]. |
| 19:32:52 | flaviu | Jehan_: Rather than nil and option at the same time, you should use an Either[T, DescriptiveEnum]. |
| 19:33:09 | Araq | and with 'nil' becoming more valid for string/seq in the upcoming release not only Rope is affected by this problem |
| 19:33:25 | flaviu | It's clearer and doesn't require that nil be allowed inside the option. |
| 19:33:36 | fowl | Jehan_, if every function silently worked fine with nil maybe wouldn't be needed, in this case PRope has taken the optimization that maybe would have used, i would offer the customer a refund and subscribe them to a bunch of newsletters and free bibles |
| 19:34:02 | Jehan_ | flaviu: Not sure what Either would do here. |
| 19:34:03 | repax | Some styles of programmin uses null-objects instead of nil, i.e. valid addresses to empty objects. |
| 19:34:56 | Jehan_ | flaviu: If anything, it seems to be a leaky abstraction. |
| 19:35:20 | repax | nil as no string is also a leaky abstraction |
| 19:35:32 | flaviu | Jehan_: Rather than using two unnamed failure states (Some(nil) and None), explicitly use two named failure states, (Left(MyEnum.Foo) or Left(MyEnum.Bar)). |
| 19:36:05 | fowl | the goal is to avoid allocations and a string is two pointers |
| 19:36:13 | Jehan_ | flaviu: The problem is that you're folding two abstraction layers into one. |
| 19:36:43 | repax | a statically allocated empty string avoids that problem |
| 19:36:56 | Jehan_ | flaviu: Also, you're sacrificing efficiency again. |
| 19:37:24 | Jehan_ | And if you do that, you again cannot argue that you desperately need it for Option[T]. |
| 19:37:59 | flaviu | Jehan_: I understand what you mean by leaky abstraction, but that depends on how you approach the problem mentally. |
| 19:37:59 | flaviu | But I don't see how using `nil` to represent None is sacrificing efficiency. |
| 19:38:25 | Jehan_ | It isn't. Nil to represent None is an efficiency gain at the cost of expressiveness. |
| 19:38:33 | Jehan_ | That's my point. |
| 19:38:45 | Jehan_ | There's no reason to represent None as nil other than efficiency. |
| 19:39:21 | flaviu | Jehan_: Even if I didn't use that optimization, I still require that my Options do not contain nil. |
| 19:39:23 | Jehan_ | And you sacrifice efficiency elsewhere for that (in that T must not be nil). |
| 19:39:56 | Jehan_ | flaviu: Then your options are broken, because they don't work for nullable types. |
| 19:40:55 | flaviu | I see that brokenness as desirable in this case. |
| 19:41:33 | Jehan_ | flaviu: Why? |
| 19:41:45 | Jehan_ | I see big problems. |
| 19:41:55 | Jehan_ | For starters, it would introduce silent errors. |
| 19:42:16 | flaviu | I don't want the client to worry about receiving a Some(nil) -- they either get a Some(#real value goes here), or they get a None. |
| 19:42:19 | Jehan_ | You instantly get all problems with nil again. |
| 19:42:39 | flaviu | Jehan_: I don't understand what you mean by silent errors. |
| 19:42:40 | * | xcombelle joined #nim |
| 19:42:58 | Jehan_ | Uninitialized variable => nil => becomes silently None when turned into an option rather than raising an error when accessed. |
| 19:43:01 | * | HakanD___ quit (Quit: Be back later ...) |
| 19:43:11 | Araq | flaviu: Rope is a very good example. 'nil' is simply the empty rope, it doesn't produce crashes |
| 19:43:21 | Joe-T | should PType.sym ever be nil? |
| 19:43:37 | Joe-T | or is the fact that type.sym is nil a bug? |
| 19:43:44 | Araq | Joe-T: yeah it can be for structural types, e.g seq[int] |
| 19:43:47 | flaviu | Jehan_: It'll assert(false) if it gets nil, so not quiet silent. |
| 19:43:53 | Jehan_ | The whole point of Option[T] is to make sure that the programmer is explicit about testing the content before accessing it. |
| 19:43:55 | Joe-T | what about generics? |
| 19:44:05 | Jehan_ | If nil implicitly becomes None, you have a similar problem again. |
| 19:44:21 | Joe-T | template ifFastObjectTypeCheckFailed is causing SIGSEGV because |
| 19:44:32 | Araq | Joe-T: I fixed this bug already |
| 19:44:34 | flaviu | Jehan_: nil implicitly becomes a assertion failure, not None. |
| 19:44:39 | Joe-T | oh lol |
| 19:44:52 | Araq | Joe-T: but I still need to test it and push |
| 19:45:04 | flaviu | Araq: That's an interesting implementation, I'll have to consider how to handle that. |
| 19:45:10 | Jehan_ | flaviu: Ah, we weren't there yet. In that case, you still have the problem that you can't have nil as a value. |
| 19:45:16 | BlaXpirit | guys |
| 19:45:17 | BlaXpirit | https://gist.github.com/BlaXpirit/429f0889d1bc645a9c58 |
| 19:45:25 | BlaXpirit | i know almost nobody will like this |
| 19:45:34 | BlaXpirit | but it incorporates many of mentioned ideas |
| 19:45:40 | flaviu | Araq: Is there some sort of compile-time reflection to figure out if a value is not-nil? |
| 19:46:04 | Araq | flaviu: you can do that with macros.getType, kind of |
| 19:46:30 | flaviu | BlaXpirit: Exposing implementation details publicly. Tsk, tsk. |
| 19:46:37 | BlaXpirit | nah dude |
| 19:46:42 | * | ehaliewicz joined #nim |
| 19:46:45 | BlaXpirit | what if someone wants to opt into using DistinctOption |
| 19:46:55 | BlaXpirit | i mean |
| 19:47:04 | BlaXpirit | what if someone wants to opt into using TupleOption |
| 19:47:11 | BlaXpirit | to also allow nil |
| 19:47:22 | reactormonk | Araq, could you also make arrow-like if it starts with ~ - = and ends with >? |
| 19:47:59 | fowl | BlaXpirit, you could allow a function to be defined like forceTupleOption(t) to force tuple implementation |
| 19:48:08 | BlaXpirit | yeah |
| 19:48:32 | Araq | reactormonk: do we *really* need that? the definition of "arrow like" is beginning to annoy me |
| 19:48:54 | reactormonk | Araq, just a random idea. I didn't follow the discussion too closely |
| 19:49:07 | flaviu | Jehan_: Looks like Araq has convinced me, Some(nil) is practical in cases. |
| 19:49:29 | Araq | er no no no, don't do this. Jehan_ convinced you. |
| 19:49:37 | Araq | he came up with the example. |
| 19:49:48 | Jehan_ | flaviu: You could probably make a good argument for a non-system programming language, actually. |
| 19:49:54 | reactormonk | is the type inference in nim strong enough for https://github.com/Araq/Nim/issues/2179 ? |
| 19:50:07 | Jehan_ | But in a system programming language, nil as a representation is simply too pervasive. |
| 19:50:08 | flaviu | Really? Sorry, I stepped away for a few moments for food and must have missed the message. |
| 19:50:36 | flaviu | Jehan_: Nim provides the "not nil" specifier, which will work fine for optimization purposes :) |
| 19:50:37 | repax | Perhaps I'm just dense but Some(EmptyRope) would also be meaningful. |
| 19:51:08 | Jehan_ | flaviu: Oh yes, I thought I had mentioned that T not nil would work? |
| 19:51:18 | fowl | reactormonk, should be possible to get to `x => x.lastName` from `specialident.lastName` |
| 19:51:31 | Araq | reactormonk: not sure, looks like one only has to rewrite _.foo to x => x.foo which has nothing to do with type checking |
| 19:51:56 | flaviu | Also, this thing with Ropes being nil would not work in a class-based language where methods depend on the "this" value being non-null. |
| 19:52:09 | flaviu | Nim is in a fairly unique position here. |
| 19:52:14 | Jehan_ | flaviu: Only if you dispatch on the argument. |
| 19:52:49 | fowl | reactormonk, if you want to look into it, dot operator macro should be what you need |
| 19:53:30 | reactormonk | fowl, is x => x.name valid nim? |
| 19:53:48 | reactormonk | aka what should the rewritten expression look like? |
| 19:53:48 | fowl | thats a lambda shortcut from future.nim |
| 19:54:33 | reactormonk | ah, neat |
| 19:54:42 | Jehan_ | Wouldn't x still need a type? |
| 19:54:54 | Jehan_ | E.g. (x: T) => x.name |
| 19:55:16 | Araq | reactormonk: I'm beginning to like _.age < _.age more than (x, y) => x.age < y.age |
| 19:55:17 | reactormonk | I didn't know about future before |
| 19:55:31 | reactormonk | Araq, yup, it is |
| 19:55:41 | def- | Araq: what if you want (x,y) => x*x == y ? |
| 19:55:59 | reactormonk | Araq, although I'd go for cmp_by(_.age) if possible I think that's a bit too much |
| 19:55:59 | Araq | def-: then you might as well use 'proc' IMHO |
| 19:56:26 | Jehan_ | Araq: The only problem is to figure out what the boundaries of the expression are. |
| 19:56:37 | reactormonk | def-, exp(_, 2) == _ |
| 19:56:48 | * | Arrrrr quit (Quit: Page closed) |
| 19:57:01 | Araq | I never liked '=>' too much, it was always "terse, but not as cute as 'it' " for me |
| 19:57:03 | Jehan_ | I.e. is _.age <_.age equivalent to (x, y) => (x.age < y.age) or (x => x.age) < (y =>y.age) |
| 19:57:05 | BlaXpirit | :O this would be amazing |
| 19:57:14 | fowl | Jehan_, you're right |
| 19:57:25 | BlaXpirit | yes. |
| 19:57:26 | fowl | map wont accept x => x*2 |
| 19:57:30 | reactormonk | Jehan_, I think that would depend on the surrounding expression, e.g. you would always need to to map(_.age) |
| 19:57:30 | * | bcinman quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 19:57:34 | Araq | Jehan_: Scala manages |
| 19:57:49 | Jehan_ | Araq: Yeah, and it tends to confuse people. :) |
| 19:58:06 | reactormonk | Araq, I tend to go with ({_.age}) in scala just because that pretty much covers every parser hiccup |
| 19:58:38 | * | bcinman joined #nim |
| 19:58:45 | Jehan_ | Scala is exactly why I was thinking of that problem. :) |
| 19:59:06 | reactormonk | so I would be fine to require map(_.foo) - if that can be done without parser help |
| 19:59:10 | reactormonk | lemme see what dumpTree says |
| 19:59:33 | flaviu | hm, how about foo _ < 1? foo(_) < 1 or foo(1 < 1) ? |
| 19:59:40 | flaviu | *foo(_ < 1) |
| 19:59:41 | Jehan_ | For what it's worth, Sather used an explicit bind(...) |
| 19:59:55 | reactormonk | test.nim(2, 10) Error: invalid token: _ (\95) |
| 20:00:25 | fowl | reactormonk, use a diff ident for now |
| 20:00:26 | reactormonk | flaviu, a) invalid b) foo(<identity function>) < 1 c) eh. |
| 20:00:42 | reactormonk | fowl, which one? |
| 20:01:12 | flaviu | .eval import macros; dumpLisp(foo(a.age)) |
| 20:01:14 | Mimbus | flaviu: Call(Ident(!"foo"), DotExpr(Ident(!"a"), Ident(!"age"))) |
| 20:02:05 | reactormonk | .eval import macros; dumpLisp(foo(a.age < a.age)) |
| 20:02:06 | Mimbus | reactormonk: Call(Ident(!"foo"), Infix(Ident(!"<"), DotExpr(Ident(!"a"), Ident(!"age")), DotExpr(Ident(!"a"), Ident(!"age")))) |
| 20:02:22 | reactormonk | seems to be handled well enough by the parser |
| 20:02:30 | BlaXpirit | weren't we talking about Option? |
| 20:02:41 | reactormonk | BlaXpirit, nah, I switched in something else ;_) |
| 20:03:01 | flaviu | .eval import macros; dumpLisp(foo(_.age < _.age)) |
| 20:03:02 | Mimbus | flaviu: eval.nim(4, 13) Error: invalid token: _ (\95) |
| 20:03:07 | Araq | reactormonk: there is a PR to make _ a valid but somewhat special identifier |
| 20:03:21 | flaviu | .eval import macros; dumpLisp(foo(ߺ.age < ߺ.age)) |
| 20:03:21 | reactormonk | Araq, I know, and I would say skUnderscore isn't too bad of an idea |
| 20:03:22 | Mimbus | flaviu: Call(Ident(!"foo"), Infix(Ident(!"<"), DotExpr(Ident(!"ߺ"), Ident(!"age")), DotExpr(Ident(!"ߺ"), Ident(!"age")))) |
| 20:03:58 | flaviu | Araq: Looks like the compiler is susceptible to a homoglyph attack ;) |
| 20:04:32 | reactormonk | flaviu, but yup, seems to work as expected. |
| 20:04:54 | * | wink-s quit (Quit: Page closed) |
| 20:05:01 | reactormonk | Araq, hm, let me see how exactly it's handled and if it would work |
| 20:05:23 | * | wink-s joined #nim |
| 20:05:39 | reactormonk | Araq, should I look into the _ part or pull up the tests for the GC? |
| 20:07:46 | * | user7181 joined #nim |
| 20:08:00 | flaviu | IIRC _ is just an if in the parser. |
| 20:09:03 | reactormonk | in the patch it's just a branch of a case statement |
| 20:09:30 | Araq | reactormonk: *after* quite some discussion though |
| 20:09:43 | Araq | reactormonk: tests for GC are more pressing |
| 20:09:50 | reactormonk | Araq, ok, so be it |
| 20:10:32 | BlaXpirit | guys, srsly, this is cool https://gist.github.com/BlaXpirit/429f0889d1bc645a9c58 |
| 20:11:26 | reactormonk | BlaXpirit, you would need all the monoid operations for them to be really useful |
| 20:11:41 | reactormonk | well, "all the" isn't too many |
| 20:12:22 | reactormonk | wait a minute, I don't think I grasped the full code yet... |
| 20:12:44 | Araq | Jehan_: _.foo is parsed like it.foo ? how can it become confusing? |
| 20:12:46 | flaviu | BlaXpirit: You're really going to have to stop exposing implementation details. |
| 20:12:54 | BlaXpirit | flaviu, you don't get it |
| 20:13:11 | flaviu | I do, but using a tuple isn't a good idea. |
| 20:13:19 | flaviu | Use an object and don't make the fields public. |
| 20:13:21 | BlaXpirit | maybe |
| 20:13:50 | BlaXpirit | tuple can be unpacked |
| 20:13:51 | BlaXpirit | no, this is nice |
| 20:14:08 | Jehan_ | Araq: If you have multiple instances of _, they can indicate multiple parameters. |
| 20:15:24 | dom96 | BlaXpirit: cool! |
| 20:15:50 | * | lyro quit (Quit: WeeChat 0.4.3) |
| 20:16:02 | flaviu | BlaXpirit: Then add a asTuple() proc. Please don't expose things unnecessarily. |
| 20:16:12 | BlaXpirit | flaviu, see updated code |
| 20:16:31 | BlaXpirit | both fields are meant to be readable |
| 20:16:39 | BlaXpirit | and if u think about it, no harm will come from writing to them |
| 20:17:24 | * | lyro joined #nim |
| 20:17:45 | flaviu | Yes, there can be. Rather then just having some(foo) to create a sum, (true, foo) will also be valid, as will myOption.val = foo. |
| 20:17:56 | flaviu | s/sum/option |
| 20:18:16 | flaviu | See https://github.com/flaviut/nre/blob/master/src/nre.nim#L88 in nre. |
| 20:18:17 | BlaXpirit | which is useful |
| 20:18:35 | flaviu | Not at all. It makes the client code harder to understand. |
| 20:18:43 | * | milosn quit (Ping timeout: 255 seconds) |
| 20:18:56 | BlaXpirit | unpacking tuple is useful |
| 20:19:19 | flaviu | Perhaps useful in the sense of saving keystrokes, but not useful in the sense of reducing mental overhead. |
| 20:19:32 | BlaXpirit | we may find that there is a cool template-based replacement for this unpacking |
| 20:19:49 | BlaXpirit | it's most likely best to not make fields readable, sure |
| 20:20:07 | BlaXpirit | but first i have to hear if such an implementation is even remotely acceptable |
| 20:20:39 | flaviu | What I would do is have a single Option implementation, and instead take advantage of the "not nil" tag on the type whenever possible. |
| 20:21:56 | * | HakanD___ joined #nim |
| 20:22:03 | BlaXpirit | welp i just caused compiler to sigsegv in a way i've never seen |
| 20:22:04 | Araq | BlaXpirit: I like it, but you don't have to convince me as I don't like Option[T] anyway |
| 20:22:44 | BlaXpirit | ah Stack overflow |
| 20:23:20 | xcombelle | may I say that the #!strongSpaces directive looks like problematic feature |
| 20:23:24 | flaviu | The names DistinctOption and TupleOption also violate encapsulation. |
| 20:23:34 | BlaXpirit | kinda |
| 20:23:47 | flaviu | Completely. Client code doesn't need to know how they're implemented. |
| 20:23:49 | BlaXpirit | in your eyes, flaviu. the `Tuple` part was meant to be a feature |
| 20:24:02 | BlaXpirit | if it is not a tuple anymore, of course i wouldn't call it tuple :p |
| 20:25:20 | BlaXpirit | Jehan_ was an advocate of tuples |
| 20:25:34 | BlaXpirit | i was amused by the idea, but honestly i don't see the advantage now |
| 20:25:35 | Jehan_ | BlaXpirit: Not necessarily. |
| 20:26:11 | Jehan_ | I was wondering if a different implementation would confer any practical benefit. |
| 20:26:46 | BlaXpirit | NilOption, CompositeOption? |
| 20:26:51 | BlaXpirit | not nearly as attractive |
| 20:27:39 | flaviu | Sure, but they're better names. |
| 20:27:43 | * | milosn joined #nim |
| 20:28:02 | flaviu | The idea with macros and the not nil tag is the best way to do it, I think. |
| 20:28:33 | Jehan_ | I am wondering whether it's necessary to complicate the implementation at this point. |
| 20:28:38 | BlaXpirit | don't forget the 0 overhead part of NilOption |
| 20:28:54 | Jehan_ | There's something to be said for the KISS principle. |
| 20:30:08 | flaviu | Jehan_: Certainly something to consider. How about sticking to the dump implementation and fixing it when someone complains about performance? :P |
| 20:30:22 | Jehan_ | flaviu: That's pretty much what I was thinking. |
| 20:30:43 | Jehan_ | As I said, I'm still not entirely convinced that a simple tuple-based implementation isn't perfectly sufficient. |
| 20:30:55 | Araq | xcombelle: you may say it, but IMHO the lack of it caused more problems in reality |
| 20:30:59 | BlaXpirit | flaviu hates tuples |
| 20:31:12 | BlaXpirit | Jehan_, what exactly is the advantage of tuple over object |
| 20:31:25 | Jehan_ | Especially given that Nim isn't a functional language, it has a convenience factor. |
| 20:31:31 | flaviu | Jehan_: The tuple-based implementation cannot be swapped for another without breaking client code. |
| 20:31:41 | Jehan_ | E.g.: var (found, value) = search(…) |
| 20:31:47 | Jehan_ | flaviu: I am aware of that. |
| 20:31:57 | BlaXpirit | that could be done with a template |
| 20:32:22 | BlaXpirit | search(...).unpack(found, value) |
| 20:32:32 | BlaXpirit | or anything else |
| 20:32:35 | Jehan_ | BlaXpirit: Yeah, but inconvenient. |
| 20:32:53 | flaviu | Jehan_: I wouldn't be against a converter option-to-tuple. |
| 20:33:08 | BlaXpirit | oooohh |
| 20:33:43 | Jehan_ | flaviu: What I'm wondering is whether Option[T] in its traditional form makes the same sense for a non-functional language, or if it's really overengineering it. |
| 20:33:49 | BlaXpirit | is good |
| 20:33:57 | xcombelle | Araq if I would do something would be eventually raise an exception when space is not following priority but 1+3 * 4 == (1+3) * 4 just looks wrong |
| 20:34:09 | Jehan_ | It's nothing that I feel particularly strongly about. |
| 20:34:14 | flaviu | Jehan_: I'd love for the stdlib to become more functional. |
| 20:34:35 | * | Kingsquee joined #nim |
| 20:35:09 | Jehan_ | But I'd like to see the options evaluated rather than just adapting something because everybody else does it, too. |
| 20:35:47 | BlaXpirit | what is the naming convention for private fields? |
| 20:36:11 | Araq | BlaXpirit: fields are lowerCased, private just means there is no * |
| 20:36:24 | BlaXpirit | yeah but i have a private field "val" and i want proc "val" |
| 20:36:35 | BlaXpirit | to basically make a read-only field |
| 20:36:40 | flaviu | BlaXpirit: If you want to copy C++, m_foo :P |
| 20:36:53 | Jehan_ | That's actually a good question in general. |
| 20:37:00 | * | xcombelle quit (Quit: Leaving) |
| 20:37:10 | Jehan_ | Make a field readonly for other module is something that I've wanted more than once myself. |
| 20:37:15 | dom96 | I usually go with "getVal" for proc in that case. |
| 20:37:21 | BlaXpirit | oh hell no |
| 20:37:39 | Araq | Jehan_: there is an idea that foo+: int means public, but readonly |
| 20:37:39 | BlaXpirit | i'm not making a json module here |
| 20:37:53 | BlaXpirit | that would be nice |
| 20:39:07 | Jehan_ | Araq: Hmm. I think I'd almost like something like a {.readonly.} pragma better. |
| 20:39:23 | BlaXpirit | that would be nicer |
| 20:39:36 | flaviu | I agree, I'd prefer a pragma. |
| 20:39:43 | dom96 | I'd prefer + |
| 20:39:49 | Jehan_ | (Being speculative, not sure what the code would actually look like.) |
| 20:39:49 | Araq | lol |
| 20:40:00 | dom96 | {.readonly.} is far too long for something which, I assume, will be quite common. |
| 20:40:20 | Jehan_ | Alternatively, a way to cleanly overload a template or proc to access a field with the same name. |
| 20:40:32 | Jehan_ | I honestly don't know right now what would happen if one tried. |
| 20:40:46 | Araq | BlaXpirit: I *think* proc foo(x: Obj): T = x.foo does work |
| 20:41:07 | Jehan_ | Araq: Hmm, let me check. |
| 20:41:07 | Araq | in fact, I'm quite sure it does |
| 20:41:09 | dom96 | yeah, it does. I tried it recently. |
| 20:41:21 | BlaXpirit | :o that's nice |
| 20:41:37 | BlaXpirit | oh yeah, don't know why i thought it wouldn't work |
| 20:41:40 | flaviu | No need for anything then :D |
| 20:41:43 | BlaXpirit | false alert. thanks |
| 20:43:00 | * | Trustable joined #nim |
| 20:44:18 | Jehan_ | Hmm, it works with templates, too. |
| 20:44:34 | Araq | yeah overloading for templates is quite cool |
| 20:44:54 | Jehan_ | Not within the same module, though. |
| 20:45:06 | Jehan_ | In that case, direct field access takes precedence. |
| 20:45:07 | Araq | lol |
| 20:45:09 | Jehan_ | But that's fine. |
| 20:45:28 | Araq | oh yeah, that's the way it's supposed to work |
| 20:52:48 | BlaXpirit | flaviu, million dollar idea here. |
| 20:53:12 | BlaXpirit | you know how something returns Option[RegexMatch] |
| 20:53:15 | * | a5i quit (Quit: Connection closed for inactivity) |
| 20:53:34 | flaviu | yep. |
| 20:53:39 | * | vendethiel joined #nim |
| 20:53:51 | BlaXpirit | what if one could do if "s".match(re"stuff").extract(m): use(m) |
| 20:54:23 | BlaXpirit | m is a template that returns bool and injects |
| 20:54:37 | BlaXpirit | this is actually a feature for option |
| 20:54:40 | Araq | so you reinvented re.`=~` |
| 20:54:42 | flaviu | Sounds fine, I'm going to need a better name through. |
| 20:54:45 | BlaXpirit | yes but generically |
| 20:54:53 | BlaXpirit | a better name... how about `->` |
| 20:54:59 | BlaXpirit | lol |
| 20:55:04 | flaviu | Name, not symbol :P |
| 20:55:36 | BlaXpirit | Araq, well of course, `=~` is not pointless, but this would work for all Options and everyone will be happy as heck |
| 20:56:03 | flaviu | This is sort of like bind, but not as functional. |
| 20:57:14 | flaviu | Where "functional" refers to the padigrim, not as a assessment of worth. |
| 20:57:45 | dtscode | padigrim? |
| 20:57:53 | flaviu | dtscode: I can't spell :P |
| 20:58:01 | dtscode | paradigm? |
| 20:58:30 | Araq | BlaXpirit: the general consensus is that if (let m = "s" =~ re"stuff"; m.isMatch): echo m.capture[0] is best |
| 20:58:31 | flaviu | "extract" is like option 'a -> option () |
| 20:58:50 | flaviu | dtscode: Yep, as I said, I can't spell. |
| 20:59:01 | BlaXpirit | if "s".match(re"stuff") ~> m: |
| 20:59:05 | Jehan_ | Honestly, this is where a small amount of OOP would greatly simplify things. :) |
| 20:59:06 | BlaXpirit | this is radical |
| 20:59:16 | dtscode | flaviu, just making sure it was that |
| 20:59:28 | Araq | Jehan_: how so? |
| 20:59:30 | Jehan_ | let m = matcher(someregexp); if m.success: doSomethingWith(m.capture) |
| 20:59:48 | Araq | nah, doesn't work well |
| 20:59:54 | Araq | if m.success: ... |
| 20:59:56 | Jehan_ | Rather than trying to carry all the state through local variables, put it inside a matcher object. |
| 21:00:04 | Araq | else: |
| 21:00:09 | Araq | let nextMatch = ... |
| 21:00:20 | Araq | if nextMatch: ... # damn, I want 'elif' |
| 21:00:40 | Araq | that was one of the reasons we introduced the (;) construct |
| 21:00:59 | Araq | Jehan_: nre already returns a match object |
| 21:01:06 | Jehan_ | Can do: if m.match("foo"): … elif: m.match("bar"): … |
| 21:01:06 | Araq | I think |
| 21:01:27 | flaviu | Jehan_: Yes, that syntax should work as-is. |
| 21:01:44 | flaviu | except that m: string and "foo" -> re"foo" |
| 21:02:36 | fowl | flaviu, does nre have `=~` like stdlib's? |
| 21:02:42 | flaviu | fowl: No. |
| 21:03:23 | fowl | any reason why not? |
| 21:03:32 | flaviu | But optional_t will have the feature that BlaXpirit is suggesting, just as soon as someone comes up with a name I like. |
| 21:03:53 | BlaXpirit | lol i'ma make my own library with blackjack and |
| 21:03:53 | Araq | fowl: Not-invented-somewhere-else-syndrome |
| 21:03:54 | flaviu | fowl: I dislike having multiple names for the same thing, especially as an excuse for poor design. |
| 21:04:05 | Jehan_ | if x ?= somethingThatReturnsOption(…): doSomethingWith(x) |
| 21:04:17 | BlaXpirit | Jehan_, that's cool |
| 21:04:24 | BlaXpirit | much better in fact |
| 21:04:32 | BlaXpirit | flaviu, there is no need for a name |
| 21:04:36 | BlaXpirit | embrace operators |
| 21:04:50 | flaviu | Operators are the lazy way to come up with a name. |
| 21:04:55 | Jehan_ | Heh. :) |
| 21:04:59 | fowl | flaviu, i fail to see how re.`=~` is poor design |
| 21:05:20 | dtscode | other than precedence, theres not much difference between a method and an operator :D |
| 21:05:20 | BlaXpirit | fowl, it is not poor design |
| 21:05:24 | BlaXpirit | but it's just a one-off |
| 21:05:30 | Jehan_ | Expressions with side effects do make me a bit queasy, I have to say. |
| 21:05:50 | fowl | nobody cares about this in perl |
| 21:06:01 | BlaXpirit | Jehan_, it seems like... i can't implement it named `?=` |
| 21:06:07 | flaviu | fowl: The rest of the library is poorly designed, and `=~` is to work around that design, it lets the client avoid `var matches: array[MaxSubpatterns, string] ` |
| 21:06:22 | Jehan_ | BlaXpirit: You mean? |
| 21:06:24 | BlaXpirit | nvm |
| 21:06:36 | BlaXpirit | it works |
| 21:06:47 | flaviu | fowl: And because no one cares about that in perl, just look at all the jokes it's triggered. |
| 21:06:49 | fowl | yes |
| 21:06:54 | fowl | many keystrokes were avoided |
| 21:06:54 | * | ehaliewicz quit (Remote host closed the connection) |
| 21:07:19 | Araq | when I borrowed perl's =~ I never was concerned with "should I do it?". it was "can I do it?" :P |
| 21:07:22 | fowl | and the user knows about matches because they RTFM'd |
| 21:08:01 | BlaXpirit | proc test(): ?string = some "abc"; if r ?= test(): echo r |
| 21:08:03 | BlaXpirit | duuuude |
| 21:08:13 | Araq | flaviu: I disagree. I think my 're' is much better designed than you give it credit for |
| 21:08:28 | BlaXpirit | nope |
| 21:08:34 | Araq | parallelReplace being a good example :P |
| 21:08:43 | BlaXpirit | especially the name |
| 21:09:11 | flaviu | Araq: parallelReplace is useful, but I'll accuse it of being too hard to understand. |
| 21:09:21 | BlaXpirit | and slow? |
| 21:09:36 | flaviu | Why would it be slow? |
| 21:09:45 | BlaXpirit | well it calls N regexes for each character |
| 21:09:51 | BlaXpirit | doesn't it? |
| 21:10:08 | flaviu | Unless you use the DFA engine of PCRE, you'll have to do the same. |
| 21:10:19 | BlaXpirit | i know, just saying |
| 21:10:40 | BlaXpirit | (i mean, i don't know what "DFA" is, just that i know it can't be made faster under simple circumstances) |
| 21:11:02 | BlaXpirit | behold https://gist.github.com/BlaXpirit/429f0889d1bc645a9c58 |
| 21:12:22 | flaviu | BlaXpirit: Allows partial matches and and guarantees O(string_len) performance. |
| 21:12:58 | BlaXpirit | time to make a nimble package |
| 21:12:59 | fowl | BlaXpirit, wont line 51 cause recursion |
| 21:13:11 | BlaXpirit | nah, fowl, it gets the field |
| 21:13:33 | flaviu | How does "injectAs" sound? |
| 21:13:43 | BlaXpirit | worse than ?= |
| 21:13:57 | flaviu | BlaXpirit: I refuse to take the easy approach to naming things. |
| 21:14:03 | Araq | flaviu: Nim's =~ actually solves Perl's problem of introducing globals for the same effect |
| 21:14:44 | BlaXpirit | Araq, that's great, but you added `=~` because you actually want Option[T] |
| 21:14:50 | fowl | gn |
| 21:14:59 | BlaXpirit | and there's the solution for all Option[T] cases |
| 21:15:19 | Araq | BlaXpirit: no. I didn't want Option[T]. |
| 21:15:29 | BlaXpirit | well you didn't want it, but you needed it |
| 21:15:46 | fowl | BlaXpirit, no you still need a way to force a type to be the tuple option |
| 21:15:47 | Araq | I wanted if match: doSomethingWith(capture) |
| 21:16:12 | Araq | and I succeeded :P |
| 21:16:25 | BlaXpirit | fowl, you can just use CompositeOption[T] instead of ?T and that's done |
| 21:16:35 | fowl | thats hideous |
| 21:16:44 | Araq | without spending nights of discussions on the feature |
| 21:16:45 | BlaXpirit | actually no |
| 21:16:48 | fowl | lets fill it with hidden behavior |
| 21:17:17 | BlaXpirit | fowl, what's actually hideous is defining a dummy proc |
| 21:17:19 | fowl | semantics should be impossible to foretell |
| 21:17:46 | fowl | BlaXpirit, why? doing that is useful in all kinds of scenarios |
| 21:17:47 | Araq | without caring if the average Java developer would be scared to death because of the injected 'matches' var |
| 21:18:10 | Araq | in fact |
| 21:18:29 | Araq | after my strange loop talk people came to me and told me they loved my =~ template ... |
| 21:18:56 | BlaXpirit | Araq, it is not bad, you don't need to defend it |
| 21:19:21 | Araq | I'm not defending it, I'm bragging about it |
| 21:19:29 | BlaXpirit | but here i am with a more generic solution, so let's add it to stdlib Araq, let's add https://gist.github.com/BlaXpirit/429f0889d1bc645a9c58 to stdlib right about now :D |
| 21:19:54 | BlaXpirit | look at the bottom |
| 21:20:00 | fowl | BlaXpirit, how does line 68 work? what is val? |
| 21:20:19 | BlaXpirit | fowl, that appears to be an error |
| 21:20:25 | BlaXpirit | i just never tried totuple and it somehow passed |
| 21:20:35 | Jehan_ | For what it's worth, it's possible to implement none[T] instead of none(T), too (though it's not-pretty). |
| 21:20:36 | fowl | because its generic |
| 21:21:21 | BlaXpirit | Jehan_, i actually like that better |
| 21:21:58 | flaviu | Araq: if "foo".match(re"bar").injectVar(matches): ... will soon work the same way, although I'd like to request some bikeshedding on the name. |
| 21:22:04 | Jehan_ | Make none a variable of a distinct type and implement template `[]`(t: typedesc) for it. |
| 21:22:18 | BlaXpirit | flaviu :( |
| 21:22:18 | Jehan_ | Eh, constant of a distinct type. |
| 21:22:27 | Araq | flaviu: that loses its mojo :P |
| 21:23:01 | Jehan_ | flaviu: This is actually something where I'd like to see an operator. |
| 21:23:14 | BlaXpirit | yeah |
| 21:23:21 | Jehan_ | A function call doesn't really make it clear that this messes with the local variables. |
| 21:23:26 | flaviu | Araq: If you give a total noob nothing more than the type signature of match() and ask them what it means, they'd probably immediately be able to figure it out. |
| 21:23:37 | BlaXpirit | Araq, seriously, how do you like the Option[T] i implemented? |
| 21:23:54 | Jehan_ | Something like ?= looks unusual enough that you know you have to look it up. |
| 21:24:07 | Araq | BlaXpirit: I like it quite a bit, but I leave this to #nim |
| 21:24:28 | Jehan_ | For what it's worth, BlaXpirit: I have something very similar in my own stdlib, except for tuples (so far). |
| 21:25:29 | * | milosn_ joined #nim |
| 21:25:29 | * | milosn quit (Read error: Connection reset by peer) |
| 21:25:38 | flaviu | All I have to say is that you'll need to stop hating typing. |
| 21:25:43 | * | milosn_ is now known as milosn |
| 21:25:57 | BlaXpirit | it's not only typing. Jehan_ provided real arguments. |
| 21:26:41 | Jehan_ | This time I actually wasn't trying to make an argument, just saying that's what I had. |
| 21:26:56 | flaviu | Yeah, Jehan_ does have a good point. |
| 21:26:57 | BlaXpirit | "arguments" are not necessarily to "argue" |
| 21:28:05 | flaviu | I'm really not a big fan of the `?` template. Also, encapsulation, encapsulation, encapsulation. |
| 21:28:11 | Jehan_ | For what it's worth, I've been using tuples in my stdlib, because I've been deconstructing and constructing them a lot in practice. |
| 21:28:23 | Jehan_ | That is, however, pretty specific to my own code. |
| 21:28:52 | flaviu | Oh, you've changed from tuple to object |
| 21:28:55 | Araq | flaviu: this argument about total noobs is getting tiresome. noobs do not stay noobs forever. |
| 21:29:00 | Jehan_ | But at some point it felt silly to wrap things behind an object type when it was pretty much obvious everywhere what the actual implementation was. |
| 21:29:54 | flaviu | Araq: If the library user has to dig into the docs to get a general idea of what a function does, I feel I've failed as a API designer. |
| 21:30:24 | flaviu | re. me @ tuple to object: Well, in that case, just encapsulation, encapsulation. |
| 21:30:24 | Araq | flaviu: you also failed if nobody has fun using your API |
| 21:30:38 | BlaXpirit | i didn't have fun honestly |
| 21:31:24 | Araq | the costs of people having no fun at programming are never measured but I can assure you it's a real problem too. |
| 21:31:29 | BlaXpirit | strange, but toTuple actually doesn't work |
| 21:31:39 | BlaXpirit | oh, to hell with it, ?= is better |
| 21:31:53 | flaviu | Araq: When using re, I didn't have much fun. I spent much of my time worrying about functions that do almost, but not quite what I want. |
| 21:32:00 | BlaXpirit | that too |
| 21:32:12 | Araq | flaviu: fair enough but I'm making a general point :P |
| 21:33:08 | flaviu | Araq: Many simple composable pieces are better than one amazing, non-composable piece. |
| 21:33:14 | flaviu | At least IMO. |
| 21:33:55 | flaviu | I think that's where the appeal of functional programming is. It's possible to compose things in ways that would not be traditionally possible. |
| 21:34:58 | Jehan_ | Hmm. My problem with functional programming is that it's really only easy to compose a limited amount of stuff. |
| 21:35:15 | flaviu | BlaXpirit: If you didn't have fun using nre, please tell me the reason why. |
| 21:35:20 | Jehan_ | map is easy to do functionally, histogram isn't. |
| 21:35:24 | BlaXpirit | no, i didnt have fun using optional_t |
| 21:35:33 | Araq | yup and in contrast to Unix it actually works :P because it uses a type system and structured data :P |
| 21:36:16 | flaviu | Araq: I'd like to remain on-topic. |
| 21:36:31 | flaviu | BlaXpirit: I can definitely see how that's possible. |
| 21:36:46 | BlaXpirit | well i'm going to try to push a fun lib into stdlib |
| 21:37:11 | flaviu | Please no type operators. |
| 21:37:28 | BlaXpirit | you don't have to use them, really |
| 21:37:39 | BlaXpirit | just have your way with CompositeOption everywhere |
| 21:38:00 | * | NimBot joined #nim |
| 21:38:03 | flaviu | BlaXpirit: But I have to look at everyone else use them and feel my blood pressure rising :/ |
| 21:38:08 | BlaXpirit | :/ |
| 21:38:13 | flaviu | BlaXpirit: Option[T] is a better name. |
| 21:38:31 | BlaXpirit | if you can implement it based on what's there, grea |
| 21:38:41 | BlaXpirit | but it's already taken: Option*[T] = NilOption[T] or CompositeOption[T] |
| 21:38:57 | Araq | did we agree it should be in its own module btw? and not in system.nim? |
| 21:39:05 | BlaXpirit | oh but of course!!! |
| 21:39:07 | flaviu | Araq: Of course! |
| 21:39:08 | BlaXpirit | option.nim |
| 21:39:22 | BlaXpirit | flaviu, I did try to override Option[], but it just tries to instantiate that type |
| 21:39:25 | flaviu | BlaXpirit: Ah, I see what you mean. |
| 21:39:33 | Araq | ok though our naming standard says options.nim |
| 21:39:41 | BlaXpirit | that's great too |
| 21:39:46 | flaviu | BlaXpirit: What about using Option[T] and using macros to test not nil? |
| 21:39:57 | flaviu | Have you considered that? |
| 21:40:01 | BlaXpirit | I don't understand |
| 21:40:08 | Araq | but I think Maybe[T] is a better name |
| 21:40:16 | BlaXpirit | ok, Araq, anything u want |
| 21:40:28 | Jehan_ | I still like Cond[T]. :) |
| 21:40:38 | BlaXpirit | don't think anybody else does |
| 21:40:47 | Araq | Cond reminds me too much of condition variable |
| 21:40:52 | BlaXpirit | Araq, https://github.com/fowlmouth/nimlibs/blob/master/fowltek/maybe_t.nim these names? |
| 21:41:17 | BlaXpirit | I really like "some" and "none" tho :/ |
| 21:41:54 | Araq | just and nothing won't produce as many clashes though |
| 21:42:03 | BlaXpirit | ok then |
| 21:42:14 | BlaXpirit | CompositeMaybe? :| |
| 21:42:42 | Araq | why do we need Composite? |
| 21:42:43 | BlaXpirit | NilMaybe is also not as clear of an intent |
| 21:42:57 | BlaXpirit | Araq, to implement option for non-nullable types |
| 21:43:47 | BlaXpirit | or we could rename CompositeMaybe into Maybe |
| 21:44:04 | BlaXpirit | but then what would be the type that encompasses them both? |
| 21:44:17 | BlaXpirit | the most undecided type name :D SomeMaybe |
| 21:44:56 | Araq | CompositeOption wasn't a good name either, IMO and neither is NilOption |
| 21:45:11 | BlaXpirit | SomeMaybe*[T] = NilMaybe[T] or Maybe[T] |
| 21:45:12 | Araq | DistinctMaybe, ObjectMaybe, Maybe |
| 21:45:50 | BlaXpirit | there is an advantage in naming ObjectMaybe just Maybe to please people who don't want to use `?` or DistinctMaybe |
| 21:45:56 | Araq | or perhaps MaybeObj, MaybeDistinct, Maybe |
| 21:46:22 | BlaXpirit | Obj prefix kinda means something else already |
| 21:46:39 | Araq | the Obj suffix means "Object not ref" which is not wrong here |
| 21:46:52 | BlaXpirit | flaviu wouldn't like naming it "obj" |
| 21:47:02 | flaviu | Can we hold out on merging this until I see the feasibility of using a macro here? |
| 21:47:10 | BlaXpirit | nobody's merging anything |
| 21:47:16 | BlaXpirit | i'm gonna make docs, tests |
| 21:47:32 | flaviu | Ok, sounds great. |
| 21:47:40 | flaviu | .eval type Foo = ref object not nil |
| 21:47:41 | Mimbus | flaviu: <no output> |
| 21:47:56 | flaviu | .eval type Foo = ref object not nil; a: int |
| 21:47:57 | Mimbus | flaviu: eval.nim(4, 2) Error: invalid indentation |
| 21:47:58 | BlaXpirit | i propose... SomeMaybe*[T] = DistinctMaybe[T] or Maybe[T] |
| 21:48:07 | flaviu | But.. wat? |
| 21:49:23 | BlaXpirit | Maybe*[T] = MaybeDistinct[T] or MaybeObj[T] for now |
| 21:51:17 | * | HakanD___ quit (Quit: Be back later ...) |
| 21:52:06 | Araq | be back later or tomorrow |
| 21:52:37 | * | mwbrown quit (Ping timeout: 264 seconds) |
| 21:55:18 | * | brson quit (Quit: leaving) |
| 21:56:01 | * | bcinman quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 21:56:28 | * | saml quit (Quit: Leaving) |
| 21:57:43 | * | HakanD___ joined #nim |
| 21:59:55 | * | Jehan_ quit (Quit: Leaving) |
| 22:01:53 | flaviu | Little unrelated, but interesting: |
| 22:01:55 | flaviu | .eval import nre; echo("$1€2¥3£4".findall(re"\p{Sc}")) |
| 22:01:56 | Mimbus | flaviu: @[$, ¥, £] |
| 22:03:49 | flaviu | Don't mind the �s, it appears that either IRC or Mimbus doesn't like unicode. |
| 22:04:13 | BlaXpirit | all fine here |
| 22:04:13 | flaviu | I found it interesting that PCRE comes with this functionality. |
| 22:04:26 | flaviu | My client dislikes unicode then, dunno. |
| 22:08:33 | flaviu | I think I've found my favorite bug: |
| 22:08:36 | flaviu | .eval type Foo = ref object; var x: Foo not nil |
| 22:08:37 | Mimbus | flaviu: <no output> |
| 22:08:40 | flaviu | .eval type Foo = ref object; var x: Foo not nil = Foo() |
| 22:08:41 | Mimbus | flaviu: eval.nim(4, 24) Error: cannot prove 'Foo()' is not nil |
| 22:14:00 | flaviu | https://gist.github.com/815fa1353c86fc396b0e |
| 22:14:03 | flaviu | \o/ |
| 22:15:12 | BlaXpirit | flaviu, that is actually worse |
| 22:15:21 | * | bcinman joined #nim |
| 22:15:28 | BlaXpirit | it is supposed to work for any type that defines isNil |
| 22:17:13 | BlaXpirit | so with nre you could define isNil for RegexMatch |
| 22:17:27 | flaviu | I see. Give me a few moments. |
| 22:18:35 | flaviu | https://gist.github.com/234c784502a81376dd37 not sure what's going on here. |
| 22:18:44 | BlaXpirit | actually... this isn't so well thought out |
| 22:19:05 | flaviu | BlaXpirit: It isn't, but my version will be. |
| 22:19:15 | flaviu | Araq is adding assignment operators. |
| 22:19:25 | def- | flaviu: i think they are there already |
| 22:19:31 | flaviu | So x: something_not_ref = nil will work fine. |
| 22:20:27 | BlaXpirit | does this mean we don't need nothing? |
| 22:20:33 | BlaXpirit | nothing/none |
| 22:20:49 | flaviu | BlaXpirit: ? |
| 22:21:02 | BlaXpirit | just use `nil` instead of `Nothing` |
| 22:22:20 | flaviu | That doesn't *seem* right. |
| 22:23:45 | * | jefus quit (Quit: WeeChat 0.4.2) |
| 22:23:52 | * | jefus joined #nim |
| 22:25:47 | * | bcinman quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 22:31:08 | * | jefus quit (Quit: WeeChat 0.4.2) |
| 22:31:16 | * | jefus joined #nim |
| 22:34:16 | * | HakanD___ quit (Quit: Be back later ...) |
| 22:36:26 | * | elbow_jason quit (Ping timeout: 272 seconds) |
| 22:39:53 | * | gsingh93 quit (Ping timeout: 256 seconds) |
| 22:40:00 | * | jefus quit (Quit: WeeChat 0.4.2) |
| 22:40:08 | * | jefus joined #nim |
| 22:46:18 | * | Matthias247 joined #nim |
| 22:50:26 | * | jefus quit (Quit: WeeChat 0.4.2) |
| 22:50:33 | * | jefus joined #nim |
| 22:55:01 | * | bcinman joined #nim |
| 22:55:04 | * | brson joined #nim |
| 22:57:52 | * | xandy left #nim ("bye") |
| 23:02:58 | * | heinrich5991 quit (Ping timeout: 256 seconds) |
| 23:06:51 | * | heinrich5991 joined #nim |
| 23:07:19 | * | irrequietus joined #nim |
| 23:18:43 | * | MagusOTB joined #nim |
| 23:23:15 | * | MagusOTB quit (Ping timeout: 244 seconds) |
| 23:25:18 | * | pregressive quit (Remote host closed the connection) |
| 23:25:39 | * | davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 23:29:21 | * | davidhq joined #nim |
| 23:35:24 | * | davidhq quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 23:38:51 | * | davidhq joined #nim |
| 23:39:37 | * | Varriount joined #nim |
| 23:46:21 | * | brson quit (Ping timeout: 250 seconds) |
| 23:48:24 | BlaXpirit | options.nim is not good if we renamed Option to Maybe |
| 23:48:26 | BlaXpirit | maybes? |
| 23:48:52 | BlaXpirit | optionals, because http://hackage.haskell.org/package/base-4.7.0.1/docs/Data-Maybe.html |
| 23:49:51 | * | bcinman quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 23:49:52 | * | Trustable quit (Remote host closed the connection) |
| 23:50:47 | * | bcinman joined #nim |
| 23:55:48 | renesac | SomeMaybe*[T] = NilMaybe[T] or Maybe[T] <-- I like those names better, not sure about "NilMaybe[T]" |
| 23:57:39 | renesac | and I'm also in the side of exceptions instead of checking every returned value |
