| 00:06:20 | * | q66 quit (Remote host closed the connection) |
| 00:51:20 | fowl | Araq: heres an example of how it would work, in ruby with metaprogramming https://gist.github.com/fowlmouth/5439848 |
| 01:29:26 | OrionPK | Araq: is that new constructor syntax in the last stable? |
| 01:56:31 | fowl | OrionPK: not in 0.9.0 |
| 01:57:06 | fowl | most people run from HEAD |
| 02:31:50 | * | fowl quit (Read error: Connection reset by peer) |
| 03:41:58 | * | fowl joined #nimrod |
| 03:42:03 | * | Madison left #nimrod ("Leaving") |
| 04:37:45 | * | OrionPK quit (Quit: Leaving) |
| 05:25:29 | * | Trix[a]r_za is now known as Trixar_za |
| 06:57:32 | * | Trixar_za is now known as Trix[a]r_za |
| 07:18:53 | * | fowl quit (Ping timeout: 240 seconds) |
| 07:19:20 | * | fowl joined #nimrod |
| 07:57:46 | * | xcombelle joined #nimrod |
| 11:44:10 | * | q66 joined #nimrod |
| 11:44:56 | NimBot | Araq/Nimrod 2c8fe3e Araq [+0 ±2 -0]: fixes #395 |
| 15:06:47 | dom96 | hi |
| 15:07:44 | Araq | hi dom96 |
| 15:10:37 | dom96 | sup? |
| 15:12:46 | Araq | not much, I'm fixing bugs |
| 15:18:07 | dom96 | great |
| 15:19:52 | NimBot | Araq/Nimrod defe341 Araq [+1 ±0 -1]: added distinct array test |
| 15:19:52 | NimBot | Araq/Nimrod 7aa2b3e Araq [+0 ±1 -0]: fixes #394 |
| 15:30:41 | * | xcombelle_ joined #nimrod |
| 15:32:15 | NimBot | Araq/Nimrod ce9809c Araq [+0 ±1 -0]: fixes #393; now works with backticks |
| 15:33:21 | * | xcombelle quit (Ping timeout: 245 seconds) |
| 16:36:36 | fowl | love nimrod |
| 16:36:49 | fowl | love that bugs are always getting fixed |
| 16:37:00 | fowl | and I love the attention to detail |
| 16:42:57 | Araq | fowl: thank you :-) |
| 16:43:07 | Araq | tested the new parser? ;-) |
| 16:43:26 | fowl | nah ill try it now |
| 16:48:22 | reactormonk | Araq, what does it offer? |
| 16:49:02 | Araq | reactormonk: come on, I told you twice already |
| 16:49:18 | Araq | it fixes the 'do' parsing bug for a start |
| 16:49:43 | Araq | and I think it uses a much cleaner approach to indentation parsing |
| 16:50:06 | reactormonk | Araq, yeah, I got the indentation part |
| 16:54:23 | Araq | well ... it has to parse nimrod so there are not many new things |
| 16:54:43 | Araq | we could allow things like: |
| 16:54:55 | Araq | echo "ha" |
| 16:55:00 | Araq | & "hu" |
| 16:55:17 | reactormonk | that's where tabs vs. spaces comes in... |
| 16:55:27 | reactormonk | ehh, tabs n spaces |
| 16:55:41 | fowl | Araq: new parser runs on all the code i tried |
| 16:55:53 | Araq | fowl: yay :-) |
| 16:56:04 | fowl | you said that it should be easy to add a new grammar, how would I go about doing that |
| 16:58:04 | Araq | hmm I don't know if the mechanism still works, fowl, but it's in compiler/syntaxes.nim |
| 16:58:30 | Araq | the idea is that the first line of a file can contain a #! overriding the default parser |
| 17:00:01 | fowl | cool thanks |
| 17:01:07 | Araq | skimming the code it might still work :-) |
| 17:01:42 | Araq | you need to register your parser and add it to the 'case' statement dispatchers |
| 17:01:56 | Araq | but I think only syntaxes.nim needs to be edited |
| 17:02:27 | Araq | reactormonk: what tabs n spaces to do with it? |
| 17:22:30 | reactormonk | Araq, in a tab-based indentation env, that would be a space. |
| 17:23:13 | Araq | yeah great, "make" for the win |
| 17:23:20 | dom96 | Araq: Should this really work? https://gist.github.com/dom96/c5a9dd77092410748bfc |
| 17:23:25 | dom96 | because it does. |
| 17:24:05 | Araq | ugh |
| 17:24:23 | Araq | it shouldn't |
| 17:24:43 | Araq | does it work with the old parser? |
| 17:24:59 | * | dom96 checks |
| 17:29:21 | dom96 | It doesn't work with the old parser. |
| 17:41:36 | * | benedek joined #nimrod |
| 17:43:23 | * | gradha joined #nimrod |
| 17:44:45 | fowl | dom96: here's what i was trying to accomplish (in ruby though) https://gist.github.com/fowlmouth/5439848 |
| 17:44:46 | reactormonk | dom96brokeit |
| 17:46:49 | dom96 | Araq: Also the old parser doesn't require you to indent the body of the proc. |
| 17:47:06 | dom96 | Araq: It does require the body of that if statement to be indented though. |
| 17:47:49 | Araq | dom96: yeah the old parser has its bugs too :-/ |
| 17:48:14 | Araq | however I already fixed it for the new parser :P |
| 17:49:13 | dom96 | hrm, I like zahary's idea: https://github.com/Araq/Nimrod/issues/393#issuecomment-16866410 |
| 17:50:03 | fowl | i like that |
| 17:50:11 | fowl | ill help with the macros/templates if you need |
| 17:51:01 | Araq | meh, NIH |
| 17:51:27 | Araq | sure it's nice, but what does the 'html' macro actually do? |
| 17:51:54 | Araq | does it produce a proc that can be called? does it produce a string literal? |
| 17:52:10 | Araq | the later doesn't work unforutnately then: |
| 17:52:17 | Araq | const myhtml = html: |
| 17:52:20 | Araq | ... |
| 17:53:29 | dom96 | fowl: if only I could understand Ruby better... |
| 17:53:51 | reactormonk | dom96, just ask |
| 17:57:27 | fowl | dom96: in this design the components store the field they're accessed under and what methods they implement then that info is used when an entity type is created to generate dispatching methods |
| 17:58:57 | fowl | so if you have two components that need update() the entity's update() ends up looking like update(*args) field1.update self, *args; field2.update self, *args; end |
| 18:02:39 | dom96 | right |
| 18:03:02 | Araq | fowl: please go ahead and implement the html macro |
| 18:03:07 | Araq | however I think it should do: |
| 18:03:13 | Araq | html myConstName: ... |
| 18:03:27 | Araq | and produce a 'const myConstName = ...' |
| 18:03:56 | dom96 | what, why a const? |
| 18:04:02 | Araq | ugh |
| 18:04:11 | Araq | I dunno |
| 18:04:31 | dom96 | Wouldn't that make it pretty much useless since you will not be able to dynamically generate the html? |
| 18:04:41 | Araq | yeah ... good point lol |
| 18:05:09 | fowl | currently does it just produce strings? gotta admit i didnt even see this module before lol |
| 18:05:21 | fowl | shame because it looks 99% macros:/ |
| 18:06:15 | Araq | it produces pretty optimal string concatenation code though |
| 18:08:14 | fowl | i can throw macro_dsl.quoted2ident() into htmlgen and add a clause for infix '-' to fix gradha 's problem |
| 18:08:39 | fowl | oh there's already getIdent() |
| 18:09:08 | * | xcombelle_ quit (Ping timeout: 258 seconds) |
| 18:09:40 | Araq | I guess it should be: |
| 18:10:03 | Araq | html do (input: string) -> string: ... |
| 18:10:15 | Araq | but then I can't name the resulting proc ... lol |
| 18:10:34 | fowl | let generator = that |
| 18:11:30 | Araq | proc genHtml(input: string): string {.html.} ftw |
| 18:12:19 | Araq | ah and then I can use body and p like it were some macros that produce the html ... oh wait |
| 18:12:29 | Araq | that's what htmlgen actually already provides :P |
| 18:13:22 | dom96 | html varname: ? |
| 18:13:58 | fowl | I'm in favor of it returning a closure |
| 18:14:06 | Araq | and how do you pass input to a var, dom96? |
| 18:14:35 | dom96 | what input do you need to pass? |
| 18:14:54 | Araq | the Title of the webpage? I don't know |
| 18:15:15 | Araq | obviously it's pretty bad to have no parametrization |
| 18:15:22 | dom96 | That doesn't need to be passed to a var. |
| 18:15:32 | dom96 | html var, attr="blah"? |
| 18:15:32 | fowl | i'd say |
| 18:15:39 | fowl | let gen = html: ... |
| 18:15:57 | fowl | pass a tuple to html to use it as arguments if you want |
| 18:16:30 | dom96 | how about: |
| 18:16:37 | dom96 | html: generates a special object |
| 18:16:57 | dom96 | Then we can define operators which perform an action on that object. |
| 18:17:47 | dom96 | Perhaps something like this would then be possible: gen <- html: |
| 18:18:17 | Araq | yeah, lets do: obj.param = value; obj.param = value2; obj.generate() |
| 18:18:24 | fowl | eh i think thats beyond the scope of htmlgen |
| 18:18:32 | Araq | who wants generate(value, value2) anyway ... |
| 18:18:41 | Araq | stateful programming ftw |
| 18:19:12 | dom96 | huh? |
| 18:19:15 | fowl | you should be able to do a simple echo(p("sometext")) or use html() to generate a closure you can use later imo |
| 18:19:42 | Araq | well htmlgen is perfectly fine the way it is |
| 18:19:59 | Araq | an additional "html" macro could be added |
| 18:20:17 | Araq | but then we can't agree how to do that :P |
| 18:20:36 | dom96 | The reason we can't assign this html macro to a string is because it may contain side effects right? |
| 18:20:43 | fowl | whoever writes it first then? ;) |
| 18:21:08 | dom96 | (well if statements) |
| 18:21:21 | Araq | and 'html:' is not that needed, use a .tmpl file instead to get control flow within an html code section |
| 18:21:51 | Araq | dom96: I can't follow, what have side effect to do with it? |
| 18:22:17 | dom96 | i'm confused too :P |
| 18:22:28 | dom96 | why is this not possible: |
| 18:22:35 | dom96 | var resp = html: ... |
| 18:22:53 | fowl | dom96: because currently the body isnt used at all |
| 18:23:44 | dom96 | yeah, why I included the ellipsis... |
| 18:39:51 | gradha | does nimrod have the concept of static vars inside procs for runtime pseudo-globals? |
| 18:40:29 | Araq | gradha: {.global.} pragma should work for that |
| 18:42:37 | * | xcombelle_ joined #nimrod |
| 18:43:25 | * | xcombelle_ quit (Read error: Connection reset by peer) |
| 18:49:00 | benedek | Araq: Do you think it would be possible to make strings more of an array (or seq) subtype? I mean so that procecures working on arrays could also work on strings automatically. |
| 18:50:06 | gradha | benedek: if you want to process strings you may want to convert string to unicode TRunes, and store them in a seq anyway |
| 18:52:10 | benedek | Yeah, that's kind of the reason I'm asking |
| 18:53:51 | benedek | I see that there are some procedures in strutils and unicode, and they don't seem to be very consistent... |
| 18:54:30 | benedek | There's "toUpper", "align" and "editDistance", for example, working on strings, but there are no corresponding ones for TRune sequences. |
| 18:56:02 | Araq | that's because I never work with seq[TRune] |
| 18:56:14 | benedek | I think it might be a little bit more consistent if both UTF-8 and UTF-32 strings would be simple arrays/seqs of the respective characters, like in D... |
| 18:56:41 | Araq | Nimrod's strings are 0 terminated for C interop |
| 18:56:56 | benedek | Why can't that be done just for cstring objects? |
| 18:57:29 | Araq | because then converting to cstring would require a concatenation? |
| 18:58:01 | Araq | and then the other half of all programmers would complain about that ... |
| 18:58:41 | fowl | Araq: if the TRune is a wchar then the address of item 0 should work for *wchar right |
| 18:58:51 | fowl | in a seq[TRune] |
| 18:59:03 | benedek | If those people were worried about efficiency, they could stick to cstrings for their C-heavy code. |
| 19:00:17 | Araq | fowl: wchar is 16 bits on some OSes, so no |
| 19:00:51 | benedek | And even if there have to be many conversions, I can't imagine adding a single character would become a bottleneck... |
| 19:02:24 | benedek | I might be wrong about the efficiency, but I'm pretty sure consistent string types and thorough Unicode support are a big plus. |
| 19:05:54 | Araq | it's not adding a single character |
| 19:06:07 | Araq | you have to copy the whole string buffer to append 0 |
| 19:06:37 | Araq | otherwise you'd modify the old string but that's not safe to do in general |
| 19:06:44 | benedek | Oh right, forgot about that |
| 19:07:09 | benedek | But you could still do an in-place modification where it would be safe, right? |
| 19:07:45 | benedek | And doesn't adding a zero at the end in every situation have an overhead, too? |
| 19:08:14 | reactormonk | benedek, often you modify the string, doing a little more isn't as expensive. |
| 19:08:45 | reactormonk | Araq, and doesn't relying on \0 as string terminator in nimrod lead to unpredictable results given \0 inside a string? |
| 19:09:39 | Araq | you have to know which operation supports \0 inside strings |
| 19:10:08 | reactormonk | welcome to ugly bugs |
| 19:10:48 | Araq | 336 closed bugs |
| 19:11:02 | Araq | bugs that are about the \0 in strings: 0 |
| 19:11:45 | reactormonk | it's not a bug because it works as specified, and it's a bug in your code, not the nimrod compiler. And a possible security issue. |
| 19:12:01 | Araq | oh come on |
| 19:12:11 | Araq | as if people wouldn't report it anyway |
| 19:12:18 | benedek | You could still keep using cstring in most places for efficiency, but also have a cleaner string object... or do you think that would imply making duplicate functions for both types? |
| 19:12:20 | reactormonk | you have a point there |
| 19:12:38 | reactormonk | benedek, cstring == native string - say JS |
| 19:13:36 | reactormonk | benedek, do we wrap ICU in nimrod btw? |
| 19:14:23 | benedek | reactormonk: Sorry, what's ICU? |
| 19:14:30 | fowl | reactormonk: there are places where \0 is ok, streams for example no problem with it coming up there |
| 19:15:16 | Araq | you could also use seq[byte] for the low level stuff ... |
| 19:15:53 | reactormonk | benedek, http://site.icu-project.org/ |
| 19:17:03 | benedek | reactormonk: I don't know whether that's wrapped in Nimrod. |
| 19:17:17 | Araq | imho UTF-32 strings are an abomination, they take up 4x more memory and yet hardly solve anything |
| 19:17:27 | reactormonk | Araq, I think I brought this up already |
| 19:17:55 | Araq | the proper toUpper("ß") used to be "SS" in german |
| 19:18:18 | Araq | how does utf-32 solve anything here? |
| 19:18:27 | benedek | Araq: That's a good point. |
| 19:19:19 | benedek | Araq: Still, toUpper from the unicode package seems to have TRune as a return type... |
| 19:20:14 | reactormonk | Araq, python does that, ruby does not. |
| 19:20:36 | reactormonk | and according to the ICU webpage python uses it |
| 19:20:46 | Araq | benedek: yeah and I don't know what it does :-) |
| 19:20:55 | benedek | Araq: Aren't UTF-32 arrays more efficient to work with in some situations, where random access and such is needed? |
| 19:23:16 | Araq | that depends |
| 19:23:38 | reactormonk | Araq, are nimrod strings unicode-aware? |
| 19:23:43 | reactormonk | let's say UTF8-aware |
| 19:23:52 | Araq | for fast string searching "octets" are fine too, no need to convert to utf-32 just to skip over some characters |
| 19:24:47 | benedek | Araq: Of course, but for more involved operations I'd think it's justified in some cases to handle UTF-32. |
| 19:25:32 | Araq | reactormonk: for windows we convert to utf-8 from ansi for filenames etc. ... for Linux it's utf-8 everywhere anyway |
| 19:25:41 | Araq | not sure if that answers your question ;-) |
| 19:26:17 | Araq | it's not like most procs check it's valid utf-8 or something |
| 19:26:45 | benedek | The string functions in strutils don't appear to be unicode-aware, though. |
| 19:27:43 | Araq | toUpper's docs explicitly say it only handles a-z iirc |
| 19:28:34 | reactormonk | Araq, say does len() handle utf8 correctly |
| 19:28:51 | benedek | Maybe "align" and "editDistance" should mention that, too. |
| 19:28:58 | Araq | there is no such thing as "handling len correctly" |
| 19:28:59 | benedek | reactormonk: I think it doesn't |
| 19:29:17 | benedek | reactormonk: If you mean if it returns the "correct" unicode character count |
| 19:29:58 | Araq | len = number of bytes? or number of unicode character? or number of actually displayed characters? |
| 19:30:38 | reactormonk | Araq, python-style? unicode and string? |
| 19:30:54 | Araq | look, I did use Python, I really did |
| 19:31:00 | * | fowl quit (Ping timeout: 252 seconds) |
| 19:31:03 | Araq | Python's handling of unicode is crap |
| 19:31:13 | Araq | it tries to abstract over it |
| 19:31:17 | reactormonk | or ruby-style? add an encoding field to string? |
| 19:31:24 | Araq | however Unicode is too hard to abstact over |
| 19:32:14 | reactormonk | or use the typing and create a bunch of types, each one for its own encoding |
| 19:32:29 | Araq | yeah that would work |
| 19:32:38 | Araq | but then I only use utf-8 encoding anyway |
| 19:33:25 | reactormonk | then we have ascii (speed), utf8, binary? |
| 19:33:45 | reactormonk | The problem with 'binary' is that it may contain \0 |
| 19:33:48 | Araq | there is no difference between ascii and utf-8 and binary |
| 19:34:03 | Araq | ok binary could contain \0 but that's about it |
| 19:35:11 | reactormonk | you have bytesize == charsize in ascii |
| 19:35:26 | reactormonk | len == charsize with utf-8, len == bytesize in binary |
| 19:35:36 | Araq | len == bytesize in nimrod |
| 19:36:29 | reactormonk | so string is binary, subtype stuff and redefine string-only stuff like toUpper to only work on ascii/utf8 |
| 19:36:55 | reactormonk | Maybe add utf16 so I don't have to convert too much in JS ;-) |
| 19:37:23 | reactormonk | I'm fine with strings having \0, but imho you shouldn't be allowed to rely on it in nimrod code |
| 19:37:56 | Araq | why not deal with real problems instead? |
| 19:38:11 | gradha | anybody got any luck with nimrod serve? I can type commands but never get any reply |
| 19:38:13 | reactormonk | like #347? |
| 19:38:44 | Araq | like "nimrod serve" being broken yeah, or like #347 |
| 19:38:47 | reactormonk | gradha, see https://github.com/Araq/Nimrod/issues/345 |
| 19:39:06 | gradha | reactormonk: the first suggestion is because you are passing the command on the commandline, which works |
| 19:39:14 | gradha | you don't get any more answers because they never echo |
| 19:39:23 | gradha | if you start the server without parameters it stays there, silently, waiting |
| 19:39:26 | reactormonk | gradha, am I? |
| 19:39:46 | gradha | oh, that's two lines there? |
| 19:39:47 | reactormonk | gradha, that's a newline there |
| 19:39:57 | gradha | I don't get answer even for the first command |
| 19:40:27 | reactormonk | Araq, I'll pastie the IRC log here as issue |
| 19:40:45 | reactormonk | Araq, some of it that, is. |
| 19:40:50 | Araq | if it makes you happy ... |
| 19:41:26 | gradha | oh, so it answers if you pass the project file, but doesn't if you don't and pass it as command |
| 19:41:41 | gradha | yes, only first reply is echoed |
| 19:42:16 | gradha | could it be that the normal output closes stdout? the quit command still works, as well as parsing errors |
| 19:48:45 | Araq | benedek: I agree that editDistance should become a generic though |
| 19:49:42 | reactormonk | http://sprunge.us/LOeZ |
| 19:50:15 | * | fowl joined #nimrod |
| 19:51:57 | reactormonk | gradha, nope, it doesn't |
| 19:52:00 | gradha | it's not the echoing |
| 19:52:07 | gradha | I've done now another test |
| 19:52:27 | gradha | I've added a simple "echo you typed blah" in the server loop |
| 19:52:39 | gradha | the first time I run the idetools command it answers |
| 19:52:43 | reactormonk | I don't see any close call on the stdout |
| 19:52:51 | gradha | the second time, it doesn't answer, but the echo still goes |
| 19:53:04 | gradha | now the interesting part: if you start up the server and type the wrong command, it fails |
| 19:53:12 | gradha | for instance, start it up and type "idex" |
| 19:53:21 | gradha | it will say "invalid command" |
| 19:53:34 | reactormonk | aaand it quits |
| 19:53:36 | reactormonk | that's ugly |
| 19:53:47 | gradha | but if you type a "good" command, then "idex", it doesn't fail |
| 19:53:54 | reactormonk | nope, it doesn't react anymore |
| 19:53:56 | gradha | so it means it's not runnint the same code the second time |
| 19:54:04 | gradha | the echo in the runloop still works though |
| 19:54:07 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
| 19:58:28 | reactormonk | blub |
| 19:58:50 | Araq | https://github.com/Araq/Nimrod/issues/400 seriously? |
| 20:01:25 | reactormonk | hm? |
| 20:02:02 | Araq | well what is it you suggest? MOAR string types for the fun of it? |
| 20:02:17 | reactormonk | exactly. |
| 20:02:47 | Araq | we have runeLen and len already |
| 20:04:02 | Araq | and we do have unicode and encodings modules |
| 20:04:35 | Araq | admittedly string handling still requires you to use your brain |
| 20:05:28 | Araq | however, the "no brainer" string handling solutions somehow all got it wrong; C# and Java use utf-16 internally |
| 20:06:13 | reactormonk | encoding is not a no-brainer |
| 20:06:44 | Araq | huh? |
| 20:07:35 | reactormonk | Ruby uses no specific interally, people just tend to set it to utf8 |
| 20:08:00 | Araq | (this means broken surrogate handling everywhere for Java and c#) |
| 20:08:24 | reactormonk | Araq, let's just set it aside and fix other stuff first... |
| 20:08:31 | Araq | Nimrod's strings are utf-8 ... |
| 20:08:49 | Araq | unless you decide to store something else instead but then that's your problem |
| 20:09:14 | Araq | it's not the job of stdlib to check everywhere for broken utf-8 sequences |
| 20:09:37 | reactormonk | imho it is |
| 20:10:05 | fowl | dont penalize ascii lovers plz |
| 20:10:27 | Araq | it's more important to be efficient if correctness has become impossible to achieve :P |
| 20:19:24 | Araq | btw what do you do when the string is a concatenation of 2 different encodings? |
| 20:19:48 | Araq | you'd be suprised how many websites actually do this ;-) |
| 20:21:23 | * | fowl quit (Ping timeout: 258 seconds) |
| 20:41:02 | * | benedek quit (Quit: Leaving) |
| 20:52:13 | * | fowl joined #nimrod |
| 21:11:49 | NimBot | Araq/Nimrod c1de322 Araq [+0 ±1 -0]: new parser: diallow more things |
| 21:17:56 | reactormonk | Araq, some will work (e.g. ascii + utf8) some will throw an error (e.g. binary + anything) |
| 21:19:30 | Araq | reactormonk: I'm pretty sure that python's httpclient doesn't accept mixed encoding websites; it'll throw some nice unicode exception instead |
| 21:19:40 | Araq | thanks for that |
| 21:19:56 | reactormonk | Araq, mixed encoding websites? O.o? like? |
| 21:20:04 | Araq | the web is full of it |
| 21:20:29 | reactormonk | gimme one |
| 21:21:02 | Araq | can't remember :P |
| 21:21:19 | Araq | I'd need to dig through some logs for that |
| 21:22:30 | reactormonk | Araq, then you get a binary and have to sort out the mess yourself |
| 21:23:07 | Araq | indeed and that's what I always do anyway |
| 21:23:29 | reactormonk | how costly is a method vs. a proc? |
| 21:24:17 | reactormonk | argh, let's stop it. First issues first... |
| 21:24:42 | Araq | methods are quite slow currently but I hope we can get it do 5ns overhead |
| 21:24:55 | Araq | however, methods for strings suck |
| 21:26:55 | reactormonk | how would you handle if you don't know which encoding you get (e.g. FS)? in the type system? |
| 21:27:33 | Araq | how do you handle string comparisons for sorting? |
| 21:27:45 | Araq | by knowing the input language, that's how |
| 21:28:02 | Araq | turkish has special rules for I or something like that |
| 21:28:18 | reactormonk | locale != encoding, that's kinda orthogonal |
| 21:28:28 | reactormonk | it has some correlation |
| 21:29:18 | Araq | that's true |
| 21:29:27 | Araq | and the correlation is highly relevant |
| 21:29:37 | Araq | and it's a mistake to pretend it doesn't exist |
| 21:29:57 | reactormonk | so you say a turkish encoding implies turkish sorting? |
| 21:30:43 | Araq | I say you'd better ask the locale to determine how to sort |
| 21:31:22 | reactormonk | imo you should have the option to ask the locale how to sort |
| 21:31:43 | reactormonk | it's still a fucking mess... |
| 21:51:42 | * | Boscop quit (Read error: Connection reset by peer) |
| 21:52:13 | * | Boscop joined #nimrod |
| 22:15:20 | * | OrionPK joined #nimrod |
| 22:16:13 | Araq | reactormonk: that's why the stdlib doesn't deal with it |
| 22:24:57 | fowl | Araq: i dont like how `somefunc` doesnt call it |
| 22:25:07 | fowl | proc foo = |
| 22:25:09 | fowl | echo 42 |
| 22:25:11 | fowl | foo |
| 22:25:20 | fowl | ^ Error: value returned by statement has to be discarded |
| 22:26:30 | Araq | it's ambiguous to do otherwise |
| 22:29:48 | fowl | when would you use a function as a statement without calling it? its not useful |
| 22:31:23 | Araq | meh alright |
| 22:31:51 | Araq | once the stmt/expr unification is complete, I can tell you more ;-) |
| 22:32:03 | Araq | could turn out to be trivial to special case |
| 22:32:12 | Araq | could turn out to cause problems |
| 22:32:40 | fowl | can you see if it should be discardable but refers to a no-argument function |
| 22:33:18 | fowl | er should be discarded |
| 22:33:45 | Araq | yeah well, 'discardable' already has its problems |
| 22:33:49 | fowl | hmm but what if that function returns another function, should it be called? |
| 22:35:23 | OrionPK | fowl, re: yesterday, Im running 0.9.1 |
| 22:36:03 | OrionPK | dont have that new constructor syntax as far as I can tell |
| 22:36:18 | Araq | 0.9.1 has the new constructor syntax |
| 22:36:26 | Araq | if you mean git HEAD that is |
| 22:36:50 | Araq | there is no 0.9.1, it's a moving target, it's 0.9.2 when it's released |
| 22:36:58 | fowl | OrionPK: update and recompile |
| 22:37:08 | OrionPK | Araq, I mean latest as of last night |
| 22:37:11 | OrionPK | from git |
| 22:40:52 | fowl | OrionPK: the syntax is like this: type TFoo = object x: int ; var some = TFoo(x: 42) |
| 22:41:27 | OrionPK | Error: ')' expected |
| 22:41:38 | fowl | yea that wont work on one line |
| 22:41:48 | OrionPK | no, I didnt do that :P |
| 22:42:55 | fowl | can you paste it |
| 22:43:08 | OrionPK | type TFoo object |
| 22:43:08 | OrionPK | x: int |
| 22:43:08 | OrionPK | var some = TFoo(x: 42) |
| 22:43:20 | OrionPK | oop |
| 22:43:30 | OrionPK | type TFoo = object |
| 22:43:30 | OrionPK | x: int |
| 22:43:30 | OrionPK | var some = TFoo(x: 42) |
| 22:43:41 | dom96 | https://gist.github.com/dom96/1d3eb546b87ef5b27e4f |
| 22:43:43 | dom96 | Try that. |
| 22:44:25 | OrionPK | Error: ')' expected |
| 22:44:33 | OrionPK | I'm typing it the right way guys, i"m just doing something else wrong :P |
| 22:44:50 | dom96 | What line/char is that error on? |
| 22:45:17 | OrionPK | var some = TFoo(x: 42), on the : |
| 22:45:27 | dom96 | You're on the master branch right? |
| 22:46:00 | OrionPK | I assume so, since I just got latest and rebuilt |
| 22:46:04 | OrionPK | Nimrod Compiler Version 0.9.1 (2013-01-31) [Windows: i386] |
| 22:46:14 | fowl | thats from january |
| 22:46:21 | OrionPK | yeah, I see that |
| 22:46:25 | fowl | :p |
| 22:46:27 | OrionPK | I assume it just wasnt updated |
| 22:46:34 | dom96 | lol |
| 22:46:49 | OrionPK | what do you guys get when you run --version |
| 22:46:53 | fowl | OrionPK: nimbuild hasnt been ran in a while i guess |
| 22:47:14 | dom96 | Nimrod Compiler Version 0.9.1 (2013-04-23) [Linux: amd64] |
| 22:47:24 | Araq | speaking of which ... we still need a windows server for nimbuild |
| 22:47:27 | dom96 | fowl: What makes you think that? |
| 22:47:58 | fowl | dom96: the date on it is Aug 24 |
| 22:48:22 | fowl | for windows at least |
| 22:48:59 | dom96 | Yeah, for Windows: what you said is correct. |
| 22:50:17 | OrionPK | so, am I a 2nd class or 3rd class citizen? :P |
| 22:51:09 | OrionPK | nimrod.exe was built 4/23, but the version is from january |
| 22:51:19 | fowl | OrionPK: you said you just pulled from the repo and rebuilt, do you have another one on your PATH thats interfering? |
| 22:51:29 | Araq | OrionPK: you need to bootstrap |
| 22:51:31 | OrionPK | I uninstd |
| 22:51:36 | OrionPK | .9.0 |
| 22:51:41 | Araq | compiling the C sources is not enough |
| 22:52:07 | dom96 | yeah, you need to compile koch.nim and then execute `koch boot` |
| 22:54:09 | OrionPK | see, this is what happens when you dont read instructions |
| 22:54:39 | OrionPK | Nimrod Compiler Version 0.9.1 (2013-04-23) [Windows: i386] |
| 22:54:52 | OrionPK | thanks for being patient guys ;) |
| 22:55:14 | Araq | you're welcome; I hardly read anything either :P |
| 22:55:31 | OrionPK | haha |
| 22:56:00 | OrionPK | I'm terrible actually, it's only gotten worse. I always try to skip to the good stuff. Haven't read a "company-wide" email in over a year I think |
| 22:58:04 | fowl | lol |
| 23:33:53 | * | q66 quit (Remote host closed the connection) |