| 00:07:32 | renesac | I edited a few dozen lines of the tut1.txt, but git is considering the whole file changed |
| 00:07:36 | renesac | :/ |
| 00:08:01 | renesac | I will commit anyway, and hope that github diff is smarter... |
| 00:12:34 | dom96 | renesac: you sure your editor didn't change the line endings? |
| 00:12:46 | renesac | oh, I can check |
| 00:13:29 | dom96 | git's handling of line endings is really quite annoying |
| 00:15:58 | dom96 | good night |
| 00:17:21 | BitPuffin | dom96: well an editor should know better |
| 00:18:00 | renesac | yeah... somewow kate was configured for windows line ends |
| 00:23:25 | EXetoC | why two bytes to indicate newlines? |
| 00:23:34 | renesac | ok, fixed |
| 00:24:12 | renesac | EXetoC, because when using typewriters you needed to do 'carriage return' to start the next line right |
| 00:24:13 | EXetoC | renesac: you could also try "git config --global core.autocrlf input" |
| 00:24:30 | EXetoC | maybe in the 19th century :> |
| 00:24:39 | renesac | nah, I used one of those |
| 00:25:02 | renesac | in the 19th century there were no computers |
| 00:25:04 | * | ehaliewicz quit (Remote host closed the connection) |
| 00:25:21 | renesac | well, notepad++ to the rescue |
| 00:25:41 | renesac | I think I fixed most of the breakage, the diff is now reasonable |
| 00:26:22 | renesac | kate couldn't even highlight the line-ends... (I didn't found the option) |
| 00:27:36 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:32:42 | EXetoC | banned. got WH apparently |
| 00:37:47 | * | BitPuffin mumbles about how we should all use hg instead |
| 00:38:04 | renesac | hg highlights the line ends? |
| 00:43:07 | * | DAddYE quit (Remote host closed the connection) |
| 00:44:20 | Skrylar | it greatly irritates me when you try to express to someone that you don't like a concept, and they turn around and commit personal attacks in response |
| 00:48:29 | BitPuffin | renesac: I dunno haha |
| 00:51:10 | renesac | https://github.com/Araq/Nimrod/pull/1107 <-- ok, new pull request |
| 00:53:43 | reactormonk | do we have a csv writer with escapes etc.? |
| 00:54:06 | * | Demos joined #nimrod |
| 00:59:06 | * | Demos quit (Ping timeout: 240 seconds) |
| 01:04:26 | BitPuffin | what was that tiny computer thing that someone linked the other day |
| 01:04:32 | BitPuffin | think it maybe was fowl |
| 01:05:25 | BitPuffin | cubox |
| 01:11:25 | fowl | OrionPK, 's cubox |
| 01:11:49 | fowl | BitPuffin, did u get it working or what |
| 01:12:14 | BitPuffin | fowl: no |
| 01:12:19 | fowl | whats the issue |
| 01:14:46 | BitPuffin | I don't wanna rebuild allegro? o.O |
| 01:25:17 | * | nande joined #nimrod |
| 01:31:22 | fowl | BitPuffin, the function was removed, you have to change it to a template |
| 01:32:13 | fowl | BitPuffin, do it inside when SUB_VERSION > 0: |
| 01:41:06 | * | nande quit (Ping timeout: 240 seconds) |
| 01:42:20 | BitPuffin | subversion is a crappy vcs |
| 01:42:54 | EXetoC | :EEEEEE |
| 01:42:59 | fowl | svn is king |
| 01:50:11 | EXetoC | fowl: how about that game and stuff |
| 01:55:39 | fowl | EXetoC, i've got no ideas :x |
| 01:56:28 | BitPuffin | fowl: well what do you want me to do |
| 01:56:54 | BitPuffin | template al_toggle_display(params): expr = al_set_display_flags(params) ? |
| 02:01:03 | fowl | BitPuffin, except for the al_ prefix |
| 02:01:11 | BitPuffin | yeah |
| 02:06:47 | EXetoC | fowl: so you want me to take care of that part? |
| 02:07:25 | EXetoC | well I have some ideas but no skills, so that balances it out |
| 02:08:36 | * | Skrylar git rebases fowl |
| 02:08:58 | fowl | BitPuffin, heres the changelog http://alleg.sourceforge.net/changes-unstable.html |
| 02:10:45 | Skrylar | y'know what would be cool |
| 02:10:51 | Skrylar | the pandoc equivalent of data markup |
| 02:14:25 | Skrylar | its pretty common to want to store data files for games in XML because its a more durable format for catching errors, but want the stat sheets to be fed in via CSVs and hand-written blocks being yaml/json |
| 02:16:10 | BitPuffin | fowl: I'll take a look later |
| 02:16:18 | BitPuffin | gonna eat some sandwitches and hack some linagl |
| 02:16:55 | BitPuffin | or |
| 02:17:05 | BitPuffin | maybe sleep, but I feel I haven't gotten much work done today |
| 02:24:16 | * | Demos joined #nimrod |
| 02:37:53 | * | Demos quit (Ping timeout: 258 seconds) |
| 02:39:23 | * | brson quit (Quit: leaving) |
| 02:51:53 | * | q66 quit (Quit: Leaving) |
| 03:13:14 | * | Trixar_za quit (Remote host closed the connection) |
| 03:14:00 | * | Trixar_za joined #nimrod |
| 03:25:29 | * | bjz quit (Ping timeout: 250 seconds) |
| 03:31:06 | fowl | BitPuffin, u wanted allegro bindings, i expect a AAA game by friday |
| 03:31:41 | * | bjz joined #nimrod |
| 03:35:20 | * | Jesin quit (Quit: Leaving) |
| 03:42:23 | * | cark quit (Ping timeout: 246 seconds) |
| 03:51:21 | * | xenagi quit (Quit: Leaving) |
| 03:56:11 | * | superfunc_ joined #nimrod |
| 04:01:53 | * | Cycling joined #nimrod |
| 04:02:58 | Cycling | hi... can paths of modules be declared inside a file? |
| 04:03:28 | Varriount | Erm, what do you mean? |
| 04:03:40 | Varriount | Like, with the import statement? |
| 04:04:59 | Cycling | like if modules are kept in a directory other than the current one |
| 04:05:33 | Cycling | path of modules |
| 04:05:34 | Varriount | Cycling: Modules can be imported by relative or absolute path eg 'import "path/to/module'" |
| 04:06:03 | Cycling | nice. |
| 04:07:11 | Varriount | Cycling: I can't remember what relative paths are supposed to be relative to. I *think* it's to the first module that is imported, but it might either be more complicated, or use a different method. |
| 04:07:40 | Varriount | Nimrod might look in multiple place for relative paths. |
| 04:08:00 | Varriount | Or it might use the path the nimrod compiler was invoked in. |
| 04:09:36 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 04:19:55 | Skrylar | i think i'm going to port over some fuzzy string matching routines |
| 04:20:32 | fowl | Skrylar, add it to the compiler please |
| 04:21:58 | Varriount | Skrylar: diffmatchpatch port? |
| 04:22:16 | Skrylar | Varriount: no, fuzzy strings |
| 04:22:22 | Varriount | Skrylar: https://code.google.com/p/google-diff-match-patch/ |
| 04:22:29 | Skrylar | right now i read over hamming and lischetin differences |
| 04:22:33 | Varriount | "Given a search string, find its best fuzzy match in a block of plain text. Weighted for both accuracy and location." |
| 04:22:34 | Skrylar | so you can ask "how similar is dog and fog" |
| 04:23:37 | Skrylar | sublimetext has this awesome thing where it tokenizes the source file and offers fuzzy autocompletion |
| 04:23:49 | Skrylar | so if you have a symbol DoThingsSlowly you can type in "dts" and it suggests that |
| 04:41:04 | Cycling | this python code to print the last letter in string is astring = "test" print (astring[-1]) prints 't' Does something similar exist in nimrod? |
| 04:47:27 | fowl | Skrylar, just add fuzzy matching for identifiers (: |
| 05:00:41 | Skrylar | levenschtein distance is really weird |
| 05:02:10 | Varriount | Cycling: I believe strings support negative slicing as well. |
| 05:02:34 | Varriount | If not, then you can do astring[astring.len()-1] |
| 05:03:55 | Varriount | Cycling: Sorry for the slow chat - most of the regulars in here are asleep this time of day. |
| 05:06:10 | * | DAddYE joined #nimrod |
| 05:08:17 | Cycling | Varriount, negative astring[-1] seems not to work but astring[2] does. astring[astring.len()-1] works though no probs thank you |
| 05:08:50 | Cycling | astring[-1] looks simpler. |
| 05:17:57 | Varriount | Cycling: Hm. Odd |
| 05:18:10 | Varriount | Cycling: It works for sequences (seqs) |
| 05:21:22 | Cycling | var stringa = "test" what would be the quickest way to convert that string into a sequence? |
| 05:22:06 | renesac | a string is a sequence of chars basically |
| 05:22:11 | renesac | why you want to convert? |
| 05:23:00 | Cycling | because astringseq[-1] should work want to test it. |
| 05:23:46 | renesac | var astring = "abcd" |
| 05:23:46 | renesac | echo astring[astring.high] |
| 05:23:53 | renesac | it echos 'd' |
| 05:24:01 | Varriount | Cycling: Well, I don't know what the performance impact would be, but the way to convert a string to a sequence, assuming there isn't already a procedure in the stdlib somewhere, would be.. |
| 05:24:17 | renesac | I don't think that negative indexes work in nimrod... |
| 05:24:45 | Varriount | var s = newSeq[char](astring.len) |
| 05:24:58 | Varriount | for c in astring: s.add(c) |
| 05:25:31 | Varriount | renesac: Sequences can handle them. Arrays can't, but that's because they can have actual negative indices |
| 05:26:02 | renesac | Varriount, acording to the manual: "A sequence S is always indexed by integers from 0 to len(S)-1 and its bounds are checked" |
| 05:26:29 | renesac | "The lower bound of an array or sequence may be received by the built-in proc low(), the higher bound by high(). The length may be received by len(). low() for a sequence or an open array always returns 0, as this is the first valid index." |
| 05:27:44 | Varriount | Huh, you're right. |
| 05:28:50 | Varriount | renesac: Ah! *slices* can have negative indices |
| 05:29:35 | renesac | oh |
| 05:29:37 | Varriount | This is something I'll have to bring up with Araq. |
| 05:29:44 | renesac | slices aren't well documented in the manual it seems |
| 05:30:22 | Varriount | Cycling: Try echo("Hello World"[-1.. -1]) |
| 05:31:34 | Varriount | renesac: We need an eval feature for nimbot. |
| 05:31:43 | Cycling | Varriount nice |
| 05:32:33 | Varriount | Cycling: It's a bit unorthodox. When Araq awakes, I'll ask him why negative ranges are allowed, but negative indices aren't. |
| 05:33:45 | Varriount | As far as I know, the only 2 possible reasons against including negative indices are performance (unlikely) and avoidance of user confusion (more likely) |
| 05:34:34 | Cycling | alist = list(astring) this is something I like in ython to make a list array. maybe var aseqlist = seq(astring) could be done? |
| 05:36:46 | Varriount | Cycling: 'proc toSeq(s: string): seq[char] = newSeq(result, s.len());for c in s: result.add(c)' |
| 05:37:23 | Cycling | i'm slow today |
| 05:37:30 | Varriount | Cycling: Do you want an array of strings or an array of characters |
| 05:37:45 | Varriount | characters are single.. characters only. |
| 05:38:07 | Cycling | in python is will make the characters yes |
| 05:38:18 | * | superfunc_ quit (Ping timeout: 240 seconds) |
| 05:38:44 | Varriount | Cycling: Then the procedure I just posted will turn a string into a sequence of characters. |
| 05:39:04 | Cycling | like that one. |
| 05:39:31 | renesac | Varriount, it won't |
| 05:39:53 | renesac | you will have s.len() blank values, and then add the string characters after them |
| 05:40:04 | Varriount | Hm. |
| 05:40:29 | renesac | It is in my pipeline hacking the newSeq to add a 'cap' parameter |
| 05:40:39 | renesac | that is what you wanted |
| 05:40:49 | renesac | well, I can do it now |
| 05:41:50 | fowl | result.newseq(s.len); copymem(result[0].addr, s.cstring, s.len) |
| 05:42:08 | Varriount | Well then "proc toSeq(s: string): seq[char] = newSeq(result, s.len());for n, c in s: result[n]= c" |
| 05:42:13 | Varriount | should work. |
| 05:42:44 | renesac | yeah |
| 05:42:46 | Cycling | Varriount, do you receive Error: 'seq[char]' cannot be assigned to? |
| 05:43:15 | Cycling | sorry my mistake |
| 05:43:35 | renesac | there is a 'result' missing there, I think |
| 05:43:51 | Varriount | Cycling: You need to turn the semicolon into a linebreak and indent. |
| 05:44:09 | renesac | Varriount, what is the difference between 'gc', 'gc2' and 'gc_ms' |
| 05:44:15 | renesac | I should modify those three? |
| 05:44:36 | Varriount | Huh? |
| 05:45:10 | Varriount | I think 'gc_ms' is the mark and sweep garbage collector. |
| 05:45:14 | renesac | it seems all three define 'newSeq' |
| 05:45:45 | Varriount | renesac: Probably because newSeq is a magic procedure that dynamically allocates memory. |
| 05:45:49 | renesac | quite a bit of code duplication it seems |
| 05:46:02 | Varriount | Each definition will correspond to a particular garbage collector. |
| 05:46:31 | renesac | the code seems identical |
| 05:47:14 | Varriount | --gc:refc|v2|markAndSweep|boehm|none |
| 05:47:14 | Varriount | select the GC to use; default is 'refc' |
| 05:47:56 | renesac | ok, gc2 is a bit different |
| 05:48:09 | Varriount | renesac: I can only speculate that they were either different at some point in the past, or are planned to be different in the future. |
| 05:49:10 | Varriount | renesac: Maybe you can look at the 'newStringOfCap' procedure's implementation - it does for strings what we want for sequences. |
| 05:49:50 | renesac | I'm not sure |
| 05:50:02 | renesac | it is not even in the gc.nim |
| 05:50:54 | renesac | any idea of what is 'newSeqRC1' |
| 05:50:54 | renesac | ? |
| 05:51:07 | renesac | and the difference # generates a new object and sets its reference counter to 1 |
| 05:51:09 | renesac | ok |
| 05:51:10 | Varriount | new sequence ref count 1? |
| 05:51:13 | renesac | yeah |
| 05:51:40 | Varriount | renesac: Possibly one is used for optimization purposes. Or maybe it's dead code. |
| 05:51:42 | renesac | well, I will ask araq latter |
| 05:51:53 | renesac | yeah, probably optimization |
| 05:52:18 | Varriount | It would be really helpful if we could read Araq's mind without disturbing him. It would make internal documentation so much easier. |
| 05:53:23 | * | Cycling quit (Ping timeout: 258 seconds) |
| 05:59:49 | * | DAddYE quit () |
| 06:00:25 | Varriount | renesac: You still there? |
| 06:20:13 | * | bjz quit (Read error: Connection reset by peer) |
| 06:20:44 | * | bjz joined #nimrod |
| 06:20:45 | Skrylar | okay |
| 06:21:09 | Skrylar | i ported the levenschtein (i can't spell that) distance function from wikipedia, and also hamming distance for strings |
| 06:25:04 | Varriount | Skrylar: We already have levenschtein in strutils. |
| 06:26:03 | Skrylar | where? |
| 06:26:17 | Skrylar | also you should have said that two hours ago when i said i was doing it :P |
| 06:26:39 | Varriount | Skrylar: I assumed you knew. In strutils |
| 06:26:54 | renesac | hello Varriount |
| 06:27:15 | renesac | I'm going to sleep |
| 06:27:30 | renesac | but if you want to say something, say it |
| 06:30:20 | renesac | good night |
| 06:30:50 | Skrylar | interesting |
| 06:31:04 | Skrylar | there's not a huge difference between the wikipedia version and the strutils one |
| 06:36:32 | * | ehaliewicz joined #nimrod |
| 06:41:49 | * | cark joined #nimrod |
| 07:06:03 | * | bjz quit (Ping timeout: 250 seconds) |
| 07:50:45 | * | bjz joined #nimrod |
| 07:51:44 | * | bjz_ joined #nimrod |
| 07:55:15 | * | bjz quit (Ping timeout: 240 seconds) |
| 08:36:15 | * | zielmicha_beta quit (Remote host closed the connection) |
| 08:39:31 | * | zielmicha_beta joined #nimrod |
| 08:41:08 | * | Tetragon joined #nimrod |
| 08:48:21 | Skrylar | bleh.. tomorrow is due for a lot more yak shaving |
| 09:23:09 | * | Tetragon quit (Remote host closed the connection) |
| 09:36:32 | * | ehaliewi` joined #nimrod |
| 09:36:55 | * | zahary1 joined #nimrod |
| 09:37:38 | * | brihat quit (Ping timeout: 258 seconds) |
| 09:37:58 | * | zahary quit (Read error: Connection reset by peer) |
| 09:39:15 | * | ehaliewicz quit (Ping timeout: 240 seconds) |
| 09:39:25 | * | brihat joined #nimrod |
| 09:41:25 | * | reciprocal joined #nimrod |
| 09:50:37 | Araq | hi reciprocal welcome |
| 09:50:48 | Araq | Varriount: the reason to disallow -1 for ordinary a[i] access is indeed performance |
| 09:54:12 | reciprocal | Hi |
| 09:56:59 | * | ehaliewi` quit (Ping timeout: 252 seconds) |
| 09:59:11 | * | Matthias247 joined #nimrod |
| 10:05:45 | * | darkf_ joined #nimrod |
| 10:09:04 | * | darkf quit (Ping timeout: 258 seconds) |
| 10:16:02 | * | darkf_ is now known as darkf |
| 10:20:32 | reciprocal | is assert supposed to echo something when used? |
| 10:32:58 | Skrylar | no |
| 10:33:03 | reciprocal | as in assert ext == ".html" if ext is not ".html" what should assert do? |
| 10:33:17 | Skrylar | it throws an eassert error |
| 10:33:30 | Skrylar | also assert is elided on release builds |
| 10:33:45 | Skrylar | so you need doAssert, or a regular if/else/throw |
| 10:34:08 | Skrylar | unless its just a debug-time test |
| 10:35:49 | reciprocal | i'm using a release build so that explains it |
| 10:36:16 | Skrylar | doAssert remains in release builds as far as i know, and you can also specify a failure message |
| 10:36:28 | Skrylar | doAssert(blah, "OH NO IT BROKE") |
| 10:37:12 | Skrylar | though as i mentioned an assert isn't so much validation as a panic condition, things like the wrong file extension should return a code or whatnot |
| 11:05:17 | reciprocal | is there a way to control what goes on the stack or heap when working with the GC? |
| 11:08:37 | reciprocal | # allocate memory for TData on the heap: var d = cast[ptr TData](alloc0(sizeof(TData))) From the manual |
| 11:10:00 | reciprocal | could the TData could be made to go on stack in a similar way |
| 11:30:01 | Araq | reciprocal: var d = TData() # allocates on the stack |
| 11:34:49 | Araq | and IMHO the GC allows for more control than most allocators ;-) |
| 11:35:18 | * | BitPuffin quit (Ping timeout: 245 seconds) |
| 11:36:49 | * | q66 joined #nimrod |
| 11:36:50 | * | q66 quit (Changing host) |
| 11:36:50 | * | q66 joined #nimrod |
| 11:42:22 | reciprocal | proc textchange (text : ptr string); chars[] = "changing text" # works when I call with textchange (addr(text1)) but not when I use "ref" in place of "ptr" |
| 11:45:28 | * | OrionPK quit (Remote host closed the connection) |
| 11:47:15 | Araq | yes. so? |
| 11:48:48 | reciprocal | Traced references are declared with the ref keyword, untraced references are declared with the ptr keyword. I thought the only difference is that one is traced and the other is not. So i'm not sure how to use ref in this case |
| 11:49:55 | Araq | 'addr' returns a 'ptr |
| 11:50:24 | Araq | 'ptr' is not only untraced, it is also *unsafe* and taking the address in nimrod is unsafe too |
| 11:51:21 | reciprocal | doing proc textchange (text : ref string) how would that be called? |
| 11:51:50 | Araq | var ugh: ref string; new(ugh); textchange(ugh) |
| 11:52:25 | Araq | 'ref' means it's on the GC'ed heap. so it's always on the heap, never on the stack. |
| 11:52:35 | Araq | and so you need 'new' here |
| 11:53:21 | reciprocal | that makes good sense. |
| 11:54:02 | Araq | btw usually you use 'var string' in this case |
| 12:02:25 | reciprocal | if ref is used then ugh = "text won't be assigned" because type mismatch: got (string) but expected 'ref string'. what would be the correct way to assign the text in this case? |
| 12:03:44 | reciprocal | i got it texts[] = "text goes here" |
| 12:03:53 | reciprocal | thanks |
| 12:05:09 | reciprocal | works perfect |
| 12:12:06 | * | io2 joined #nimrod |
| 12:15:57 | * | EXetoC joined #nimrod |
| 12:27:38 | * | tonlika joined #nimrod |
| 12:28:59 | tonlika | hello |
| 12:29:17 | dom96 | hi tonlika |
| 12:29:20 | tonlika | any project build on/using nimrod for example? |
| 12:30:02 | dom96 | plenty on github: https://github.com/trending?l=nimrod |
| 12:30:13 | tonlika | ok thanks :) |
| 12:30:15 | * | tonlika quit (Client Quit) |
| 12:31:22 | * | BitPuffin joined #nimrod |
| 12:32:51 | Araq | quick poll: how many cores do you have? |
| 12:33:34 | dom96 | 4 |
| 12:34:30 | reciprocal | 8 |
| 12:35:21 | EXetoC | 4 |
| 12:35:30 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 12:36:33 | Araq | well for now I'm hardcoding 4. :P |
| 12:38:13 | jez0990 | 4 |
| 12:39:00 | EXetoC | ok now we got enough samples |
| 12:39:08 | jez0990 | reactormonk: (in response to "coding in emacs?") nope, vim mostly, but is now the right time? |
| 12:46:47 | * | Araq silently replaces system.rand with system.CpuCount |
| 12:48:56 | dom96 | I think it's about time we add a proper multi-line comments syntax. |
| 12:48:58 | dom96 | Thoughts? |
| 12:48:59 | EXetoC | Araq: is this what you meant: "const X = defined(x) #\[newline][indent]# ..."? |
| 12:49:16 | Araq | EXetoC: correct |
| 12:49:19 | EXetoC | ##\ works, just that it indents lines following the first |
| 12:49:53 | EXetoC | but the doc command outputs nothing for #\ in this case |
| 12:50:19 | Araq | doc comments start with ## not # |
| 12:50:58 | EXetoC | well, that's the same as ##[newline] |
| 12:51:32 | EXetoC | I tried both together with #\. I'll look for this pattern again and compare |
| 12:53:45 | dom96 | #| multi-line? |# |
| 12:55:04 | Araq | dom96: should these be nestable? I guess they should |
| 12:55:21 | * | io2 quit () |
| 12:55:28 | dom96 | is """ ... """ nestable? |
| 12:55:34 | Araq | no |
| 12:55:59 | EXetoC | so the only problem is the output formatting |
| 12:56:06 | dom96 | hrm, coffeescript uses ### ... ### for multi line comments |
| 12:56:39 | Araq | lets use that then. coffeescript rules |
| 12:57:11 | * | dom96 wonders if you're serious |
| 12:57:29 | Araq | it's always hard to tell isn't it? |
| 12:59:09 | Araq | but I am serious |
| 12:59:21 | * | psquid joined #nimrod |
| 12:59:29 | Araq | ### is not nestable so regex based scanners continue to work |
| 12:59:40 | Araq | and we already use """ |
| 13:00:08 | * | Guest59079 quit (Ping timeout: 265 seconds) |
| 13:00:12 | Araq | so it makes perfect sense plus we can always say "It is not our fault, we copied coffeescript" |
| 13:00:59 | Araq | however it raises the question: are ### doc comments? |
| 13:01:43 | dom96 | if not then it would be nice if we could make them be doc comments |
| 13:02:01 | dom96 | take a look at http://rosettacode.org/wiki/Comments |
| 13:02:11 | dom96 | maybe you'll find some syntax you like better :P |
| 13:02:57 | Araq | comments should start with a semicolon as in 6502 assembly :P |
| 13:03:22 | Araq | but then we don't have non-doc multi line comments |
| 13:03:58 | Araq | mayb we should have #[ long comment that can [ nest ] ] |
| 13:04:08 | Araq | ##[ long doc comment that can [ nest ] ] |
| 13:05:10 | dom96 | what is the purpose of nesting? |
| 13:05:34 | Araq | you can comment out code easily that contains long comments |
| 13:05:55 | Araq | or you use an editor that doesn't suck ... |
| 13:05:59 | Araq | speaking of which |
| 13:06:19 | Araq | when I press enter with my cursor in a # section |
| 13:06:32 | Araq | aporia should simply insert an aligned # |
| 13:09:43 | dom96 | well then surely you mean: #[ long comment that can #[ nest ] ] |
| 13:10:26 | Araq | no |
| 13:10:52 | Araq | it should count the [ ] whether they start with # is not relevant |
| 13:10:54 | Araq | so I can do: |
| 13:10:57 | Araq | #[ |
| 13:11:06 | Araq | computes: a[i] * b[j] |
| 13:11:09 | Araq | ] |
| 13:11:44 | dom96 | That looks challenging to parse using regex |
| 13:11:56 | Araq | it's impossible |
| 13:12:02 | Araq | to parse using regexes |
| 13:12:04 | dom96 | hah |
| 13:12:21 | * | BitPuffin joined #nimrod |
| 13:12:24 | dom96 | then why do you want this syntax? |
| 13:12:38 | Araq | nesting is handy, as I said |
| 13:12:44 | Araq | but ### is fine with me too |
| 13:12:59 | BitPuffin | fowl: you got it |
| 13:13:03 | BitPuffin | but it's friday now |
| 13:13:07 | Araq | bbl |
| 13:13:29 | EXetoC | the problem with my proc-generating macro is that the symbols aren't included in the documentation. that might be a problem |
| 13:13:52 | Araq | EXetoC: use doc2 and then they should be listed |
| 13:14:15 | * | reciprocal quit (Remote host closed the connection) |
| 13:14:22 | EXetoC | ok. I tried doc again for some reason |
| 13:16:19 | EXetoC | I can't remember why. it works now with doc2 |
| 13:16:21 | EXetoC | great |
| 13:30:05 | * | darkf quit (Quit: Leaving) |
| 13:32:09 | EXetoC | ok so this "NoAutoGlErrorCheck* = defined(noAutoGlErrorCheck)" gets rewritten and that's why I tried 'doc' too. |
| 13:42:43 | * | [1]Endy joined #nimrod |
| 14:14:13 | * | Demos joined #nimrod |
| 14:25:36 | * | OrionPK joined #nimrod |
| 14:27:18 | EXetoC | what up |
| 14:49:48 | * | [2]Endy joined #nimrod |
| 14:53:11 | * | [1]Endy quit (Ping timeout: 250 seconds) |
| 15:03:13 | * | Demos quit (Ping timeout: 245 seconds) |
| 15:15:44 | * | BitPuffin quit (Ping timeout: 258 seconds) |
| 15:44:03 | * | Trimsty joined #nimrod |
| 15:51:26 | EXetoC | GL_Z6Y10Z6CB10Z6A10Z6Y10Z6CR10Z6A10_4224_NV that's a mouthful |
| 16:02:18 | EXetoC | should shadowing of 'result' really be allowed? |
| 16:14:38 | * | Trimsty quit (Remote host closed the connection) |
| 16:19:39 | * | Demos joined #nimrod |
| 16:23:04 | Demos | EXetoC: what up yourself |
| 16:23:24 | EXetoC | killing time |
| 16:25:14 | Demos | same |
| 16:26:41 | Demos | I decided to refactor my GUI code to be pretty much full on OOP. It was essentially that or do depth buffering and stuff on the drawing. And honestly so what if you have to do a bunch of pointer indirection and heap allocation on GUI objects. There are like 1000 of them max |
| 16:27:27 | Demos | wow. I just got a download link for a journal article. Guess the format |
| 16:27:39 | EXetoC | txt |
| 16:27:47 | Demos | html |
| 16:28:37 | Demos | oh, it is just the bib infor |
| 16:30:33 | dom96 | what up my glipglobs?!? |
| 16:32:46 | EXetoC | Demos: that design was that bad? |
| 16:33:23 | Demos | well it has a "download" link, and the link to get actual PDFs is tiny and under a collapsed tree thing |
| 16:33:44 | EXetoC | no the original GUI code |
| 16:34:00 | Demos | wait what design? |
| 16:34:33 | Demos | I never said what my original design was |
| 16:36:42 | EXetoC | nevermind |
| 16:36:48 | EXetoC | mmh eggs |
| 16:39:25 | Demos | also when working on this refactoring it struck me how having multimethods means you do not really need interfaces any more. I like that the dynamic dispatch is totally seperate from the type checking |
| 16:39:44 | * | nande joined #nimrod |
| 16:42:31 | Demos | To kill time I have been borwseing software engeneering journals, kinda interested to see researchers have actually been able to come up with anything interesting |
| 16:52:31 | renesac | Araq, I'm against ### for multiline comments |
| 16:52:51 | renesac | we already have 'discard """ """ ' for those |
| 16:52:59 | renesac | in what way ### would be different? |
| 16:53:03 | Araq | ask dom96 |
| 16:53:13 | Araq | he thinks we need it |
| 16:53:35 | renesac | I'm adding that 'discard' trick to the tutorial |
| 16:53:36 | dom96 | typing 'discard' is annoying IMO |
| 16:53:48 | EXetoC | when false? |
| 16:54:03 | renesac | when false still does some syntax checking, I think |
| 16:54:26 | EXetoC | Araq: another case of "use a real editor"? ;) |
| 16:54:27 | dom96 | yeah, and then I have to indent... |
| 16:55:08 | renesac | if we get a different type of multiline comments, they better be nestable |
| 16:55:28 | renesac | though the normal # comments are already nestable and multiline, if you are using a good editor |
| 16:55:29 | renesac | :P |
| 16:56:46 | renesac | """ """ is used on python too (or actually ''' ''') |
| 16:57:01 | renesac | the only "wart" is that we have to put a discard in front of it |
| 16:57:54 | Araq | template `//` (x: string) = discard x |
| 16:58:11 | Araq | //""" no need for discard really""" |
| 16:59:00 | EXetoC | I'd reserve that for something more useful |
| 16:59:09 | renesac | I'm using // for integer division in my bithacks module |
| 16:59:10 | renesac | :P |
| 16:59:31 | renesac | I prefer a simpler language |
| 16:59:33 | EXetoC | anyway, just add relevant functionality to aporia |
| 16:59:44 | EXetoC | renesac: unexported? |
| 17:00:07 | renesac | exported of course |
| 17:00:25 | renesac | also >> for shr, etc |
| 17:01:23 | EXetoC | eh ok |
| 17:01:31 | dom96 | why don't we just make """ ... """ implicitly discardable? |
| 17:01:45 | EXetoC | that's reasonable I think |
| 17:01:51 | Demos | dom96: if "false": |
| 17:02:00 | renesac | indeed |
| 17:02:25 | dom96 | ? |
| 17:02:40 | Demos | come to think of it I think if "false" is not valid |
| 17:02:58 | renesac | I like the idea of ''' and """ implicitly discardable |
| 17:03:36 | renesac | well, it is an special rule... complicates the language, but better than a new comment format |
| 17:04:01 | Demos | discard """ is just fine for me |
| 17:04:04 | renesac | and dom96 please add nestable comments to aporia (by that I mean #) |
| 17:04:10 | Demos | and # will be eaiser when they are not part of the AST |
| 17:04:55 | renesac | I agree with Demos, but I'm also ok with adding that special rule |
| 17:04:57 | dom96 | renesac: i'm not sure what you mean |
| 17:05:32 | Demos | yeah comments are not really top on my criteria for language goodness |
| 17:06:02 | Demos | unless you are like ALL CAPS ARE COMMENTS or everything after the 72nd line is a (silent) comment |
| 17:06:03 | renesac | if I select a bunch of text and type "ctrl + shift + c" or "ctrl + /", I want # added to the start of every line |
| 17:06:14 | renesac | even already commented lines |
| 17:06:46 | renesac | and then have a similar 'uncomment' shortcut that removes one # from every line that has it in the selection |
| 17:06:50 | dom96 | renesac: it already adds 'discard """ ... """' when you have multiple lines selected |
| 17:06:57 | renesac | those are not nestable |
| 17:07:00 | renesac | and are ugly |
| 17:07:08 | dom96 | I agree. |
| 17:07:16 | dom96 | But I don't have time to work on Aporia right now |
| 17:07:56 | Demos | ctrl-v, jjjjjjjj, shift-i, #, esc |
| 17:09:06 | EXetoC | 8j |
| 17:09:15 | EXetoC | :p |
| 17:09:25 | Demos | but just pressing it is faster than counting the number of lines |
| 17:09:53 | EXetoC | isn't relative numbering the default in the latest version? |
| 17:09:56 | EXetoC | that helps a lot |
| 17:10:11 | EXetoC | I probably wouldn't bother otherwise |
| 17:10:20 | renesac | ok, it was uglier because the 'discard' was indented... |
| 17:10:29 | renesac | # comments are superior anyway, with proper editor support |
| 17:13:02 | EXetoC | 'when false' is fine if the syntax is correct. nothing wrong with the indent imo |
| 17:13:06 | EXetoC | a block is a block |
| 17:13:46 | dom96 | Araq: Are you planning on removing comments from the AST in the future? |
| 17:14:05 | Araq | yeah |
| 17:14:24 | dom96 | Then we should get a dedicated multi-line comment syntax IMO |
| 17:15:06 | dom96 | Multi-line strings should be multi-line strings, and only multi-line strings. |
| 17:16:15 | dom96 | You should be for this idea, you like to type as little as possible after all. |
| 17:16:46 | Araq | maybe I'm already happy with # |
| 17:18:30 | dom96 | are you though? |
| 17:20:40 | EXetoC | he's only tough behind the computer |
| 17:22:21 | * | io2 joined #nimrod |
| 17:23:54 | * | DAddYE joined #nimrod |
| 17:25:51 | * | zezba9000 joined #nimrod |
| 17:26:25 | zezba9000 | Saw this article of 10 new langs and Nimrods #13 http://www.infoworld.com/slideshow/146094/not-the-usual-suspects-10-plucky-programming-languages-the-rise-240677#slide9 |
| 17:27:46 | zezba9000 | ** #9 |
| 17:28:15 | renesac | the problem with nested # is that after one nested comment it looks like a doc comment... |
| 17:30:01 | * | zezba9000 left #nimrod (#nimrod) |
| 17:30:44 | renesac | that is probably why python doc strings are """ """ and not ## |
| 17:30:53 | * | zezba9000 joined #nimrod |
| 17:31:39 | renesac | I forgot this issue with nimrod |
| 17:33:04 | dom96 | How is that an issue? |
| 17:33:29 | dom96 | I don't see a case where nested # would happen |
| 17:33:33 | dom96 | what am I missing? |
| 17:34:46 | zezba9000 | How is "#" for a comment an issue. "#" seems better for comments then "//" does. Although the "!" character might make more sense idk |
| 17:34:51 | dom96 | what does a nested # even look like? |
| 17:34:55 | dom96 | # this is # nested? |
| 17:36:03 | zezba9000 | Is "!" used in nimrod for anything? |
| 17:36:27 | zezba9000 | err stupid question nvr mind |
| 17:40:14 | EXetoC | maybe not what you think it is used for. it might be used in pegs |
| 17:40:19 | * | filwit joined #nimrod |
| 17:41:58 | Araq | ugh I really with mingw32 had non-broken atomic ops ... |
| 17:41:59 | EXetoC | `!` is overloaded in compiler/sigmatch, macros.nim and pegs.nim |
| 17:42:21 | Araq | it's also part of != and thus everywhere |
| 17:43:36 | zezba9000 | Araq: I know, thats why it was stupid question lol. Wasn't thinking |
| 17:43:39 | Varriount | Araq: What about Mingw-w64 |
| 17:43:59 | * | askatasuna joined #nimrod |
| 17:44:27 | Araq | Varriount: we can't drop win32 support. |
| 17:44:43 | * | psquid_ joined #nimrod |
| 17:45:05 | Varriount | Araq: Mingw-w64 has both 32 and 64 bit versions, both of which can compile 32 and 64 executables. |
| 17:45:14 | Araq | argh |
| 17:45:22 | Araq | and you tell me *now*? |
| 17:45:33 | Varriount | I assumed you knew |
| 17:45:35 | zezba9000 | Varriount: Does it let you compile with the VC++ compiler? |
| 17:45:56 | Varriount | zezba9000: Eh.. what? |
| 17:45:57 | * | psquid quit (Ping timeout: 252 seconds) |
| 17:46:07 | Varriount | Mingw is a compiler toolchain |
| 17:46:16 | Varriount | Essentially gcc for windows |
| 17:46:30 | reactormonk | jez0990, I read backlog |
| 17:46:35 | filwit | on windows, GCC seems to be much slower than VC++ |
| 17:46:53 | Varriount | Your question is sorta like asking if the intel compiler can use VC++ compiler |
| 17:46:57 | zezba9000 | Varriount: I know, but it also lets for posix stuff... so wasn't sure if you could mix posix with VC++ or some crazy thing |
| 17:47:37 | Demos | mingw does not really "do" POSIX |
| 17:47:46 | Demos | apart from having a bash-like shell |
| 17:48:17 | Demos | for POSIX you need the posix subsystem (windows services for unix applications) which is not depricated, or cygwin which is not great |
| 17:49:32 | Varriount | Which is why I don't use either, and just kick people into supporting windows. |
| 17:49:32 | zezba9000 | Demos: I know, I meant that. So nimrod could use posix like bash shell stuff while still targeting VC++ |
| 17:49:46 | Demos | nimrod does not use any shell |
| 17:49:52 | * | DAddYE quit (Remote host closed the connection) |
| 17:50:00 | zezba9000 | But idk, on windows I use windows only tools |
| 17:50:10 | Demos | you are welcome to put VCC in the path on mingw's bash shell |
| 17:51:23 | zezba9000 | I compile nimrod once with Mingw and ran a benchmark with it. It seems like G++ for Windows was much slower then VC++. |
| 17:51:32 | zezba9000 | If I remember right |
| 17:51:55 | Demos | were you using the -d:release? were you compileing with a recent version of GCC? |
| 17:52:09 | Demos | sometimes there are compiler optimizations that get in the way as well |
| 17:52:21 | Demos | like small code changes can really change the time for benchmarks |
| 17:52:42 | zezba9000 | Yes it was with "release" |
| 17:53:01 | zezba9000 | ANd yes with the newest version of MinGW tool chain |
| 17:53:42 | Araq | visual c++ is not bad when it comes to optimization. could use a good dose of my effect tracking though |
| 17:53:43 | * | DAddYE joined #nimrod |
| 17:53:45 | Varriount | zezba9000: Do you mean, the compilation time was longer, or the executable produced, when run, was slower? |
| 17:54:10 | zezba9000 | Varriount: No the exicution time was slower. |
| 17:54:20 | zezba9000 | ONLY on windows |
| 17:55:25 | zezba9000 | VC++ seems like the compiler you want to use on Windows. And why not as its going to make it easier to interface with other Windows APIs and platforms anyway. I don't see the reason for using the GCC on windows as it will just not be compatible with WinRT ect. |
| 17:56:00 | Varriount | zezba9000: Because as of Windows 8, the Windows SDK no longer has a compiler bundled with it. |
| 17:56:03 | * | Jesin joined #nimrod |
| 17:56:06 | Araq | zezba9000: the reason is we can ship GCC, but can't ship Visual C++ |
| 17:56:31 | Varriount | And I'd rather not install a 6+ gigabyte IDE just for the compiler. |
| 17:56:40 | Araq | and windows people (myself included btw) really love and expect working installers that don't depend on other stuff |
| 17:57:06 | * | askatasuna quit (Ping timeout: 240 seconds) |
| 17:57:11 | Varriount | Also, the majority of programs I have to build require autoconf and gcc |
| 17:57:25 | Varriount | Because of POSIX elitists |
| 17:57:38 | zezba9000 | I don't understand that logic when you can just download the VC++ compiler... |
| 17:57:43 | zezba9000 | how is that any different |
| 17:58:07 | zezba9000 | But sure ship it, thats cool, nothing wrong with it. Just at the end of the day VC++ seems to be the one to go with. |
| 17:58:32 | Varriount | zezba9000: You mean, *just* the compiler, and not all the bells and whistles and horrible large IDE's? |
| 17:58:47 | * | Demos quit (Ping timeout: 252 seconds) |
| 17:59:05 | zezba9000 | Varriount: how does that matter. As a window dev you should have Visual Studios 2013 on your computer... |
| 17:59:17 | Varriount | zezba9000: Surprise! I don't. |
| 17:59:42 | Varriount | I have the SDK installed, and use SublimeText as an IDE |
| 17:59:48 | zezba9000 | And what do you develop on windows? |
| 18:00:09 | Varriount | Nimrod - Wrapping native calls and such. |
| 18:00:28 | zezba9000 | Your argument is so silly sorry. Who cares if you have to download VS lol |
| 18:00:54 | Varriount | *shrug* |
| 18:00:56 | zezba9000 | Sounds like your just being a hater of MS products which doesn't solve and real world issues |
| 18:01:30 | Varriount | I'm a hater of bundling stuff I'm not going to use with stuff I am going to use. |
| 18:02:46 | zezba9000 | Varriount: Do you know how much stuff you have in your OS right now you are never going to "use"... |
| 18:03:03 | zezba9000 | We have 500GB to 1TB harddives these days |
| 18:03:34 | Araq | yeah and then you put into a small SSD and mount it as C: and swoosh |
| 18:03:47 | Varriount | ^ |
| 18:03:49 | Araq | you can't install MS's products anymore. great. |
| 18:04:01 | Araq | happened to me btw |
| 18:04:02 | zezba9000 | A 250GB SSD is not going away with VS |
| 18:04:25 | zezba9000 | Just put your games and low priority apps on another HD |
| 18:05:04 | Varriount | Assuming they like the split-drive finagling involved... |
| 18:05:04 | zezba9000 | If you have an SSD you must also have a hard disk |
| 18:06:09 | Araq | zezba9000: this discussion is really pointless. It was a small SSD (100GB iirc) and there was no space left and some of MS's installers require C:\ disk space |
| 18:06:15 | zezba9000 | You guys are ridiculous |
| 18:06:33 | Varriount | Araq: So concerning Mingw, would you consider dropping support for the regular 32 bit Mingw for the 32/64 Mingw=w64? |
| 18:06:52 | Varriount | *Mingw-w64 |
| 18:07:04 | Varriount | I mean, just for the atomic operations |
| 18:07:25 | Araq | Varriount: how does the switch between 32bit and 64bit work? |
| 18:08:02 | Varriount | Araq: Well, for programs that use autoconf, it's just a --host option |
| 18:08:10 | Varriount | Let me look up the actual compiler flags. |
| 18:11:29 | Varriount | Araq: I assume that you use the options on this page -> http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/i386-and-x86_002d64-Options.html |
| 18:13:29 | * | brson joined #nimrod |
| 18:16:42 | Araq | Varriount: I'm installing mingw64 and we will see |
| 18:29:14 | * | BitPuffin joined #nimrod |
| 18:30:14 | * | ehaliewicz joined #nimrod |
| 18:37:45 | * | BitPuffin quit (Ping timeout: 258 seconds) |
| 18:40:59 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 18:41:58 | Araq | Varriount: which one to pick from here http://mingw-w64.sourceforge.net/download.php ? |
| 18:42:34 | * | EXetoC joined #nimrod |
| 18:47:36 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 18:48:10 | renesac | dom96, yes |
| 18:48:12 | renesac | # some_commented_out(code) |
| 18:48:12 | renesac | # # This is a comment inside the comment! |
| 18:48:12 | renesac | # # Still inside the nested comment. |
| 18:48:12 | renesac | # some_more_code_in(outer_comment) |
| 18:48:19 | * | EXetoC joined #nimrod |
| 18:48:29 | renesac | ok, addin that space between them works even in nimrod |
| 18:48:31 | renesac | *adding |
| 18:49:38 | renesac | so yeah, you only need some basic editor support for multiline nested comments in nimrod (and python, etc) |
| 18:49:59 | renesac | The problem is that some editors add only "#" for commenting out, not "# " |
| 18:55:27 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 18:56:43 | dom96 | renesac: yes, and also ## are only doc comments if they are at the very top of a proc body |
| 19:00:44 | renesac | dom96, not true: https://github.com/Araq/Nimrod/blob/devel/lib/system.nim |
| 19:01:11 | renesac | they can be outside a proc too |
| 19:01:36 | dom96 | Yeah. But it's more likely you will end up with nesting inside procs. |
| 19:02:32 | dom96 | That said, this is only a problem for IDEs which automatically add and remove '#' |
| 19:02:57 | dom96 | it's easily solvable by making sure those IDEs add/remove '# ' instead. |
| 19:03:23 | renesac | yeah |
| 19:03:28 | zezba9000 | Varriount: O and BTW, you don't need VS to use the VC++ compiler: http://msdn.microsoft.com/en-us/windows/bb980924.aspx |
| 19:03:37 | renesac | and putting a space after your '#' is good style anyway |
| 19:05:08 | dom96 | yep |
| 19:08:24 | filwit | wait.. aren't AST comments on the copping block? or did something change since last i was around? |
| 19:09:10 | renesac | copping block? |
| 19:09:32 | filwit | er.. scheduled to be removed. |
| 19:09:36 | filwit | planned** |
| 19:09:45 | dom96 | they are |
| 19:10:03 | renesac | '#' yes, '##' I think not |
| 19:10:16 | renesac | removed from syntax checking |
| 19:10:25 | filwit | yeah okay, that's good |
| 19:10:25 | renesac | and the AST, but not from the language |
| 19:10:45 | filwit | i was just confused about you '# # nested comment' stuff above |
| 19:11:00 | filwit | just checking |
| 19:11:04 | renesac | this was an example from python |
| 19:11:13 | filwit | ah, i c |
| 19:11:16 | renesac | but that works in nimrod too with the spaces |
| 19:11:28 | * | EXetoC joined #nimrod |
| 19:12:01 | filwit | wait python as ast comments too? |
| 19:12:07 | renesac | no |
| 19:12:18 | renesac | it has simple '#' comments |
| 19:12:21 | filwit | er.. okay nvrmd |
| 19:12:25 | renesac | and """ """ are doc comments |
| 19:13:08 | renesac | (and also multiline strings, like nimrod |
| 19:13:11 | renesac | ) |
| 19:17:27 | * | Varriount|Mobile joined #nimrod |
| 19:19:05 | * | [2]Endy quit (Ping timeout: 252 seconds) |
| 19:19:33 | * | io2 quit (Ping timeout: 252 seconds) |
| 19:22:24 | * | nequitans joined #nimrod |
| 19:39:54 | * | Demos joined #nimrod |
| 19:56:13 | renesac | zezba9000, that infoworld article will be a nice reference for the next round of nimrod's deletion review on wikipedia |
| 19:56:47 | * | shodan45 joined #nimrod |
| 19:57:23 | zezba9000 | renesac: Nimrod was deleted from Wikipedia?? |
| 19:57:30 | renesac | yes |
| 19:57:48 | renesac | two or three times already |
| 19:57:57 | zezba9000 | what why? |
| 19:58:20 | dom96 | Not enough reliable references. |
| 19:58:41 | dom96 | i.e. it failed their notability requirements. |
| 19:58:46 | zezba9000 | lol accourding to who |
| 19:59:02 | dom96 | brb |
| 19:59:14 | renesac | acording to wikipedia deletionists |
| 19:59:15 | zezba9000 | and I thought Wikipedia was about information, what a joke |
| 19:59:16 | renesac | :P |
| 20:00:14 | renesac | http://en.wikipedia.org/wiki/Nimrod_%28programming_language%29 |
| 20:00:44 | renesac | probably after the 0.9.4 release we will try again |
| 20:00:46 | renesac | :P |
| 20:03:12 | * | Jesin quit (Quit: Leaving) |
| 20:04:02 | zezba9000 | For "notability requirements", it looks like you need more 3rd party references |
| 20:04:13 | zezba9000 | and is probably why it failed |
| 20:04:34 | renesac | yes |
| 20:04:56 | zezba9000 | If there is anyone using is in a published product that would help |
| 20:05:16 | Araq | yeah but your "I thought Wikipedia was about information" is spot on |
| 20:07:05 | zezba9000 | Ya no kidding, although I can understand they may do it for spaming and people making up random stuff that isn't true. |
| 20:11:48 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 20:14:36 | * | EXetoC joined #nimrod |
| 20:17:56 | nequitans | regarding wikipedia, does the Dr. Dobbs article count as a good 3rd party reference? |
| 20:18:41 | Araq | who knows |
| 20:18:47 | Araq | it should |
| 20:19:04 | EXetoC | I think it needs to be an article by the pope himself |
| 20:20:28 | * | BitPuffin joined #nimrod |
| 20:21:28 | nequitans | lol, my blog post alone has gotten > 10,000 views, and most people I tell Nimrod about are genuinely interested, so it's quite surprising to me. |
| 20:23:18 | BitPuffin | o/ |
| 20:23:23 | BitPuffin | nequitans: interesting, what blog post? |
| 20:23:57 | nequitans | i wrote it about a month and a half ago: http://geetduggal.wordpress.com/2014/03/03/consider-nimrod/ |
| 20:25:46 | nequitans | i got an idea, we should get tatler (http://en.wikipedia.org/wiki/Tatler) to do an article on Nimrod. That will get it on Wikipedia |
| 20:31:59 | BitPuffin | doesn't really look like a magazine that talks about programming languages lol |
| 20:33:14 | * | vendethiel quit (Read error: Connection reset by peer) |
| 20:37:17 | * | vendethiel joined #nimrod |
| 20:38:16 | dom96 | Araq: Why does `==` for TTable's use mget? |
| 20:38:32 | Araq | should be faster |
| 20:38:55 | dom96 | Why does the proc signature not reflect this? |
| 20:39:03 | BitPuffin | "should be faster" - optimizing noobs |
| 20:39:36 | * | flaviu joined #nimrod |
| 20:39:50 | Araq | dom96: why should it? every TTable has a mget |
| 20:39:51 | dom96 | Also, should the compiler not catch this? I guess because of the generics it's only an error when `==` is called on a non-var TTable. |
| 20:40:13 | Araq | ah I see |
| 20:40:32 | Araq | ok, my bug then |
| 20:40:43 | dom96 | Should I add 'var' to the signature? |
| 20:40:48 | Araq | hell no |
| 20:40:58 | dom96 | then should I get rid of the 'mget'? |
| 20:40:59 | Araq | fix the implementation instead |
| 20:41:02 | Araq | yeah |
| 20:41:35 | dom96 | ok, what about my second question. Should the compiler catch this at the point when the proc has been defined? |
| 20:41:36 | flaviu | dom96: Whats wrong with discard """ """ |
| 20:41:56 | dom96 | flaviu: I dislike typing 'discard' |
| 20:41:58 | Araq | dom96: no the compiler shouldn't catch it, generics are duck typed |
| 20:42:14 | Araq | for better or worse ... |
| 20:42:37 | dom96 | hrm, ok. |
| 20:44:21 | Araq | SomeFlowVar* = shared ptr object of TObject # hmm |
| 20:44:43 | dom96 | flaviu: And I don't always have an IDE which does the work for me. |
| 20:45:00 | dom96 | Like when I want to quickly edit something on my VPS... |
| 20:45:04 | Araq | makes me wonder why people are obsessed with writing 'ref T' everywhere |
| 20:45:47 | Araq | this is only getting worse. So people write 'region ptr T' everywhere because they can't stand a type prefix? |
| 20:46:04 | flaviu | dom96: I use vim, neither do I. But I don't like changing syntax for something that insignificant |
| 20:47:38 | dom96 | Would making """ implicitly discardable be so terrible? |
| 20:48:29 | Araq | that can't resonably work, dom96 |
| 20:48:29 | flaviu | No, that sounds like a good solution. I personally like the template method, but I'm fine with that too. |
| 20:48:54 | Araq | case x |
| 20:48:59 | Araq | of true: "abc" |
| 20:49:12 | Araq | of false: """nasty comment""" "xyz" |
| 20:49:14 | Araq | ??? |
| 20:49:48 | Araq | proc p: string = |
| 20:49:57 | Araq | """ implements nothing of value """ |
| 20:50:03 | Araq | oops |
| 20:50:05 | EXetoC | they are claiming that the prefixes aren't as obvious, right? |
| 20:50:26 | flaviu | Araq: How about overloading the comment operator :P |
| 20:51:05 | dom96 | if we introduce an operator for 'discard' then it will make 'discard' a little less effective. |
| 20:51:08 | renesac | I prefer prefixes to sufixes, and 'ref T" to sufixes too |
| 20:51:22 | * | ehaliewicz quit (Remote host closed the connection) |
| 20:51:28 | Araq | EXetoC: no. they are just ugly. |
| 20:51:31 | dom96 | It'll be easier to miss in normal code, and you know that people will use it everywhere in place of 'discard' |
| 20:51:34 | * | ehaliewicz joined #nimrod |
| 20:51:42 | flaviu | I was half-joking, not really serious |
| 20:51:46 | EXetoC | someone claimed that |
| 20:52:13 | renesac | I'm not sure if I prefer prefixes to 'ref T' |
| 20:52:52 | flaviu | What if someone doesn't declare a PThing type? Then its a mix of `ptr Thing` and people making their own `PThing`s |
| 20:52:53 | renesac | at first I though prefixes were very ugly, but I came to like them... still not pretty, but the alternatives aren't very good too |
| 20:53:24 | flaviu | I prefer the separate symbol over the prefixes |
| 20:55:41 | renesac | the only problem with separate symbol is if someone exports only 'ref T' and not 'T' |
| 20:55:53 | renesac | it is inconsistent then |
| 20:56:00 | Araq | renesac: that is a feature though |
| 20:56:12 | EXetoC | dom96: might as well change it do 'disc' or something then |
| 20:56:27 | renesac | I know, sometimes you don't want people to directly touch your type |
| 20:56:30 | EXetoC | or dis! |
| 20:56:36 | Araq | but you should always be able to do type(PFoo[]) to get the underlying type |
| 20:56:38 | renesac | and prefixes were great to make this explicit |
| 20:56:38 | EXetoC | ret, res |
| 20:56:54 | flyx | hey guys, is the stream API unable to read files that contain null bytes? |
| 20:57:06 | flyx | because it stops here when encountering the first null byte |
| 20:57:11 | dom96 | EXetoC: might as well add a proper multiline comment syntax! |
| 20:59:05 | flaviu | Araq: Remember when I suggested to get rid of most keywords and you pointed out scoping? What about macros, those could avoid scoping issues? |
| 21:00:47 | Araq | flyx: I don't think so, but outputting the string perhaps stops at the first 0 byte |
| 21:01:14 | Araq | when you use 'echo', that is |
| 21:01:24 | flyx | Araq: ah, that might as well be the case. I'll investigate further. |
| 21:01:29 | Araq | stdout.write should be fine with 0 |
| 21:02:04 | Araq | flyx: in any case make a bug report please |
| 21:02:23 | flyx | Araq: will do, tomorrow. bedtime for me now |
| 21:02:45 | Araq | sure thing |
| 21:03:42 | renesac | Araq, can I add an additional 'cap' parameter to 'newSeq'? |
| 21:03:56 | Araq | flaviu: no I don't remember |
| 21:04:10 | renesac | or you think three parameters is too much and preffer the 'newSeqOfCap' that I think is ugly? |
| 21:04:36 | Araq | newSeqOfCap is at least consistent |
| 21:04:50 | Araq | and less error prone than 2 int params |
| 21:04:57 | Araq | where 1 is optional |
| 21:05:06 | renesac | we have named parameters |
| 21:05:28 | Araq | sure but still |
| 21:06:02 | renesac | and why 'len' isn't assignable? |
| 21:06:18 | renesac | like 'someseq.len = 10' |
| 21:06:27 | BitPuffin | because it's not a property |
| 21:06:32 | BitPuffin | is it? |
| 21:06:35 | Araq | setLen predates `x=` accessors |
| 21:06:35 | flaviu | Araq: http://build.nimrod-lang.org/irclogs/13-03-2014.html 20:34 |
| 21:06:35 | flaviu | Basically, the keywords could be replaced with macros to do the actual translation into AST. So `if` might be `macro if(expr: bool, body: stmt)` |
| 21:06:37 | BitPuffin | or is it a proc? |
| 21:06:49 | EXetoC | dom96: what's wrong with indenting? nothing imo, and it's greppable and so on |
| 21:06:52 | BitPuffin | oh wait we have x= accessors? |
| 21:06:54 | BitPuffin | nice |
| 21:06:56 | renesac | Araq, can I add an accessor then? |
| 21:07:11 | renesac | that calls setLen? |
| 21:07:12 | flaviu | It wouldn't work for if though, it also would have to handle else in that case |
| 21:07:12 | dom96 | EXetoC: comments should be allowed anywhere. |
| 21:07:22 | dom96 | EXetoC: And that is why they will be removed from the AST |
| 21:07:25 | renesac | and maybe deprecate setLen? |
| 21:08:11 | flaviu | dom96: What about nimrod pretty? Or possible AST-based automated refactorings? |
| 21:09:05 | dom96 | flaviu: No idea. |
| 21:09:06 | EXetoC | dom96: seems like a minor point |
| 21:09:52 | Araq | renesac: well I still prefer 'setLen' |
| 21:10:24 | Araq | assigning length which might trigger a reallocation doesn't seem to be right, IMHO |
| 21:10:37 | renesac | it is more intuitive |
| 21:10:50 | renesac | you don't have to open the manual to search for it |
| 21:10:55 | flaviu | dom96: How will docgen work? It relies on the AST documentation information, so it would need to be changed a huge amount |
| 21:11:17 | dom96 | flaviu: I'm wondering that myself. |
| 21:11:29 | Araq | renesac: fix the bugs that keep "nimrod idetools" from working instead |
| 21:11:37 | dom96 | Someone broke $ for floats. |
| 21:11:45 | renesac | what bugs? |
| 21:11:47 | Araq | reactormonk. |
| 21:12:05 | dom96 | Araq: known bug? |
| 21:12:06 | Araq | renesac: we have lots of tests, and nobody knows if they work. I bet they don't. |
| 21:12:22 | Araq | dom96: reactormonk told me it's "fine" |
| 21:12:32 | Araq | I told him to be very careful |
| 21:12:47 | Araq | turns out ... people don't listen to me and regret it |
| 21:12:48 | dom96 | yeah... it just gives 0.0 for everything |
| 21:13:09 | flaviu | I'm really against removing the comments from the AST, it losses quite a bit of flexibility. |
| 21:13:36 | Araq | well doc comments will stay being part of the AST |
| 21:13:49 | Araq | so the docgen works just as before |
| 21:15:15 | flaviu | How about nimrod pretty? That'd be much harder to do after removing comments from the AST. |
| 21:16:08 | Araq | no |
| 21:16:56 | Araq | nimrod pretty already tracks accurate line, column information and performs edits that keep as much as possible |
| 21:17:10 | Araq | so your \n\n\n in the code stay this way |
| 21:17:19 | EXetoC | dom96: would it be for doc comments too? |
| 21:17:29 | Araq | everything else is simply too annoying |
| 21:17:56 | Araq | and now that we have that "technology" keeping comments in the AST doesn't buy us anything for "nimrod pretty" |
| 21:19:36 | flaviu | Hmm, I guess not. Some special cases might be a bit more tricky, but no point in complicating the compiler for those. |
| 21:20:19 | filwit | flaviu, AST comments make block-commenting difficult for various IDEs, since Nimrod is indent-sensitive and comments must rest on the appropriate indent |
| 21:20:48 | Araq | filwit: that's actually quite an orthogonal issue |
| 21:21:15 | Araq | the alignment requirement simply looked like a good idea |
| 21:21:38 | EXetoC | dom96: anyway, I wouldn't mind it. have you discussed this on the forums? |
| 21:21:41 | Araq | but I can imagine other ways and still have them part of the AST |
| 21:21:56 | filwit | Araq: i'm not sure exactly what you're saying |
| 21:22:23 | flaviu | Araq: What is the goal of removing them from the AST? |
| 21:22:24 | filwit | either way, having them part of the AST makes supporting different IDEs/editors more difficult |
| 21:23:01 | flaviu | filwit: nimrod is the IDE, anything else should just be a graphical wrapper over it |
| 21:23:07 | flaviu | IMO at least |
| 21:23:14 | filwit | nimrod is not an ide.. |
| 21:23:26 | flaviu | The compiler |
| 21:23:47 | renesac | nimrod is not an ide... |
| 21:24:00 | filwit | i'm not sure what you're trying to say, flaviu |
| 21:24:23 | Araq | renesac: when editors can show me 'x.setLen ' as a suggestion that's much more useful than being able to write 'x.len = 8' |
| 21:24:34 | Araq | your point is valid of course |
| 21:24:57 | Araq | but at this point we can easily get much more bang for your work |
| 21:25:13 | filwit | Araq: sorry, not trying to butt into a conversation, but 'x.len' could be highlighted as both a getter/setter in intellisense |
| 21:25:27 | filwit | Araq: and having 'setLen' is a bad standard, IMO |
| 21:26:24 | flaviu | IDEs typically do stuff like parse the source and that allows them to do all sorts of fancy things. In nimrod, the compiler does all the parsing and the IDEs just have to query the compiler for everything that isn't trivial. |
| 21:26:24 | flaviu | For example, in the Java world, each IDE has its own parser and its own AST structure for the language. In nimrod, the compiler should do all that. |
| 21:26:42 | renesac | filwit, it is not a private conversation, fell free to give your input |
| 21:27:10 | renesac | flaviu, nimrod has the 'idetools' so yes, an *IDE* can call the compiler for many things |
| 21:27:53 | renesac | but for simple syntax highlighting, for example, there is no need for that |
| 21:28:06 | renesac | thankfully |
| 21:28:38 | filwit | flaviu, nimrod's design here is good, but it doesn't stop programmers from having existing preferences in editors, and AST comments makes supporting those slightly more difficult in one aspect |
| 21:30:05 | flaviu | renesac: Yes, the nimrod grammar is simple enough for that. |
| 21:30:05 | flaviu | filwit: Ok, add an option to idetools to strip comments from any AST communicated. Same effect, also allows for who wants the comments to get it. |
| 21:30:07 | BitPuffin | wat |
| 21:30:12 | BitPuffin | nimrod is the IDE? |
| 21:30:25 | EXetoC | there's idetools |
| 21:30:32 | BitPuffin | ah |
| 21:30:32 | BitPuffin | yeah |
| 21:30:35 | BitPuffin | but that's not an IDE |
| 21:30:49 | filwit | flaviu, you're missing my point i think. Supporting Kate, for instance, has nothing to do with Nimrod's idetools. |
| 21:30:56 | BitPuffin | fowl: did you mean this friday or the next? |
| 21:31:06 | flaviu | BitPuffin: Sorry, bad word choice |
| 21:31:09 | filwit | flaviu, you don't need to use idetools at all for most editors basic highlightings and stuff |
| 21:31:32 | superfunc | For most, I'd figure you just set up a keyvalue type file |
| 21:31:47 | renesac | filwit, btw, did you manage to make the errors and warnings from the nimrod compiler show in the apropriate tab on kate? |
| 21:31:50 | filwit | flaviu, it's true that AST comments only really make "block commenting" hard for random text-editors to do on Nimrod code, but that's pretty common |
| 21:32:02 | renesac | or you have aways to go to the output tab? |
| 21:32:52 | filwit | renesac, hmm... i'm not sure what you're asking. I never did anything with errors/warnings in Kate |
| 21:33:07 | filwit | renesac, i also just use a terminal |
| 21:33:15 | renesac | oh, right |
| 21:33:22 | filwit | always** |
| 21:33:39 | renesac | I was using the build plugin |
| 21:34:16 | filwit | Kate just received full D intellisense support tho. perhaps i will take a look at how that's done and see if it can be adapted to Nimrod at some point |
| 21:34:27 | Demos | hoenstly I feel like AST based comments are neat, but I do not see any possible use for them that is not totally fucked up. Now having doc comments be part of the AST is a good idea |
| 21:35:19 | Demos | I looked at visual D, and python tools for visual studio. They were totally ad-hoc and hacky and consisted of totally HUGE amounts of code. It really feels like the VS extension APIs were designed by interns |
| 21:35:49 | flaviu | filwit: I'm not sure I understand, the internal representation of the AST in the compiler shouldn't matter if you aren't using idetools. |
| 21:35:49 | flaviu | Are you trying to say that editors have a hard time figuring out how to indent comments? |
| 21:36:08 | filwit | flaviu, yes exactly |
| 21:36:33 | filwit | flaviu, most editors have "place comment block (#) before or after whitespace" |
| 21:36:50 | renesac | removing the comments from the AST will probably lower the compiler memory usage a bit |
| 21:36:52 | filwit | flaviu, but that breaks compiling in Nimrod cause the comments are part of the AST |
| 21:37:28 | renesac | not that it is a real problem now |
| 21:37:29 | Demos | filwit: any code that depends on regular comments being part of the AST deserves to be broken |
| 21:37:32 | filwit | flaviu, so you can support block-comment functionality easily for Nimrod like you can for other languages (only in this area) |
| 21:38:34 | filwit | Demos, well i was never against them being part of the AST really... i mean, what's the difference? It's just that because of text-editor support, IMO, it's best to just remove them since they don't add much |
| 21:38:46 | Demos | yeah |
| 21:39:43 | filwit | flaviu, cant** support.... |
| 21:39:53 | flaviu | I'd use the word block-indented, but I get what you're saying. You could get rid of that part of the grammar though and still keep them in the AST, but it'd be more work. |
| 21:40:45 | filwit | flaviu, i'm talking specifically when you select a large chunk of text, and hit a shortcut to comment the whole block in/out |
| 21:41:06 | * | uvelichitel joined #nimrod |
| 21:41:45 | flaviu | filwit: I understand what you're saying now |
| 21:42:01 | fowl | is anybody against making tables nil tolerant? tab[key] = x would initialize tab and tab[key] would return the default value |
| 21:44:46 | flaviu | Should `macro foo(a: static[int]): stmt` work or am I misunderstanding static? |
| 21:47:40 | filwit | flaviu, dunno, but there's also `macro foo(a: int{lit}): stmt` |
| 21:51:04 | filwit | flaviu, take a look at http://build.nimrod-lang.org/docs/manual.html#parameter-constraints |
| 21:51:12 | filwit | if you haven't already seen it |
| 21:51:26 | filwit | not sure that's the best way to achieve what you're after |
| 21:52:17 | renesac | fowl, python has a separate 'defaultdict' for it |
| 21:54:01 | * | ehaliewicz quit (Remote host closed the connection) |
| 21:57:41 | fowl | renesac, not the same thing, its initialized when you call defaultdict() or w/e to create it |
| 21:57:54 | * | Skrylar shaves more yaks |
| 21:58:27 | reactormonk | Araq, ah fuck. |
| 22:01:12 | flaviu | filwit: Yes, that's it, thanks |
| 22:07:03 | flaviu | Actually, the exact same issue with the same stack trace arises |
| 22:08:36 | filwit | probably a bug with static[T] stuff then, idk |
| 22:08:57 | filwit | last i heard, static[T] was still buggy |
| 22:12:45 | renesac | fowl, I'm not sure if I understood what you said, but you need to declare a dict or a defaultdict(type) |
| 22:12:47 | renesac | anyway |
| 22:13:30 | renesac | well, nimrod tables must be of a certain type, I guess, so it don't have the same problem of python's normal dict, it could work like defaultdict |
| 22:13:44 | renesac | the problem is breaking backwards compatibility |
| 22:14:03 | renesac | there might be code out there that expects an exception in those cases |
| 22:14:35 | flaviu | Hmm, it also fails if there is no static involved. I guess that's bug. |
| 22:17:01 | flaviu | It also might be that I forgot to type cd :\ |
| 22:18:18 | OrionPK | hows that allegro stuff coming? :D |
| 22:26:49 | * | nequitans quit (Ping timeout: 252 seconds) |
| 22:26:56 | dom96 | reactormonk: Do you want to fix $ for floats? |
| 22:30:38 | reactormonk | dom96, not right now I gotta say |
| 22:30:45 | fowl | renesac, i want to be able to do this: var x: TTable[string,int]; x["hi"] = 4 |
| 22:31:07 | dom96 | reactormonk: can you give me a link to the commit that changes it so that I can take a look? |
| 22:31:09 | renesac | yeah, I understood |
| 22:31:26 | flaviu | dom96: git bisect |
| 22:31:28 | renesac | and I agree that it is a better default |
| 22:31:33 | fowl | renesac, in python there are no types so you cant really have a nil defaultdict |
| 22:31:41 | reactormonk | dom96, I basically reimplemented it, there's not much to see |
| 22:31:45 | reactormonk | dom96, otherwise, git blame does help |
| 22:32:00 | dom96 | reactormonk: Yeah, if I knew which line you changed. |
| 22:32:40 | renesac | fowl, there are types, but it is normally duck typing. An default dict is initialized with 'defautdict(int)' for example |
| 22:33:28 | fowl | you dont get what im saying still but it doesnt matter |
| 22:33:41 | dom96 | reactormonk: I guess it's https://github.com/Araq/Nimrod/commit/4b09baa0a030d899b7e75bb81828e0d9df90ce32 and https://github.com/Araq/Nimrod/commit/33fcd112360c60078ae7ee4ddb93cbe9f44393bd |
| 22:34:14 | renesac | fowl, but what you suggest would break backwards compatibility, right? |
| 22:34:21 | dom96 | flaviu: too slow :P |
| 22:35:05 | fowl | renesac, no, currently you get a segfault, cant recover from that |
| 22:35:37 | reactormonk | dom96, yup |
| 22:35:42 | renesac | oh, now I understood |
| 22:35:49 | reactormonk | dom96, and I take all the blame for not testing :-/ |
| 22:35:58 | dom96 | reactormonk: happens to the best of us |
| 22:36:04 | renesac | you want it to be initialized at first insertion, like seqs do now |
| 22:36:08 | reactormonk | and I feel bad because I always urge people to... Maybe because I know how bad it will hurt ^^ |
| 22:36:19 | renesac | the entire dict |
| 22:36:22 | renesac | *table |
| 22:36:42 | fowl | renesac, yea |
| 22:37:06 | * | renesac haven't used nimrod TTables yet |
| 22:37:21 | reactormonk | renesac, *hasn't :-P |
| 22:37:48 | reactormonk | dom96, I think the ruby float formatting is quite good |
| 22:37:57 | reactormonk | but it's its own implementation :-/ |
| 22:38:06 | renesac | reactormonk, -_-' I never know the difference |
| 22:38:17 | dom96 | reactormonk: How does it work? |
| 22:38:43 | reactormonk | renesac, third person singular |
| 22:38:48 | reactormonk | dom96, let me see |
| 22:38:54 | dom96 | 4.5 -> 4.5, 4.5555 -> 4.5555 etc. ? |
| 22:39:15 | * | shodan45 quit (Quit: Konversation terminated!) |
| 22:39:23 | renesac | well, as aseq.add() now initializes the seq if empty, and the relative overhead for this is bigger than on a hash table, I guess this change is probably the future |
| 22:40:09 | reactormonk | dom96, http://lpaste.net/102896 |
| 22:40:35 | dom96 | lol no way. |
| 22:40:44 | flaviu | reactormonk: What does it do that looks nice? |
| 22:40:47 | reactormonk | dom96, yup, it's a bit more complicated. |
| 22:40:47 | dom96 | reactormonk: Can you give me some examples of the output? |
| 22:40:51 | reactormonk | dom96, coming |
| 22:41:03 | * | xenagi joined #nimrod |
| 22:41:09 | reactormonk | dom96, gimme a few numbers and I can punch them for you |
| 22:41:36 | flaviu | reactormonk: I have a ruby repl open, I see nothing special |
| 22:41:42 | reactormonk | flaviu, that's the point. |
| 22:41:48 | * | xenagi quit (Client Quit) |
| 22:41:59 | * | uvelichitel quit (Quit: Textual IRC Client: www.textualapp.com) |
| 22:42:03 | renesac | 0.1 + 0.1 + 0.1 |
| 22:42:05 | reactormonk | flaviu, the previous one was just .16f, which is just all-in-your-face |
| 22:42:11 | dom96 | I guess I can play around in try ruby |
| 22:42:14 | reactormonk | 0.30000000000000004 |
| 22:42:16 | reactormonk | ^^ |
| 22:42:19 | reactormonk | dom96, use `pry` |
| 22:42:20 | renesac | right |
| 22:42:23 | renesac | equal to python |
| 22:42:27 | reactormonk | or `irb` if you don't feel like installing gems |
| 22:42:28 | * | xenagi joined #nimrod |
| 22:42:41 | dom96 | reactormonk: I'm on Windows... |
| 22:42:56 | flaviu | dom96: You need some linux |
| 22:42:59 | fowl | pray for him |
| 22:43:02 | dom96 | 0.1*0.1 |
| 22:43:03 | dom96 | => 0.010000000000000002 |
| 22:43:18 | dom96 | Doesn't look so nice... |
| 22:43:23 | reactormonk | dom96, that's just sucky floats |
| 22:43:33 | flaviu | would you rather it lie to you? |
| 22:43:48 | fowl | try 1/10 |
| 22:43:50 | reactormonk | it should be better than plain .16f |
| 22:43:52 | fowl | lol |
| 22:43:58 | reactormonk | fowl, that's 0 |
| 22:44:09 | dom96 | why is that 0? |
| 22:44:42 | flaviu | dom96: int division |
| 22:44:58 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 22:45:05 | dom96 | ahh |
| 22:45:09 | flaviu | he should have done 1.0/10 or 1/10.0, most languages don't force division to float like nimrod |
| 22:47:15 | BitPuffin | http://www.ibm.com/developerworks/aix/library/au-multithreaded_structures1/index.html should be an interesting read |
| 22:47:26 | BitPuffin | nd http://www.ibm.com/developerworks/aix/library/au-multithreaded_structures2/index.html |
| 22:47:31 | reactormonk | flaviu, it's 0.1 |
| 22:48:26 | renesac | https://groups.google.com/forum/#!msg/ruby-core-google/oWWhfY-XgKY/fnAmr_5_SrgJ <-- some more examples on rounding |
| 22:52:02 | renesac | we should really have settled on an octal/hexadecimal numeral system |
| 22:52:03 | renesac | :P |
| 22:54:13 | renesac | the java example is using a bigDecimal, not a float or bigFloat |
| 22:54:23 | renesac | so it can get the rounding right |
| 22:55:08 | * | DAddYE quit (Remote host closed the connection) |
| 22:55:36 | * | DAddYE joined #nimrod |
| 23:04:01 | flaviu | I guess the docgen only runs before macro expansion? |
| 23:04:07 | renesac | wow, division latency is huge |
| 23:04:37 | renesac | 26 cycles for 32bit, 92 for 64bits on a sandy bridge |
| 23:04:50 | renesac | 45 and 77 for a K10 |
| 23:04:57 | flaviu | Float division? |
| 23:05:08 | renesac | integer division, I think |
| 23:05:10 | renesac | div |
| 23:05:19 | renesac | yeah, integer |
| 23:05:36 | renesac | on atom it is 50 and 191 |
| 23:05:47 | renesac | an L1 cache miss is much better than that |
| 23:05:54 | flaviu | Can you compare it to C? |
| 23:06:00 | renesac | ? |
| 23:06:12 | renesac | I'm talking about CPU instruction latency |
| 23:06:41 | Demos | yeah division is heavy, everything else is not so bad |
| 23:06:52 | renesac | yeah |
| 23:07:14 | flaviu | oh, ok. But compilers can optimize lots of division to multiplication |
| 23:07:21 | renesac | multiplication is 3~4 cycles |
| 23:07:26 | renesac | latency |
| 23:08:04 | Demos | although I suspect that miss in L1 could be somewhat more costly than just the miss if there are data dependencies on that load |
| 23:08:14 | Demos | or rather is later instructions depend on that load |
| 23:08:16 | EXetoC | flaviu: not doc2 |
| 23:08:17 | renesac | on an atom it is 5~18 cycles latency for multiplication |
| 23:10:00 | flaviu | EXetoC: doc2 crashes for me with my complicated macros |
| 23:10:43 | EXetoC | :/ |
| 23:10:57 | renesac | Demos, I was comparing the L1 miss with division |
| 23:11:04 | Demos | I know |
| 23:11:35 | renesac | it might be better to fetch a table in L2 than do a division |
| 23:11:49 | renesac | especially for 64bit |
| 23:12:15 | Demos | again, if you have subsiquent instructions dependent on the load the CPU may have to stall |
| 23:12:33 | Demos | although I guess that is true if you have intructions dependent on the div as well |
| 23:12:38 | renesac | exactly |
| 23:12:45 | renesac | that was my comparison |
| 23:13:29 | Demos | still you should just profile and then find out what is actually happening, the CPU can tell you "hey I am doing all these divs, stahp" |
| 23:13:40 | renesac | I just watched last week the series of talks about the Mill CPU |
| 23:13:59 | renesac | so I was curious about those instructions latencies in normal cpus |
| 23:14:40 | renesac | https://www.youtube.com/playlist?list=PLFls3Q5bBInj_FfNLrV7gGdVtikeGoUc9 |
| 23:15:07 | Araq | fowl: I'm against making tables nil tolerant |
| 23:15:15 | renesac | if you don't want to see 10+ hours of talks, this is a nice summary: http://ootbcomp.com/topic/introduction-to-the-mill-cpu-programming-model-2/ |
| 23:16:35 | renesac | if you want to see the talks, I suggest starting with the second one |
| 23:16:59 | BitPuffin | Demos: does eigen do vector addition by mutating one of it's parameters? |
| 23:17:13 | renesac | the slides are much better and you don't really need the first one to understand it |
| 23:17:34 | Demos | BitPuffin: well if you say auto c = a+b a and b stay the same |
| 23:17:34 | renesac | he repeats lots of things at the start of each talk too |
| 23:17:44 | Demos | if you say a = a + b it will probably mutate a |
| 23:18:04 | renesac | Araq, why, if seqs are now nil tolerant? |
| 23:18:27 | BitPuffin | Demos: hmm, well yeah ofc a = a + b would mutate |
| 23:18:46 | Araq | a TTable is no hidden pointer, it's an object. it can't be nil anyway |
| 23:18:52 | BitPuffin | btw does a += b and a = a + b generate the same ast in nimrod? |
| 23:19:05 | Araq | but ok, the underlying seq does |
| 23:19:13 | Araq | BitPuffin: no way, that would be insane |
| 23:19:17 | BitPuffin | Demos: I'm considering changing linagl to define a + b in terms of a += b |
| 23:19:35 | BitPuffin | although I'd have to benchmark to see what's faster |
| 23:20:19 | BitPuffin | ie proc `+`(a, b) = result = a result += b |
| 23:21:22 | BitPuffin | and have `+=` be proc `+=`(a: var TVector, b: TVector) or something |
| 23:21:26 | BitPuffin | again |
| 23:21:31 | BitPuffin | would have to see what's faster |
| 23:22:00 | BitPuffin | then since a = a + b != a += b I guess I'd have to fix that with a macro |
| 23:22:11 | BitPuffin | TRM |
| 23:22:27 | fowl | Araq, yet you get a segfault when you dont initialize it. my main dislike for tables is that i have to repeat the type when i initialize it, i cant just do tab.init |
| 23:22:53 | dom96 | fowl: You don't have to repeat: var x = initTable[string, int]() |
| 23:23:35 | fowl | dom96, if its in an object |
| 23:23:57 | BitPuffin | Araq: do you think that would perform better than defining a += b to be a = a + b ? |
| 23:24:22 | dom96 | fowl: I see. Type inference isn't trivial. |
| 23:25:05 | fowl | dom96, its just a matter of defining init[k,v](t:var ttable[k,v]) |
| 23:25:52 | dom96 | define it then |
| 23:26:21 | fowl | and possibly have a pr rejected? my vanity!! |
| 23:27:22 | Araq | fowl: ok, allow 'nil' for TTable for consistency |
| 23:27:31 | Araq | better than 'init' crap |
| 23:28:06 | Demos | BitPuffin: you should not take Eigen doing any particular thing to be an indication of it being faster. Eigen does some /really/ clever metaprogramming to do lazy evaluation so that it can make less copies |
| 23:28:47 | * | darkf joined #nimrod |
| 23:29:07 | Varriount|Mobile | filwit: I saw your mockups for the new website, forums, and documentation, I think |
| 23:29:38 | Araq | Varriount|Mobile: which link exactly did you click to get mingw64? |
| 23:29:39 | Demos | Araq: how does nimrod deal with integer overflow? |
| 23:29:59 | EXetoC | it *might* raise an error |
| 23:30:10 | Araq | Demos: raises an exception in debug mode |
| 23:30:21 | Araq | in release mode it's undefined behaviour |
| 23:30:47 | renesac | and with unsigned numbers, it wraps around |
| 23:31:08 | Araq | where "undefined behaviour" means not quite the same as in C |
| 23:31:09 | renesac | or when using the unsigned (+%) operators |
| 23:31:27 | NimBot | Araq/Nimrod devel 00dc93b Dominik Picheta [+0 ±1 -0]: Fixes collections/ttables. |
| 23:31:27 | NimBot | Araq/Nimrod devel 20e3ab7 Dominik Picheta [+0 ±1 -0]: Improves tobjasgn test. |
| 23:31:27 | NimBot | Araq/Nimrod devel 1465355 Dominik Picheta [+0 ±1 -0]: Disabled tgtk test. |
| 23:31:49 | Demos | Araq: how is it different? |
| 23:32:01 | * | nequitans joined #nimrod |
| 23:32:28 | Varriount|Mobile | Araq: http://sourceforge.net/projects/mingwbuilds/files/mingw-builds-install/mingw-builds-install.exe/download |
| 23:33:01 | Araq | the compiler is free to optimize it without caring for overlfow, but at runtime it must either wrap around or saturate or raise an exception |
| 23:33:12 | Araq | well ... not really different from C I guess |
| 23:33:25 | Araq | but it can't crash with a segfault |
| 23:34:01 | Araq | "undefined behaviour" in C is allowed to format your harddisk or something |
| 23:34:09 | BitPuffin | hahahha |
| 23:34:23 | Demos | gcc actually will launch nethack if you use the right pragmas |
| 23:34:27 | Demos | just because it can |
| 23:34:59 | Demos | Araq: can I turn on overflow checks in a module if I want them? |
| 23:35:03 | BitPuffin | Demos: hrm, I wonder if I could do that in linagl without losing its flexibility |
| 23:35:08 | Varriount|Mobile | I have to wonder how things today would be if saturated integer arithmetic instead of overflow were the norm. |
| 23:35:09 | Araq | Demos: of course |
| 23:35:18 | Demos | BitPuffin: yes, but do not do it now |
| 23:35:24 | Demos | it would be a /lot/ of work |
| 23:35:29 | BitPuffin | yea |
| 23:35:37 | BitPuffin | well |
| 23:35:44 | Demos | and chances are it would break the compiler |
| 23:35:53 | BitPuffin | I'm just thinking if it's faster to define += in terms of + or + in terms of += |
| 23:35:56 | BitPuffin | or if it even matters |
| 23:36:03 | BitPuffin | Demos: linalready breaks the compiler |
| 23:36:19 | Demos | heh true |
| 23:36:22 | Demos | so does vecmath |
| 23:36:33 | Demos | it does not matter |
| 23:36:43 | BitPuffin | vecmath= |
| 23:36:44 | BitPuffin | ? |
| 23:36:58 | Demos | my linear algebra library, not on babel or anythong |
| 23:37:01 | Demos | *anything |
| 23:37:23 | BitPuffin | aha |
| 23:37:28 | BitPuffin | well how do you cope |
| 23:37:32 | BitPuffin | because I get depressed xD |
| 23:38:06 | BitPuffin | err |
| 23:38:22 | BitPuffin | reactormonk: shouldn't you show a little bit more of an example in your latest bug report lol |
| 23:39:02 | * | superfunc quit (Quit: Page closed) |
| 23:40:26 | BitPuffin | does the manual tell me which will be evaluated first in a * b * c |
| 23:41:51 | BitPuffin | ah |
| 23:41:54 | BitPuffin | left associative |
| 23:42:05 | BitPuffin | unless rel char is ^ |
| 23:42:51 | BitPuffin | Demos: doesn't that mean that with your silly col majorness you have to do C*(B*(A*v)) |
| 23:42:58 | BitPuffin | or wait |
| 23:42:59 | BitPuffin | no |
| 23:43:01 | BitPuffin | you don't |
| 23:43:04 | BitPuffin | what am I thinking |
| 23:43:33 | Demos | you do know that matrix multiplication is associative right? |
| 23:44:24 | BitPuffin | Demos: right associative? or why did you swap the position of "right" |
| 23:44:52 | Demos | I accedently a comma |
| 23:44:57 | Varriount|Mobile | Speaking of matrix multiplication, the python devs recently accepted a PEP to introduce matrix multiplication operators. |
| 23:45:17 | BitPuffin | Varriount|Mobile: what did they say? |
| 23:45:37 | EXetoC | huh |
| 23:45:37 | Demos | they are using @ right? |
| 23:45:45 | EXetoC | such specific operators |
| 23:46:02 | Varriount|Mobile | They accepted. It was kind of a strong-armed into action thing |
| 23:46:07 | BitPuffin | matrix mul doesn't have specific operators |
| 23:46:37 | Varriount|Mobile | A surprisingly large amount of python's userbase is with science and numerics |
| 23:47:25 | BitPuffin | wait |
| 23:47:29 | BitPuffin | what am I thinking |
| 23:47:30 | xenagi | no, you wait |
| 23:47:34 | xenagi | :P |
| 23:47:51 | BitPuffin | associativity won't matter |
| 23:48:01 | * | BitPuffin slaps xenagi with a sphincter |
| 23:48:09 | Varriount|Mobile | A bunch of people from the various major numeric python packages basically presented the pep and said "We make up a huge part of the community, here's a feature we need along with the logic behind it, make it so" |
| 23:48:29 | BitPuffin | Varriount|Mobile: well matrix mul is written as AB |
| 23:49:19 | BitPuffin | or wait |
| 23:49:21 | BitPuffin | it will matter |
| 23:49:22 | BitPuffin | XD |
| 23:49:42 | fowl | i am currently trying to merge roids into flaming-nemesis |
| 23:49:50 | xenagi | pretty sure it matters, BitPuffin |
| 23:49:54 | fowl | that project needs a name >_> |
| 23:49:56 | BitPuffin | it will indeed |
| 23:50:12 | xenagi | though, I have yet to open up that book "The Manga Guide to Linear Algebra" :P |
| 23:50:22 | BitPuffin | Demos: did you mean commutative when you said associative |
| 23:50:27 | Demos | no |
| 23:50:30 | BitPuffin | because that would be false |
| 23:50:31 | Demos | I meant associative |
| 23:50:45 | Demos | A(BC) = (AB)C |
| 23:50:54 | Demos | if we ignore floating point |
| 23:50:57 | BitPuffin | ah |
| 23:51:01 | BitPuffin | you meant like that |
| 23:51:04 | BitPuffin | well then I gotcha |
| 23:51:23 | xenagi | BitPuffin, what'cha coding? |
| 23:51:25 | BitPuffin | should have understood immediately |
| 23:51:29 | BitPuffin | just a bit rusty |
| 23:51:34 | BitPuffin | xenagi: updating linagl |
| 23:51:56 | BitPuffin | and I started worrying about the associativity |
| 23:54:53 | Demos | I dont think static[T]s work yet... |
| 23:55:45 | BitPuffin | Demos: they don't |
| 23:55:54 | BitPuffin | Demos: I am adding linagl/boring |
| 23:56:07 | filwit | is 'bind' no longer needed for templates which expose private module symbols? |
| 23:56:38 | Araq | filwit: yes, 'bind' is obsolete |
| 23:56:51 | filwit | Araq: nice |
| 23:57:13 | flaviu | filwit: Unrelated to what you're doing ATM, but can you include breadcrumbs in the new design? |
| 23:57:41 | filwit | Araq: well templates seem to work nicely for my global calling syntax, but i still have one more issue with OOP macros (haven't tried in awhile tho) which is the exposure symbol * |
| 23:58:04 | filwit | flaviu, sure that sounds fine, but on which design.. the docs? |
| 23:58:04 | BitPuffin | oooh |
| 23:58:05 | flaviu | My biggest gripe with the UI now is that I have to manually edit the url to move back to the main page or the documentation page |
| 23:58:09 | BitPuffin | would be sweet to have nimcss |
| 23:58:30 | flaviu | filwit: Yes, something like Home>Docs>Libraries>System |
| 23:58:41 | BitPuffin | a CSS generating DSL that takes care of platform specific bs :D |
| 23:58:44 | BitPuffin | well |
| 23:58:46 | BitPuffin | browser specific rather |
| 23:58:55 | filwit | flaviu, okay thanks for the feedback, but let's nitpick the design (especially the docs) when there's actual HTML to go over |
| 23:59:10 | filwit | flaviu, but that does sound like a good idea |
| 23:59:17 | BitPuffin | lol, cat |
| 23:59:21 | BitPuffin | way to be dramatic |
| 23:59:58 | flaviu | Ok, sure. I'll mention it again next time you ask for feedback |