| 00:00:07 | EXetoC | I don't know what you mean by correct. is it an AST pattern that doesn't have a source code equivalent? |
| 00:01:03 | dom96 | ok, let's say I have an AST which is basically nnkCall("echo", nnkIdent("foobar")) |
| 00:01:13 | dom96 | That's the equivalent to: echo foobar |
| 00:01:17 | dom96 | well |
| 00:01:20 | dom96 | echo(foobar) |
| 00:01:37 | dom96 | And that code will cause a compile-time error because foobar is not defined |
| 00:01:47 | dom96 | You can generate an incorrect AST |
| 00:02:01 | dom96 | One which cannot be compiled. |
| 00:02:21 | EXetoC | I know that but it was discard as a block |
| 00:02:28 | dom96 | I'm using the word 'compiles' incorrectly above I think. |
| 00:02:33 | dom96 | I should be saying transforms. |
| 00:02:50 | dom96 | The macro transforms an AST (which is also incorrect, because 'await' is not defined) |
| 00:03:16 | dom96 | Well, you said that they both compile. |
| 00:03:24 | dom96 | And then you said that they don't if you put it in a module |
| 00:03:41 | dom96 | I'm not entirely sure what you meant by that |
| 00:04:05 | dom96 | I assumed that you thought that because echo result.toStrLit() worked that the code was compiled successfully. |
| 00:04:20 | dom96 | But that's not the case. |
| 00:04:55 | EXetoC | discard \n [indent] 1\n2\n3 |
| 00:05:08 | EXetoC | toStrLit(result) might not compiled but it did output such patterns |
| 00:05:28 | dom96 | Yes. toStrLit can return invalid Nimrod code. |
| 00:08:13 | EXetoC | maybe it's just constructed in a weird way, but that doesn't matter in the end |
| 00:08:39 | Skrylar | humm |
| 00:08:47 | Skrylar | dealing with jmp_buf is going to be interesting |
| 00:08:47 | EXetoC | nnkDiscardStmt with several nodes |
| 00:11:32 | * | noam__ joined #nimrod |
| 00:12:08 | Araq | good night |
| 00:12:13 | Skrylar | good night Araq |
| 00:15:19 | * | noam_ quit (Ping timeout: 276 seconds) |
| 00:20:48 | dom96 | same here |
| 00:20:50 | dom96 | 'night |
| 01:14:12 | milosn | hmmm |
| 01:14:47 | milosn | how should i prefix SQL strings with db_mysql? with db_sqlite its sql"SELECT ...;" |
| 01:14:58 | milosn | it dont work with db_mysql |
| 01:14:59 | milosn | :) |
| 01:16:43 | fowl | milosn, copy the sql func to db_mysql, looks like it was left out lol |
| 01:20:58 | milosn | hmmm |
| 01:21:14 | milosn | so much about tested code :P |
| 01:27:23 | Varriount | Meep |
| 01:31:40 | reactormonk | milosn, looks like no one likes mysql |
| 01:43:27 | milosn | ummm i used to dislike mysql ... than we had a requirement at work to scale to multi-master-cluster |
| 01:43:57 | milosn | galera+mysql is the only open source solution that can do it and its been relatively proven in real world scenarios |
| 01:44:25 | milosn | or should i say ... galera+mariadb |
| 01:45:19 | milosn | it breaks almost every 2nd week, and our DB admin gets SMS at 3AM ... but oh well, at least he is sure about his job |
| 01:45:22 | milosn | :D |
| 01:46:37 | milosn | fowl: ive added it, works fine now |
| 01:46:40 | milosn | thanks |
| 01:47:54 | fowl | milosn, do a PR too |
| 01:51:11 | milosn | https://github.com/Araq/Nimrod/issues/1176 |
| 01:51:17 | milosn | there you go, have fun :) |
| 01:51:34 | * | Demos_ joined #nimrod |
| 01:53:12 | milosn | fowl: while you are there ... can nimrod do python style getattr() and setattr() on objects? |
| 01:53:31 | milosn | i presume not, but dont hurt to ask |
| 01:54:23 | fowl | no |
| 01:54:39 | * | Demos quit (Ping timeout: 245 seconds) |
| 02:07:58 | reactormonk | milosn, what do you intend to do with it? |
| 02:08:31 | Varriount | milosn: You could probably do something with a macro. |
| 02:09:00 | Varriount | If you want python-like properties, nimrod has those though. |
| 02:24:06 | njoejoe | i really wish echo 14.123 would echo just that instead of scientific notation. I see formatFloat, but how do I figure out what precision to use? i want the same precision as number of numbers to the right of the decimal place. |
| 02:26:29 | Varriount | njoejoe: I think there's a PR that aims to fix that. |
| 02:26:57 | Varriount | It may or may have not been merged recently. |
| 02:29:50 | reactormonk | njoejoe, https://github.com/Araq/Nimrod/pull/1130 |
| 02:31:09 | reactormonk | Varriount, can you test the PR and see if it doesn't break anything too big? |
| 02:31:51 | NimBot | Araq/Nimrod float_ bebdeb2 Simon Hafner [+2 ±16 -0]: Merge branch 'devel' into float_$ |
| 02:31:51 | NimBot | Araq/Nimrod float_ 634852e Simon Hafner [+0 ±2 -0]: Merge branch 'float_$' into devel |
| 02:31:58 | Varriount | -_- |
| 02:32:24 | NimBot | Araq/Nimrod float_ bebdeb2 Simon Hafner [+2 ±16 -0]: Merge branch 'devel' into float_$ |
| 02:32:24 | NimBot | Araq/Nimrod float_ 634852e Simon Hafner [+0 ±2 -0]: Merge branch 'float_$' into devel |
| 02:32:29 | reactormonk | ah whatever |
| 02:32:51 | Varriount | Now nimbot will do the work for us, and we can compare test results. |
| 02:32:58 | reactormonk | exactly |
| 02:33:09 | reactormonk | I wanted to push it as float_$_test |
| 02:33:23 | Varriount | (Though, one day Nimbot should test PR's like the fancy BuildBot software does) |
| 02:33:59 | reactormonk | yeah, how do you connect them? |
| 02:34:20 | Varriount | Connect what? The PR's? |
| 02:35:07 | njoejoe | this is all greek to me |
| 02:35:31 | Varriount | njoejoe: PR = Pull Request |
| 02:36:09 | Varriount | We have build bots that run tests when things are committed to the main nimrod repository. |
| 02:41:03 | njoejoe | ah |
| 02:41:33 | Demos_ | speaking of, I should submit the (one line) change to turn on error printing inside typeclasses |
| 02:42:03 | Demos_ | I dont know how araq feels about "messy" PRs though, that is ones that have a bunch of small, unrelated changes |
| 02:42:30 | Skrylar | is it that hard to use git to cut multiple small stuff in to a big stuff |
| 02:42:45 | Skrylar | i've used rebase and whatnot before to cut out a sequence of changes back in to a logical order |
| 02:42:58 | Skrylar | (assuming people know how to do that before making requests) |
| 02:43:07 | Varriount | My GUI frontend lets me select specific lines to commit. |
| 02:43:40 | Demos_ | I know how to select stuff to commit, but I dont know how to move specific commits from one branch to another |
| 02:44:12 | Demos_ | I am sure I could google it but I think I will wait till next week since I am on the road right now |
| 02:44:19 | Varriount | How can I tell if a pointer address is on a DWORD boundary? |
| 02:44:36 | Varriount | Eg, a 32 bit int boundary. |
| 02:44:47 | Demos_ | mod it by 32? |
| 02:44:58 | Varriount | That's what I thought. |
| 02:53:41 | Varriount | This is probably another stupid question, but how does one do pointer arithmatic in Nimrod? Just cast a pointer to an int and do arithmatic that way? |
| 02:55:19 | * | q66 quit (Quit: Leaving) |
| 02:55:35 | NimBot | Araq/Nimrod float_$ 03ffc34 Grzegorz Adam Hankiewicz [+0 ±3 -0]: Version switch displays options used during `koch boot` |
| 02:55:35 | NimBot | Araq/Nimrod float_$ a822d0b EXetoC [+1 ±0 -0]: Add spawn test. Hangs most of the time on linux x64 at least. |
| 02:55:35 | NimBot | Araq/Nimrod float_$ c0338ea Varriount [+0 ±3 -0]: Merge pull request #1118 from gradha/pr_show_boot_options... 2 more lines |
| 02:55:35 | NimBot | Araq/Nimrod float_$ 9ea55bf Dominik Picheta [+0 ±3 -0]: Website updates. |
| 02:55:35 | NimBot | 16 more commits. |
| 02:56:00 | reactormonk | Varriount, well, there's the unbounded array |
| 02:56:11 | reactormonk | Varriount, but if you want to do some more math, yup, cast to ptr. |
| 02:56:38 | Varriount | reactormonk: Eh.. Are you sure you pulled/commit things correctly? |
| 03:01:24 | reactormonk | Varriount, yeah, somewhat of |
| 03:02:52 | Varriount | reactormonk: Be sure of things before you commit to devel. |
| 03:11:49 | Varriount | Ok, why does this always report that it isn't aligned? -> https://gist.github.com/Varriount/b35bb90a650ce03de235 |
| 03:12:24 | Varriount | I need a dword aligned block of memory whose size can be specified at run time. >_< |
| 03:18:30 | reactormonk | Varriount, didn't commit stuff to devel |
| 03:18:44 | reactormonk | ... I hope |
| 03:19:25 | Varriount | reactormonk: I meant that as a warning. As in, before you commit that to devel, make sure it doesn't eat babies and cause rampant destruction. |
| 03:22:01 | reactormonk | nah, it should possess babies and make them wreck their homes |
| 03:34:03 | * | Demos_ quit (Ping timeout: 252 seconds) |
| 03:39:46 | Varriount | Anyone know if 'memove', when moving overlapping sections of memory, deallocates the non-overlapped part of the original piece of memory? |
| 04:22:54 | Varriount | dom96: The asyncdispatch is going to need some way to support outside extension and such. For example, it currently derefs the overlapped structure tied to a callback, regardless of whether the callback should be dereferenced. |
| 04:40:13 | fowl | Error: internal error: (filename: compiler/sem.nim, line: 143) |
| 04:40:14 | fowl | :< |
| 04:40:41 | * | Varriount pats fowl on the back |
| 04:52:07 | reactormonk | fowl, what are you messing with? |
| 04:53:32 | Skrylar | huh |
| 04:53:40 | Skrylar | i imported unsigned, yet it says system./ doesn't work on uints |
| 04:54:19 | Varriount | Hm. Should I buy a .kiwi domain name? |
| 04:56:09 | fowl | reactormonk, some nasty stuff. when this line is not commented it causes that error: https://gist.github.com/fowlmouth/d926a6df3036d7ea1c74#file-p3-nim-L125 |
| 05:08:12 | Skrylar | hrm |
| 05:13:51 | fowl | .. i fixed it by using a template |
| 05:28:09 | Varriount | Why did the template fix it? |
| 05:50:47 | * | DAddYE joined #nimrod |
| 05:55:06 | njoejoe | "commify" numbers routine: https://gist.github.com/jots/11511274 I'm sure that is not the right nimrod way of doing things, so critique welcome... |
| 06:04:04 | reactormonk | njoejoe, you want to format floats? |
| 06:04:16 | reactormonk | I think sprintf + locale does that for you |
| 06:05:30 | njoejoe | I did not know that, will have to look into it |
| 06:12:27 | Skrylar | i figured out the division issue :| |
| 06:44:01 | * | Skrylar quit () |
| 06:54:10 | * | slacko15949 joined #nimrod |
| 07:25:53 | * | slacko15949 quit (Ping timeout: 250 seconds) |
| 07:26:37 | * | slacko15949 joined #nimrod |
| 08:00:35 | * | Kelet quit (Ping timeout: 258 seconds) |
| 08:03:06 | * | Kelet joined #nimrod |
| 08:07:03 | * | slacko15949 quit (Quit: Leaving) |
| 08:11:11 | * | musicalchair quit (Ping timeout: 255 seconds) |
| 08:12:35 | * | musicalchair joined #nimrod |
| 08:22:37 | * | Puffin is now known as BitPuffin |
| 08:28:04 | * | wan quit (Quit: leaving) |
| 08:37:52 | * | Skrylar joined #nimrod |
| 08:39:37 | * | skyfex joined #nimrod |
| 09:16:48 | * | wan_ joined #nimrod |
| 09:17:51 | Araq | milosn: nimrod can do getattr and setattr via its RTTI module |
| 09:18:02 | Araq | seems nobody knows about this ... :P |
| 09:18:02 | * | wan_ is now known as wan |
| 09:22:32 | * | Jehan_ joined #nimrod |
| 09:23:20 | * | wan quit (Quit: leaving) |
| 09:25:45 | * | wan joined #nimrod |
| 09:44:18 | Skrylar | I kinda want something like pivotal tracker but not webbased :( |
| 09:52:20 | milosn | Araq: morning |
| 09:52:32 | milosn | cool, where is RTTI module its not in the list |
| 09:52:33 | milosn | ? |
| 09:53:23 | Skrylar | i think thats 'types.nim' |
| 09:55:40 | Araq | no |
| 09:56:22 | Araq | typeinfo.nim |
| 09:59:08 | Araq | bbl |
| 10:13:31 | * | wan quit (Quit: leaving) |
| 10:14:53 | * | skyfex quit (Ping timeout: 250 seconds) |
| 10:23:32 | * | wan joined #nimrod |
| 10:41:00 | Skrylar | aand the hand massaging of libpng is over |
| 10:41:04 | Skrylar | gif is next ._. |
| 10:42:54 | Araq | Skrylar: if it is not in babel, it doesn't exist |
| 10:43:05 | Araq | keep that in mind ;-) |
| 10:45:11 | Skrylar | pff, these aren't bricks anyway :P |
| 10:45:29 | Skrylar | the actual load/save library is what they're for |
| 10:47:51 | Skrylar | also i'm somewhat deliberately uncomfortable with package management at the moment, since i haven't finalized APIs yet |
| 10:53:53 | Skrylar | Araq: that said we still have to do something about the skUnicode chunks |
| 10:54:05 | Skrylar | i have notes around here somewhere i was supposed to bug you sometime about the formatting |
| 10:54:42 | Araq | reactormonk: JNull == JNull surely should produce 'true'. Screw "SQL logic" |
| 10:58:03 | Araq | Skrylar: so bug me now |
| 11:21:16 | EXetoC | some logic |
| 11:21:58 | dom96 | we're on top of HN guys |
| 11:27:04 | EXetoC | dom96: is a "discard block" created by accident? and then later transformed of course |
| 11:28:48 | * | q66 joined #nimrod |
| 11:28:48 | * | q66 quit (Changing host) |
| 11:28:49 | * | q66 joined #nimrod |
| 11:30:31 | dom96 | EXetoC: not sure what you mean, elaborate please |
| 11:31:43 | EXetoC | dom96: I'm referring to what we talked about yesterday, where asyncdispatch temporarily generates a discard statement with multiple children |
| 11:33:41 | dom96 | EXetoC: The reason you get a discard block is because if you remove the discard specific createVar then you are left with the code at the end of processBody |
| 11:33:53 | dom96 | Which will iterate over all the children of that nnkDiscardStmt |
| 11:34:16 | dom96 | Thus only transforming the children and resulting in a discard block |
| 11:45:45 | EXetoC | if simplicitly is the reason then I'd use some dummy ident node, but ok now I know |
| 11:45:50 | EXetoC | onwards, to important stuff! |
| 11:50:03 | EXetoC | do you ever use getAst? it does allow you to construct ASTs in more literal way |
| 11:51:08 | EXetoC | I started using it after seeing it in action in unittest.nim |
| 11:53:48 | EXetoC | ok now I found the right HN article. I noticed that the other one was published 1219 days ago |
| 11:53:57 | dom96 | lol |
| 11:54:00 | dom96 | we're on reddit too |
| 11:58:50 | EXetoC | that guy is right. the name will make sure that no one will ever write nimrod code for money |
| 12:02:04 | Jehan_ | No American, you mean. :) |
| 12:03:42 | Jehan_ | Well, Araq can always rename the language to Artemis. :) |
| 12:05:29 | Jehan_ | Or he can claim that he just wanted to jump on the bandwagon of Git's popularity. :) |
| 12:06:47 | EXetoC | someone made a point about git in that thread |
| 12:07:00 | Jehan_ | What thread? |
| 12:09:02 | EXetoC | http://www.reddit.com/r/programming/comments/24ok6c/nimrod_for_c_programmers/ |
| 12:10:48 | Jehan_ | Ah. I don't read Reddit. |
| 12:11:06 | * | q66_ joined #nimrod |
| 12:11:20 | * | q66_ quit (Changing host) |
| 12:11:20 | * | q66_ joined #nimrod |
| 12:11:27 | * | q66 quit (Disconnected by services) |
| 12:11:36 | * | q66_ is now known as q66 |
| 12:12:02 | dom96 | oh look, now people are complaining about unsigned being in a seperate module |
| 12:12:30 | Jehan_ | From the discussion yesterday, it's more that unsigned support is somewhat incomplete. |
| 12:12:56 | Jehan_ | E.g., var x: uint; x += 1 doesn't work. |
| 12:13:03 | Jehan_ | Even with "import unsigned" |
| 12:13:31 | Jehan_ | I do think a lot of "this should be the default" depends on what application domain people are writing for. |
| 12:14:13 | dom96 | I wonder why `+=` just isn't a template for .inc |
| 12:14:53 | Jehan_ | inc doesn't work for unsigned types, either. |
| 12:15:00 | dom96 | true |
| 12:15:31 | Jehan_ | It wouldn't be hard to add the relevant code to unsigned.nim, it's just that someone would have to do it. :) |
| 12:15:47 | Jehan_ | Maybe I will, in my ample *cough* spare time. |
| 12:16:50 | Jehan_ | But I have more important things to do first, alas. |
| 12:32:45 | EXetoC | it does work, but not for uint64 |
| 12:38:41 | Skrylar | i don't really agree with unsigned hate |
| 12:39:50 | Skrylar | i've only seen a scant few arguments against unsigned from technical grounds, mostly being that ignorant people use it and then get surprised that 5 - 6 is four billion |
| 12:45:03 | Skrylar | EXetoC: does your gl module support 2.x and 3.x? |
| 12:46:07 | EXetoC | Skrylar: up to the latest version |
| 12:47:12 | Skrylar | those are two incompatible versions |
| 12:48:14 | Skrylar | EXetoC: anyway, where is it and i'll look at it later |
| 12:48:30 | EXetoC | there aren't any symbol conflicts or anything, so it doesn't matter |
| 12:49:33 | Skrylar | i don't have very much text stuff left over to do, so i'll have to work on the mid-level GL stuffs |
| 12:49:59 | EXetoC | Skrylar: the package is called opengl, and the repository is here https://github.com/nimrod-code/opengl.git |
| 12:50:21 | Skrylar | EXetoC: starred |
| 12:50:59 | Skrylar | huh |
| 12:51:09 | Skrylar | those are some strange importc's |
| 12:51:54 | EXetoC | there's no readme, but I think people should get used to generating the docs. perhaps it can be automated by babel |
| 12:52:06 | EXetoC | I'll add it either way |
| 12:52:32 | EXetoC | Skrylar: they're just dummies. I wasn't able to omit them |
| 12:53:49 | Skrylar | i'll peer more at it later, though i think linking to gl32 doesn't provide much more than the 1.1 apis on windows |
| 12:54:13 | Skrylar | IIRC SDL and GLFW have their own "x_get_gl_function" type of API for loading |
| 12:54:22 | EXetoC | see loadExtensions |
| 12:54:33 | Skrylar | not extensions |
| 12:54:39 | Skrylar | the core is supposed to be loaded in silly ways too |
| 12:55:52 | EXetoC | I don't know if it's specifically for extensions. either way, I've never heard about such complaints, so I guess it works somehow |
| 12:56:27 | Skrylar | i'll have to check some time i'm not sleepy |
| 12:56:42 | Skrylar | i remember the derelict apis for D loading the whole of opengl through the wgl-bleh commands |
| 12:56:43 | EXetoC | ok |
| 12:58:21 | Skrylar | huh. the libgif headers look sensible |
| 13:02:52 | * | darkf quit (Quit: Leaving) |
| 13:04:56 | Skrylar | textures are going to be weird |
| 13:06:36 | Skrylar | so far i was thinking of having texture objects with a non-managed pointer internally, which gets freed on a mix of finalizer/refcount |
| 13:07:21 | Skrylar | mostly so you could say "load this texture for me", then immediately get a usable handle, and let other threads load the image in proper |
| 13:23:05 | EXetoC | pointer? what other than the handle will you be storing? |
| 13:24:27 | EXetoC | the reference count probably :p |
| 13:31:19 | EXetoC | I wonder how fast texture deletions are. pretty fast I'd assume |
| 13:33:59 | EXetoC | a lot of people mention ADA. has it stood the test of time? |
| 13:35:43 | Jehan_ | Ada? In what way? |
| 13:35:56 | Jehan_ | It is a better language than some that people use in its stead. :) |
| 13:36:16 | Jehan_ | I think what scares a lot of people off is the verbosity. |
| 13:36:48 | EXetoC | symbol lookup seems pretty verbose, while other things seem fairly concise |
| 13:39:25 | Jehan_ | But let's just say that Ada had generics back in 1983 while more "modern" languages still struggle with the very concept. |
| 13:49:23 | * | closures999 joined #nimrod |
| 13:49:38 | * | closures999 quit () |
| 13:56:55 | * | tymat joined #nimrod |
| 13:57:13 | tymat | lib/nimrod/system.nim(1746, 41) Error: invalid pragma: noStackFrame |
| 13:57:23 | tymat | getting that trying to compile a simple program |
| 13:58:54 | EXetoC | lib/compiler mismatch? |
| 13:58:58 | Jehan_ | Huh. That's an odd path, too. |
| 13:59:15 | milosn | db_mysql's getRow() is broken :D |
| 13:59:20 | * | milosn trying to fix it |
| 13:59:33 | EXetoC | I don't know if it's noStackFrame that was renamed to asmNoStackFrame, but what I said seems plausible either way |
| 14:00:00 | EXetoC | make sure to bootstrap again if you've pulled |
| 14:00:13 | Jehan_ | The current version of system.nim doesn't use noStackFrame at all? |
| 14:00:31 | Jehan_ | Unless I've forgotten how grep works. :) |
| 14:00:49 | EXetoC | no. it's just mentioned once in a comment |
| 14:02:04 | EXetoC | and in a couple of text documents. I should fix that |
| 14:12:26 | EXetoC | reactormonk: did you create the float branch and then merge with master after? |
| 14:22:05 | EXetoC | tymat: *nick highlight* |
| 14:32:22 | milosn | hmm looks like db_mysql cant handle NULLs |
| 14:36:03 | * | brechtm joined #nimrod |
| 14:36:52 | milosn | db_mysql.nim(134) getRow |
| 14:36:53 | milosn | SIGSEGV: Illegal storage access. (Attempt to read from nil?) |
| 14:37:00 | brechtm | hello |
| 14:37:08 | EXetoC | hola |
| 14:37:26 | milosn | can someone enlighten me :), why is reading nil from what i think is a sequance a problem? |
| 14:37:29 | EXetoC | milosn: what's nil? |
| 14:37:35 | EXetoC | hm |
| 14:37:36 | milosn | that field in DB is NULL |
| 14:37:49 | milosn | i assume, mysql.nim converts it to nil |
| 14:38:27 | milosn | its 8th field in the resultset, ive run the query in mysql prompt, and its value is NULL |
| 14:38:37 | milosn | obviosly db_mysql/mysql dont like it |
| 14:39:11 | brechtm | Araq: could it be the "typedef struct a a" code in cparse.nim was copied from the "typedef enum a a" code where it perhaps does make sense? |
| 14:39:36 | milosn | EXetoC: exact line is probably wrong, ive already made change to db_mysql to fix something else |
| 14:39:43 | milosn | line is: add(result[i], row[i]) |
| 14:40:02 | milosn | row[i] is nil, i think ... and thats where it barfs |
| 14:40:29 | * | Skrylar quit (Ping timeout: 245 seconds) |
| 14:44:59 | EXetoC | you could check if it's that |
| 14:46:18 | milosn | how? :) |
| 14:46:22 | milosn | i am new to nimrod |
| 14:46:55 | brechtm | milosn: isNil(), IIRC |
| 14:47:34 | milosn | brechtm: so i should do isNil(row[i])? |
| 14:47:44 | milosn | isnt that gonna trigger the error anyway? |
| 14:48:15 | brechtm | milosn: well, if it is nil, you'll have to handle that case of course |
| 14:48:22 | EXetoC | I usually just compare with nil. anyway, I don't know how to debug this. fetchRow is some mysql function |
| 14:48:36 | EXetoC | and L might or might not return the correct length |
| 14:48:54 | milosn | EXetoC: yeah, its all from mysql wrapper ... i dont understand a thing in it |
| 14:49:04 | milosn | L is correct, its 13 |
| 14:49:19 | milosn | checked in mysql prompt for that sql query i am running |
| 14:49:46 | milosn | and it barfs on 8 ... first field thats NULL |
| 14:50:49 | milosn | let me try to use rows() function ... and try to execute same query |
| 14:50:55 | milosn | it has slightly different impl |
| 14:50:56 | brechtm | milosn: I would expect an SQL NULL to be mapped to a nil indeed... so you'll need to handle that case |
| 14:51:14 | milosn | but if it barfs on nil, than it got the same problem |
| 14:51:38 | brechtm | I'm missing some context here... are you running an existing example that should work or? |
| 14:52:03 | EXetoC | the prompt barfs on it too? |
| 14:53:22 | milosn | brechtm: nope, i am just playing around with mysql ... trying to run some simple queries using rows(), fastRows(), getRow() etc. |
| 14:54:13 | milosn | db_mysql.nim(153) getAllRows |
| 14:54:14 | milosn | SIGSEGV: Illegal storage access. (Attempt to read from nil?) |
| 14:54:25 | milosn | yup same problem, i think db_mysql cant handle NULL |
| 14:54:26 | milosn | :D |
| 14:54:45 | milosn | so much for DB wrapper :P |
| 14:54:46 | milosn | :D |
| 14:56:04 | milosn | EXetoC: mysql prompt? of course not ... it just shows that the 8th field in the result row is NULL :) |
| 14:56:50 | brechtm | milosn: so it also fails on fetching the row? |
| 14:56:55 | milosn | yup |
| 14:57:05 | brechtm | milosn: that sounds like a bug indeed |
| 14:57:23 | EXetoC | these are uncaught bugs of course. nil-checking might be necessary in multiple locations |
| 14:57:35 | EXetoC | maybe it tries to copy the strings, which won't work in this case |
| 14:57:59 | * | zahary quit (Ping timeout: 252 seconds) |
| 14:58:35 | EXetoC | but maybe it should work, because "" might be an ambiguous value |
| 14:58:52 | brechtm | the mysql wrapper must to more than just wrap the C API then, no? |
| 14:59:42 | EXetoC | yes. there's lib/wrapper/mysql.nim, and then there's lib/impure/db_mysql.nim which uses the other module |
| 15:00:05 | milosn | btw while you are at it ... if you have commit access ... https://github.com/Araq/Nimrod/issues/1176 |
| 15:00:08 | milosn | :) |
| 15:00:12 | milosn | i submitted that earlier |
| 15:03:09 | brechtm | milosn: what version of nimrod are you running? |
| 15:03:45 | brechtm | db_mysql.nim line 153 is getValue(), not getAllRow() here |
| 15:03:57 | milosn | Nimrod Compiler Version 0.9.4 (2014-04-21) [Linux: amd64] |
| 15:04:05 | milosn | brechtm: because i have made changes already |
| 15:04:17 | milosn | have a look at that issue link i pasted :) |
| 15:04:18 | brechtm | oh |
| 15:04:27 | milosn | ive just added a missing proc |
| 15:04:38 | milosn | didnt change any code logic anywhere |
| 15:04:59 | milosn | it looks like mysql support was just blindly coded, maybe with some quick tests |
| 15:05:03 | EXetoC | is result[i] nil? |
| 15:05:17 | milosn | i think row[i] is |
| 15:05:26 | milosn | let me try ... gimme a moment |
| 15:05:46 | EXetoC | no, it sets the length just above |
| 15:06:05 | EXetoC | so yeah, nil check might do the trick: if row[i] == nil: .. |
| 15:06:32 | EXetoC | isNil is often used though. apparently it's faster in some cases, but I don't know when |
| 15:07:29 | milosn | if i change the line to: |
| 15:07:29 | milosn | add(result[i], "") |
| 15:07:32 | milosn | it works |
| 15:08:05 | milosn | so row[i] is nil for i = 7, 8th fields in my result |
| 15:08:10 | * | zahary joined #nimrod |
| 15:08:25 | milosn | let me try to stick in a check and insert string "NULL" |
| 15:09:29 | milosn | yup that worked EXetoC |
| 15:10:11 | milosn | i can create some patches for db_mysql and fix this everywhere, just not sure you want string "NULL" to represent NULL value in DB |
| 15:10:15 | milosn | :) |
| 15:10:47 | milosn | so why cant 'nil' value be fetched out of row[i]? |
| 15:10:55 | EXetoC | probably not. it makes more sense to just let it remain nil though |
| 15:11:23 | milosn | ah, maybe getting row[i] is not the problem, its adding it to string ""? |
| 15:11:24 | * | tymat left #nimrod (#nimrod) |
| 15:11:30 | EXetoC | in which case maybe setLen should be omitted too, but you might have a better idea of what's the correct behavior |
| 15:11:52 | EXetoC | milosn: appending nil does indeed cause a segfault. I'll ask if this is intended |
| 15:12:04 | brechtm | milosn: where is it doing that? |
| 15:12:20 | milosn | EXetoC: i understand now, where the problem was |
| 15:12:22 | milosn | ! |
| 15:13:21 | EXetoC | Araq: what's the correct behavior for add(string, nil)? neither add nor safeAdd handles this safely |
| 15:13:32 | milosn | EXetoC: 'nil' breaks 'echo' proc a well |
| 15:13:33 | milosn | heh |
| 15:14:12 | EXetoC | yeah |
| 15:14:13 | brechtm | EXetoC: well, I'm pretty sure it should fail, no? |
| 15:14:14 | milosn | as in i cant echo the result row with nil-s in it |
| 15:14:31 | brechtm | shouldn't just succeed silently |
| 15:15:10 | milosn | so is there a different between 'add(str1, str2)' and 'str1 & str2'? |
| 15:15:19 | milosn | in performance or anything else |
| 15:15:36 | brechtm | milosn: you could define: |
| 15:15:36 | milosn | s/deifferent/difference |
| 15:15:39 | brechtm | proc `$` (a: ptr): string = "NULL" |
| 15:15:56 | * | q66 quit (Ping timeout: 252 seconds) |
| 15:15:57 | brechtm | milosn: err, no, you need to check for nil first, of course |
| 15:16:28 | milosn | brechtm: i fixed the error with nil check before add() |
| 15:16:41 | milosn | and if its nil, i just assign nil to result[i] |
| 15:16:52 | brechtm | milosn: in fastRows? |
| 15:16:55 | milosn | ill have a look if i can fix whole module |
| 15:17:00 | milosn | in getRow() |
| 15:17:07 | milosn | ill check others if i get more time |
| 15:17:55 | EXetoC | just omit the call to setLen too then |
| 15:18:14 | milosn | because value is already ""? |
| 15:20:15 | milosn | i am actually trying to put together basic ORM :) |
| 15:20:39 | milosn | not sure nimrod language features would allow me to make what i have in mind, but unless i try ill never know |
| 15:21:26 | EXetoC | nevermind. just leave it in there |
| 15:21:45 | EXetoC | it can do a hell of a lot. if Nimrod won't be able to do what you have in mind, contact Araq immediately ;) |
| 15:21:45 | milosn | i have made myself something i call "DirtyORM" in python, for internal use ... its the ugliest but most usefull thing i ever made :D |
| 15:21:58 | milosn | so i wanna port that to nimrod |
| 15:21:59 | milosn | :) |
| 15:22:53 | milosn | ... something to play with on sunday afternoon anyway :P |
| 15:24:34 | milosn | EXetoC: i am not gonna patch up anything yet, please find out if add("", nil) should result in "" or nil if you can (in this context) |
| 15:25:01 | milosn | my logic is ... nil should be propageted to application code as representation of NULL value in the DB |
| 15:25:17 | milosn | but maybe who ever made db_* thinks different |
| 15:26:00 | milosn | maybe NULLs should be "" ... which is kinda strange |
| 15:26:00 | milosn | :D |
| 15:28:05 | * | q66 joined #nimrod |
| 15:28:05 | * | q66 quit (Changing host) |
| 15:28:05 | * | q66 joined #nimrod |
| 15:29:31 | milosn | actually it was easy to patch |
| 15:29:41 | milosn | only 3 places where it needs to be changes |
| 15:29:44 | milosn | *changed |
| 15:30:03 | milosn | let me play around a bit and i can post a patch to issue tracker |
| 15:30:29 | * | Jesin quit (Ping timeout: 245 seconds) |
| 15:31:26 | milosn | fastRows() works |
| 15:32:04 | milosn | rows() seems to work as well |
| 15:32:05 | milosn | ! |
| 15:32:20 | milosn | milos you are amasing. |
| 15:33:13 | OrionPK | hola |
| 15:35:08 | milosn | http://pastie.org/9139705 |
| 15:39:59 | milosn | hmm wonder how easy/hard would be to add support for "DictRow" ... where i can access fields like: row['my_column_name'] |
| 15:40:26 | brechtm | milosn: only one way to find out! |
| 15:42:17 | * | Matthias247 joined #nimrod |
| 15:46:26 | * | menscrem joined #nimrod |
| 15:48:39 | EXetoC | maybe you can wrap the row type in an object which defines those operators |
| 16:01:58 | * | untitaker quit (Ping timeout: 240 seconds) |
| 16:08:12 | * | untitaker joined #nimrod |
| 16:13:53 | EXetoC | Araq: or what about assert checks |
| 16:23:38 | * | brechtm quit (Ping timeout: 265 seconds) |
| 16:28:11 | * | HollyRain joined #nimrod |
| 16:28:24 | Araq | hi HollyRain welcome |
| 16:29:32 | HollyRain | I'm cururious about one thing, why do you think that to use a language based into a VM is not efficient? |
| 16:29:55 | HollyRain | see V8 or the Dart's VM which has better performance that V8's |
| 16:30:39 | renesac | HollyRain, it has to compile the code on the fly, and do it fast |
| 16:31:12 | renesac | this takes time, and the JIT can't use optimizations as advanced as an ahead of time compiler |
| 16:32:02 | renesac | and most languages that run on a VM need it because their dinamicity, and weren't projected for highest speed (dart is an exception) |
| 16:32:52 | renesac | nimrod runs on a VM (not a JIT) during compilation to evaluate macros and such |
| 16:33:14 | renesac | you can run it with 'nimrod i', but it is very limited ATM as it don't support FFI |
| 16:34:15 | HollyRain | renesac, very interesting, thx |
| 16:34:23 | Araq | HollyRain: also VMs tend to cause never ending problems when it comes to program distribution and installation |
| 16:35:05 | Jehan_ | Also, debugging a JIT compiler is much harder than one that produces binaries. |
| 16:36:43 | HollyRain | Araq, true, but the positive side is that it can be embedded in other programs, like v8 is being done |
| 16:36:59 | HollyRain | not only in the web browser |
| 16:38:58 | HollyRain | Araq, at the beginning, I though that you were a bot xD |
| 16:39:19 | HollyRain | "Nimrod produces small executables without dependencies" => does means that the compilation is static? |
| 16:39:37 | Araq | depends on what you understand by "static" |
| 16:40:04 | Araq | IMO it is static, but it doesn't like statically against libc |
| 16:40:12 | Araq | *link |
| 16:40:23 | Araq | (strange typo ...) |
| 16:40:58 | HollyRain | Araq, $ file "some_executable": ... statically linked ... |
| 16:42:45 | renesac | and nimrod compiles to Javascript (thought I don't know how well supported that target is) |
| 16:45:32 | Jehan_ | In practice, if you want to use JIT compilation, you want to use an established implementation rather than rolling your own. There are not many people in the world that can write a performance-competitive JIT compiler. |
| 16:46:17 | Jehan_ | And right now, most of them are being employed by Microsoft, Oracle, IBM, and Google. |
| 16:53:38 | Jehan_ | Araq: Is there an easy way to figure out if a type contains a ref, directly or indirectly? |
| 16:54:18 | Jehan_ | E.g. tuple[foo: int, bar: ref int] would be such a type. |
| 16:54:57 | Jehan_ | (This is to plug a potential memory leak in queues.) |
| 17:06:46 | * | milosn quit (Ping timeout: 240 seconds) |
| 17:08:45 | * | milosn joined #nimrod |
| 17:16:16 | * | olahol joined #nimrod |
| 17:16:56 | Araq | Jehan_: I don't think so, more typetraits are planned though |
| 17:17:23 | Jehan_ | Hmm, use "when T is ref:" as a stopgap solution then? |
| 17:17:37 | * | brechtm joined #nimrod |
| 17:17:56 | Araq | brechtm: typedef struct foo foo; is often also used for forward declarations |
| 17:18:03 | Araq | hence we remove it and hope for the best |
| 17:18:06 | Araq | ;-) |
| 17:18:30 | brechtm | Araq: I see |
| 17:18:32 | EXetoC | can fields be used recursively for this? |
| 17:21:46 | Araq | brechtm: but try to remove that special case, I think it's better to have duplicated definitions than none |
| 17:23:26 | brechtm | Araq: I did manage to get it to output "type structname* = object" eventually, but I'm not sure I'm doing the right thing |
| 17:23:46 | Araq | well make a PR and I'll tell you |
| 17:24:01 | brechtm | Araq: any docs on the ast stuff? |
| 17:24:26 | Araq | ast.nim is documented |
| 17:24:59 | brechtm | Araq: macros.html is perhaps also useful? |
| 17:25:05 | Araq | yep |
| 17:32:41 | OrionPK | araq hows that vm register issue looking |
| 17:35:28 | brechtm | Araq: astspec.txt is also still relevant? |
| 17:35:54 | Araq | brechtm: dunno, I think so |
| 17:36:04 | brechtm | nm, is the same as macros.txt |
| 17:36:07 | Araq | OrionPK: it's already the number 1 bug on my list |
| 17:36:30 | brechtm | or included in macros.txt in any case |
| 17:36:43 | OrionPK | araq alrighty |
| 17:37:47 | brechtm | ok, macros.nim then ... |
| 17:38:00 | * | brechtm will get the eventually |
| 17:38:10 | brechtm | *there |
| 17:38:16 | * | brechtm sighs |
| 17:39:01 | reactormonk | EXetoC, yes, no. |
| 17:39:52 | brechtm | should the comments in ast.nim show up in the html after "nimrod doc ast.nim"? |
| 17:40:23 | EXetoC | only if they are doc comments (##) |
| 17:40:36 | EXetoC | also, you might want to use doc2 instead |
| 17:41:09 | brechtm | EXetoC: what nim-file do I pass doc2? |
| 17:41:39 | brechtm | ah, it will generate docs for all imported modules? |
| 17:42:28 | EXetoC | maybe it does |
| 17:43:05 | * | HollyRain quit (Quit: bye, bye) |
| 17:43:06 | brechtm | doesn't seem to |
| 17:43:17 | Araq | they are not doc comments |
| 17:44:00 | brechtm | Araq: so I just read the nim file, no problem |
| 17:45:50 | Araq | Jehan_: the builtin 'reset' could also be used to fix the leak |
| 17:46:06 | Araq | 'reset' works on everything iirc |
| 17:46:15 | Jehan_ | Yeah, but that creates overhead for non-ref types. |
| 17:46:41 | Jehan_ | I knew that that was possible, I was wondering if it could be avoided. |
| 17:48:56 | Jehan_ | Incidentally, what will happen if/when strings/seqs get non-nil default values? |
| 17:49:48 | Araq | that wont happen |
| 17:50:23 | Jehan_ | Ah, okay. I thought you were considering it. |
| 17:50:44 | Araq | len and add will deal with nil instead |
| 17:51:47 | Jehan_ | Hmm, I hadn't considered that option. |
| 17:53:06 | Araq | that's what Delphi does |
| 17:53:35 | Araq | it conflates "" and nil even more though, there is no nil, only "" which is stored as nil |
| 17:54:10 | Jehan_ | Huh. |
| 17:54:44 | Jehan_ | Can't say I ever used Delphi/TP past the Windows 3.1 years. |
| 17:55:21 | * | zahary quit (Read error: Connection reset by peer) |
| 17:55:40 | * | zahary joined #nimrod |
| 18:04:21 | EXetoC | there doesn't seem to be any obvious ways of getting milliseconds passed since the epoch |
| 18:06:24 | EXetoC | except maybe epochTime() :p |
| 18:07:01 | EXetoC | but that's only for the current time |
| 18:08:09 | EXetoC | TTime.TTimeImpl.int64. there we go |
| 18:09:12 | EXetoC | no it's not exported. I think I'll have to patch it |
| 18:15:34 | * | dLog joined #nimrod |
| 18:16:21 | Araq | hi dLog welcome |
| 18:24:24 | reactormonk | milosn, give us a PR |
| 18:25:15 | milosn | reactormonk: aye? |
| 18:25:27 | milosn | https://github.com/Araq/Nimrod/issues/1176 |
| 18:25:29 | milosn | that? |
| 18:25:29 | EXetoC | there seems to exist little support for getting the time passed since the epoch in milliseconds, so I won't bother |
| 18:26:16 | milosn | reactormonk: check the patch link ... ive incorporated all tweaks i made in single patch |
| 18:27:35 | Araq | milosn: the other db_* modules indeed treat NULL as "" |
| 18:28:18 | Araq | it's only ambiguous for 'string' (nvarchar) and I'd argue that if your database model distinguishes between NULL and "" it's simply broken. |
| 18:28:44 | Araq | and you deserve using the low level wrappers instead |
| 18:29:33 | milosn | Araq: hmmmm you decide, if you wanna keep it consistent, convert nil-s to "" |
| 18:31:10 | milosn | Araq: i am trying to write an "active record" style ORM in nimrod ... ill tell you where NULL as "" breaks everything ... imagine you load row from the DB into your AR object and NULL-s get convrted to ""-s ... on next update you no longer have NULL-s in the DB |
| 18:31:32 | milosn | for varchar fields and friends, that holds true |
| 18:31:42 | milosn | so you got broken ISNULL() for example |
| 18:33:55 | brechtm | Araq: http://programmers.stackexchange.com/a/32582/25032 |
| 18:34:06 | Araq | good point, but the db_* modules are for convenience (and also quite old btw). The real problem is that they map everything to 'string' and don't know anything about SQL's datatypes |
| 18:35:06 | Araq | fixing 'NULL' is not nearly enough for an ORM, I think |
| 18:35:15 | milosn | Araq: everything as string is actually OK ... i can convert to nimrod types as i see fit :P |
| 18:35:29 | milosn | :) |
| 18:36:14 | milosn | mind you, doubt ill progress much in next few days, even weeks, i just dont know the basic language that well |
| 18:36:23 | milosn | so its a learning experience |
| 18:36:25 | milosn | :) |
| 18:37:30 | Araq | milosn: once 'nil' is acceptable for 'add' and 'len' we can indeed properly distinguish NULL from "" and patch the db_* modules |
| 18:37:58 | Araq | so ... go ahead please, an ORM is a welcome addition for Nimrod |
| 18:39:09 | Araq | brechtm: I know these arguments but IME nobody cares and you end up using ISNULL(x, '') <> '' everywhere |
| 18:39:57 | Araq | btw "" could also mean "we KNOW this person has no email address" and NULL "we don't know anything" |
| 18:41:27 | milosn | Araq: i doubt i can write nice and easy to use ORM based on db_mysql alone ... ill need to peak into low level mysql wrapper ... opened it up, dont understand a thing |
| 18:41:35 | milosn | but it can only get better :P |
| 18:41:46 | milosn | :) |
| 18:41:53 | brechtm | Araq: you mentioned clang2nim yesterday... will that obsolete cparse.nim? |
| 18:42:11 | Araq | brechtm: time will tell |
| 18:42:38 | Araq | clang2nim doesn't even exist yet, we have no idea how good it will work |
| 18:42:49 | brechtm | Araq: just wondering if I should go for quick-n-dirty or nice-and-slow :) |
| 18:43:15 | Araq | DAddYE is working on it, maybe he can comment when he's around |
| 18:44:30 | Araq | brechtm: from your link: "Unfortunately, Oracle confused the representation of VARCHAR string of length zero with the representation of NULL. They are both represented internally by a single byte with value zero. This makes the discussion just that much harder." .... ;-) |
| 18:45:48 | brechtm | Araq: I'm personally not much into databases, but it seems like the right thing to differentiate between NULL and "" |
| 18:49:46 | reactormonk | milosn, pull requests make it more streamlined than issues |
| 18:49:52 | EXetoC | Araq: and what should add(string, nil) do? |
| 18:50:06 | reactormonk | milosn, fork, push a branch, go to github |
| 18:50:35 | milosn | reactormonk: sorry about that, ill have a look at github workflow, cant be much different to bitbucket |
| 18:51:29 | Araq | EXetoC: append nothing. |
| 18:51:38 | milosn | reactormonk: i dont think this needs to be incorporated immidietly? as Araq said fix is to be made in add() ... and we need to decide on represenation of DB NULL in nimrod |
| 18:51:45 | EXetoC | milosn: there you have it ^ |
| 18:52:31 | brechtm | Araq: but only if nil is a string (ref?)? |
| 18:52:33 | EXetoC | so perform the nil check if you want, but I'll try to patch the string procs |
| 18:53:14 | milosn | EXetoC: yeah feel free, i can tell whats the correct expected behaviour of add(str, nil) :) |
| 18:53:27 | milosn | if you think it shouldnt break ... fix it please |
| 18:53:35 | milosn | s/can/cant |
| 18:56:36 | EXetoC | Araq: for add or safeAdd? |
| 18:56:56 | Araq | well I agree NULL should be mapped to 'nil', but the old way was not completely without its reasons |
| 18:57:19 | Araq | EXetoC: safeAdd should be deprecated |
| 18:57:50 | EXetoC | I know, but ok I'll patch add |
| 18:58:02 | EXetoC | milosn: dunno when I'm done, but I guess you have your local changes in place anyway |
| 18:58:15 | Araq | good luck, fowl tried and failed, EXetoC ;-) |
| 18:59:46 | EXetoC | really? ok |
| 19:00:29 | EXetoC | some posted this for babel-git "This pkg no longer depends on nimrod-git". so are you going to make sure that master can compile babel? |
| 19:00:56 | EXetoC | *someone |
| 19:02:12 | EXetoC | because we did discuss the significance of releases prior to 1.0 before, and I don't know whether or not what he said will remain true |
| 19:03:00 | fowl | EXetoC, it can probably be done but it requires moving stuff around in system.nim |
| 19:03:42 | Araq | fowl: probably? I bet I could do it :P |
| 19:04:07 | NimBot | Araq/Nimrod devel 79891b6 Reimer Behrends [+2 ±1 -0]: Added support for ref type hash tables.... 4 more lines |
| 19:04:07 | NimBot | Araq/Nimrod devel 93fed1f Andreas Rumpf [+2 ±1 -0]: Merge pull request #1177 from rbehrends/reftables... 2 more lines |
| 19:04:22 | fowl | Araq, you know what the cryptic that come up mean |
| 19:04:25 | fowl | cryptic errors* |
| 19:04:43 | EXetoC | dom96: thoughts? |
| 19:05:06 | EXetoC | maybe a release that compiles on master? but I don't know if you plan to break things soon |
| 19:06:00 | Araq | EXetoC: what do you mean? I thought Babel is part of the distribution already |
| 19:08:46 | EXetoC | Araq: as in the arch package babel-git |
| 19:08:51 | EXetoC | the official nimrod distribution? |
| 19:17:49 | * | nande joined #nimrod |
| 19:24:46 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 19:31:01 | * | Varriount|Mobile joined #nimrod |
| 19:32:42 | Varriount|Mobile | Anyone seen the latest Nimrod oriented reddit post? It's at https://github.com/Araq/Nimrod/wiki/Nimrod-for-C-programmers |
| 19:33:25 | Varriount|Mobile | Oh, and http://www.reddit.com/r/programming/comments/24ok6c/nimrod_for_c_programmers/ |
| 19:34:20 | Varriount|Mobile | If anyone sees skyfex, give her/him my congratulations. |
| 19:35:35 | Jehan_ | Varriount: Did you remove the comment that you had posted regarding my issue with 8-bit constants again? Asking because I'm seeing it only in my mailbox, but not on Github. |
| 19:51:48 | * | skyfex joined #nimrod |
| 19:52:17 | Araq | hi skyfex. congratulations from Varriount|Mobile |
| 19:52:53 | skyfex | :) |
| 19:54:24 | skyfex | Sucks though.. they stole my karma! ;) |
| 19:54:33 | Jehan_ | ??? |
| 19:54:49 | Jehan_ | I think I'm lost. :) |
| 19:54:56 | dom96 | skyfex: it's ok, you get infinite karma from us. |
| 19:55:18 | skyfex | dom96: Can I have it in the form of a meaningless number? :P |
| 19:55:36 | dom96 | EXetoC: Sure, change the dependency to 'nimrod'. |
| 19:55:43 | dom96 | EXetoC: we can always change it to nimrod-git later |
| 19:56:20 | dom96 | skyfex: ∞ |
| 19:56:25 | * | Varriount|Mobile quit (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )) |
| 19:56:36 | skyfex | dom96: Sweet! |
| 20:02:19 | Araq | dom96: EXetoC's patch for #1170 looks good to me |
| 20:02:31 | Araq | apply it whenever you feel like it |
| 20:03:37 | dom96 | oh yes, forgot about that |
| 20:03:53 | dom96 | skyfex: hehe, looks like you've been inspired to make lots of edits to your wiki article. |
| 20:04:09 | NimBot | Araq/Nimrod devel b1c865a EXetoC [+1 ±1 -0]: Fix #1170. |
| 20:04:09 | NimBot | Araq/Nimrod devel 88cb485 Dominik Picheta [+1 ±1 -0]: Merge pull request #1175 from EXetoC/await-discard... 2 more lines |
| 20:04:15 | dom96 | EXetoC: Thanks! |
| 20:04:38 | skyfex | dom96: Github annoys me, I've had to change the cheat-sheet table several times just because they've changed how they render markdown |
| 20:05:14 | skyfex | Having formatted code blocks in tables used to work, suddenly it just stopped working |
| 20:05:35 | skyfex | Now suddenly the page was narrower, so the third column became invisible |
| 20:05:55 | brechtm | skyfex: I know this isn't much help, but reStructuredText might be better in that area, since it has a spec |
| 20:06:22 | skyfex | brechtm: Thanks :) |
| 20:06:46 | dom96 | skyfex: Time to write a strongly worded letter to Github. |
| 20:06:59 | brechtm | AFAICR, GitHub supports rST |
| 20:17:33 | dom96 | Jehan_: Your answers on HN are awesome. Good job :) |
| 20:18:37 | Jehan_ | Umm, thank you, though most of them don't really have anything to do with Nimrod. :) |
| 20:20:28 | Araq | Jehan_: " # aborts at run: 44 on win32 with 3.2GB with out of memory" |
| 20:20:38 | Araq | that's not nice for our testers |
| 20:20:48 | Jehan_ | Oops. What did I do? |
| 20:20:49 | Araq | fortunately I already pulled it ... :-/ |
| 20:21:17 | Jehan_ | If it's the ptables tests, I just copied them from the ttables tests. |
| 20:21:32 | Jehan_ | If one of them blows up, so should the original ones. :( |
| 20:22:15 | Araq | it's table/ptables2.nim |
| 20:22:45 | Araq | oh I see |
| 20:22:53 | Araq | indeed it's simply a copy |
| 20:22:54 | Jehan_ | [behrends@Hilbert develop/nimrod]$ diff tests/table/?tables2.nim |
| 20:22:54 | Jehan_ | 8c8 |
| 20:22:54 | Jehan_ | < var tab = newTable[int,int]() |
| 20:22:54 | Jehan_ | --- |
| 20:22:54 | Jehan_ | > var tab = initTable[int,int]() |
| 20:23:15 | Araq | so it just ensures the leak is gone for good |
| 20:23:24 | Jehan_ | Heh. :) |
| 20:23:26 | dom96 | Yep, the VPS is swapping to death. yay. |
| 20:23:27 | Jehan_ | Phew. :) |
| 20:23:48 | Jehan_ | Well, assuming it is and I didn't break it indirectly? |
| 20:24:27 | Araq | this test is simply flawed |
| 20:24:43 | Jehan_ | But really, all the new code does is wrap TTables in a ref and do exactly what the original does. |
| 20:25:00 | Araq | dom96: please disable these for now |
| 20:25:10 | Jehan_ | By the way, I plan to fix collision behavior sometime this week (assuming I find the time). |
| 20:25:20 | Araq | we need to use the OSes API to check memory usage |
| 20:25:41 | Araq | but having a test breaking the test machines is not good |
| 20:26:05 | Jehan_ | Yeah, I saw the comment, but figured it was outdated. |
| 20:26:16 | Araq | Jehan_: do you know if this also will improve compile-times? |
| 20:26:34 | Jehan_ | Doubtful. Or at least not a lot. |
| 20:26:53 | Jehan_ | Right now, the hash tables do essentially an expensive form of linear probing. |
| 20:27:04 | dom96 | I think I will move the x86 builder to the gcc farm |
| 20:27:06 | Jehan_ | Since they don't use the perturb part of Python's algorithm. |
| 20:27:15 | Araq | lol good point |
| 20:27:24 | Jehan_ | But linear probing isn't all that bad most of the time. |
| 20:27:32 | Araq | yeah |
| 20:27:47 | Jehan_ | Changing that is more about fixing worst case performance than average performance. |
| 20:28:04 | Araq | that doesn't change the hash function, right? |
| 20:28:25 | Araq | cause changing that is not so easy |
| 20:28:28 | Jehan_ | And Nimrod's compilation is generally plenty fast unless I construct stuff that makes the compiler do extra work. |
| 20:28:49 | Araq | the compiler uses the hash function too for generating string cases |
| 20:28:49 | Jehan_ | The hash function would remain unchanged. |
| 20:29:07 | Araq | so the compiler and the stdlib need to agree on the hash function |
| 20:29:11 | Jehan_ | It would just be about resolving collisions differently. |
| 20:29:41 | Jehan_ | Oh, you mean case somestring? Yeah, I remember seeing that. |
| 20:29:57 | Jehan_ | But no, I'm not planning on touching that. |
| 20:30:48 | * | menscrem quit (Ping timeout: 240 seconds) |
| 20:31:00 | Jehan_ | My near future plans for additions to Nimrod are: GMP bindings, 128-bit ints, stacks, and better hash collision resolution. Any problems with any of that? |
| 20:32:17 | Jehan_ | Mind you, they're mostly based on personal needs, so I'm writing the code anyway, but since I'm doing it, I may as well contribute them to Nimrod. :0 |
| 20:32:35 | njoejoe | is there an incantation to allow multiple statements on one line with "var" like: var x:int; s:string; f:float i would find it handy. |
| 20:32:49 | EXetoC | Araq: hm, stack*trace* off? |
| 20:33:17 | dom96 | we're over 600 stargazers now :O |
| 20:33:57 | Jehan_ | njoejoe: I don't know of any. Would love to be able to do something like "let x = 1, y = 2" myself. |
| 20:34:00 | Araq | EXetoC: what do I know |
| 20:34:18 | Jehan_ | dom96: Stargazers? |
| 20:34:30 | dom96 | Jehan_: https://github.com/Araq/Nimrod/stargazers |
| 20:34:37 | Araq | formerly known as "watchers" |
| 20:35:03 | Jehan_ | Oh, I see. |
| 20:35:11 | EXetoC | Araq: it must be a push/pop? |
| 20:35:19 | Jehan_ | I don't use Github much, hence my ignorance. |
| 20:35:31 | Araq | EXetoC: it really should be, yes |
| 20:36:12 | njoejoe | i'm used to thinking of ";" as somewhat equivalent to a newline. and it helps in reducing "lines of code" ;-) |
| 20:36:36 | Araq | njoejoe: implement it, compiler/parser.nim |
| 20:36:46 | Jehan_ | Heh. :) |
| 20:37:03 | njoejoe | Araq: you crack me up :-) |
| 20:41:34 | EXetoC | Araq: that's just a comment though. you want me to include the word push in there? |
| 20:41:46 | EXetoC | in the change made to osproc anyway |
| 20:42:05 | Araq | I dont care |
| 20:43:58 | EXetoC | and no further changes to manual.txt? |
| 20:45:26 | Araq | if it doesn't use "noStackFrame" then no |
| 20:50:21 | Araq | Jehan_: what do you mean by "stacks"? |
| 20:51:01 | Varriount | Jehan_: Yes, I removed the comment. I accidentally missed reading your example, and thought you hadn't posted one. Luckily, I make it a point to double check. |
| 20:51:05 | Jehan_ | Stack data type. You know, push, pop, top, empty. |
| 20:51:37 | Jehan_ | Yes, overlaps with seq a lot, but unless I'm missing something, it's still cumbersome to do some basic operations. |
| 20:51:46 | Jehan_ | Mind you, it's entirely possible that I'm missing something. :) |
| 20:53:50 | Jehan_ | Or should the additional stuff go in sequtils? |
| 20:53:50 | Varriount | Jehan_: Doesn't a linked list make more sense? |
| 20:53:50 | Jehan_ | Varriount: linked lists have pretty bad memory locality. |
| 20:53:50 | Varriount | Also, me had someone in here a day or two ago, with some related changes. |
| 20:53:50 | Varriount | *we had |
| 20:53:50 | Araq | push = add, pop = pop, top = last, empty = len == 0 |
| 20:54:04 | Jehan_ | There's a last routine? |
| 20:54:13 | Araq | I'm not sure lol |
| 20:54:17 | Jehan_ | O…kay. I guess I've been missing the obvious. |
| 20:54:25 | Araq | I remember adding something like that |
| 20:55:08 | Jehan_ | Hmm, it's named something different then. |
| 20:55:27 | EXetoC | so someone made a comment about VLAs being very efficient. how often does it make sense to use one though? |
| 20:55:34 | Jehan_ | But yeah, foo[len(foo)-1] is a bit tedious. |
| 20:55:52 | Araq | foo[foo.high] |
| 20:55:56 | Araq | but sure |
| 20:56:07 | Varriount | Or foo(-1.. -1] |
| 20:56:16 | Jehan_ | Oh, right. Part of me is still stuck in other languages. |
| 20:56:37 | Araq | Varriount: but that returns a seq with 1 element |
| 20:56:48 | Jehan_ | EXetoC: Depends on the situation. |
| 20:56:58 | Jehan_ | The problem with VLAs is, well, the risk of overflowing the stack. |
| 20:57:24 | Jehan_ | Even if you don't actually overflow it, Linux tends to get unhappy if you alloca() a really large piece of memory at once. |
| 20:57:49 | Jehan_ | It then decides that it isn't proper stack-like behavior and throws a hissy fit, eh, a segmentation fault. |
| 20:59:21 | Jehan_ | If you don't need recursion, most of the time you can also keep a seq in a global or thread-local variable that you expand on demand. |
| 21:01:05 | Jehan_ | If you do need it in Nimrod, just use C's alloca() to return a ptr. |
| 21:06:40 | EXetoC | a better interface could be added, but it's not like every other programmers needs to do this |
| 21:07:48 | Araq | are you sure? some random guy on reddit thinks they are important |
| 21:08:09 | EXetoC | ok I take that back |
| 21:09:52 | Jehan_ | Umm. They can be situationally useful. A killer feature they're not (at least not IMO, YMMV, etc.). |
| 21:10:22 | Jehan_ | That said, alloca() support in the standard library would be nice for a system language. |
| 21:11:49 | Varriount | Variable length arrays would be nice.. |
| 21:12:25 | Jehan_ | The real problem is that for most non-trivial applications you want to cap the maximum size on those. |
| 21:12:49 | Jehan_ | At which point you can just use an array of that size. |
| 21:16:04 | fowl | are you talking about variable length array in struct |
| 21:17:30 | Jehan_ | No, they are local variables on the stack whose size depends on a function argument. |
| 21:18:05 | EXetoC | then it'd be enforced at compile-time if anything |
| 21:18:06 | Jehan_ | Honestly, they're primarily used in languages that don't have GC. |
| 21:18:20 | fowl | oh |
| 21:18:40 | fowl | Jehan_, sounds fun... good luck |
| 21:19:55 | * | keodameo joined #nimrod |
| 21:20:26 | * | keodameo quit (Client Quit) |
| 21:22:05 | Kelet | Has anyone made a REPL for nimrod? |
| 21:22:27 | * | Jehan_ quit (Quit: Leaving) |
| 21:23:21 | * | nande quit (Remote host closed the connection) |
| 21:23:40 | * | nande joined #nimrod |
| 21:23:44 | EXetoC | there's "nimrod i" and it's broken |
| 21:23:53 | Kelet | oh, that's a shame |
| 21:24:11 | brechtm | Kelet: but there's good news too |
| 21:24:27 | brechtm | Kelet: you arrived just in time to fix it! :) |
| 21:24:45 | Kelet | I don't really know how to code anything, I just read about coding |
| 21:25:10 | EXetoC | just do some shotgun coding until it works |
| 21:25:17 | Kelet | In D, the REPLs compile to shared libraries |
| 21:25:27 | Kelet | and then execute the code in shared libraries I guess |
| 21:25:31 | brechtm | Don't we all just copy and paste bits and pieces from the internet? |
| 21:25:56 | Kelet | http://drepl.dawg.eu/ |
| 21:26:02 | Kelet | Something like that for Nimrod would be nice |
| 21:26:13 | Kelet | I'll start coding it as soon as I learn to code |
| 21:26:23 | * | Jehan_ joined #nimrod |
| 21:26:32 | brechtm | I would love to try out D, but it doesn't have significant indentation |
| 21:26:40 | njoejoe | Kelet: you can use "nimrod i" for simple things. it breaks is if you import a library that uses "FFI" from what I understand... |
| 21:26:52 | brechtm | Kelet: those are one and the same... you'll only learn by doing it |
| 21:27:05 | dom96 | Kelet: That looks nice. |
| 21:27:08 | Kelet | brechtm: There are preprocessors that add it |
| 21:27:08 | Kelet | but |
| 21:27:13 | Kelet | i don't like preprocessors all that much |
| 21:27:15 | EXetoC | good luck starting by only reading about code |
| 21:27:24 | EXetoC | that's how I started out. didn't work |
| 21:27:32 | dom96 | Kelet: Are there any articles or anything describing how that repl works? |
| 21:27:46 | * | brechtm will never get to grips with the X clipboard(s) |
| 21:27:57 | Kelet | dom96: There are 3 REPLs for D, each work ok, and each compiled to a shared library. Let me try to find the usenet posts where it's described more in-depth. |
| 21:28:06 | fowl | brechtm, i love x clipboards |
| 21:28:12 | fowl | brechtm, i really miss them when i use windows |
| 21:28:13 | Kelet | compile entered code into shared libraries* |
| 21:28:30 | Kelet | s/usenet/mailing list/ |
| 21:28:44 | brechtm | fowl: we will never get along! :) |
| 21:29:14 | fowl | lol |
| 21:29:21 | Kelet | dom96: Some information here: http://forum.dlang.org/thread/[email protected] |
| 21:29:46 | brechtm | fowl: I copy something into one, then try to paste from another |
| 21:29:46 | Kelet | dom96: Also another D repl here, with some information in the main readme: https://github.com/callumenator/dabble |
| 21:30:00 | brechtm | fowl: so far, I've only discovered two, but I believe there are three? |
| 21:30:38 | fowl | brechtm, there are two clipboards, one is for ctrl+v/ctrl+c (though some GTK copies selection to this buffer, hexchat for example) and the selection buffer thats what you highlight then hit the middle mouse to paste |
| 21:30:38 | reactormonk | so you want a nimrod repl written in nimrod that can compile to javascript... |
| 21:30:39 | brechtm | can't seem to be able to guess a single correct D statement |
| 21:30:47 | njoejoe | brechtm: i was happy when i got my emacs kill buffer tied in with the clipboard. even works in terminal mode. forgot how the heck i did it though |
| 21:30:50 | Kelet | Apparently the approach was also used here: http://neugierig.org/software/c-repl/ |
| 21:30:57 | fowl | brechtm, yep there is a 3rd buffer but nobody uses it |
| 21:31:01 | brechtm | njoejoe: hehe |
| 21:31:12 | reactormonk | njoejoe, let me see... |
| 21:31:52 | brechtm | fowl: I absolutely love how the buffer is cleared when you close the application in which you made the selection, not |
| 21:31:55 | Jehan_ | On a practical note, I'm working on the current instability of the Nimrod REPL around by using a nimrun script. |
| 21:32:09 | Jehan_ | Combined with vim bindings. |
| 21:32:16 | fowl | brechtm, lol :D |
| 21:32:25 | Kelet | I just figured since nimrod has fairly decent compiler-as-a-library functionality it might have a nice REPL somewhere |
| 21:32:28 | reactormonk | njoejoe, I assume you can get something working with xclip |
| 21:32:41 | * | brechtm patiently waits for Haiku to become mainstream |
| 21:32:45 | Kelet | Ocaml has a really nice third-party REPL floating around, the name escapes me |
| 21:32:49 | fowl | Kelet, there is a GTK repl somewhere |
| 21:32:57 | fowl | Kelet, its called nimrepl.nim iirc |
| 21:33:10 | Kelet | interesting |
| 21:33:49 | njoejoe | reactormonk: i think it uses "xsel" |
| 21:33:54 | brechtm | D> write("hello") |
| 21:34:01 | brechtm | => hellvoid |
| 21:34:09 | brechtm | => hellovoid |
| 21:34:13 | brechtm | interesting |
| 21:34:13 | fowl | Kelet, https://github.com/Araq/Nimrod/blob/devel/tools/nimrepl.nim |
| 21:35:04 | njoejoe | reactormonk: this is what i followed: http://hugoheden.wordpress.com/2009/03/08/copypaste-with-emacs-in-terminal/ |
| 21:36:40 | dom96 | I think with symbol files creating a REPL which works this way is viable. |
| 21:37:41 | fowl | reactormonk, what is "SQL logic" |
| 21:37:46 | milosn | whats wrong with this table type: var my_table = initTable[string, [string, string]]() |
| 21:38:03 | milosn | its suppose to be table of tables, is this not how you define it? |
| 21:38:26 | Jehan_ | You need a TTable before the inner [ |
| 21:38:35 | milosn | ah |
| 21:38:38 | milosn | let me try |
| 21:38:42 | Jehan_ | Or whatever the inner table type is supposed to be. :) |
| 21:39:32 | Jehan_ | Just be aware that TTable has value semantics. |
| 21:39:47 | Jehan_ | If you assign it to a different variable, the entire table gets copied. |
| 21:41:14 | Kelet | Is there a way to use generics but enforce that the incoming type is a number? |
| 21:42:37 | fowl | Kelet, http://build.nimrod-lang.org/docs/manual.html#static- |
| 21:42:49 | Kelet | thanks |
| 21:42:55 | reactormonk | fowl, everything is != null |
| 21:43:41 | fowl | reactormonk, nil is different here, it doesnt denote the absense of a value, its a distinct value |
| 21:44:25 | fowl | reactormonk, also nil string == nil string, so |
| 21:46:14 | dom96 | Kelet: proc foo[T: TNumber](x: T) = ... # should work I think |
| 21:46:17 | Jehan_ | Kelet: http://build.nimrod-lang.org/docs/manual.html#type-classes |
| 21:46:35 | EXetoC | (system.TNumber) |
| 21:46:42 | Jehan_ | Type classes in Nimrod are confusingly something different from the Haskell kind. |
| 21:47:11 | dom96 | They are kind of similar. |
| 21:48:57 | reactormonk | fowl, hm. |
| 21:50:36 | reactormonk | fowl, ok, should do. |
| 21:51:01 | EXetoC | I think it makes more sense when there's a distinct null "type", but "not nil" will remedy this somewhat |
| 21:51:50 | EXetoC | but I wonder if we'll have to type "not nil" a whole lot |
| 21:52:41 | reactormonk | EXetoC, I think it should be default, and with an 'trying to access a non-inititalized object' error |
| 21:53:50 | EXetoC | was it not considered "too late"? |
| 21:55:17 | milosn | Jehan_: yeah that fixed that error ... but now when i try: cs_description[cname]["type"] = ctype |
| 21:55:23 | milosn | it says |
| 21:55:36 | milosn | Error: for a 'var' type a variable needs to be passed |
| 21:55:38 | milosn | hmmm |
| 21:56:11 | EXetoC | you need a var. it's as simple as that |
| 21:57:36 | Jehan_ | Try cs_description.mget(cname)["type"] = ctype. |
| 21:58:15 | EXetoC | you either need to replace 'let' with 'var', or just add 'var' in case of a parameter |
| 21:58:28 | EXetoC | yeah that does return a 'var' |
| 21:58:46 | Jehan_ | EXetoC: The problem is that cs_description[x] returns a TTable, which cannot be passed to []=. |
| 21:59:02 | Jehan_ | This is part of the reason why I submitted a patch for PTable earlier. :) |
| 21:59:25 | Jehan_ | Value types are terribly awkward for nested dictionaries. |
| 21:59:39 | dom96 | We're going to have a problem with TTable vs. PTable when we remove the prefixes. |
| 22:00:18 | Jehan_ | Yeah, same problem as anywhere else where T/P types are concerned. |
| 22:00:48 | Jehan_ | One will be the default implementation (say, Foo), the other will be FooObj or FooRef, I guess. |
| 22:02:12 | dom96 | Maybe we should just use the ref version everywhere? Are there drawbacks to that approach? |
| 22:02:41 | Jehan_ | Dunno. Araq tends to favor value types, and probably for a reason. |
| 22:03:06 | Jehan_ | One disadvantage to ref types is that they can be mutated even when not passed as a var parameter. |
| 22:04:33 | brechtm | if a param is not flagged as var, are the values copied? |
| 22:04:37 | EXetoC | so "ref Foo" causes problems? |
| 22:05:30 | Araq | I picked value types for consistency only |
| 22:05:36 | Jehan_ | brechtm: Small types get copied for non-var parameters, large types passed by reference (since they're effectively immutable). |
| 22:05:59 | Jehan_ | EXetoC: Not necessarily. It's what most languages do. |
| 22:06:21 | brechtm | would it be bad to make ref params const by default? |
| 22:06:22 | Jehan_ | Nimrod is just somewhat unusual in that it doesn't allow non-var parameters to be mutated. |
| 22:07:00 | Araq | actually I copied that feature from Ada ... |
| 22:07:15 | Jehan_ | Eiffel also has this (for value types). |
| 22:07:27 | Jehan_ | Didn't say it's unique, just somewhat unusual. |
| 22:07:30 | Kelet | https://github.com/Araq/Nimrod/wiki/Nimrod-for-C-programmers says C doesn't have generics but it does, doesn't it? |
| 22:07:43 | Jehan_ | C++ has generics. C doesn't. |
| 22:07:47 | Araq | yeah but I copied nothing from Eiffel :P |
| 22:07:58 | Kelet | c1x has _Generic |
| 22:08:00 | EXetoC | brechtm: const? you disallow mutation by omitting var. it doesn't do a whole lot though |
| 22:08:01 | Kelet | doesn't it? |
| 22:08:11 | Kelet | http://www.robertgamble.net/2012/01/c11-generic-selections.html |
| 22:08:28 | Kelet | oops, guess it's c11 now |
| 22:08:29 | brechtm | EXetoC: for ref types I meant |
| 22:08:34 | Araq | brechtm: yes, it would be bad because it would break every single line in the compiler |
| 22:08:53 | brechtm | Araq: any real reasons aside from that? ;) |
| 22:09:16 | Araq | dunno, I played with it and decided it sucks |
| 22:09:17 | brechtm | EXetoC: though it's possible to dereference the ref before passing, which gets you the same, I suppose |
| 22:09:39 | Jehan_ | It will take a few years until generics from C11 can actually be used portably. |
| 22:09:54 | Jehan_ | Especially if Microsoft decides to not play ball again. :( |
| 22:10:21 | Kelet | I thought Microsoft said no C99 support even, just use our C++ compiler for your C code |
| 22:10:24 | Kelet | afaik |
| 22:10:49 | reactormonk | EXetoC, as in backwards compability? |
| 22:10:50 | Jehan_ | Also, C11 generics are pretty cumbersome to use. |
| 22:10:52 | brechtm | Jehan_: large types are composite types I assume? |
| 22:11:02 | reactormonk | Araq, not-nil default too late? |
| 22:11:04 | Kelet | Yeah, but they're there, I think it would be dishonest not to mention them :) |
| 22:11:07 | * | Kelet shrugs |
| 22:11:14 | Jehan_ | You'll have to ask Araq, but from what I've seen, anything that's bigger than two machine words. |
| 22:11:32 | Araq | two floats iirc, but yes |
| 22:11:48 | Araq | and no, I haven't done any benchmarks |
| 22:12:06 | Araq | so if you know better, let me know |
| 22:12:07 | Jehan_ | Kelet: Has any compiler actually implemented them yet? |
| 22:12:32 | Araq | Kelet: C11 is academic. It doesn't exist. |
| 22:13:02 | Kelet | Jehan_: Araq: http://gcc.gnu.org/wiki/C11Status |
| 22:13:24 | Kelet | I think clang may be further along, but that's a fair amount of features, given many of them are optional. |
| 22:13:27 | Jehan_ | Also, as far as I recall, generics in C11 are actually a typecase statement. |
| 22:13:39 | Araq | why should Microsoft support C11? it doesn't support Posix either. |
| 22:13:45 | Jehan_ | Which is not quite the same. |
| 22:15:00 | Jehan_ | For what it's worth, the absence of generics in C was what drove me primarily to look into D and Nimrod (and a bunch of other languages). |
| 22:15:17 | Kelet | http://gustedt.wordpress.com/2012/10/14/c11-defects-c-threads-are-not-realizable-with-posix-threads/ |
| 22:15:21 | Kelet | An interesting read |
| 22:15:47 | Varriount | What drove me into Nimrod was type inference, lack of semicolons, and lack of braces. (I'm not ashamed, even if those are petty reasons) |
| 22:16:46 | Kelet | I don't really program much but I looked into Nimrod because I liked the Lua-like GC and ADA-like features, to be extremely general and inspecific :) |
| 22:17:11 | * | Jesin joined #nimrod |
| 22:17:30 | Jehan_ | Varriount: I enjoy those too (though I prefer an Eiffel-style syntax myself), but they or their absence were not dealmakers or dealbreakers. |
| 22:17:46 | brechtm | Varriount: same here... though I'm really starting to appreciate the "pragmatic" easy of interop with C now |
| 22:18:18 | Kelet | Lack of semicolons and braces kind of keep me away. Ideally, I prefer the Nimrod way but my eyes are untrained to read it nearly as fast. |
| 22:18:19 | brechtm | which might be very important for adoption |
| 22:18:23 | Jehan_ | I need a minimally expressive type system to do serious work. For my purposes, linking the Boehm GC to get GC is good enough. So, it's really the generics that were my biggest problem. |
| 22:18:47 | Varriount | Jehan_: I hear that you're good with low-level stuff. Can you veryify that my alligned allocation procedure is correct? https://gist.github.com/Varriount/335018e9f5d9ed177743 |
| 22:18:52 | Jehan_ | What I do enjoy is having actual bound and overflow checks. |
| 22:19:25 | brechtm | reminds me... what's the current stance on multiple inheritance support? |
| 22:19:31 | Jehan_ | Varriount: looks okay, just a bit inefficient. |
| 22:19:40 | Varriount | Jehan_: How could it be more efficient? |
| 22:19:52 | Jehan_ | You don't need a loop. |
| 22:21:04 | Varriount | Actually, that reminds me of a question. Does moveMem expect both pointer addresses to be already allocated? |
| 22:21:16 | Jehan_ | Also, may want to use and (alignment-1) if it's not constant rather than mod alignment. Though that will be dwarfed by the allocation call. |
| 22:21:33 | Araq | brechtm: MI is lots of work to implement so it won#t happen anytime soon |
| 22:21:56 | brechtm | Araq: but it's not something you want to avoid at all costs? |
| 22:22:00 | Araq | I'm not morally opposed to it though, I prefer MI over SI + interfaces |
| 22:22:15 | brechtm | great |
| 22:22:32 | Araq | SI + interfaces is stupid IME, how is having not 1 but 2 type hierarchies a good idea? |
| 22:22:52 | brechtm | I find myself using it MI a lot, but I'll have to investigate the alternatives in Nimrod |
| 22:22:57 | Varriount | Araq: Because Java does it! :3 |
| 22:23:17 | Jehan_ | brechtm: multiple dispatch and parametric polymorphism allow you to avoid a number of MI use cases. |
| 22:23:44 | Varriount | Jehan_: "and (alignment-1)"? where would I insert that? |
| 22:23:51 | brechtm | Jehan_: you happen to have an article with some examples illustrating that? |
| 22:23:51 | Jehan_ | And for what it's worth, I agree that SI+Interfaces is an awful hack. |
| 22:24:28 | Jehan_ | Varriount: x mod p == x and (p-1) if p is a power of 2. |
| 22:24:37 | Araq | I don't like inheritence at all, but IF you want/need it, I don't see how MI suddenly makes everything "too complex" |
| 22:24:38 | Jehan_ | Actually, you may want to use "and" anyway. |
| 22:24:56 | Jehan_ | That's because mod may give you something bad when applied to a negative number. |
| 22:25:18 | Jehan_ | And an address cast to an int often is. |
| 22:25:26 | Araq | Jehan_: I think we should fix that in fact |
| 22:25:27 | Jehan_ | Actually, let me write that up for you, Varriount. |
| 22:25:40 | Jehan_ | Araq: It's difficult to do that efficiently. |
| 22:25:53 | Jehan_ | Sather is the one language I recall that did it. |
| 22:26:10 | Araq | I thought it's only an 'if' that we have to add to 'mod' |
| 22:26:36 | Varriount | Jehan_: Thanks. I'm pretty new when it comes to low-level logic. I know a lot of the overall concepts, but don't have much experience. |
| 22:28:28 | Jehan_ | Kinda sorta: It's one branch if we know that the modulus is positive. |
| 22:28:35 | Jehan_ | Even so, one branch can hurt. |
| 22:29:00 | Jehan_ | Admittedly, branch prediction should handle it correctly for most sane cases ... |
| 22:29:16 | Jehan_ | Something that I'd definitely benchmark first. |
| 22:29:25 | Araq | Kelet: indeed interesting. But it proves my point :P |
| 22:29:42 | Araq | 'mod' is expensive already |
| 22:30:53 | brechtm | why do I get "Error: expression has no address" on getting the address for a proc arg? |
| 22:31:32 | Varriount | brechtm: Sounds like you're trying to take the address of an inline procedure result. |
| 22:33:06 | fowl | brechtm, thats nimrods semantics, arguments are const |
| 22:33:35 | fowl | brechtm, (though they may be passed by reference, you cant modify unless you make it var T |
| 22:33:46 | brechtm | fowl: but but it still has an address, no? |
| 22:34:33 | fowl | brechtm, you cant access it |
| 22:35:05 | brechtm | as in, not allowed |
| 22:36:06 | Kelet | Speaking as a huge Nimrod newb, would it be possible to have something like: |
| 22:37:12 | Kelet | var fx = toEquation("f(x) = x*2") |
| 22:37:23 | Kelet | and then fx(2) = 4? |
| 22:37:26 | Kelet | and so on |
| 22:37:51 | Jehan_ | Varriount: https://gist.github.com/rbehrends/ab31743265488801cf02 |
| 22:38:08 | Kelet | (I realize that might not exactly be the syntax, but on a higher level, is it possible?) |
| 22:38:21 | Jehan_ | Note that it returns a tuple, the first is the address you can deallocate, the second is where the aligned part starts. |
| 22:38:33 | Jehan_ | I also fixed it so that it actually allocates enough memory. |
| 22:39:04 | Jehan_ | Kelet: parseStmt and parseExpr in macros should in principle have what you need. |
| 22:39:15 | Jehan_ | As long as it's compile time stuff. |
| 22:39:42 | Varriount | Jehan_: Thanks! I actually realized that problem after I gist'd it, but only had an inkling on how to fix it. |
| 22:39:45 | Jehan_ | Araq: Yeah, but branch mispredictions can still hurt. Would prefer to benchmark that on a few architectures first. |
| 22:40:40 | Jehan_ | I have learned not to trust my intuitions with respect to modern CPUs. :) |
| 22:42:11 | dom96 | Kelet: I'm assuming you want to create your own parser for that which will transform that string into a procedure at compile-time? It is indeed possible. |
| 22:42:48 | Kelet | dom96: Yeah, pretty much. |
| 22:42:59 | Kelet | It's kind of important that is assignable to a variable so it must create anonymous proc |
| 22:43:06 | Kelet | but I suppose that's possible too. |
| 22:43:07 | Kelet | neat. |
| 22:43:08 | fowl | dom96, who wrote that macro that parses a string into a template |
| 22:43:25 | dom96 | fowl: OrionPK I think |
| 22:43:36 | Araq | fowl: OrionPK but it's broken due to a regression |
| 22:43:42 | Kelet | dom96: I was thinking about writing a small, meager, likely useless numerical analysis library to get my feet wet. |
| 22:43:48 | Kelet | And wanted to maybe hack on this first |
| 22:43:52 | fowl | oh :( |
| 22:43:55 | Kelet | so I don't have to make procs for everything |
| 22:45:34 | Varriount | Through the magic of macros! |
| 22:45:48 | Kelet | I suck at programming. I suck a lot more at metaprogramming. |
| 22:46:08 | Varriount | Kelet: Which is why you have to practice, in order to suck less. |
| 22:46:43 | fowl | Kelet, whats your experience with metaprogramming |
| 22:47:13 | EXetoC | import macros\ndumpTree:\n f(x) = x*2 |
| 22:47:27 | Kelet | fowl: In Ruby there are some neat things where you can define variables pragmatically and do things if a missing method was called. |
| 22:47:40 | EXetoC | make an equation solver! |
| 22:47:42 | Kelet | fowl: And in D there is some template metaprogramming stuff but I mostly ran away. |
| 22:47:50 | Kelet | I looked at C++'s Boost once |
| 22:47:56 | Varriount | Kelet: We have delegators for the missing-method thing |
| 22:48:00 | Kelet | and then I promptly turned off my computer and went to bed. |
| 22:48:21 | Varriount | With a migraine? |
| 22:48:32 | EXetoC | that's different in that you need about 10 times the amount of trial and error |
| 22:48:35 | Kelet | I don't even understand C++ error messages 95% of the time. |
| 22:49:05 | Kelet | I had a parallel and distributed computing course and we primarily used C++. |
| 22:49:12 | Kelet | I made my solutions in D and then ported them to C++ |
| 22:49:15 | Kelet | was easier that way |
| 22:49:24 | fowl | Kelet, nimrods macros are a bit different. the macros are functions that run at compile-time to build AST directly |
| 22:50:20 | Jehan_ | Araq: Hmm, a quick test has the overhead for the check in a loop as .290 vs. .235 seconds, approximately. |
| 22:51:01 | Jehan_ | An option would be to have two mod operators, of course. |
| 22:51:09 | Araq | Jehan_: yeah, was about to suggest that |
| 22:51:27 | Araq | but in Ada I was always wondering which one to use for highest speed ... |
| 22:51:42 | Jehan_ | Anyhow, I've got work tomorrow and need to head off to bed. Night, folks! |
| 22:51:51 | Kelet | One thing I didn't like about Scala is that two things which are functionally equivalent have big speed differences |
| 22:51:56 | Kelet | for example, foreach vs for loop |
| 22:51:57 | Araq | good night |
| 22:52:06 | Kelet | there were preprocessors made to convert all foreach loops into equiv. for loops |
| 22:52:14 | * | Jehan_ quit (Quit: Leaving) |
| 22:52:15 | Kelet | among other things |
| 22:52:28 | Varriount | Good night Araq |
| 22:52:40 | Araq | Varriount: no, I'm still here |
| 22:52:50 | Araq | I said "good night" to Jehan_ |
| 22:52:57 | Varriount | Oh, I see. |
| 22:55:06 | Kelet | So do you think using Nimrod's macro is the best way to parse math expressions into procs? |
| 22:55:28 | Kelet | What I mean is, using it's Nimrod Expression => Corresponding AST conversions |
| 22:55:32 | Kelet | in the macro module |
| 22:55:57 | Araq | Kelet: that depends onto whether your math expressions are all known at compiletime |
| 22:56:13 | Araq | otherwise you need a real parser |
| 22:56:15 | brechtm | and why not implement them as procs? |
| 22:56:53 | EXetoC | proc f(x: int): int = x * 2 :-p |
| 22:57:36 | Kelet | I guess I'll write a real parser, then |
| 22:57:46 | * | Kelet digs his grave an inch deeper |
| 22:59:33 | brechtm | goodnight |
| 22:59:36 | * | brechtm quit (Quit: leaving) |
| 22:59:58 | Araq | Kelet: you can also simply import nimrod's parser and ast modules |
| 23:00:10 | Araq | though this is likely overkill for math formulas |
| 23:00:38 | Kelet | Yeah I think I'll just write my own, I guess |
| 23:00:54 | fowl | Araq, whens the last time something you wrote went into an infinite loop |
| 23:01:17 | Araq | recently in fact |
| 23:01:27 | Araq | when I patched the mark and sweep GC for dom96 |
| 23:01:43 | EXetoC | nub |
| 23:02:58 | Araq | OrionPK: if it's blocking you you can edit HighRegisterPressure in vmgen.nim; set it to 100 and your example compiles |
| 23:03:07 | fowl | hey guys is this whack/not whack? https://gist.github.com/fowlmouth/d926a6df3036d7ea1c74#file-p3-nim-L123 |
| 23:03:35 | fowl | i want to hide the generic part since it will affect every rule |
| 23:04:27 | Araq | fowl: looks dangerous but I'm busy |
| 23:05:14 | Kelet | NimLime is pretty laggy on my 5ghz intel i5 |
| 23:05:16 | Kelet | seems suspicious |
| 23:07:58 | * | Kelet goes and tries to copy and paste pieces of lexer.nim |
| 23:08:47 | * | nande quit (Remote host closed the connection) |
| 23:11:23 | * | nande joined #nimrod |
| 23:15:56 | * | zahary quit (Read error: Connection reset by peer) |
| 23:16:14 | * | zahary joined #nimrod |
| 23:16:33 | Araq | good night |
| 23:16:38 | Araq | this time for real, Varriount |
| 23:18:26 | Kelet | Bla = object vs Bla = ref object |
| 23:18:33 | Kelet | the first one uses value semantics ? |
| 23:18:37 | Kelet | and the second one doesn't? |
| 23:18:42 | Araq | yes |
| 23:18:53 | Kelet | Seems like it could get confusing |
| 23:19:35 | Araq | Kelet: most nimrod users are constantly confused about everything |
| 23:20:19 | Araq | I often confuse '+' and * and - |
| 23:21:31 | Araq | and 'proc' vs 'while' |
| 23:21:52 | reactormonk | Araq, stop being sarcastic. |
| 23:22:16 | reactormonk | Kelet, `ref` means `reference`. Not sure if the C * is better than that. |
| 23:22:34 | reactormonk | [] is deref, in case you ever need it. But in most cases, the compiler does the deref for you. |
| 23:22:49 | dom96 | wow, look at that spike in traffic: https://github.com/Araq/Nimrod/graphs/traffic |
| 23:23:47 | Kelet | Let's assume that I'm writing some code using someone else's library, and I don't recognize that he is using value semantics for his type. I then copy it around a lot and it degrades performance. I assume the only way to know concretely is to look at documentation or source code. |
| 23:23:54 | Kelet | Or is this not a problem? |
| 23:24:02 | reactormonk | dom96, wow. |
| 23:24:15 | Araq | Kelet: that's why we have the T/P convention but people consider it too ugly |
| 23:24:17 | dom96 | Kelet: This is where type prefixes are an advantage. |
| 23:24:29 | Araq | so we're getting rid of them |
| 23:24:47 | Kelet | But that's just a convention, right? |
| 23:25:03 | Kelet | Or was it enforced somehow |
| 23:25:06 | reactormonk | Kelet, I consider IDE help for that as solution. |
| 23:25:08 | reactormonk | Kelet, nope. |
| 23:25:56 | Araq | IMHO programmers do not care about readability at all. They pretend they do but in the end it only matters that it *looks* nice and clean. |
| 23:25:59 | reactormonk | Araq, apropos, I don't get anything back in the caas suggest tests where I should get stuff if I add the nilguard |
| 23:26:20 | Araq | reactormonk: so add the nil guard? |
| 23:26:22 | EXetoC | Kelet: you can choose to export just the ref symbol |
| 23:26:28 | Kelet | So if I want to program "modern Nimrod" style I should avoid the T and P prefixes? |
| 23:26:33 | Kelet | odd |
| 23:26:35 | reactormonk | Araq, yeah, I added it, but then the suggest doesn't provide anything anymore. |
| 23:26:55 | EXetoC | but the planned changes will make it less obvious |
| 23:26:58 | Kelet | to be fair, I never really liked the prefixes in Pascal, but they do serve a purpose. |
| 23:27:04 | reactormonk | Kelet, I would actually prefer postfixes ^^ |
| 23:27:08 | EXetoC | but nothing is set in stone |
| 23:27:19 | Kelet | TBla = object, PBla = ref object? |
| 23:27:28 | Araq | Kelet: actually it's worse in Pascal |
| 23:27:33 | Varriount | Hm. Is there a way to add a portion of previously unmanaged memory to the GC? |
| 23:27:41 | EXetoC | Kelet: yes, ref or ptr |
| 23:27:43 | Araq | in Pascal T is used for classes which are reference types |
| 23:28:10 | Araq | Varriount: not really but you can wrap it in a 'ref' and give a finalizer |
| 23:29:17 | * | darkf joined #nimrod |
| 23:29:31 | Kelet | darkf: hi :) |
| 23:29:34 | Varriount | Araq: So when the ref is collected, the finalizer will deallocate the unmanaged memory? |
| 23:29:46 | Araq | Varriount: exactly |
| 23:29:56 | Araq | but I really need to sleep now |
| 23:29:59 | Araq | good night |
| 23:30:06 | Varriount | Good night. |
| 23:31:25 | darkf | hello Kelet |
| 23:32:23 | reactormonk | skyfex, good work o/ |
| 23:35:38 | Varriount | skyfex: I only wish you could have been able to finish it before someone posted it on reddit. |
| 23:38:31 | EXetoC | what when how |
| 23:38:55 | * | Skrylar joined #nimrod |
| 23:40:40 | EXetoC | nvm |
| 23:59:59 | Varriount | dom96: I would really like some non-hacky way for my async callbacks to recieve the entire overlapped structure, instead of just choice bits of information. |