| 09:34:22 | * | NimBot joined #nimrod |
| 10:15:06 | * | Trix[a]r_za is now known as Trixar_za |
| 10:35:56 | dom96 | welcome back apotheon ;) |
| 11:06:08 | NimBot | Araq/Nimrod 848a839 Araq [+0 ±8 -0]: rod file viewer for easier debugging of rod files |
| 12:23:35 | * | q66 joined #nimrod |
| 13:03:00 | * | Trixar_za is now known as Trix[a]r_za |
| 13:51:45 | Araq | ping zahary |
| 14:24:39 | apotheon | dom96: thanks |
| 14:47:00 | zahary | hi Araq |
| 15:38:34 | * | tass_ joined #nimrod |
| 15:41:46 | Araq | zahary: I'm having a hard time to find the cause of how you broke symbol files |
| 15:42:02 | Araq | it's related to some change about the handling of the system module |
| 15:44:12 | Araq | hi tass_, welcome |
| 15:46:09 | zahary | ah, I planned to fix this month ago |
| 15:48:25 | zahary | *months* . it's easy to fix - the culprit is the new way I assign module IDs now |
| 15:51:13 | zahary | oh, I better try to finally do it even if don't get a good night sleep tonight |
| 15:53:58 | * | tass_ quit (Ping timeout: 258 seconds) |
| 15:58:04 | Araq | speaking of which ... do the new typeInstCache, procInstCache and usedGenerics |
| 15:58:12 | Araq | fields need to be persisted? |
| 16:00:35 | zahary | there is a bug with the old scheme I haven't told you about. in certain sequence of events it was possible to remove an implementation of generic proc while it's still being used by another module |
| 16:02:39 | zahary | to answer your question, the new fields must be persisted somehow, but that's not enough - you must also put the implementations in the right file (I planned to implement my "binning" scheme to solve the problem) |
| 16:09:51 | Araq | what do you mean with "old scheme"? my way of doing it? |
| 16:10:39 | zahary | yes, putting the generic in the file of the first user, without tracking other usages |
| 16:11:05 | Araq | but that's not how it was done |
| 16:11:14 | Araq | at least not how it was supposed to be done |
| 16:11:32 | Araq | instead it duplicated the generic instantiations |
| 16:11:34 | zahary | how was it supposed to be? |
| 16:11:54 | Araq | the generics cache was by module for --symbolFiles:on |
| 16:13:17 | zahary | I remember this, but let me try to recall what was the problem |
| 16:15:27 | Araq | I suppose it was that the C backend doesn't know about it ;-) |
| 16:15:51 | Araq | so for the C backend you can end up with a situation you described |
| 16:16:22 | zahary | it had something to do with the codegen, yes |
| 16:16:29 | Araq | generics would have to be put into special C merge section for it to work |
| 16:16:36 | Araq | *instantiated generics |
| 16:16:50 | Araq | on the other hand ... |
| 16:17:01 | Araq | I forgot how the C file merging works ;-) |
| 16:19:58 | reactormonk | Araq, broke down to 130 |
| 16:23:09 | Araq | and again the price for the most undecipherable messages goes to --- reactormonk! |
| 16:24:20 | reactormonk | Araq, I tend to keep the context based on the message I wrote last time ;-) |
| 16:24:46 | Araq | context is a very unfunctional thing :P |
| 16:26:44 | reactormonk | how do you think you keep state in FP? |
| 16:29:56 | Araq | you pass it around via parameters? |
| 16:34:33 | reactormonk | yeah, but they get bound to context eventually ;-) |
| 16:35:51 | reactormonk | Araq, need to kick you again for 347? ^^ |
| 16:38:22 | Araq | nah I got it |
| 16:38:49 | Araq | you can't continue your work because you NEED slightly different semantics in closures |
| 16:39:52 | zahary | what must be different in closures? |
| 16:40:15 | Araq | zahary: nimrod's JS backend currently uses JS's closures |
| 16:40:45 | zahary | ah, and the for loops bite you? |
| 16:41:12 | Araq | yeah |
| 16:41:25 | Araq | and it's not that easy to fix as the workaround we use for C doesn't work |
| 16:41:45 | Araq | as JS has clojures already and Nimrod's callbacks need to be compatible |
| 16:41:53 | Araq | *closures lol |
| 16:42:18 | Araq | so passing a hidden dummy param doesn't work |
| 16:42:30 | zahary | is there an example gist with all of the problems? |
| 16:44:33 | reactormonk | zahary, there's just one example in the issue :-/ |
| 16:49:12 | zahary | well, it can be solved the coffee-script way |
| 16:49:53 | Araq | via an additional dummy function() {...} block? |
| 16:50:08 | zahary | yes, if you detect that the loop variable is captured |
| 16:50:52 | zahary | or should I say "a loop variable", because it applies to all local variables in the stupid JS world |
| 16:51:36 | zahary | the dummy block replaces the loop body, not the closure itself |
| 16:52:00 | zahary | so you don't break inter-op with javascript |
| 16:58:10 | reactormonk | zahary, see my `fix` in the issue |
| 16:58:19 | reactormonk | https://gist.github.com/Tass/5225756 |
| 16:58:46 | reactormonk | zahary, and yeah, JS scoping is ugly. |
| 17:00:14 | zahary | your fix is too hairy, I have a hard time following it |
| 17:00:49 | zahary | but it doesn't seem to be the way I would do it |
| 17:04:11 | zahary | I left some comments |
| 17:05:49 | reactormonk | Ok |
| 18:05:11 | reactormonk | zahary, I'll create a different patch then |
| 18:31:05 | * | gradha joined #nimrod |
| 18:43:18 | * | silven_ is now known as silven |
| 19:25:56 | reactormonk | zahary, new patch, more the idea you indicate? |
| 19:43:04 | * | zahary1 joined #nimrod |
| 19:58:42 | gradha | So I have objc code to recycle files https://gist.github.com/gradha/5313645 and nimrod version at https://gist.github.com/gradha/5313649 |
| 19:58:59 | gradha | the nimrod version only works if you use objc code generation |
| 19:59:18 | gradha | any ideas if it would be possible to have this available always even from c generation? |
| 20:00:55 | dom96 | objc is such an odd beast |
| 20:01:44 | dom96 | Is there no way to access this API using straight C? |
| 20:01:49 | reactormonk | dom96, nope |
| 20:02:37 | reactormonk | dom96, or, rather, how would you create one? |
| 20:03:29 | gradha | I have a C API version, but it's deprecated in Mountain Lion, plus I don't know if it compiles in C, it just looks plain C because there are no objects |
| 20:03:52 | gradha | you still need to link against the cocoa/appkit frameworks, and I guess that makes you objc anyway |
| 20:04:01 | reactormonk | gradha, yeah, they want to capture people in their ecosystem >:) |
| 20:04:20 | Araq | gradha: newException(EOS, ...) looks wrong, use OSError() instead |
| 20:05:51 | Araq | and I suppose we need a "target by module" switch soon |
| 20:06:05 | reactormonk | Araq, what's that? |
| 20:06:08 | Araq | so that recycle.nim gets compiled as ObjC and the rest does not |
| 20:07:19 | dom96 | won't this recycle stuff be a part of os.nim though? |
| 20:08:30 | dom96 | What would be nice is objc: ... |
| 20:08:48 | dom96 | and the code in that block would be automatically compiled as objc if that's possible. |
| 20:08:59 | reactormonk | what if not? |
| 20:09:15 | dom96 | reactormonk: what? |
| 20:09:36 | reactormonk | dom96, what if it's not possible to compile it as objc |
| 20:09:46 | gradha | Araq: maybe putting the implementation in a separate file and using {.compile: "macosxrecycle.m".} ? |
| 20:10:14 | dom96 | reactormonk: in that case the compilation should fail. |
| 20:10:41 | dom96 | This will mostly be used on Mac OS X, so it should be possible. Right? |
| 20:10:50 | Araq | gradha: ha, exactly my idea :-) |
| 20:11:30 | Araq | however I think it shouldn't become part of os.nim anyway |
| 20:13:36 | gradha | I'll test the idea while you think of a better place |
| 20:14:36 | Araq | new module: fancyos.nim? |
| 20:14:41 | Araq | ;-) |
| 20:14:46 | reactormonk | Araq, go for it |
| 20:14:50 | gradha | notsouserfriendlyos.nim |
| 20:15:10 | Araq | I dunno, but it doesn't seem to be that useful |
| 20:15:42 | gradha | who recycles anyway |
| 20:16:05 | dom96 | perhaps babel? |
| 20:16:20 | Araq | for automation you better know for sure it's unnecessary and then delete it properly |
| 20:16:53 | Araq | or you move it to /tmp |
| 20:17:34 | Araq | the recycle bin feature looks to be a part of a UI toolkit to me |
| 20:20:50 | gradha | I've made myself a few scripts which I integrate from the desktop and it's nice to have them behaving like other desktop operations, thus this implementation, since I'm rewritting all in nimrod |
| 20:22:11 | Araq | I'm glad to hear that :-) |
| 20:22:29 | Araq | and recycle.nim is useful to have of course |
| 20:22:44 | gradha | shell scripts have a limit, and scripting has horrendous performance |
| 20:23:08 | Araq | I'm still not convinced it should go into os.nim especially since it then has an ObjC dependency on mac |
| 20:23:29 | gradha | np, I'll babel it |
| 20:23:45 | Araq | cool |
| 20:24:12 | Araq | if only we had babel's design finished |
| 20:24:25 | gradha | nimfancypants sounds promising |
| 20:25:27 | gradha | maybe I should name it something which rhymes with dongle |
| 20:26:28 | Araq | careful now |
| 20:26:42 | Araq | maybe some feminist will read the logs one day |
| 20:27:08 | gradha | can't wait for that to happen |
| 20:27:40 | Araq | you could lose your job ;-) |
| 20:27:54 | gradha | you mean, pestering you on irc? |
| 20:29:01 | Araq | no pestering *you* as you're the one with the dongle jokes |
| 20:29:16 | dom96 | "I'll babel it" -- I like that. |
| 20:29:24 | Araq | I'm merely the guy who thinks feminism is a form of fascism |
| 20:30:56 | gradha | maybe something kpop, since coreans are the superior race anyway and we will die in a zerg rush |
| 20:31:03 | gradha | a bus zerg rush |
| 20:34:21 | gradha | btw, does blizzard make something else other than diablo and *craft? |
| 20:34:42 | Araq | sure, "lost wikings" |
| 20:36:37 | gradha | nice, they are working on a card game, hearthstone |
| 20:37:08 | dom96 | Don't forget Blizzard Dota |
| 20:37:35 | dom96 | oh, they renamed it. |
| 20:41:47 | Araq | oh look an interview with Alan Kay http://www.osnews.com/comments/26914. Again. |
| 20:42:36 | Araq | where he can explain to us again what idiots we all are and that nobody comes close to his awesome imagination |
| 20:52:34 | gradha | at least he is trying, I'm not trying to convince anybody else they are stupid for not coming close to my awesome imagination, maybe I should |
| 20:54:12 | Araq | you need many more failed prototypes to become as famous as him :P |
| 20:59:22 | * | zahary1 quit (Quit: Leaving.) |
| 21:00:33 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
| 21:01:31 | Araq | and he left without discussing babel with us |
| 21:02:14 | dom96 | he can read logs right? |
| 21:02:23 | Araq | true |
| 21:08:44 | Araq | what's missing for Babel again? |
| 21:11:44 | dom96 | proper versioning, dependencies |
| 21:11:53 | dom96 | seamless integration with the compiler |
| 21:12:46 | dom96 | You had a nice plan for integrating the compiler with it. |
| 21:13:06 | Araq | dependency management can be done with a simple compiler change |
| 21:13:37 | Araq | when it doesn't find any matching module, it could invoke "babel install modname" and then try again |
| 21:14:29 | dom96 | Wasn't the original idea to explicitly state the packages in the .cfg file? |
| 21:14:56 | Araq | yeah but it's a never ending list of meta information then |
| 21:15:18 | Araq | and the deps are already in the "import" statements, so we'd better make use of that information |
| 21:16:14 | dom96 | what about being able to specify non-babel deps? |
| 21:17:28 | dom96 | what about versions? |
| 21:18:42 | dom96 | I think it might turn out to be a bit of an annoyance if for each module which cannot be located the compiler tries to use babel to install it. |
| 21:19:25 | Araq | hmm |
| 21:22:22 | Araq | I dunno |
| 21:22:30 | Araq | it happens rarely enough |
| 21:24:08 | Araq | but alright, so lets make a 'nimrod install' for that feature :-/ |
| 21:25:24 | dom96 | I really prefer the explicit config way |
| 21:27:07 | dom96 | having to install each package manually defeats the purpose |
| 21:27:20 | dom96 | You can do that already |
| 21:27:55 | Araq | no no |
| 21:28:05 | Araq | nimrod install would install stuff recursively |
| 21:28:20 | Araq | it would basically run 'nimrod check' over the given project |
| 21:28:38 | Araq | except that modules that it cannot find are handled over to babel to download and install |
| 21:29:43 | * | fowl quit (Ping timeout: 245 seconds) |
| 21:32:07 | dom96 | hrm, ok. |
| 21:32:17 | dom96 | How would the import look then? |
| 21:36:14 | Araq | I dunno, I would make it look like any other import |
| 21:36:33 | dom96 | well you need the package name in there |
| 21:36:40 | dom96 | so that babel knows what to install |
| 21:37:49 | Araq | the package name is the module name? |
| 21:39:00 | dom96 | what if your package wishes to expose multiple modules? |
| 21:39:49 | Araq | that's not really a problem oh wait it kind of is |
| 21:40:35 | Araq | so we need a notion of a package in the compiler :-/ |
| 21:41:29 | Araq | or indeed leave it all to babel |
| 21:47:39 | Araq | so dom96 make a suggestion of how a package should look like |
| 21:48:04 | Araq | I guess a package is a directory with some .babel file in it? |
| 21:48:42 | dom96 | sure |
| 21:48:53 | Araq | or maybe simply a directory? |
| 21:50:52 | Araq | if I have /lib/a/modA and that imports modB and there is a /lib/a/modB I guess it doesn't make much sense to use $stdlib/modB ? |
| 21:52:33 | dom96 | perhaps that is why we should explicitly specify the packages in the config file. |
| 21:52:55 | Araq | I am no fan of double book keeping |
| 21:53:16 | Araq | the filesystem is enough to store these things implicitly |
| 21:54:39 | dom96 | However you would specify the package in your import line anyway |
| 21:58:04 | dom96 | I dislike these ambiguities though |
| 21:58:13 | Araq | which ones? |
| 21:59:50 | dom96 | someday you might add something to stdlib which will conflict with some package |
| 22:00:41 | dom96 | also, remember that you can do: import "package" |
| 22:00:53 | dom96 | which makes this conflict more likely |
| 22:02:47 | Araq | well within a package there is no problem with that |
| 22:03:01 | Araq | as the module within the package gets priority |
| 22:04:46 | Araq | but it's a point worth considering |
| 22:05:10 | Araq | maybe some packages become part of the stdlib or vice versa |
| 22:05:43 | Araq | but hm that's just a versioning problem |
| 22:08:45 | Araq | but back to dependencies |
| 22:09:11 | Araq | so I can say "requires jester > 0.1" |
| 22:09:40 | Araq | however, I have no idea if every version after 0.1 does indeed work |
| 22:09:57 | Araq | nor do I have a chance to find out |
| 22:10:21 | Araq | --> versioning is fundamentally flawed :P |
| 22:11:14 | Araq | blacklisting would work though |
| 22:11:24 | Araq | "doesn't work with version 0.1" |
| 22:12:33 | Araq | or maybe "works with version 1.0" |
| 22:14:07 | Araq | what one really wants is "try latest version, if it doesn't work, try the version listed here" |
| 22:14:19 | Araq | for some definition of "doesn't work" |
| 22:14:53 | Araq | in our case I suppose it means "doesn't compile" ... ;-) |
| 22:15:27 | dom96 | IMO it should be: "try version currently installed, if not installed install specific version" |
| 22:15:43 | Araq | oh yeah that's a good point |
| 22:16:30 | dom96 | perhaps that behaviour could be configurable. |
| 22:16:45 | dom96 | might also be nice to install a newer version if the currently installed one is lower than the specified one |
| 22:17:56 | Araq | but then it may also be nice to not update in order to not break anything |
| 22:21:07 | dom96 | well, will we allow multiple versions to be installed? |
| 22:21:19 | dom96 | say one module specifies version 1 and another version 2. |
| 22:21:23 | dom96 | er |
| 22:21:26 | dom96 | s/module/package/ |
| 22:23:11 | Araq | dunno |
| 22:23:39 | Araq | still looks like a paper tiger to me |
| 22:24:01 | Araq | (a problem you can spend ages to solve and yet never really occurs) |
| 22:24:43 | Araq | you can always rename the offending package in the worst case |
| 22:25:06 | dom96 | well we're already spending way too much time perfecting this |
| 22:25:16 | dom96 | it's annoying me to be honest :P |
| 22:26:00 | Araq | *shrug* people get what they deserve :P |
| 22:27:21 | Araq | but right now we an unfinished nothing |
| 22:27:39 | dom96 | how do we? |
| 22:27:44 | dom96 | babel exists |
| 22:27:47 | dom96 | it's a something |
| 22:27:50 | dom96 | it's not nothing |
| 22:28:05 | Araq | alright but it can't download deps recursively |
| 22:30:31 | Araq | but then maybe it's a feature :P |
| 22:30:44 | Araq | so that people don't have to list deps in the babel file |
| 22:31:14 | Araq | so it's the user's problem :-) |
| 22:32:05 | dom96 | yeah, people should just write a sh file to execute babel many times :P |
| 22:33:25 | Araq | C/C++ survive without a package manager |
| 22:34:47 | dom96 | yeah, maybe we should just wait until someone creates a package manager for us |
| 22:34:55 | dom96 | but it's too late now :P |
| 22:35:08 | Araq | no it's good we're doing it |
| 22:35:18 | Araq | other people will only get it wrong :P |
| 22:39:23 | dom96 | that's not very nice |
| 22:39:38 | Araq | but I'm kidding |
| 22:40:38 | dom96 | i'm sure you are |
| 22:40:47 | Araq | I'm not sure ;-) |
| 22:58:39 | Araq | well I have to sleep now, see you tomorrow |
| 23:06:06 | dom96 | bye |
| 23:29:50 | * | q66 quit (Remote host closed the connection) |