| 00:11:37 | * | Anaphaxeton quit (Remote host closed the connection) |
| 00:17:56 | * | SchalaZeal joined #nimrod |
| 00:23:11 | SchalaZeal | I don't think I can wrap jQuery... the API docs are confusing |
| 02:50:18 | SchalaZeal | Additionally I may need help regarding objects that are prototype oriented |
| 06:08:20 | shevy | hmm |
| 06:08:41 | shevy | now that you guys have this babel-addon installer thingy, is there a plan to have some kind of central repo for nimrod packages/addons or something like that? |
| 06:34:16 | * | SchalaZeal quit (Quit: Konversation terminated!) |
| 06:48:44 | * | FreeArtMan joined #nimrod |
| 08:42:19 | * | Araq_ joined #nimrod |
| 08:43:55 | * | Araq_ quit (Client Quit) |
| 08:44:42 | * | zahary_ joined #nimrod |
| 08:45:53 | * | Trix[a]r_za is now known as Trixar_za |
| 08:58:34 | * | Trixar_za is now known as Trix[a]r_za |
| 09:02:39 | * | Trix[a]r_za is now known as Trixar_za |
| 09:32:52 | * | Trixar_za is now known as Trix[a]r_za |
| 10:10:12 | * | zahary_ quit (*.net *.split) |
| 10:10:12 | * | Zor quit (*.net *.split) |
| 10:13:08 | * | zahary_ joined #nimrod |
| 10:13:08 | * | Zor joined #nimrod |
| 11:16:41 | * | XAMPP_8 joined #nimrod |
| 11:20:02 | * | XAMPP-8 quit (Ping timeout: 245 seconds) |
| 11:33:01 | * | gradha joined #nimrod |
| 11:34:18 | gradha | shevy: the central repo for packages would be https://github.com/nimrod-code/packages |
| 11:44:41 | shevy | cool |
| 11:44:56 | shevy | oh |
| 11:44:58 | gradha | what are you going to add? |
| 11:45:01 | shevy | it requires one to have github? |
| 11:45:10 | shevy | nah, I am far from being able to add anything meaningful yet |
| 11:45:34 | gradha | I'm sure you could shout here and it would be added anyway |
| 11:45:51 | gradha | as a user you could always open an issue asking for a package |
| 11:46:43 | gradha | pull requests may give you more control and make it easier on dom96's time |
| 11:47:21 | shevy | yeah I can understand that |
| 11:47:28 | shevy | poor dom96 is going to be drained of his time :D |
| 11:47:44 | gradha | nah, he loves it |
| 11:48:15 | gradha | it's true however that babel seems to lack retrieval methods other than git |
| 11:48:27 | gradha | see https://github.com/nimrod-code/babel/blob/master/babel.nim#L199 |
| 11:50:47 | shevy | hmm |
| 11:50:56 | shevy | wget would be nice |
| 11:51:09 | shevy | there is probably no other easy way to push than git :( |
| 12:05:14 | gradha | yay, first february post! http://forum.nimrod-code.org/t/122 |
| 12:17:29 | * | Anaphaxeton joined #nimrod |
| 12:20:44 | * | zahary quit (Ping timeout: 252 seconds) |
| 12:22:03 | * | zahary joined #nimrod |
| 12:56:05 | * | gradha quit (Quit: Leaving) |
| 13:31:32 | * | zahary quit (Ping timeout: 248 seconds) |
| 13:33:24 | * | zahary joined #nimrod |
| 15:06:43 | * | Anaphaxeton quit (Remote host closed the connection) |
| 15:38:30 | * | XAMPP_8 quit (Ping timeout: 264 seconds) |
| 15:55:31 | * | Trix[a]r_za is now known as Trixar_za |
| 16:41:42 | * | Trixar_za is now known as Trix[a]r_za |
| 17:35:57 | * | gradha joined #nimrod |
| 17:51:48 | * | Trix[a]r_za is now known as Trixar_za |
| 17:59:15 | * | gradha quit (Quit: Leaving) |
| 18:06:03 | * | Trixar_za is now known as Trix[a]r_za |
| 18:36:12 | Araq | ping zahary |
| 19:15:12 | * | shevy quit (Ping timeout: 264 seconds) |
| 19:27:32 | * | shevy joined #nimrod |
| 20:30:25 | * | gradha joined #nimrod |
| 20:30:41 | Araq | hey gradha |
| 20:30:45 | gradha | hey Araq |
| 20:31:04 | Araq | I answered your question |
| 20:31:16 | gradha | cool, going to check it |
| 20:32:30 | gradha | the "And yes, it's planned to get rid of nil for sequences and strings..." is for 1.0? |
| 20:32:47 | Araq | dunno |
| 20:32:56 | Araq | there are a couple of options for 'nil' |
| 20:33:26 | Araq | easiest is that 'nil' stays but 'len' and 'add' check for it and treat it like @[], "" |
| 20:34:15 | Araq | maybe we'll have a super fast xlen then that skips the nil check for performance junkies |
| 20:34:52 | gradha | isn't it enough to check for nil inside an assert? |
| 20:35:26 | gradha | the kind of asserts which go away when compiled in release mode |
| 20:35:30 | Araq | but then this doesn't help the poor programmer who gets useful default values for almost everything but not for strings and seqs |
| 20:36:01 | Araq | most of my constructors are only necessary to init strings and seqs to "", @[] |
| 20:36:21 | Araq | otherwise the "default constructor" which sets everything to 0, false, etc. is just fine |
| 20:37:03 | Araq | an assertion would only provide a more helpful error message for newbies |
| 20:37:24 | Araq | the code crashes immediately already with a stack trace |
| 20:37:32 | gradha | does the planning to get rid of nil for sequences and strings involve avoiding heap allocation for @[] and the empty string? |
| 20:37:57 | Araq | sure |
| 20:38:03 | Araq | let me explain it again :P |
| 20:38:20 | Araq | 'nil' stays but is for most built-ins treated as "" |
| 20:38:36 | Araq | this way you don't have to initialize your strings to "" as nil works fine too |
| 20:38:53 | Araq | and yeah that should reduce heap allocations |
| 20:38:53 | gradha | you said that, but also with that being "the easiest" |
| 20:39:04 | Araq | well yeah |
| 20:39:09 | gradha | what is your "hardest" option? |
| 20:39:46 | Araq | making 'string' equivalent to 'string not nil' and make the compiler enforce the 'not nil' annotations |
| 20:40:53 | Araq | this means that you don't get nil crashes anymore but still have to use "" everywhere |
| 20:41:09 | Araq | so it won't affect heap allocations |
| 20:42:29 | gradha | when I started objc I disliked how "sending a message" implicitly checks the object for nil to avoid crashing, yet I've never had a performance problem with that |
| 20:42:58 | gradha | the code is really bad if the bottleneck is on nil checks |
| 20:43:11 | gradha | or rather than bad, not doing much other than if checking |
| 20:43:33 | Araq | I agree |
| 20:58:37 | gradha | You could slip in nil checks in nimrod without announcing it and see if anybody notices performance issues (ignoring people whining about idetools) |
| 21:03:46 | Araq | the compiler itself is not a bad benchmark for these kind of things |
| 21:05:26 | Araq | I have to check out these cachegrind etc. profiling tools |
| 21:06:04 | Araq | but my guts say it's all pretty irrelevant, a cache miss costs 200-600 cycles now |
| 21:07:26 | Araq | so optimizing for memory usage should always pay off |
| 21:07:41 | gradha | I heard valgrind helps with cache miss detection |
| 21:07:54 | gradha | but I've only used it for crash debugging, and just a few times |
| 21:08:14 | Araq | yeah but that subsystem is called "cachegrind" afaik |
| 21:09:00 | gradha | indeed, I also heard it was implemented in haskell |
| 21:09:10 | Araq | nah |
| 21:09:23 | Araq | it's implemented in C++ I think |
| 21:10:57 | gradha | my sources are unreliable and old, they told me this about 13 years ago |
| 21:12:31 | gradha | hehe, so testing a rails app with valgrind results in a minimum memory footprint of 4GB, impressive |
| 21:14:59 | Araq | thanks |
| 21:15:09 | Araq | you made me download valgrind's source code |
| 21:15:19 | Araq | and now my nightmares will return :P |
| 21:15:21 | gradha | meh, sorry about that |
| 21:15:32 | Araq | it's actually written in C |
| 21:15:40 | Araq | millions of lines of C |
| 21:16:01 | gradha | if there are so many, maybe some haskell is hidden in there? |
| 21:16:34 | gradha | but nightmares about source code, that's really something |
| 21:17:24 | Araq | I don't see any *.hs file |
| 21:17:36 | Araq | there is also some assembler code |
| 21:19:31 | gradha | there's a clear lesson in here: don't trust strangers on IRC |
| 21:22:36 | Araq | dunno, your github avatar looks trustworthy ;-) |
| 21:23:03 | gradha | ALL HAIL HELLO KITTY! |
| 21:23:15 | gradha | I would be nothing without those cereals |
| 21:25:57 | gradha | maybe you should get a cerebrate avatar in march |
| 21:26:09 | Araq | hrm, yeah |
| 21:26:18 | Araq | maybe even this weekend |
| 21:54:04 | Araq | so gradha, what about some new project for ya? |
| 21:54:20 | Araq | nimrod on NaCl? |
| 21:54:43 | gradha | I'm still doing argument parsing |
| 21:54:55 | gradha | it's a fascinating world of strings with dashes |
| 21:55:18 | Araq | you'll note that parseopt is actually very well designed :P |
| 21:55:35 | gradha | it is, I simply prefer my wheel more squared |
| 21:55:37 | Araq | except for the uncommon --key:value syntax I guess |
| 21:57:43 | gradha | investigating python's argparse module I've reached a strange conclusion: it seems overcomplicated because they lack callbacks/custom procs |
| 21:58:14 | gradha | I'm at a point where implementing further functionality is easier letting the user provide her own procs for specialized parsing |
| 21:58:35 | gradha | and it strikes me as really weird that the python module doesn't use such a strategy |
| 21:58:49 | Araq | *his own procs please ;-) |
| 21:59:19 | Araq | (there are hardly any female users anyway) |
| 21:59:42 | Araq | and yes |
| 21:59:52 | Araq | soon you require a mapping string->proc |
| 22:00:16 | Araq | at which point you may figure that you could yield the string instead and let the client use a string case |
| 22:00:36 | Araq | at which point you've reinvented parseopt :P |
| 22:01:10 | gradha | yeah, but my wheel has more corners, I export even three objects! |
| 22:01:33 | Araq | but of course case statements are "ugly" and a table[string, proc] is "beautiful" |
| 22:02:46 | gradha | my original aim for argument parsing stays: learn to use macros |
| 22:02:56 | gradha | so whenever I feel confident writing macros I'll switch to something else |
| 22:03:48 | gradha | this is again another point which freaks me out about the python module: instead of parsing a DSL for argument specification they resort to dozens of named parameters |
| 22:04:15 | gradha | I dunno, at some point in the past I thought that code was brilliant, now it seems kinda meh |
| 22:06:43 | Araq | it's more code to use it than to process the command line yourself |
| 22:09:29 | gradha | shevy: things like https://www.youtube.com/watch?v=pYJ4A53UziQ get slightly more complicated to make, indeed |
| 22:23:38 | Araq | how could kratos ever become imprisoned? |
| 22:24:15 | gradha | I think this is not the first "god of war" game, maybe in previous ones tried to rewrite the wheel? |
| 22:24:58 | gradha | the camera system is very cinematic and good for watching, but there are blind spots and situations where your player is hidden, I really hate that |
| 22:25:16 | Araq | gameplay looks stultifying |
| 22:26:09 | gradha | never got the hang on button smashing games, feel pretty random to me |
| 22:28:41 | Araq | true |
| 22:54:26 | Araq | ugh, why is this cycle collector so hard to get right? |
| 22:55:24 | gradha | taking a break and doing something else might help |
| 22:57:19 | Araq | I already watched your video ... :-/ |
| 22:58:21 | gradha | didn't help me either |
| 23:27:18 | gradha | I wonder what these autoaway message options do... tell me if they spam the channel too much |
| 23:36:29 | gradha | why do you need to forward declare procs but not forward declare types? are they easier? |
| 23:36:48 | gradha | or maybe everything internally is just an object and you don't need to worry about the type? |
| 23:37:35 | gradha | just wrote a callback with a parameter type which is introduced later, I expected that would fail compilation without a forward type declaration |
| 23:39:35 | Araq | you have to forward declare types too in a way |
| 23:39:53 | Araq | it's just that within a single 'type' section order does not matter |
| 23:40:12 | Araq | and you cannot have recursive types spanning multiple 'type' sections |
| 23:40:30 | gradha | heh, was just going to try that |
| 23:41:06 | Araq | and believe it or not |
| 23:41:23 | Araq | it never occured to me that people despise forward declarations that much |
| 23:41:45 | Araq | zahary's working on getting rid of them for nimrod |
| 23:42:52 | gradha | to put it in other words: haven't found yet many people who prefer forward declarations |
| 23:43:25 | Araq | *shrug* it surely simplifies things for the compiler |
| 23:43:41 | Araq | especially for a language like nimrod |
| 23:45:28 | gradha | forward declarations require a little bit more of discipline, but so does a language with strong types, it's odd zahary likes one and not the other |
| 23:45:46 | gradha | unless you tell me now he is working also on making everything a number (to mess up TCL followers) |
| 23:46:02 | Araq | nah, it's not odd |
| 23:46:25 | Araq | it's about making computer perform the mundane work for you |
| 23:46:48 | Araq | when you have dynamic typing you often end up doing the type checking in your head |
| 23:46:58 | Araq | offloading it to the computer is a pretty good idea |
| 23:47:27 | gradha | I spread asserts like ebola, catches most stuff in debug mode, release version tends to works fine |
| 23:49:16 | Araq | hopefully we'll soon have race detection at compile time |
| 23:49:27 | Araq | try to do that with 'assert' :P |
| 23:50:04 | gradha | that's going to be interesting |
| 23:52:09 | gradha | still not sure what kind of race detection it is, so far I've read nimrod's threading is message passing and non shared memory, is that right? |
| 23:54:19 | Araq | there is a shared memory heap, it's not GC'ed for now though |
| 23:54:58 | Araq | the plan is to improve on that |
| 23:55:47 | Araq | as message passing is inevitably less efficient IMO |
| 23:57:15 | gradha | argh, that reminds me today I had the urge to write a threaded image processing library in nimrod |
| 23:59:34 | Araq | use sharedAlloc and it should work out quite nicely |
| 23:59:41 | Araq | er, allocShared |