| 00:01:34 | Stefan_Salewski | Araq: I just remembered: One reason why Wirth replaces enums with plain integers was, that it was difficult to extend enums in Modula2. |
| 00:02:25 | dts|pokeball | Araq, did you come up with the result variable idea |
| 00:02:56 | Araq | well he could have looked at Ada and introduced "distinct int" then, but this is all wrong anyway |
| 00:03:06 | Araq | it's a feature that you cannot extend them |
| 00:03:22 | Stefan_Salewski | I have to admit that I do not know how we extend enums defined in one Nim module later in new user defined modules. Have to read the manual more carefully... |
| 00:03:34 | Araq | so you can easily ensure you have exhaustive case statements |
| 00:03:55 | Araq | exhaustiveness is paramount for correctness |
| 00:04:05 | Araq | and so Wirth should really know better |
| 00:04:34 | Araq | instead of hunting for the "extensible" cargo cult |
| 00:05:46 | flaviu | Araq: Not counting lisp, Nim is the most extensible language I've seen so far. |
| 00:06:41 | Araq | dts|pokeball: no I stole it from Delphi and Eiffel |
| 00:07:18 | flaviu | Practically all of Nim is based around UFCS |
| 00:09:38 | Araq | flaviu: there are different forms of "extensible" and I'm arguing from wirth's very own point of view here |
| 00:10:11 | Araq | he stresses correctness and type safety quite a bit in his books |
| 00:10:25 | Araq | and then throws away 'enum' |
| 00:18:49 | Stefan_Salewski | Sorry -- I still wonder why types and constants in Nim can refer only to the same block or stuff defined above. For wrappers that generates some reordering work. What is the great benefit? |
| 00:19:35 | flaviu | Stefan_Salewski: Compiler simplicity mostly. If macros get involved, it becomes very hard. |
| 00:20:00 | flaviu | But why do you need forward declaration for wrappers? Place all the types at the top, and all the procs at the bottom |
| 00:20:30 | Stefan_Salewski | OK, thanks for explanation. |
| 00:22:07 | Stefan_Salewski | No, I really like to keep the order as close to the header files as possible. Stuff that belongs together should be at the same location when possible. |
| 00:22:44 | Stefan_Salewski | And it is not very much work that reordering... |
| 00:22:53 | EXetoC | seems pointless |
| 00:23:38 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 00:24:26 | flaviu | Stefan_Salewski: Perhaps a pretty nim wrapper source file and an automatically generated version with the types at the front? |
| 00:25:01 | flaviu | Stefan_Salewski: But it doesn't matter too much, Nim's documentation generator places the types at the top anyway |
| 00:26:06 | Stefan_Salewski | No, it is not pointless. It helps to read wrapper modules -- that may be necessary to verify or learn... We have not detailed tutorials for all wrapped libs. |
| 00:35:46 | * | Stefan_Salewski quit () |
| 00:36:24 | * | Matthias247 quit (Quit: Matthias247) |
| 00:43:00 | Araq | dom96: do you know where the tests for the future module hide? |
| 00:43:34 | * | Trustable quit (Remote host closed the connection) |
| 00:44:32 | dom96 | Araq: in the future module? |
| 00:45:14 | Araq | not in my version of it |
| 00:45:30 | Araq | there are examples in the documentation, however |
| 00:47:32 | dom96 | then i can't remember, sorry |
| 00:48:09 | EXetoC | grep? :> |
| 00:48:45 | flaviu | ack! |
| 00:49:28 | flaviu | http://beyondgrep.com/ |
| 00:50:37 | EXetoC | I have a good shell so I haven't bothered still |
| 00:51:58 | Araq | nice but I prefer nimgrep |
| 00:52:14 | flaviu | EXetoC: As do I, but I'm reminded of that ascii cat each time I use ack :P |
| 00:53:21 | Araq | "The --pager, --regex and --output options are powerful tools for users to manage the output of ack, but with carefully crafted parameters, they can be used to execute arbitrary code." |
| 00:54:05 | EXetoC | flaviu: of what? |
| 00:54:22 | flaviu | EXetoC: http://beyondgrep.com/ |
| 00:54:30 | flaviu | the cat on that page |
| 00:55:05 | EXetoC | good point |
| 00:55:36 | flaviu | Araq: `.ackrc` is a useful concept, but malicious actors take all the fun out of everything :( |
| 00:56:53 | Araq | flaviu: all I see is the same old design mistakes leading to security issues, repeated forever |
| 00:59:38 | Araq | text based formats are simply a bad idea and quoting and escaping doesn't work. length prefixed stuff might work much better but then it's a "binary" format |
| 01:00:34 | flaviu | Araq: This isn't an accidental problem. Arbitrary code execution was a *feature*, the full consequences just weren't considered at the time. |
| 01:01:51 | Araq | no, it's because Perl allows arbitrary code in regexes |
| 01:02:12 | Araq | and the regexes in the config file are not shielded (escaped) against that |
| 01:02:23 | Araq | well that's how I understand it |
| 01:02:28 | Araq | maybe I'm wrong |
| 01:02:59 | EXetoC | :o |
| 01:03:04 | flaviu | `--pager foo` would execute `foo` with ack's output in `foo`'s stdin |
| 01:04:28 | flaviu | "disallowing the --pager, --regex or --output options in a per-project .ackrc file" |
| 01:04:28 | flaviu | If `--regex` had led to ACE through bugs, they would have fixed the bugs rather than just disabling the thing. |
| 01:05:19 | * | milosn quit (Ping timeout: 252 seconds) |
| 01:18:46 | * | mko quit (Quit: Bye.) |
| 01:30:03 | Araq | hrm, did anybody ever use the fact that leading \ do not affect operator precedence? |
| 01:30:21 | Araq | cause I'm removing that feature |
| 01:41:13 | fowl | why would it |
| 01:41:31 | fowl | you mean \+ vs -+ |
| 01:42:07 | Araq | I mean 3 \+ 4 \* 8 is parsed as 3 + 4 * 8 |
| 01:42:25 | Araq | but 3/+ 4 /* 8 is not |
| 01:43:46 | EXetoC | o rly |
| 01:44:17 | Araq | I added that to the spec to support TR macro meta operators |
| 01:44:37 | Araq | but even these don't use this feature |
| 01:44:49 | Araq | turned out to be unnecessary |
| 01:46:04 | Araq | if fowl didn't use the feature, it really is safe to remove it from the language :-) |
| 01:46:14 | Araq | fowl: did you use it? |
| 01:46:17 | fowl | no |
| 01:46:23 | fowl | i dont use TR macros |
| 01:46:41 | Araq | the feature has nothing to do with TR macros |
| 01:47:16 | Araq | but ok, good |
| 02:02:04 | * | AMorpork is now known as AFKMorpork |
| 02:13:48 | * | darkf joined #nimrod |
| 02:18:05 | * | AFKMorpork is now known as AMorpork |
| 02:20:46 | * | flaviu quit (Read error: Connection reset by peer) |
| 02:21:59 | * | flaviu joined #nimrod |
| 02:43:24 | flaviu | my macro works as long as the invocation is in the same file, but it fails if it's not. |
| 02:45:16 | flaviu | I think it's trying to look up the symbols, I'm not sure what's going on. |
| 02:49:30 | * | flaviu quit (Read error: Connection reset by peer) |
| 02:49:52 | * | milosn joined #nimrod |
| 02:50:49 | * | flaviu joined #nimrod |
| 03:03:34 | * | brson quit (Ping timeout: 244 seconds) |
| 03:15:38 | * | saml_ joined #nimrod |
| 03:15:57 | * | BitPuffin quit (Quit: See you on the dark side of the moon!) |
| 03:20:06 | * | saml_ quit (Ping timeout: 244 seconds) |
| 03:33:26 | * | saml_ joined #nimrod |
| 03:56:22 | * | EXetoC quit (Quit: WeeChat 1.0.1) |
| 04:01:29 | * | q66 quit (Quit: Leaving) |
| 04:20:36 | * | flaviu quit (Ping timeout: 250 seconds) |
| 04:23:02 | * | willwillson quit (Ping timeout: 265 seconds) |
| 04:56:34 | * | perturbation quit (Quit: Leaving) |
| 05:21:01 | * | vbtt joined #nimrod |
| 05:21:25 | vbtt | hello |
| 05:25:46 | * | vbtt quit (Client Quit) |
| 05:27:06 | * | darkf_ joined #nimrod |
| 05:27:51 | * | vbtt joined #nimrod |
| 05:29:48 | * | darkf quit (Ping timeout: 258 seconds) |
| 05:39:33 | * | vbtt quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 05:48:56 | * | darkf_ is now known as darkf |
| 05:57:11 | * | darkf_ joined #nimrod |
| 06:00:05 | * | darkf quit (Ping timeout: 272 seconds) |
| 06:12:47 | * | darkf joined #nimrod |
| 06:14:29 | * | saml_ quit (Ping timeout: 250 seconds) |
| 06:14:39 | * | darkf_ quit (Ping timeout: 258 seconds) |
| 06:15:13 | * | darkf_ joined #nimrod |
| 06:17:43 | * | darkf quit (Ping timeout: 258 seconds) |
| 06:21:40 | * | hguux_ quit (Ping timeout: 244 seconds) |
| 06:22:26 | * | hguux_ joined #nimrod |
| 06:22:51 | Varriount | Meep |
| 06:24:09 | Varriount | Araq: Unfortunately, I won't be able to help over the weekend... I have 2 exams to study for, and a final project to complete. |
| 06:25:25 | * | brson joined #nimrod |
| 06:25:50 | * | darkf_ is now known as darkf |
| 06:28:15 | Varriount | Also, for all you linux-lovers who disparage windows over it's performance: You wouldn't *believe* how much is done for the sake of compatibility. |
| 06:48:42 | * | darkf_ joined #nimrod |
| 06:50:41 | * | darkf quit (Ping timeout: 258 seconds) |
| 06:51:16 | * | darkf joined #nimrod |
| 06:53:45 | * | darkf_ quit (Ping timeout: 258 seconds) |
| 07:08:38 | * | flaviu joined #nimrod |
| 07:22:07 | * | bjz_ quit (Ping timeout: 244 seconds) |
| 07:24:40 | * | bjz joined #nimrod |
| 07:30:27 | * | darkf_ joined #nimrod |
| 07:32:51 | * | darkf quit (Ping timeout: 258 seconds) |
| 07:35:55 | * | brson quit (Quit: leaving) |
| 07:43:58 | * | vbtt joined #nimrod |
| 07:57:24 | * | vbtt quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 07:57:37 | * | darkf joined #nimrod |
| 07:59:41 | * | darkf_ quit (Ping timeout: 258 seconds) |
| 08:06:22 | * | darkf_ joined #nimrod |
| 08:07:52 | * | milosn quit (Remote host closed the connection) |
| 08:08:53 | * | darkf quit (Ping timeout: 258 seconds) |
| 08:21:29 | * | gour joined #nimrod |
| 08:29:21 | * | BlaXpirit joined #nimrod |
| 08:33:02 | * | milosn joined #nimrod |
| 08:53:36 | * | bjz quit (Read error: Connection reset by peer) |
| 08:53:41 | * | bjz_ joined #nimrod |
| 09:30:16 | * | vendethiel joined #nimrod |
| 09:46:20 | * | BlaXpirit quit (Read error: Connection reset by peer) |
| 09:46:39 | * | gour quit (Quit: Konversation terminated!) |
| 09:47:15 | * | BlaXpirit joined #nimrod |
| 09:48:50 | * | gour joined #nimrod |
| 10:17:09 | * | Matthias247 joined #nimrod |
| 10:35:09 | * | darkf_ is now known as darkf |
| 10:37:37 | * | vendethiel quit (Ping timeout: 265 seconds) |
| 11:07:29 | * | yglukhov joined #nimrod |
| 11:18:42 | * | gokr_ joined #nimrod |
| 11:20:17 | * | gokr quit (Ping timeout: 240 seconds) |
| 11:26:49 | * | BitPuffin joined #nimrod |
| 11:28:19 | * | yglukhov quit (Ping timeout: 246 seconds) |
| 11:42:07 | * | gour quit (Quit: Konversation terminated!) |
| 11:43:21 | * | bjz_ quit (Ping timeout: 265 seconds) |
| 11:45:00 | * | gour joined #nimrod |
| 11:45:26 | * | Trustable joined #nimrod |
| 11:45:52 | * | gour quit (Client Quit) |
| 11:49:18 | * | gour joined #nimrod |
| 11:51:09 | * | bjz joined #nimrod |
| 11:54:31 | * | yglukhov joined #nimrod |
| 12:02:45 | * | gour quit (Quit: Konversation terminated!) |
| 12:06:26 | * | yglukhov quit (Quit: Be back later ...) |
| 12:06:36 | * | Trustable quit (Remote host closed the connection) |
| 12:08:17 | * | Trustable joined #nimrod |
| 12:11:45 | NimBot | Araq/Nimrod devel cd0f172 juxiliary [+1 ±1 -0]: Fixing extraneous semicolon in jsgen output... 6 more lines |
| 12:11:45 | NimBot | Araq/Nimrod devel 5ee7458 Andreas Rumpf [+1 ±1 -0]: Merge pull request #1709 from juxiliary/devel... 2 more lines |
| 12:14:21 | Araq | flaviu: that's why you should use bindSym |
| 12:15:38 | * | gour joined #nimrod |
| 12:19:12 | * | gokr_ quit (Ping timeout: 258 seconds) |
| 12:30:34 | * | q66 joined #nimrod |
| 12:38:26 | * | gokr_ joined #nimrod |
| 12:41:28 | * | yglukhov joined #nimrod |
| 13:00:44 | * | EXetoC joined #nimrod |
| 13:08:44 | flaviu | It's hard for me to use bindSym because I'm generating text and having it parsed |
| 13:13:38 | Araq | I see |
| 13:13:50 | Araq | we can make bindSym more lazy I think |
| 13:15:27 | Araq | gokr_: it was the t5000 test that sometimes deadlocks, right? |
| 13:16:27 | * | johnsoft quit (Ping timeout: 264 seconds) |
| 13:17:06 | * | johnsoft joined #nimrod |
| 13:21:33 | Araq | unfortunately I can't reproduce this on my 64bit linux |
| 13:21:38 | Araq | it never deadlocks |
| 13:21:47 | Araq | always produces the correct result |
| 13:24:44 | flaviu | I don't see any deadlocks in the waterfall: http://178.62.143.63:8010/waterfall |
| 13:33:38 | gokr_ | yrah t5000 |
| 13:34:04 | * | willwillson joined #nimrod |
| 13:36:39 | Araq | well there is still an enhancement from Jehan we can try |
| 13:36:45 | Araq | but see you later |
| 13:50:44 | * | gokr joined #nimrod |
| 13:52:44 | * | gokr_ quit (Ping timeout: 258 seconds) |
| 13:53:30 | * | gokr_ joined #nimrod |
| 13:55:02 | * | gokr quit (Ping timeout: 258 seconds) |
| 13:58:09 | * | willwillson quit (Ping timeout: 245 seconds) |
| 13:58:36 | * | vendethiel joined #nimrod |
| 14:05:00 | * | gokr_ quit (Ping timeout: 258 seconds) |
| 14:25:09 | * | allany joined #nimrod |
| 14:35:14 | * | BlaXpirit quit (Ping timeout: 245 seconds) |
| 14:36:48 | * | allany quit (Quit: WeeChat 1.0.1) |
| 14:38:53 | * | gokr_ joined #nimrod |
| 14:41:36 | * | zio_tom78 joined #nimrod |
| 14:41:40 | zio_tom78 | Hi to everybody |
| 14:42:04 | * | milosn quit (Remote host closed the connection) |
| 14:53:47 | * | yglukhov quit (Quit: Be back later ...) |
| 15:10:26 | * | zio_tom78 quit (Quit: Cheers to everybody connected!) |
| 15:17:35 | * | j3rky joined #nimrod |
| 15:17:40 | flaviu | Has anyone tried using the VM for runtime code execution? |
| 15:29:01 | EXetoC | I couldn't figure out how |
| 15:29:47 | flaviu | I guess with all the problems with CASS, using it as a library won't be much easier. |
| 15:34:15 | dom96 | Does this build bot even work? |
| 15:34:24 | dom96 | It seems to time out testament most of the time |
| 15:34:52 | flaviu | dom96: Huh? I don't see any timeout issues. |
| 15:36:12 | dom96 | http://178.62.143.63:8010/builders/windows-x32-builder/builds/15/steps/Run%20Testament/logs/stdio |
| 15:36:34 | dom96 | also where can you check the test results? |
| 15:37:29 | flaviu | dom96: I don't think it uploads the database atm |
| 15:50:15 | * | q66[lap] quit (Quit: Textual IRC Client: www.textualapp.com) |
| 15:50:52 | * | q66[lap] joined #nimrod |
| 15:53:20 | gokr1 | flaviu: The timeout on t5000 happened a while back, I had to kill it then. |
| 15:53:39 | gokr1 | It only seems to happen occasionaly. |
| 16:03:37 | dom96 | Interesting: http://plan9.bell-labs.com/wiki/plan9/Mouse_vs._Keyboard/index.html |
| 16:06:42 | * | darkf quit (Quit: Leaving) |
| 16:18:42 | * | BlaXpirit joined #nimrod |
| 16:20:33 | EXetoC | a relevant vim plugin comes to mind |
| 16:31:49 | EXetoC | for one of the supposed issues related to keyboard editing |
| 16:42:24 | * | yglukhov joined #nimrod |
| 16:46:11 | EXetoC | and vi does some things worse than vim obviously |
| 16:47:12 | * | yglukhov quit (Ping timeout: 256 seconds) |
| 17:07:14 | * | milosn joined #nimrod |
| 17:19:26 | * | willwillson joined #nimrod |
| 17:23:42 | flaviu | I need to close a steam, but osproc says not to do so. |
| 17:23:50 | NimBot | nim-lang/nimble master 8da2fe7 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Fixes crash when running `nimble path something`. |
| 17:23:50 | NimBot | nim-lang/nimble master 8753fa2 Dominik Picheta [+0 ±1 -0]: Merge pull request #71 from gradha/pr_fixes_path_crash... 2 more lines |
| 17:25:19 | NimBot | nim-lang/nimble master 7384083 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds babel spec support for path action. |
| 17:25:19 | NimBot | nim-lang/nimble master 28f4c9d Dominik Picheta [+0 ±1 -0]: Merge pull request #72 from gradha/pr_supports_babel_spec_for_path_action... 2 more lines |
| 17:40:26 | * | j3rky quit (Ping timeout: 258 seconds) |
| 17:47:11 | dom96 | Varriount: I'm going to take the server down to create a snapshot. |
| 17:49:58 | * | AMorpork is now known as AFKMorpork |
| 18:06:45 | * | yglukhov joined #nimrod |
| 18:10:50 | * | yglukhov quit (Ping timeout: 244 seconds) |
| 18:24:13 | * | j3rky joined #nimrod |
| 18:28:13 | * | j3rky quit (Client Quit) |
| 18:29:41 | flaviu | Isn't a `var T` essentially `T*`? |
| 18:30:03 | flaviu | I can't seem to be able to convert `var T` to `ptr T` |
| 18:33:32 | willwillson | don't you just use addr? |
| 18:33:45 | dom96 | Using 'addr' should work. |
| 18:34:52 | flaviu | It might, let me check |
| 18:56:59 | * | AFKMorpork is now known as AMorpork |
| 18:59:18 | flaviu | It does seem to work |
| 19:00:02 | flaviu | Should destructors really require that their parameter be a var? |
| 19:00:37 | flaviu | ie, `let foo = initMyType()` will fail since foo is by a let |
| 19:01:09 | flaviu | but let's contract can be broken since nothing will be around to observe it broken |
| 19:07:44 | fowl | yeah thats why let x = inittable... doesnt work right |
| 19:11:54 | dom96 | Destructors are still buggy. |
| 19:16:14 | dom96 | Araq: ping me when you're here |
| 19:37:42 | * | BitPuffin quit (Ping timeout: 264 seconds) |
| 19:38:36 | * | BitPuffin joined #nimrod |
| 19:46:21 | * | gour quit (Quit: Konversation terminated!) |
| 19:57:12 | * | yglukhov joined #nimrod |
| 20:11:07 | * | AraqinTrouble joined #nimrod |
| 20:11:21 | AraqinTrouble | dom96_: ping |
| 20:13:40 | dom96 | lol |
| 20:14:23 | dom96 | AraqinTrouble: oh yeah, forgot you connect to the BNC via picheta.me |
| 20:16:25 | AraqinTrouble | no worries |
| 20:22:03 | dom96 | AraqinTrouble: I copied the nim site to the new VPS |
| 20:24:47 | AraqinTrouble | yay |
| 20:24:59 | AraqinTrouble | change the logo please |
| 20:31:56 | * | tinAndi joined #nimrod |
| 20:41:01 | * | dom96- joined #nimrod |
| 20:41:31 | * | Araq_ joined #nimrod |
| 20:43:52 | * | dom96- quit (Changing host) |
| 20:43:52 | * | dom96- joined #nimrod |
| 20:44:20 | dom96- | ffs chanserv |
| 20:44:42 | dom96 | AraqinTrouble: You should be able to connect to the new bnc now. |
| 20:46:00 | * | Araq quit (Quit: Bye!) |
| 20:46:01 | * | dom96 quit (Quit: Bye.) |
| 20:46:01 | * | Amrykid quit (Quit: Goodbye!) |
| 20:46:01 | * | dom96- is now known as dom96 |
| 20:50:02 | dom96 | AraqinTrouble: do you have some time now? |
| 20:53:54 | * | dom96 is going to watch TMNT |
| 21:09:34 | * | milosn quit (Ping timeout: 255 seconds) |
| 21:14:19 | * | AraqinTrouble quit (Quit: Page closed) |
| 21:23:18 | * | ARCADIVS joined #nimrod |
| 21:28:20 | * | milosn joined #nimrod |
| 21:39:09 | * | starless joined #nimrod |
| 21:39:25 | starless | hey, does Nimrod still have default return values? |
| 21:39:42 | starless | I'd check but it's not installed on this machine |
| 21:40:04 | Araq_ | install it |
| 21:40:17 | Araq_ | it doesn't require root access to install it |
| 21:40:36 | Araq_ | but to answer your question: yes. |
| 21:40:44 | starless | Araq_: But if it has default return values I'm just going to uninstall it again :P |
| 21:40:57 | starless | thanks |
| 21:40:59 | Araq_ | why? |
| 21:41:01 | Araq_ | no wait |
| 21:41:13 | starless | waiting. |
| 21:41:23 | Araq_ | you can use warning[Uninit]:on and then the compiler complains |
| 21:41:38 | starless | aha! is that new? |
| 21:41:46 | Araq_ | not really |
| 21:41:54 | Araq_ | but people don't know about it |
| 21:42:06 | starless | more people should! |
| 21:42:27 | Araq_ | why? it's a non issue for anybody who writes more than 10 lines of Nim code ... |
| 21:43:17 | starless | really? I feel like I could see where control flow reached the end of a function that just decided to return 0 in 10 lines of code |
| 21:43:34 | starless | problems are more likely to arise in 10000 lines of code |
| 21:44:19 | Araq_ | problems are everywhere when you speculate over everything |
| 21:44:50 | starless | but I guess sacrifices have to be made when there's so many advantages that can be gained |
| 21:45:06 | starless | like...not having to write "return 0" |
| 21:46:45 | EXetoC | that's the reason for not using the language? ok |
| 21:48:18 | starless | EXetoC: the possibility of a silently passing mistake in every procedure I write? I guess that's not much to consider |
| 21:49:18 | starless | Look, I'm not trying to be a dick. I just had extremely high hopes for Nimrod. I don't want to see a lot of hard work go to waste. Tell me why default return values are useful. |
| 21:49:54 | starless | I can't be convinced they're not a problem. That may be stubborness on my part. |
| 21:50:07 | starless | stubbornness* |
| 21:50:25 | Araq_ | well you know |
| 21:50:30 | EXetoC | all I can say is that most people don't seem to have a problem with it |
| 21:50:35 | Araq_ | whenever c# tells me to initialize something |
| 21:50:44 | Araq_ | I use ' = 0' |
| 21:50:48 | Araq_ | or = false etc. |
| 21:51:09 | Araq_ | it's the obvious fix for 99.9% of the cases |
| 21:51:16 | Araq_ | so Nim shuts up and does the right thing |
| 21:51:51 | Araq_ | that also has the advantage that the language defintion doesn't depend on a control flow analysis |
| 21:52:07 | Araq_ | and apart from you nobody ever complained |
| 21:52:36 | EXetoC | I recall one other guy complaining about it |
| 21:52:49 | Araq_ | filwit? |
| 21:52:55 | Araq_ | well yes |
| 21:53:03 | Araq_ | he complained and then used it |
| 21:53:07 | Araq_ | and was happy |
| 21:53:15 | EXetoC | I don't know |
| 21:54:49 | starless | 1) The default initialization of variables is not necessarily tied to a default return value. You guys happen to have return values represented as a variable, which then ties it to local variable initialization. You can't tote the advantages of not having to initialize local variables because you could so easily just require a return statement instead of having a return parameter |
| 21:55:34 | Araq_ | but not requiring a dummy 'return 0' statement is indeed an advantage |
| 21:55:43 | starless | 2) The lack of need for control flow analysis in the compiler is not an advantage to anyone but the compiler implementers. They matter, but not nearly as much as the users. |
| 21:55:44 | Araq_ | in my experience |
| 21:56:21 | starless | 3) I may be the only one complaining about it, but you seem to be trying to convince me. So here I am. |
| 21:56:59 | starless | and in regards to point (2), isn't that kind of what dropping mustache braces and semicolons was all about? forgetting about easier parsing in favor of the user? |
| 21:57:21 | starless | and point (1); why discard single expressions? is explicit not better than implicit? |
| 21:57:47 | Araq_ | no, that's just a lame slogan with no meaning |
| 21:58:05 | Araq_ | sometimes explicit is better, sometimes it's not. |
| 21:58:18 | Araq_ | otherwise I would program in assembler. |
| 21:58:38 | EXetoC | I think it matters less in cases like this, because once you learn about it, you'll be able to infer what's going to happen |
| 21:58:39 | starless | I'll give you that, but why do you discard expressions? |
| 21:58:40 | Araq_ | in asm everything is explicit. |
| 21:58:59 | Araq_ | because it turned out to find real bugs |
| 21:59:01 | Araq_ | again |
| 21:59:05 | Araq_ | I have c# for years |
| 21:59:16 | Araq_ | and that feature of c# never found a single bug |
| 21:59:31 | Araq_ | and now that we have 'not nil' in the language we have to do that control flow analysis and warning[Uninit] was a side-effect of this |
| 21:59:44 | Araq_ | but the language didn't start with that |
| 22:00:13 | Araq_ | and I don't see the point of making people updating hundreds of thousands of lines of code when I can see no benefit |
| 22:00:49 | starless | Araq_: people have used hundreds of thousands of default return values? |
| 22:01:00 | starless | Araq_: I'd shut up if you showed me 20 |
| 22:01:19 | Araq_ | the compiler itself uses that feature everywhere |
| 22:01:25 | Araq_ | try it |
| 22:01:27 | Araq_ | enable it |
| 22:01:30 | Araq_ | and patch the compiler |
| 22:01:54 | Araq_ | maybe I'm wrong and then I'll re-consider my position |
| 22:02:26 | starless | and what do I get in return for patching the compiler? :) |
| 22:03:22 | Araq_ | you will not be regarded as a troll anymore then |
| 22:03:39 | starless | it's unfortunate that you think I'm trolling! |
| 22:04:14 | starless | I think Nimrod is a beautiful language. I was bothered so much by the default return values that I thought about it for months! |
| 22:04:25 | starless | I came back just to ask because I was in such disbelief. |
| 22:05:17 | starless | Anyways, thanks for your time. |
| 22:05:44 | Araq_ | you're still welcome |
| 22:06:42 | Araq_ | starless: btw that feature has been copied from Eiffel |
| 22:06:48 | EXetoC | other than the satisfaction of having the language behave the way you want it to? a dollar in addition perhaps? :p |
| 22:06:52 | Araq_ | it's not even my invention |
| 22:07:00 | EXetoC | just for additional motivation |
| 22:07:23 | starless | Araq_: I know; you told me last time |
| 22:07:42 | Araq_ | and Eiffel did it for exactly the same reasons |
| 22:08:06 | Araq_ | and btw C# does the checking slightly differently than its spec suggests, but maybe they fixed that by now. |
| 22:08:37 | Araq_ | these things are not trivial and yet you suggest that I'm a lazy fool :P |
| 22:08:47 | starless | Araq_: I would never |
| 22:09:00 | starless | and hold on. there's something more important to discuss here |
| 22:09:07 | starless | I don't consider your decision uninformed |
| 22:09:10 | starless | I don't understand it |
| 22:09:26 | starless | I, in no way, intended to insult anyone |
| 22:09:28 | starless | designers or users |
| 22:11:24 | starless | We'll have to disagree for now. |
| 22:11:30 | starless | I'll be looking at the compiler code. |
| 22:14:34 | Araq_ | starless: if you are obviously right and I'm obviously wrong can we perhaps still agree that it is a minor issue and that maybe you can like the rest of language enough to use it? |
| 22:19:36 | flaviu | starless: I'm not part of the project, but I'm sorry about the less than warm welcome. |
| 22:19:36 | flaviu | `result` is frequently used equivalently to a functional fold. Having to explicitly write `return result` isn't too bad, but I assume Araq wanted to encourage usage of this sort of pattern, and reducing typing is one of the few ways a language writer has of doing so. |
| 22:19:54 | * | untitaker quit (Ping timeout: 265 seconds) |
| 22:21:03 | starless | Araq_: You keep applying very coarse description to this discussion. I'm not obviously right. You're not obviously wrong. There's some misunderstanding and some difference in opinion. |
| 22:21:38 | Araq_ | no, I said 'if', maybe I should have said 'EVEN IF' |
| 22:22:06 | Araq_ | and it's not about the difference in opinion |
| 22:22:11 | starless | However, I would not consider it a minor issue. flaviu, it's alright about the discourse; it's actually quite mild compared to most of freenode :p |
| 22:22:29 | Araq_ | it's that you dismiss the complete language because of this! |
| 22:23:11 | starless | flaviu: could you explain "reducing typing"? |
| 22:23:42 | starless | Araq_: I may use the language yet. |
| 22:24:14 | starless | flaviu: oh. keystrokes? |
| 22:24:27 | flaviu | starless: `return result` -> ``, `var result: ReturnType = initBlah`, `result = initBlah` |
| 22:24:27 | flaviu | although the second example could use type inference |
| 22:24:29 | starless | I read that as typing like type systems |
| 22:24:29 | flaviu | starless: Yes |
| 22:24:49 | flaviu | Ah, I see. |
| 22:26:26 | starless | flaviu: and when you say "to a functional fold", do you mean as the base value in a fold? as in list comprehensions? |
| 22:26:41 | * | untitaker joined #nimrod |
| 22:28:24 | * | shevy joined #nimrod |
| 22:29:09 | flaviu | As in `result = 0; for i in 0..20: result += i` = `foldl (\prev curr -> prev + curr) 0 [0..20]` |
| 22:29:29 | flaviu | excuse syntax errors in my haskell, I don't actually know the language. |
| 22:30:48 | starless | I don't either...but I can see how it can be used as a base value for computation |
| 22:37:08 | dom96 | starless: As someone who has been writing Nim code for the past ~4 years. Believe me that default return values cause no issues whatsoever. |
| 22:40:45 | * | Demos quit (Read error: Connection reset by peer) |
| 22:41:01 | starless | hm. and this has been your experience as well, flaviu, Araq_, EXetoC, others? |
| 22:43:09 | flaviu | I haven't had troubles with accidentally not returning anything so far. I haven't had any really big projects yet though. |
| 22:46:59 | Araq_ | starless: as I said, not a single bug. however |
| 22:47:18 | Araq_ | that 'nil' is the default for strings/seqs surely lead to bugs |
| 22:48:14 | Araq_ | especially for newcomers |
| 22:48:49 | Araq_ | but that's not your what you were talking about |
| 22:50:45 | * | tr|nn| joined #nimrod |
| 23:07:53 | * | ekarlso- quit (Ping timeout: 240 seconds) |
| 23:11:04 | * | yglukhov quit (Quit: Be back later ...) |
| 23:19:05 | * | tr|nn| quit (Quit: Verlassend) |
| 23:19:21 | * | shodan45 joined #nimrod |
| 23:43:27 | * | quasinoxen quit (Ping timeout: 258 seconds) |
| 23:44:48 | * | quasinoxen joined #nimrod |
| 23:50:16 | flaviu | There's deepCopy, is there deepFree? |
| 23:53:49 | * | gokr_ quit (Quit: IRC for Sailfish 0.8) |
| 23:54:07 | Araq_ | flaviu: what's a deepFree? |
| 23:54:37 | Araq_ | for x in fields(y): if type(x) is ptr: free(x) ? |
| 23:54:38 | flaviu | If deepcopy follows all pointers and copies them to a new place in memory, deep free would release the allocation |
| 23:54:50 | flaviu | Yes, except more recursive. |
| 23:55:10 | flaviu | Anyway, I've found a workaround. |
| 23:55:34 | Araq_ | the problem is that 'ptr' doesn't say it has been allocated with system.alloc |
| 23:55:46 | Araq_ | so this cannot be done reliably |
| 23:56:07 | Araq_ | deepcopy only copies 'ref' because for these the underlying allocator is known |
| 23:56:24 | flaviu | Oh, I didn't realize that. |
| 23:56:37 | Araq_ | also that 'ptr' is not deeply copied is a feature for inter thread communication |
| 23:56:52 | flaviu | Right, you can avoid copying giant shared buffers and such. |