| 00:04:46 | * | shevy left #nimrod ("I'll be back ... maybe") |
| 00:06:54 | Araq | dom96: I don't think I have any project to register to babel ;-) |
| 00:07:09 | Araq | maybe if I wouldn't put everything in the stdlib ... :D |
| 00:07:18 | dom96 | yeah... :P |
| 01:14:40 | * | fowl quit (*.net *.split) |
| 01:15:17 | * | fowl joined #nimrod |
| 02:05:08 | * | Trixar_za is now known as Trix[a]r_za |
| 02:05:29 | * | q66 quit (Quit: Quit) |
| 04:18:03 | * | XAMPP quit (Ping timeout: 245 seconds) |
| 04:20:35 | * | XAMPP joined #nimrod |
| 04:20:35 | * | XAMPP quit (Changing host) |
| 04:20:35 | * | XAMPP joined #nimrod |
| 08:53:50 | * | FreeArtMan joined #nimrod |
| 11:54:01 | * | q66 joined #nimrod |
| 12:45:36 | Araq | dom96: I think babel should be part of the compiler's distribution |
| 12:45:50 | dom96 | sure |
| 12:46:38 | Zor | Araq: hey |
| 12:46:47 | Araq | hi Zor |
| 12:48:40 | Araq | but then babel would need to be able to update the compiler ... and that needs to be special cased |
| 12:49:12 | dom96 | I don't think so... |
| 12:50:22 | Araq | what do you mean? |
| 12:50:45 | Araq | that it is not babel's business? or that it doesn't require a special case? |
| 12:51:19 | dom96 | hrm, well the former. But hrm. |
| 12:51:48 | dom96 | I suppose it does make sense. |
| 12:53:24 | Araq | but 'koch' can already update |
| 12:53:32 | Araq | except on windows |
| 12:53:53 | Araq | btw check it out, babel may have the same problem |
| 12:53:55 | dom96 | hrm, why not on Windows? |
| 12:58:15 | dom96 | But for normal apps we could have some kind of a specification as to how to build them in the .babel file. You know, for nimrod: |
| 12:58:43 | dom96 | Commands: unzip build/csources.zip && ./build.sh && bin/nimrod c koch && ./koch boot |
| 12:59:05 | dom96 | But then this won't work on Windows because of the dependency on unzip |
| 13:13:11 | Araq | yeah but that's pretty much unfixable |
| 13:16:40 | Araq | Zor: I'm wondering about the difference between using a spin lock and a lock free implementation |
| 13:17:18 | Araq | seems to me that most lock free implementations simply re-invent the spin lock ... what am I missing? |
| 13:18:26 | Zor | implementation of what |
| 13:18:57 | Araq | for instance a typical lock free queue uses CAS in a loop |
| 13:19:13 | Araq | but that's how a spin lock is implemented too |
| 13:19:32 | Araq | so you could simply use a spin lock to get the very same effect |
| 13:20:17 | Zor | I think the difference is that a spin lock is a more generalized concept that can be implemented in different ways |
| 13:20:40 | Araq | well sure, but why bother with lock free then? |
| 13:22:20 | Zor | dunno...it probably depends on your particular needs |
| 13:22:33 | Zor | I haven't really ever used a spin lock for anything before |
| 13:24:52 | Zor | but it seems like a spin lock allows for arbitrary operations in a locked region |
| 13:24:55 | Zor | which CAS doesn't |
| 13:25:15 | Araq | yeah sure |
| 13:25:38 | Araq | but since lock free is incredibly hard to get right a spin lock looks like a sweet cheap alternative |
| 13:25:45 | * | Zor nods |
| 13:25:51 | Araq | but https://groups.google.com/forum/?fromgroups=#!topic/comp.programming.threads/bPAVH1OTqtI seems to contain the answer |
| 13:26:59 | Araq | "The collision probability scales with the square of the time taken in |
| 13:27:00 | Araq | one spinning loop cycle. So the basic idea is to keep this time as short |
| 13:27:02 | Araq | as possible. It is obvious that spinning at some spin-lock variable and |
| 13:27:04 | Araq | then modifying some other memory location holds the lock longer than |
| 13:27:06 | Araq | reading the old value and write the new value back, which implicitly |
| 13:27:08 | Araq | releases the lock. The compared exchange simply joins the memory |
| 13:27:09 | Araq | location of the mutex with the memory location of the data to protect. |
| 13:27:11 | Araq | This also shows when it makes sense: only as long as you do not protect |
| 13:27:12 | Araq | more than one memory place with the lock. But keep in mind that fine |
| 13:27:14 | Araq | grained locking is a requirement of scalability." |
| 13:30:57 | Araq | hrm after reading this ... ok, it's entirely different :-) |
| 15:12:24 | Zor | the build farm seems dead |
| 15:12:30 | Zor | 502 |
| 15:13:15 | dom96 | fixed |
| 15:13:59 | Zor | what ppc64 hardware is it running? |
| 15:15:51 | dom96 | "4x16x3.55 GHz IBM POWER7 / 64 GB RAM / IBM Power 730 Express server / Fedora ppc64" |
| 15:16:04 | dom96 | gcc110 http://gcc.gnu.org/wiki/CompileFarm |
| 15:16:26 | Zor | ah |
| 15:16:36 | Zor | I tried getting access to the gcc compile farm but they are ... less than responsive |
| 15:16:58 | dom96 | yeah, it took a while for them to reply to my request. |
| 15:17:39 | dom96 | pity the gcc compile farm doesn't have any windows machines. |
| 15:35:02 | * | XAMPP quit (Read error: No buffer space available) |
| 15:35:27 | * | XAMPP joined #nimrod |
| 15:35:28 | * | XAMPP quit (Changing host) |
| 15:35:28 | * | XAMPP joined #nimrod |
| 18:46:09 | * | FreeArtMan quit (Ping timeout: 276 seconds) |
| 19:07:02 | * | Vladar joined #nimrod |
| 19:12:22 | Araq | hi Vladar |
| 19:12:45 | Vladar | Hi |
| 19:13:15 | Araq | please help to fill the babel repository ;-) |
| 19:13:17 | dom96 | hey Vladar. You should put nimgame on babel's package list! |
| 19:13:58 | Vladar | Yeah, already thought of it |
| 19:18:36 | dom96 | awesome. I hope my crappy readme files are good enough to get you started heh |
| 20:09:29 | Vladar | dom96, I hope I did it right way, have a look |
| 20:14:07 | dom96 | Vladar: You need a comma between the two JSON objects. |
| 20:14:12 | dom96 | i.e. after the } |
| 20:14:21 | dom96 | (Just after the first }) |
| 20:14:48 | Vladar | oh |
| 20:15:52 | Araq | babel should be able to register packages :P |
| 20:16:09 | Araq | ./babel register |
| 20:16:20 | Araq | package name? _ |
| 20:16:22 | dom96 | Araq: You know, there is a reason the software is open source :P |
| 20:16:33 | dom96 | Araq: You are more than welcome to contribute ;) |
| 20:17:17 | Araq | ok, I will implement a good old DOS dialog then |
| 20:17:23 | dom96 | Vladar: Also, I think your babel file should say "Version: 0.4.0". Since that's the current version in the latest commit on github. |
| 20:17:51 | Vladar | I't kinda WIP version, but yes |
| 20:18:44 | Vladar | I'll make it 0.3.1 ) |
| 20:19:11 | dom96 | Sure. That works too. |
| 20:19:17 | reactormonk | dom96, want to do git integration? So you can do ./babel build <version> and it looks for git tags? |
| 20:20:39 | dom96 | reactormonk: That's actually how it's implemented :) |
| 20:20:47 | reactormonk | dom96, fancy |
| 20:20:58 | dom96 | And in fact, I just realised I forgot to document the specifics of how versioning works. |
| 20:21:23 | reactormonk | would help, yep |
| 20:21:59 | Vladar | dom96, second try |
| 20:24:02 | dom96 | Vladar: Perfect. |
| 20:25:46 | Araq | dom96: can I make babel use an sqlite database? :P |
| 20:26:11 | Vladar | hm, maybe I'll add libtcod-nim too |
| 20:27:18 | dom96 | Araq: Not until a website is made to go along with it. |
| 20:27:35 | Araq | what has that to do with a website? |
| 20:27:56 | dom96 | Like I said, we can't store the sqlite file on git |
| 20:28:08 | Araq | so what, we don't store it on git |
| 20:28:17 | dom96 | where do we store it then? |
| 20:28:39 | Araq | we will have a recipes/ folder with all the registered .babel files and babel generates an sqlite database from that |
| 20:29:08 | Araq | so people only need to create the .babel file |
| 20:29:35 | Araq | and I'll implement some user dialog to help creating a .babel file |
| 20:30:33 | dom96 | haven't we already discussed this? |
| 20:30:38 | Araq | sure |
| 20:30:46 | Araq | but I forgot why we decided against it :P |
| 20:30:57 | dom96 | We decided against it because of the problem I described. |
| 20:31:10 | Araq | yeah but that's not a real reason |
| 20:31:36 | Araq | babel can easily download the appropriate .babel and build the package according to that |
| 20:31:48 | dom96 | IMO the best way to do this is to have people upload full packages to some website |
| 20:32:01 | Araq | nah |
| 20:32:06 | Araq | nobody wants to do that |
| 20:32:19 | dom96 | instead of keeping their git repo @ some tag in sync with the package's repo .babel file. |
| 20:32:23 | Araq | people want to say: "here's the github URL, do something with it" |
| 20:34:02 | dom96 | yes, and that is what we have with the current system |
| 20:35:55 | dom96 | You're mixing up a server-side .babel file list, and a client-side sqlite database to speed things up. Please keep it simple. |
| 20:36:10 | Araq | not to speed things up |
| 20:36:26 | Araq | so that people don't have to learn 2 different syntaxes |
| 20:36:26 | dom96 | well then I don't understand what you wish to accomplish |
| 20:37:03 | Araq | just let me hack something, if you don't like it, we can remove it again |
| 20:37:22 | dom96 | fine. |
| 20:37:38 | dom96 | But I would rather hear your plan instead of letting you waste time implementing it :P |
| 20:39:00 | Araq | well I already told you, but I'll change the plan according to what is easy to implement ;-) |
| 20:39:15 | Vladar | dom96, so, after installing some package user must add it to lib-path or how it works? |
| 20:39:55 | dom96 | Well, Araq implemented a 'babelPath' option. Araq: Is it in the config file by default now? |
| 20:41:25 | dom96 | Araq: Please explain your plan more clearly so that I can understand it. |
| 20:42:46 | Araq | dom96: it's not in the config file and would break bootstrapping :-/ |
| 20:43:11 | Araq | let me see if a workaround works |
| 20:43:15 | dom96 | huh? so it's not implemented yet? |
| 20:43:30 | Araq | it is implemented |
| 20:43:43 | Araq | but you can't put it in the default config |
| 20:43:59 | dom96 | interesting, how does that affect bootstrapping? |
| 20:44:26 | Araq | the old version doesn't know about --babelPath, finds it in the config file and complains |
| 20:44:54 | Araq | (old version = the version of the generated C code) |
| 20:46:21 | dom96 | oh |
| 20:46:54 | reactormonk | Araq, so bootstrap twice? |
| 20:47:17 | Araq | people complain if I update the C sources too often ... :P |
| 20:47:27 | Araq | but I already have a solution |
| 20:47:41 | Araq | so what should --babelpath be? |
| 20:47:48 | Araq | %home/babel ? |
| 20:48:05 | Araq | $home/babel/libs ? |
| 20:48:41 | dom96 | the latter |
| 20:48:53 | reactormonk | Araq, I'd go with .babel |
| 20:49:00 | dom96 | hah. |
| 20:49:37 | dom96 | babel used to install to ~/.babel but Araq wanted it to be ~/babel |
| 20:50:20 | reactormonk | vote on it? ;-) |
| 20:51:58 | reactormonk | I don't like my homedir to be cluttered by non-dot files... |
| 20:52:07 | Araq | reactormonk: we don't believe in democracy here :P |
| 20:52:29 | reactormonk | Araq, good, I'll send some agents over |
| 20:52:57 | Araq | I don't like dot files in my homedir |
| 20:53:12 | dom96 | lol |
| 20:53:15 | Vladar | dom96, when I'm using --babelPath, package modules can't import other modules from this package, and if I'll change all imports, then it'll not work when compiles with --path option, without babel |
| 20:53:26 | reactormonk | Araq, bet you got a shitload there |
| 20:53:46 | Araq | they are hidden and yet often important, so I made them visible |
| 20:53:52 | Vladar | Also, I like ~/.babel more =) |
| 20:54:56 | Araq | you're supposed to open ~/babel and fix problems there |
| 20:55:03 | dom96 | Vladar: hrm, why not? |
| 20:55:13 | reactormonk | the backtrace tells you where to find the files - hopefully |
| 20:55:21 | reactormonk | and I'd copy/paste the path from the backtrace anyway |
| 20:55:49 | Araq | Babel copies Linux's approach :P |
| 20:56:20 | Araq | if it's broken, fix it yourself by endless tinkering |
| 20:56:22 | reactormonk | so you don't like the .babel on windows idea? |
| 20:57:29 | dom96 | Vladar: I'm not sure what you mean. Take a look at how jester does it maybe? |
| 20:58:00 | Vladar | dom96, when I use --babelPath, I must import like "import nimgame/lib/engine", right? |
| 20:59:21 | dom96 | Vladar: It depends on your directory structure. |
| 20:59:30 | Vladar | Then, I must change all imports inside nimgame to this form instead of "import engine, image", etc.? |
| 20:59:54 | Araq | ok fine it's .babel |
| 21:00:08 | Araq | damn you and your voting |
| 21:00:28 | Vladar | I mean, nimgame does not have "main" module, modules imported when they needed |
| 21:00:30 | dom96 | Vladar: no. The imports work based on the module's directory. |
| 21:00:39 | Vladar | hm� |
| 21:01:07 | dom96 | in that case it might be a good idea to rename 'lib' into 'nimgame' |
| 21:01:29 | dom96 | then you will import by doing "import nimgame/engine" |
| 21:01:47 | dom96 | But say if your audio module wants to import engine |
| 21:01:53 | dom96 | all it has to do is "import engine" |
| 21:01:58 | dom96 | because engine is in the directory |
| 21:02:05 | dom96 | *the same |
| 21:05:05 | Vladar | dom96, when I rename lib to nimgame I get "babel/libs/nimgame/nimgame" |
| 21:05:06 | dom96 | Araq: Don't worry, i'll add a configuration file to accommodate for your hate for dotfolders :P |
| 21:05:25 | dom96 | Vladar: yeah. I know it looks bleh. |
| 21:06:21 | * | reactormonk bows. |
| 21:06:59 | Vladar | dom96, also I got this error: "/home/vladar/babel/libs/nimgame/lib/engine.nim(3, 8) Error: cannot open 'common'" so it seems to not be able find modules in the same dir |
| 21:09:13 | Araq | Vladar: used --path or --babelPath? |
| 21:09:23 | Vladar | babelPath |
| 21:09:37 | Araq | hrm could be a bug |
| 21:09:43 | Vladar | maybe |
| 21:10:03 | dom96 | mmm |
| 21:14:00 | Araq | er ... ok this can't work |
| 21:14:20 | Araq | it's babel/libs/nimgame/lib/engine.nim |
| 21:14:38 | Araq | but --babelPath is babel/libs/ |
| 21:14:54 | Araq | so the compiler adds babel/libs/nimgame to its path |
| 21:15:33 | Araq | so you need to 'import lib/engine' |
| 21:16:15 | Vladar | yeah |
| 21:16:39 | Araq | but then 'engine' needs to import 'common' via 'lib/common' |
| 21:17:23 | dom96 | ugh, that shouldn't be necessary |
| 21:17:28 | Araq | it's a feature that the compiler does not add the dir of some module to its path implicitly |
| 21:18:14 | Araq | zahary and I talked about it for days and thought it's a good idea given the current configuration system |
| 21:18:20 | Vladar | so if user doesn't uses babel and just puts lib dir in his project dir, then he must use --path:. ? |
| 21:18:20 | dom96 | wait. |
| 21:18:50 | dom96 | hrm, never mind |
| 21:18:53 | Araq | but tbh I can't remember the details :P |
| 21:19:25 | Araq | so hm, we need a solution |
| 21:19:53 | Araq | Vladar: no, if you put lib dir into the project dir, it will work |
| 21:20:04 | Araq | but babelPath doesn't do that |
| 21:20:07 | Araq | that's the problem |
| 21:22:37 | Araq | it's easy to fix once we decided what --babelPath should do with nimgame's structure |
| 21:25:08 | Araq | the problem is nimgame/*.nim modules would be accessible with --babelPath |
| 21:25:25 | Araq | but nimgame has them in nimgame/lib/*.nim |
| 21:26:01 | Araq | so we could teach babelPath about an optional 'lib' subdirectory? |
| 21:26:07 | Araq | any other ideas? |
| 21:26:47 | Vladar | maybe babel-config-file might have an option like "lib"? |
| 21:27:44 | Vladar | Can compiler get info from *.babel files? |
| 21:28:13 | Araq | it could, but it doesn't and I'd like to keep it this way |
| 21:29:15 | Araq | I think I'll make the compiler look for a *.nim file and if there is none, it will add all subdirectories to its path (but only 1 level, not recursively) |
| 21:29:50 | Vladar | Hm, good idea |
| 21:30:30 | Vladar | Actually, it will work very nice |
| 21:31:14 | Araq | how did you generate index.html btw? |
| 21:31:38 | reactormonk | Araq, subdirs... but only if it doesn't find _any_ nim files in the current dir? |
| 21:31:51 | reactormonk | ... but that could break shit again in unpredictable ways |
| 21:32:14 | reactormonk | I'd say add a loadpath which defaults to something |
| 21:32:50 | Vladar | Araq, I made doc.nim file with all the imports, "nimrod doc2 doc.nim" and then edit doc.html manually. |
| 21:33:05 | Araq | reactormonk: the whole purpose of --babelPath is to be 'smart' so that the --path list doesn't need to be updated |
| 21:34:08 | dom96 | IMO it should simply add the damn path of the current module to that module only. |
| 21:34:55 | Araq | Vladar: I see; now you need to use --project for 'doc2' btw |
| 21:35:21 | Araq | so that the docs are generated for all modules you imported |
| 21:36:07 | Araq | dom96: and then I have to import it via 'lib/engine'? you've got to be kidding |
| 21:36:26 | dom96 | ugh, that's the point. |
| 21:36:36 | dom96 | I mean. |
| 21:36:53 | dom96 | engine.nim should be able to do "import common" |
| 21:36:59 | Araq | sure |
| 21:37:04 | dom96 | but module outside of the lib dir should not |
| 21:37:14 | Araq | ugh |
| 21:37:17 | dom96 | Because what happens when another package has a module with the same name? |
| 21:37:33 | Araq | we discussed that already and yes it is a problem |
| 21:37:49 | Araq | and no, fixing the --path issues won't fix that |
| 21:49:18 | Vladar | Going to sleep, bye. |
| 21:49:41 | * | Vladar quit (Quit: Leaving) |
| 22:03:27 | Araq | so reactormonk, any better ideas? |
| 22:04:34 | Araq | otherwise I'm going for "subdirs... but only if it doesn't find _any_ nim files in the current dir" |
| 22:09:05 | reactormonk | Araq, and be sure to document that somewhere |
| 22:12:14 | Araq | alright |
| 22:17:49 | reactormonk | because it sounds like something that could bite you... hard. |
| 22:19:04 | Araq | that's the purpose of a package manager :P |
| 22:19:54 | reactormonk | I prefer my packages to be shipped without any booby traps |
| 22:27:06 | dom96 | Araq: So now I will be able to do 'import engine'...? |
| 22:27:25 | dom96 | I don't get "subdirs... but only if it doesn't find _any_ nim files in the current dir" |
| 22:29:41 | Araq | well try it :P |
| 22:29:47 | Araq | I implemented it |
| 22:29:52 | Araq | and it works for nimgame |
| 22:30:16 | dom96 | just answer my question |
| 22:33:09 | Araq | nimgame/ has no .nim file |
| 22:33:27 | Araq | so the compiler looks into nimgame/lib |
| 22:33:38 | Araq | and nimgame/doc |
| 22:33:45 | Araq | and nimgame/fnt |
| 22:34:01 | Araq | and adds any of those that have any .nim file |
| 22:34:07 | Araq | which is nimgame/lib |
| 22:34:20 | Araq | and thus you can 'import engine' and it works |
| 22:34:36 | dom96 | awesome. So now as soon as any other package decides to have a audio module, or an engine module, or a common module, or ... it will simply fail. |
| 22:35:03 | Araq | nah |
| 22:35:20 | Araq | er, yes, exactly |
| 22:35:27 | dom96 | lol? |
| 22:35:34 | dom96 | seriously? |
| 22:36:34 | dom96 | ok. Fine. I realise that it's a hard problem to solve because of how the c files are generated. |
| 22:53:01 | Araq | good night |