| 00:02:03 | fowl | .j#ra |
| 00:02:12 | gradha | indeed |
| 00:06:27 | gradha | is addr the same as casting to pointer type? |
| 00:07:57 | dom96 | addr will give you a `ptr T` where as cast[pointer](...) will just be a `pointer` |
| 00:08:53 | AlexLibman | Did nimrod by any chance relicense while I was offline? :P |
| 00:09:23 | gradha | AlexLibman: highly unlikely |
| 00:10:24 | dom96 | ping zahary |
| 00:12:19 | dom96 | Guess he's not here. Pity. |
| 00:14:44 | gradha | ok, can't cast string to pointer |
| 00:14:50 | gradha | but I can addr string var |
| 00:15:02 | gradha | btw, any difference between addr string and addr string[0]? |
| 00:15:11 | dom96 | yes. |
| 00:15:24 | dom96 | addr string[0] points to the first char |
| 00:15:33 | gradha | cool, I'm overwriting memory then |
| 00:15:55 | gradha | makes sense |
| 00:16:00 | dom96 | For cstring it's the same. |
| 00:16:36 | gradha | hm? isn't that a cast? never seen cstring(string[0]) |
| 00:17:05 | dom96 | addr cstring and addr cstring[0] is the same. |
| 00:17:19 | gradha | ah, ok, didn't follow you there |
| 00:17:31 | gradha | otherwise you wouldn't be able to pass cstring to C code |
| 00:17:50 | dom96 | yes |
| 00:24:24 | reactormonk | oh, he's gone :-/ |
| 00:24:33 | reactormonk | Yes, readAll isn't that simple :-( |
| 00:26:43 | dom96 | I have a deja vu, I think this issue with readAll was already talked about. |
| 01:06:04 | reactormonk | I have no idea how to implement this correctly - maybe I should look at cruby |
| 01:06:21 | dom96 | what are you implementing? |
| 01:06:28 | reactormonk | the readAll |
| 01:06:45 | dom96 | oh, what's the problem? |
| 01:08:42 | reactormonk | see above |
| 01:09:45 | dom96 | you're having trouble fixing it? isn't it just a matter of subtracting the current file pos from fileSize? |
| 01:09:50 | dom96 | Am I missing something? |
| 01:21:08 | reactormonk | nah |
| 01:21:13 | reactormonk | gotta look at it |
| 01:36:47 | reactormonk | dom96, then do it ;-) |
| 01:36:49 | reactormonk | PR and stuff. |
| 01:38:04 | dom96 | I fear there is a reason why readAll works that way. |
| 01:40:14 | dom96 | and then Araq will hunt me down for wrecking his code :P |
| 01:46:50 | dom96 | oh man. You said PR and I thought "Public Relations", only got it now. |
| 01:47:23 | reactormonk | it's one of the few pieces I wrote :-) |
| 01:47:51 | dom96 | what? I'm confused. |
| 01:48:02 | reactormonk | the readAll |
| 01:49:41 | dom96 | I can help you fix it if you'd like, sure? |
| 01:50:05 | reactormonk | So there is no reason why readAll works that way ;-) Go ahead and fix it. |
| 01:50:39 | dom96 | come on, you can do it :P |
| 02:11:36 | reactormonk | dom96, https://github.com/Tass/Nimrod/commit/eab61f1c0e78c755611de9e589d1432771c36d69 ? |
| 02:14:31 | dom96 | well, you shouldn't do it in rawFileSize |
| 02:14:47 | dom96 | Since then the function doesn't do what it's name implies |
| 02:18:54 | dom96 | hrm, now that I think about it: readAll implies reading everything, no matter what the file pos is. |
| 02:22:38 | dom96 | We need our BDFL to decide :P |
| 02:24:46 | NimBot | nimrod-code/Aporia 6d36d13 Dominik Picheta [+0 ±3 -0]: Implemented a fail-proof way to scroll successfully. |
| 02:25:03 | reactormonk | ^^ |
| 02:25:36 | dom96 | I finally figured out how to force GTK to scroll my SourceView :D |
| 02:26:56 | dom96 | Good night |
| 02:27:17 | reactormonk | ye too |
| 02:35:38 | reactormonk | Any way to get all possible symbols in context? Just go to EOF and call suggest? |
| 10:08:02 | * | fowl joined #nimrod |
| 11:27:55 | * | q66 joined #nimrod |
| 14:01:14 | dom96 | I found a case where --def causes the compiler to go into a infinite recursion... |
| 14:21:43 | AlexLibman | * Objective-C wins the TIOBE Programming Language Award of 2012! - http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html |
| 14:21:53 | AlexLibman | ^ "Other interesting moves of 2012 are the renaissance of C++ (+1.09%, boosted by Microsoft) and Python (+0.96%). On the other hand, C# (-2.57%, due to its late entrance in the mobile market) and Delphi (-0.65%) lost considerable market share." |
| 14:25:48 | * | dom96 dreams of the day Nimrod gets the award |
| 14:27:37 | AlexLibman | Won't get there if it's copyleft. |
| 14:30:49 | AlexLibman | Libmanrod, a competing copyfree Pythonesque-to-C compiler, will get the award instead. :P |
| 14:35:10 | dom96 | patience is a virtue :P |
| 14:41:45 | dom96 | AlexLibman: Have you written any Nimrod yet? |
| 14:53:22 | AlexLibman | Officially, I wouldn't admit to writing anything in a non-copyfree language. But there are rumors of an `ununi` command on my system, which uses "unidecode" and renames all unicode filenames to ASCII, no longer being a Node.JS script. ;) |
| 14:54:54 | dom96 | hehe, good good. |
| 16:46:01 | apotheon | Is there an INI file parser library for Nimrod? |
| 16:46:24 | dom96 | apotheon: http://build.nimrod-code.org/docs/parsecfg.html |
| 16:46:38 | apotheon | Ah, nice. Thanks. |
| 16:47:45 | apotheon | By the way . . . why "of" in "case"? |
| 16:48:28 | apotheon | That's a much nicer lib design than what I've seen for C INI parsers. |
| 16:48:59 | dom96 | You're going to have to ask Araq that :) |
| 16:49:18 | dom96 | my guess is: it's not much to type. |
| 16:49:21 | apotheon | "Of" would make more sense if it was "incase" instead of just "case", I suppose. |
| 16:55:27 | dom96 | I don't think much of it nowadays. "case" + "of" is completely natural to me now :) |
| 16:57:29 | * | AlexLibman joined #nimrod |
| 16:58:03 | * | _ponce left #nimrod (#nimrod) |
| 17:13:31 | NimBot | nimrod-code/Aporia c767d72 Dominik Picheta [+0 ±4 -0]: Fixed problems with CustomStatusBar. |
| 17:13:31 | NimBot | nimrod-code/Aporia 5b34ac6 Dominik Picheta [+0 ±2 -0]: Fixed a recently introduced status bar bug. |
| 18:42:58 | Araq | hi guys, I'm back |
| 18:43:42 | Araq | AlexLibman: 'of' was chosen because: 1) I was familiar with 'case x of' from Dephi |
| 18:44:02 | Araq | 2) it has to be keyword, things like '|' clash with user definable operators |
| 18:44:30 | Araq | 3) couldn't think of any shorter keyword ;-) |
| 18:48:37 | AlexLibman | wb Araq. Apotheon was asking about 'of', not I. |
| 18:48:55 | Araq | oh ... sorry |
| 18:49:14 | AlexLibman | I once imagined a language with single-character keywords... |
| 18:49:44 | Araq | I imagine one that uses special chars instead everywhere |
| 18:49:52 | AlexLibman | (not counting type qualifiers, like ui64) |
| 18:49:59 | Araq | ? would be 'if', @ would be 'while' etc. |
| 18:50:56 | AlexLibman | With unicode, you can make it work rather well. |
| 18:51:13 | AlexLibman | (Assuming your editor makes it easy to input unicode characters.) |
| 18:51:19 | Araq | typing most unicode characters is still too much of a pain |
| 18:51:36 | AlexLibman | Related idea: http://xahlee.info/comp/html6.html |
| 18:53:20 | AlexLibman | All we need is consistant character names, like "mdash". Then it's trivial to create a keyboard shortcut to insert that character, even at OS level. |
| 18:53:52 | Araq | how would I write "mdash" then? |
| 18:54:00 | AlexLibman | But that defeats the purpose of single-character keywords. :P |
| 18:54:04 | Araq | the word, not the character |
| 18:55:06 | apotheon | I'm sure emacs has an RSI for that. |
| 18:55:22 | AlexLibman | You just type "mdash" to insert the word. To turn it into a character, that depends. On OS level it could be something like caps lock while typing it. On editor level, you can type it and then press Ctrl-something to autoconvert word at cursor. |
| 18:55:26 | apotheon | RSI is my new term for "command" when referring to emacs. |
| 18:56:03 | AlexLibman | Just random thoughts... |
| 18:56:48 | AlexLibman | http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references#Character_entity_references_in_HTML |
| 18:57:18 | apotheon | control-x control-u shift-alt-r for ř |
| 18:59:39 | AlexLibman | So like you press Ctrl-& (Ctrl-Shift-7, like the XML prefix char) and the editor goes into insert character mode. You type "di", and the autosuggest scrollbox suggests "divide" for '÷'. |
| 18:59:53 | apotheon | (Don't try that. It probably overwrites your filesystem with zeroes.) |
| 19:01:33 | AlexLibman | Yet Another Useless Idea™ (Ctrl-&trade) |
| 19:02:01 | apotheon | I think you're trying to reinvent xemacs. |
| 19:02:15 | apotheon | Considering it shouldn't have been invented in the first place . . . |
| 19:02:32 | AlexLibman | What I suggested has nothing to do with xemacs. |
| 19:02:50 | AlexLibman | It's like saying you're trying to reinvent apples because your alias starts with "ap". |
| 19:02:54 | apotheon | Ctrl-Shift-7 di click |
| 19:02:58 | apotheon | looks like xemacs to me |
| 19:03:21 | apotheon | Here's a simpler solution: |
| 19:03:22 | AlexLibman | Single keystroke combinations are used in every program. |
| 19:03:24 | apotheon | Just use a Compose key. |
| 19:03:40 | AlexLibman | I don't have a compose key. |
| 19:03:45 | apotheon | Configure one. |
| 19:03:48 | AlexLibman | OK, here's the UNIX Way To Do It... |
| 19:04:26 | AlexLibman | You have a small program that outputs a unicode character based on argument. It would have a very short name, like `U`. (Uppercase U.) |
| 19:04:44 | apotheon | setxkbmap -option compose:ralt |
| 19:05:25 | AlexLibman | And you have an editor with command mode, and a very easy way to insert command output at cursor, or filter selection through a command. |
| 19:08:57 | AlexLibman | "... and that the name of Silicon Graphics not be used in advertising or publicity pertaining to distribution ..." -- /usr/ports/x11/setxkbmap/work/setxkbmap-1.2.0/COPYING :P |
| 19:10:45 | Araq | html5 looks like a very good idea |
| 19:10:50 | Araq | er, html6 |
| 19:11:05 | AlexLibman | :D |
| 19:11:21 | Araq | so it'll never happen :P |
| 19:12:27 | AlexLibman | I prefer whitespace formatting anyway. |
| 19:13:39 | AlexLibman | s/whitespace formatting/\"off-side rule\"/ |
| 19:14:54 | AlexLibman | Hey, http://en.wikipedia.org/wiki/Off-side_rule#Off-side_rule_languages mentions Nimrod, but links to http://en.wikipedia.org/wiki/Nimrod_(distributed_computing) |
| 19:15:56 | Araq | I noticed |
| 19:16:54 | apotheon | AlexLibman: I do have an editor like that . . . but the Compose key doesn't need all that. |
| 19:16:59 | AlexLibman | What I want is an HTML/CSS/JS type format for defining textual interfaces, with support going all the way back to DOS. It would be very menu and keyboard oriented. |
| 19:17:02 | apotheon | AlexLibman: Why do you always want to reinvent the wheel? |
| 19:17:40 | Araq | "The good thing about reinventing the wheel is that you can get a round one." |
| 19:17:57 | AlexLibman | You could then compile that syntax into C (that you could even compile in dosbox, or regular UNIX terminal) -or- into HTML/JS/CSS to run in th browser. |
| 19:18:03 | apotheon | Araq: AlexLibman likes 'em triangular. |
| 19:18:12 | * | AlexLibman ignores apotheon |
| 19:20:18 | apotheon | There are many problems not satisfactorily (for now) solved that could use our attention, rather than problems that have half a dozen satisfactory solutions -- especially when the new solution we come up with is unsatisfactory, like requiring drop-down lists. |
| 19:20:49 | apotheon | . . . or typing en_US.UTF8'ian. |
| 19:22:40 | apotheon | I'm morally opposed to general purpose programming languages that cannot be used with any seriousness unless you have drop-down lists. |
| 19:23:04 | apotheon | (I use the word "morally" pretty loosely here, but you get the idea.) |
| 19:23:37 | apotheon | https://xkcd.com/927/ |
| 19:23:39 | apotheon | sums it up |
| 19:24:24 | apotheon | Nimrod, on the other hand, has promise. |
| 19:25:06 | Araq | thanks :-) |
| 19:27:13 | apotheon | quite welcome |
| 19:28:23 | apotheon | I'm tempted to create variant implementations of various languages that treat all trailing whitespace as Whitespace language syntax, then randomly replace other implementation deployments with my fudged implementations, just to teach people better whitespace discipline. |
| 19:28:58 | Araq | what is "better whitespace discipline"? |
| 19:29:07 | Araq | why is it important? |
| 19:30:16 | apotheon | Linewraps can get ugly (well, uglier) on long lines of code with trailing whitespace. |
| 19:30:47 | apotheon | (for example) |
| 19:33:47 | apotheon | Some timesaving editor facilities aren't as timesaving with trailing whitespace. |
| 19:33:54 | apotheon | (for another example) |
| 19:34:16 | apotheon | Some grep expressions will unexpectedly fail with trailing whitespace. |
| 19:34:20 | apotheon | (for another example) |
| 19:34:48 | apotheon | I could probably come up with examples of why it's important all day. |
| 19:35:27 | Araq | for now you didn't convince me ... :P |
| 19:35:29 | apotheon | I'd say "whitespace discipline" is "not being careless with whitespace so that you have a bunch of whitespace weirdness in your text that you don't even know is there", or something like that. |
| 19:36:38 | apotheon | Maybe I'll start sending you patches for Nimrod (after the license change) with sloppy whitespace management (outside of indentation, of course). |
| 19:36:46 | apotheon | . . . until you ask me to stop. |
| 19:37:05 | Araq | please stop ;-) |
| 19:37:12 | Araq | 1) I'm aware of it |
| 19:37:14 | apotheon | Aha! I've convinced you after all! |
| 19:37:30 | Araq | 2) it's because of it's been translated automatically |
| 19:37:40 | Araq | 3) the diffs are distracting |
| 19:37:55 | apotheon | Oh, diffs. I should have mentioned that first. |
| 19:37:55 | Araq | 4) it's almost never more than a single space at the end of the line |
| 19:39:05 | apotheon | What's a faster way to do "$bElC" in vi? |
| 19:39:37 | apotheon | (faster == fewer keypresses) |
| 19:40:43 | apotheon | ":s/\s\+$/" is obviously longer |
| 19:42:39 | Araq | bbl |
| 19:44:09 | apotheon | I was confused for a moment there, thinking "That doesn't do anything *like* $bElC!" until I realized Araq was just saying he'd be back later. |
| 19:59:55 | * | Araq_bnc joined #nimrod |
| 20:48:54 | NimBot | nimrod-code/Aporia fce15e7 Dominik Picheta [+0 ±3 -0]: Improved user feedback regarding single instance mode. |
| 20:48:54 | NimBot | nimrod-code/Aporia 69ab1a5 Dominik Picheta [+0 ±3 -0]: Fixed bug in findTab and updated Nimrod's language definition. |
| 21:23:01 | Araq | q66: I read that x+y where x, y are for instance unboxed int64 does allocate on the GC heap |
| 21:23:07 | Araq | in luajit |
| 21:23:11 | Araq | is that correct? |
| 21:23:24 | q66 | i don't know |
| 21:24:09 | Araq | well the FFI guide says something like that |
| 21:25:30 | Araq | I'm evaluating luajit for nimrod's REPL again ... as interfacing via libFFI is getting very time consuming |
| 21:35:08 | q66 | Araq, you mean this? |
| 21:35:12 | q66 | 64 bit integer arithmetic: the standard arithmetic operators (+ - * / % ^ and unary minus) can be applied to two cdata numbers, or a cdata number and a Lua number. If one of them is an uint64_t, the other side is converted to an uint64_t and an unsigned arithmetic operation is performed. Otherwise both sides are converted to an int64_t and a signed arithmetic operation is performed. The result is a boxed 64 bit cdata object. |
| 21:35:46 | Araq | q66: yep |
| 21:36:10 | q66 | Araq, look what section it is in |
| 21:36:13 | q66 | arithmetic on cdata object |
| 21:36:21 | q66 | a number is not a cdata object |
| 21:36:27 | Araq | I know |
| 21:36:39 | Araq | er, a Lua number is not a cdata object |
| 21:37:00 | Araq | but I intend to use luajit mostly for unboxed operations as Nimrod doesn't require boxing |
| 21:37:27 | Araq | I plan to misuse it as a great JIT with excellent C interop |
| 21:37:59 | Araq | so most generated code will operate on cdata, not on Lua's native data structures |
| 21:39:00 | q66 | Araq, just trying stuff, it doesn't seem like the result of the operation is a different object. |
| 21:45:12 | Araq | so luajit optimizes that away? |
| 22:08:41 | * | gradha joined #nimrod |
| 22:18:34 | Araq | hi gradha |
| 22:18:39 | gradha | hi |
| 22:18:47 | Araq | I know about the closure bug that you triggered |
| 22:18:56 | Araq | but do have a small test program that triggers it? |
| 22:19:11 | Araq | that should definitely help |
| 22:19:35 | gradha | wasn't a chunk of it in the pastebin? |
| 22:20:22 | Araq | let me take a look again |
| 22:20:33 | gradha | do you mean http://pastebin.com/1nrWZKJU ? |
| 22:21:29 | Araq | oh hrm |
| 22:21:37 | Araq | that's a new bug |
| 22:21:48 | Araq | the error is weird thoug, isn't it? |
| 22:22:12 | gradha | that comes from parallelBuild |
| 22:22:42 | Araq | well please make a bug report |
| 22:22:49 | Araq | I'll take a look later |
| 22:22:57 | gradha | is https://github.com/Araq/Nimrod/issues/297 this closure bug you mean? |
| 22:23:21 | Araq | no that's another new one ;-) |
| 22:23:28 | gradha | meh, lucky me |
| 22:23:29 | Araq | the closure bug is not yet reported I think |
| 22:24:12 | gradha | btw, I'm trying "each(oneList, `$`)" but doesn't compile with "Error: '$' cannot be passed to a procvar" |
| 22:24:17 | gradha | what's the correct syntax for what I mean? |
| 22:24:57 | Araq | each(oneList, proc toString(x: dunno): string = $x) I guess |
| 22:25:51 | gradha | is `$` special and therefore not a normal proc? |
| 22:26:17 | Araq | no in fact, only procs marked with .procvar. are first class |
| 22:26:33 | Araq | read the reasons for that in the manual |
| 22:26:43 | Araq | and post on the forum if you disagree with them |
| 22:27:17 | gradha | "The procvar pragma is used to mark a proc that it can be passed to a procedural variable." |
| 22:27:28 | gradha | that's certainly concise |
| 22:27:40 | gradha | I'm going to meditate over that |
| 22:27:54 | Araq | or you could try and find the passage that I meant :P |
| 22:29:34 | gradha | I'll meditate then over "The rules' purpose is to prevent the case that extending a non-procvar procedure with default parameters breaks client code" |
| 22:30:14 | Araq | what's not to understand about that? |
| 22:31:14 | Araq | htmlparser.parseHtml (just an example!) may get an additional parameter with a default value |
| 22:31:31 | Araq | so code that used parseHtml continues to work |
| 22:32:06 | Araq | but ugh, it doesn't because some brainiac could have assigned it to 'var x = parseHtml' |
| 22:32:35 | Araq | and relied on the fact that the signature PStream -> PXmlNode is cast in stone |
| 22:33:11 | Araq | so ... what can you do? you can't ever introduce a new parameter with a default value |
| 22:33:17 | Araq | but you have to use overloading instead |
| 22:33:29 | Araq | IMO this sucks |
| 22:34:00 | gradha | the problem is "var x = parseHtml" doesn't get the default parameters? |
| 22:34:22 | Araq | the type of 'x' will change |
| 22:34:55 | Araq | if you do: 'var x: proc (x: PStream): PXmlNode = parseHtml' |
| 22:35:08 | Araq | is wouldn't compile anymore |
| 22:35:21 | Araq | it's rude to rely on the signature to never ever change |
| 22:35:42 | Araq | so procs that promise stability need to be marked with 'procvar' |
| 22:36:34 | Araq | and default parameters are only one example btw; the proc may also be turned into a template for instance |
| 22:36:35 | gradha | what default parameters are you planning to add to `$`? |
| 22:37:38 | Araq | well a `$`(x: datatype, bufferSize: int): string could be introduced |
| 22:38:01 | Araq | but $ would be nice for system.each I agree |
| 22:38:31 | gradha | let's say I have proc(a: int): int |
| 22:38:50 | gradha | now, instead of adding a default parameter to it, can I add another one named proc(a, b: int): int? |
| 22:39:09 | gradha | with 'b' being a new default parameter |
| 22:39:48 | Araq | yes |
| 22:41:02 | gradha | I'll meditate on your concept of politeness |
| 22:41:05 | * | fowl joined #nimrod |
| 22:41:19 | Araq | for the built-in operators there is indeed an implementation problem |
| 22:42:14 | Araq | as often there is no machine code that would represent the proc, but this can be solved in the compiler |
| 22:44:37 | gradha | the problems with new default parameters you have described, don't they apply to a proc using aparameter of type varargs[string, `$`]? |
| 22:46:20 | Araq | no |