| 00:03:57 | dom96 | Araq: Take a look now |
| 00:04:28 | Araq | green |
| 00:10:54 | NimBot | nimrod-code/nimbuild 5c60a66 Dominik Picheta [+0 ±1 -0]: Fixed platform not being added to the hashes platforms list when a build... 2 more lines |
| 00:14:23 | reactormonk | Araq, |
| 00:14:27 | reactormonk | proc commandInactiveTitlebar1Changed*(options: TOptions, callback: proc()) {.importcpp: "commandInactiveTitlebar1Changed.connect".} |
| 00:14:34 | reactormonk | hum |
| 00:15:46 | Araq | importcpp: "commandInactiveTitlebar1Changed.connect" <-- likely to be wrong |
| 00:16:07 | Araq | you either importc: "dotty.stuff" or you importcpp: "methodname" |
| 00:19:29 | reactormonk | that's a signal, as mentioned above |
| 00:21:41 | Araq | as if I would know wtf a signal is ... |
| 00:22:00 | reactormonk | Araq, the api of a signal is obj.signalname.connect(func) |
| 00:22:54 | Araq | ok, 'importcpp' is fine then |
| 00:41:06 | Araq | good night |
| 01:18:33 | reactormonk | http://sprunge.us/NjXB |
| 01:18:36 | reactormonk | ... |
| 01:23:09 | reactormonk | is the @ a valid part of a variable name? |
| 01:28:05 | * | q66 quit (Quit: Quit) |
| 06:57:04 | libMAN | I remember http://dlang.org/comparison.html actually having a comparison to other languages (C, C++, Java?) many years ago... (Archive.org didn't save it.) |
| 06:58:09 | libMAN | It would be very nice to have a similar feature comparison table, in addition to performance and briefness benchmarks, comparing Nimrod to the competitors (D, Go, Rust, Shedskin, etc). |
| 07:05:54 | libMAN | Nevermind, archive did save it - http://web.archive.org/web/20070109042427/http://www.digitalmars.com/d/comparison.html |
| 07:07:13 | libMAN | That's the last snapshot before Bright decided to remove it - http://forum.dlang.org/thread/[email protected]?page=2#post-eoe12n:241sen:241:40digitaldaemon.com |
| 08:45:03 | reactormonk | libMAN, well, if you go do implementation-specific optimizations, stuff will be fast |
| 08:46:38 | reactormonk | http://sprunge.us/fNDA final product - how can I remote the dependency from stuff like options global and workspace? Simply use prefix again? |
| 09:24:53 | * | AshleyWaffle12 joined #nimrod |
| 09:24:55 | AshleyWaffle12 | Hi |
| 09:25:12 | AshleyWaffle12 | I have a question about the sorter example on the nimrod home page |
| 09:25:37 | AshleyWaffle12 | so you've got an array of integers (stored as strings for now) |
| 09:25:41 | AshleyWaffle12 | and then you do this to it |
| 09:25:44 | AshleyWaffle12 | echo tokens.each(parseInt).max, " is the maximum." |
| 09:25:54 | AshleyWaffle12 | My question is |
| 09:26:38 | AshleyWaffle12 | Wouldn't that just get the "max" of integer returned by "each(parseInt)"? |
| 09:26:45 | AshleyWaffle12 | of each integer* |
| 09:27:07 | AshleyWaffle12 | I don't understand how it checks the whole list, which would make sense to me like this: |
| 09:27:22 | AshleyWaffle12 | tokens.max (well, after tokens is made into an array of integers) |
| 09:35:48 | reactormonk | AshleyWaffle12, nimrod does not have a concept of lazyness, so it will map the whole list - or what is your exact question? |
| 09:39:25 | Araq | hi AshleyWaffle12 |
| 09:40:08 | AshleyWaffle12 | Hi :) |
| 09:40:12 | Araq | I can't improve on reactormonk's answer |
| 09:41:04 | AshleyWaffle12 | Well, I guess I'm specifically asking about the tokens.each part. |
| 09:41:05 | Araq | 'each' is returns a sequence (array, list whatever you like to call it) and 'max' picks the maximum of this sequence |
| 09:41:11 | AshleyWaffle12 | Ah, thanks |
| 09:41:24 | AshleyWaffle12 | But why would each return the whole sequence? Isn't tokens *already* an array of some sort? |
| 09:41:46 | Araq | yes an array of strings |
| 09:42:03 | AshleyWaffle12 | so why not do tokens(parseInt).max? |
| 09:42:04 | Araq | tokens.each(parseInt) transforms it into a list of integers |
| 09:42:15 | AshleyWaffle12 | Ah I get it now! |
| 09:42:39 | Araq | and yeah we should rename it to 'map' |
| 09:42:47 | AshleyWaffle12 | tokens.each() does whatever's in the parenthesis to each token |
| 09:42:50 | AshleyWaffle12 | basically |
| 09:42:54 | AshleyWaffle12 | thanks |
| 09:43:03 | AshleyWaffle12 | well, I'd turn each into foreach, I'd say |
| 09:43:06 | reactormonk | AshleyWaffle12, functional map. As in ruby or perl. |
| 09:43:26 | AshleyWaffle12 | Functional map? Sorry, I don't really know the terminology :/ |
| 09:43:32 | reactormonk | I might have seen it even in python, although I'm not sure |
| 09:44:06 | reactormonk | AshleyWaffle12, http://en.wikipedia.org/wiki/Map_(higher-order_function) |
| 09:44:35 | Araq | AshleyWaffle12: it's only a supposed to be a cute snippet; you can use a good old 'for' loop instead too ;-) |
| 09:44:37 | reactormonk | AshleyWaffle12, or basically, a function (each) that applies another function (parseInt) to each element in a sequence |
| 09:45:23 | reactormonk | AshleyWaffle12, actually, the pure functional definition is a bit more complex, but mine will do unless you encounter a functional language like haskell or scala |
| 09:45:59 | reactormonk | Araq, any idea on the above JS problem? |
| 09:46:55 | AshleyWaffle12 | Thanks :) |
| 09:47:17 | AshleyWaffle12 | reactormonk: do you "own" the nimrod project? |
| 09:47:23 | AshleyWaffle12 | did you found it, I guess? |
| 09:48:09 | reactormonk | AshleyWaffle12, that's Araq that does. |
| 09:48:28 | reactormonk | AshleyWaffle12, guess why the url is github.com/Araq/Nimrod |
| 09:49:14 | reactormonk | I'm just a guy with crazy ideas like using ruby to convert xml to nimrod for compilation to JS. |
| 09:51:08 | Araq | reactormonk: well I can't see a problem; import it via "workspace.XXX" |
| 09:51:17 | Araq | and remove the workspace parameter |
| 09:51:50 | AshleyWaffle12 | ah lol |
| 09:52:00 | reactormonk | and just go for good old importc I suppose |
| 09:52:04 | AshleyWaffle12 | lol |
| 09:52:25 | AshleyWaffle12 | reactormonk: How can you convert XML to JS? aren't they totally different languages? |
| 09:52:34 | AshleyWaffle12 | Like trying to convert SQL to x86 assembly... |
| 09:53:45 | reactormonk | AshleyWaffle12, well, XML from doxygen describing an API to nimrod which is compiled to JS |
| 09:54:58 | AshleyWaffle12 | Ah I see |
| 09:55:00 | AshleyWaffle12 | Okay |
| 10:03:56 | Araq | I still think you should either use a nimrod script instead of ruby or even better c2nim |
| 10:04:26 | * | AshleyWaffle12 quit (Quit: leaving) |
| 10:08:07 | reactormonk | Araq, no xpath, no nimrod. |
| 10:09:48 | Araq | reactormonk: any API that's worth considering for an xpath for Nimrod library? |
| 10:10:20 | reactormonk | Araq, I only know of libxml |
| 10:11:14 | Araq | no I mean a sweet API design that can fit Nimrod's static type system |
| 10:11:43 | Araq | libxml is gnome bloat |
| 10:13:22 | * | AshleyWaffle12 joined #nimrod |
| 10:13:50 | reactormonk | ^^ |
| 10:13:55 | reactormonk | sleeping.... |
| 10:14:33 | Araq | oh I see ... xpath is misdesigned |
| 10:14:39 | Araq | hrm |
| 10:15:38 | AshleyWaffle12 | :3 |
| 10:15:42 | AshleyWaffle12 | I got ProFont setup |
| 10:15:44 | AshleyWaffle12 | 10pt |
| 10:15:49 | AshleyWaffle12 | It's okay I guess |
| 10:16:00 | AshleyWaffle12 | I like the "u" chars, and the "," chars and the "0" chars |
| 10:16:13 | AshleyWaffle12 | However, I really *really* want Apple's "bootup" font |
| 10:16:20 | AshleyWaffle12 | Haven't been able to find it *anywhere* :'( |
| 10:17:00 | Araq | you seem to a very lucky person then if that's your biggest problem ;-) |
| 10:18:33 | AshleyWaffle12 | Lol :P |
| 10:20:26 | * | AshleyWaffle12 quit (Quit: leaving) |
| 10:35:20 | * | XAMPP quit (Read error: Connection reset by peer) |
| 10:39:06 | * | q66 joined #nimrod |
| 10:39:38 | libMAN | Just a random thought: a JIT compiler with caching. |
| 10:40:58 | libMAN | You put a shebang (i.e. "#!/usr/bin/local/nimrod-jit") on your entry point source file. It checks the binaries cache, converts to C / compiles / links / etc what has been updated, and then executes the executable with the same arguments / environment as the script. |
| 10:41:28 | libMAN | It could store the compile files and binaries in something like /var/cache/nimrod-jit |
| 10:42:37 | Araq | yeah but then you have the similar problems as all the scripting languages |
| 10:43:03 | Araq | depends on a version of nimrod-jit then for no good reason |
| 10:43:49 | Araq | but as I said, 'nirmod i myfile.nim' already works for toy examples ;-) |
| 10:44:11 | Araq | it's no JIT though but a simple AST based interpreter |
| 10:47:54 | Araq | however libMAN, I'm evaluating PCC as an embeded C compiler for Nimrod |
| 10:48:27 | Araq | tiny C used to work but is not maintained anymore and never really worked on windows |
| 10:51:20 | Araq | configure: error: 'x86_64-unknown-linux-gnu' is not (yet) supported by pcc. |
| 10:51:23 | Araq | lol |
| 10:54:37 | Araq | something is wrong here ... the configure script is "only" 6800 lines instead of 40000 |
| 11:10:53 | libMAN | What I described is not JIT in a tradition sense, more like compile-on-demand with a shebang program managing the compile, caching, and execution. |
| 11:11:24 | Araq | I think somebody wrote just that for nimrod |
| 11:11:25 | libMAN | *traditionAL |
| 11:12:39 | libMAN | interesting |
| 11:12:51 | Araq | can't remember its name though :-/ |
| 11:13:22 | Araq | however nimrod already caches the generated C code for you and only recompiles what's necessary |
| 11:14:05 | Araq | it also performs a parallel build |
| 11:14:10 | libMAN | What I'm thinking of is having all the conveniene of a script but with the advantages of compiled execution behind the scenes. |
| 11:14:26 | Araq | there was some issue with: |
| 11:14:30 | libMAN | (A disadvantage of course being long startup the first time you run it.) |
| 11:14:32 | Araq | #! nimrod c -r |
| 11:14:43 | Araq | but I can't remember |
| 11:15:15 | libMAN | *convenience |
| 11:15:50 | libMAN | The closer people are to the source (as they are with scripting languages) the better. They can see what they're executing. |
| 11:16:09 | Araq | PCC doesn't seem to support x86_64 ... that's a showstopper |
| 11:16:20 | libMAN | Yeah, I hear PCC is far from ready. |
| 11:16:48 | Araq | luajit is looking more and more attractive ... |
| 11:17:05 | Araq | though it'll look weird as a dependency |
| 11:17:13 | libMAN | And ACK (Amsterdam Compiler Kit) has been stoned for years... |
| 11:20:21 | libMAN | Also that nimrod-jit would be great for detecting nimrod / library / etc version changes and recompiling. |
| 11:21:09 | libMAN | It would also make it easier to do compile-time configuration. If a <config.h>-like file changes, it recompiles. |
| 11:23:00 | libMAN | It would also make it easier to document installing / upgrading across multiple platforms (not counting installing Nimrod itself of course). No need to install a Nimrod-based app from ports, pkgsrc, etc - just sync up the source and run it via shebang. |
| 11:23:46 | libMAN | Although an install process could precompile it to assure fast startup. |
| 11:24:38 | libMAN | And the next level of awesomeness is an app that recompiles itself and updates its executable code without restarting! |
| 11:25:10 | libMAN | I hear facebook does something like this. |
| 11:27:02 | libMAN | Middle-of-the-road solutions like luaJIT can never compete with compiled C (even with GC and other Nimrod-related overhead). |
| 11:27:51 | libMAN | Compile time is becoming less and less of an issue, while performance of hosted apps is $$$. |
| 11:31:04 | libMAN | Sorry for so many "comments from the peanut gallery", I just have lots of high-level conceptual ideas for making a business care for a new language / platform. |
| 11:31:14 | libMAN | s/care/case/ |
| 11:41:01 | Araq | you are aware of Nimrod's excessive compile time features, right? |
| 12:34:18 | libMAN | Sorry, I haven't had much time to study Nimrod in-depth yet. |
| 12:34:54 | Araq | np |
| 12:35:06 | libMAN | Can't call it a part of my arsenal yet, you know, the license issue. |
| 12:38:39 | fowl | whats the license issue |
| 12:40:21 | libMAN | Nimrod is still GPL. |
| 12:40:55 | libMAN | Can't have a serious programming language with a copyleft license. |
| 12:42:46 | fowl | how does nimrods license matter for projects written in it |
| 12:44:13 | libMAN | It's not just the legal restrictions, it's the philosophical implications of the license. |
| 12:44:35 | fowl | oh right |
| 12:44:48 | fowl | i forgot about the philosophizing |
| 12:52:10 | Araq | fowl: you can't hack the compiler itself and commercialize it without contributing the changes to the compiler back |
| 12:52:54 | Araq | that's pretty much the GPL restriction; the stdlib is not affected by this nor are your programs written in nimrod |
| 12:53:22 | fowl | can you distribute programs compiled in it |
| 12:53:42 | Araq | yes of course |
| 12:54:49 | Araq | not only distribute it, but *sell* it and keep the source closed |
| 14:51:04 | * | zahary joined #nimrod |
| 14:51:37 | Araq | hey zahary |
| 14:51:55 | zahary | hi |
| 14:52:10 | Araq | it's been a while |
| 14:52:31 | Araq | I'm too busy at work to talk |
| 14:52:41 | Araq | and you're not here in the evening |
| 14:53:00 | zahary | yeah, I've missed a lot of latest action |
| 14:53:15 | Araq | anyway, dom96 says you can push a branch and nimbuild will recognize and run the tests over it |
| 14:53:56 | zahary | I'd like to merge my branch, because conflicts are becoming too common |
| 14:54:27 | zahary | I'll run the tests locally before committing to make sure nothing is broken |
| 14:55:18 | Araq | hm |
| 14:55:35 | Araq | alright |
| 14:56:53 | Araq | so back to the GC issues: we must not conflate graph prunning for the cycle collector ('prune') with "no cycle root" = 'acyclic' |
| 14:57:22 | Araq | and indeed pruning is impossible for PNode |
| 14:58:10 | Araq | so I guess the solution is to turn off the cycle collector and turn it on between CAS runs or something like that |
| 14:59:04 | Araq | I thought about writing a simple mark&sweep GC to benchmark against |
| 14:59:26 | libMAN | GPL is a vast communist conspiracy to subvert our precious bodily fluids. :P |
| 14:59:46 | Araq | but I wasn't motivated enough because that only works easily in single threaded mode |
| 15:00:07 | Araq | for multi-threading you need to trace roots in thread local storage and that's a bit tricky to implement |
| 15:00:48 | Araq | for the single threaded case the compiler can easily emit 'registerGlobalRoot(&x);' for every global variable |
| 15:03:19 | zahary | yes, my plan is to either turn it off completely or set a high threshold like 512MB and then just to call FullCollect after the caas recompilation |
| 15:07:01 | zahary | TLS variables doesn't sound much harder than regular globals. we still have a lot of points in the codegen where we can intercept them and register them. also thread creation is already managed |
| 15:08:53 | Araq | hm true |
| 15:20:29 | Araq | btw I got 'unsafeNew' to work with ropes (was a trivial bug) and it didn't improve anything |
| 15:20:53 | Araq | likely because we already cache leaves |
| 15:21:09 | Araq | so the 1 allocation instead of 2 per leaf doesn't gain anything |
| 15:22:09 | Araq | and with it you can't have: 'newMutableRope + freeze' |
| 15:26:12 | zahary | so, you are backing off from the optimization? can you remove the large when true/false: block in ropes.nim so I won't have conflicts there |
| 15:28:23 | Araq | he he, alright |
| 15:31:06 | Araq | oh we also have a horrible scoping issue wrt generic instantiations |
| 15:31:45 | Araq | we instantiate generics within the semantic pass which means lots of scopes from the instantiating proc are still open |
| 15:32:10 | Araq | use --warning[shadowIdents]:on to see this effect |
| 15:32:41 | Araq | but you wanted to change the symtab implementation anyway, right? |
| 15:36:02 | zahary | yes, if you remember there was also a bug with immediate templates and identifiers that are inserted by them, which also can benefit from the new symtab implementation |
| 15:36:20 | zahary | immediate templates within generics |
| 15:38:53 | Araq | I remember, can't see how it can be fixed though |
| 15:39:54 | Araq | we also still have issues with nkBracketExpr vs. nkCall(`[]`) as seen by #297 |
| 15:41:11 | zahary | I don't need 2 passes if you can accurately refer to the generic definition scope |
| 15:41:17 | zahary | you don't |
| 15:41:41 | Araq | I'm still afraid of this idea :P |
| 15:41:58 | Araq | but I won't fight it anymore |
| 15:44:05 | zahary | isn't #297 just about some missed case in semBrackerExpr? |
| 15:45:01 | Araq | haven't really looked into it yet but I think nkCall(`[]`) needs to work with builtin arrays |
| 15:45:13 | Araq | for the error to disappear |
| 15:45:38 | Araq | there is no system.`[]` for built-in types |
| 15:53:12 | Araq | but yeah, it should be easy to fix |
| 16:10:51 | Araq | so zahary, people demand a license change |
| 16:11:21 | Araq | what's your opinion? |
| 16:24:28 | NimBot | Araq/Nimrod 774643b Araq [+0 ±1 -0]: old version of ropes.nim to prevent merge conflicts |
| 16:31:13 | zahary | I think the compiler should stay GPL and the library should use some permissive license like BSD, Apache, Boost, etc |
| 16:32:25 | zahary | if FSF layers get after us, they will claim that macros are linked with the compiler :) |
| 16:33:18 | zahary | if we want to be anal about it, we can explicitly say in the license that macros are not considered derivative works |
| 16:36:52 | Araq | well the planned runtime.eval feature requires the compiler to become at least LGPL |
| 16:39:15 | zahary | the linux kernel have clauses like the one I desribed in order to support binary drivers |
| 18:05:46 | libMAN | Sorry, if any part of it is (L)GPL then I won't use it. |
| 18:06:01 | apotheon | I don't think those clauses quite work in this case. The reason they seem to work for the Linux kernel is the fact the driver modules are loaded separately instead of compiled into the kernel. |
| 18:09:37 | * | apotheon needs to re-read the LGPL and see if even that would work if part of the compiler is compiled into the software. |
| 18:10:29 | Araq | apotheon: I think it won't but Nimrod's version of the LGPL has a special clause to permit static linking |
| 18:10:51 | apotheon | Araq: Link to that version . . . ? |
| 18:11:01 | apotheon | . . . or is it at least in a place that's easily found? |
| 18:11:25 | libMAN | I personally don't even care about the level of restrictiveness, since I've never closed-source-forked anything in my life and never will. |
| 18:11:43 | libMAN | It's the validation of the restrictiveness that I have a problem with. |
| 18:11:52 | Araq | https://github.com/Araq/Nimrod/blob/master/lib/copying.txt |
| 18:12:38 | Araq | also Nimrod's GPL is version 2, not some arbitrary later version of the license |
| 18:12:54 | Araq | I removed that 'or later' part from it |
| 18:13:22 | libMAN | Homesteading the noosphere with restrictive licenses is a bad precedent for many new forms of government interventionism in the software industry. |
| 18:13:35 | zahary | libMAN, what are you reasons for staying away from GPL? |
| 18:13:45 | apotheon | Araq: Good call on removing the "or later" when it comes to the GPL. As bad as it is, it's pretty much guaranteed to get worse in later versions. |
| 18:14:28 | libMAN | There are many, but all of them are idealistic matters. |
| 18:14:39 | apotheon | Araq: Is that exception modeled on the exception text for GCC? |
| 18:14:53 | apotheon | for GCC libs, that is |
| 18:15:01 | apotheon | (before the recentish license change for GCC and libs) |
| 18:15:03 | zahary | apotheon, in the end, it's our license. GPL texts exist as a convenience for software projects that have similar goals. anyone can set their own terms on top of GPL |
| 18:15:53 | libMAN | To me the software stack that I specialize in is an extension of myself. GPL is a product of ideology, and it doesn't work on a pragmatic level either. |
| 18:15:56 | apotheon | zahary: Uh . . . what? You seem to be responding to me, but I'm not sure what I said to which that was a meaningful response. |
| 18:16:19 | zahary | I was responding to "I don't think those clauses quite work in this case" |
| 18:17:02 | apotheon | zahary: Ah, that was long enough ago I didn't realize you were responding to it. Sorry. |
| 18:17:56 | libMAN | Without going into whether GPL would be enforcable in a more rational legal system, yes, of course it's "your license". But I like nimrod and want to offer you my feedback on what makes the difference between it being my primary server-side language and me avoiding it completely. |
| 18:17:59 | apotheon | zahary: The problem is that you referred to the Linux kernel clauses which cover a different legal relationship than the one you're proposing. You'd need something significantly different to cover this case, I think, if you want it to stand up in court. |
| 18:18:35 | apotheon | zahary: If the legal rigor of your license clauses is not substantial, people with lawyers will then avoid the relevant work for fear of later litigation. |
| 18:19:28 | zahary | we are discussing the problem of executing macros during compilation, right (with the added possibility to call into arbitrary code by FFI)? |
| 18:20:32 | apotheon | I believe so. |
| 18:20:47 | Araq | er ... no? |
| 18:20:55 | apotheon | Oh, wait. |
| 18:21:00 | apotheon | You said "during compilation". |
| 18:21:14 | apotheon | I was thinking of "macros" in code, metaprogramming-style. |
| 18:21:18 | Araq | there is no problem with compile time 'eval' and the compiler being GPL afaik at least |
| 18:21:34 | zahary | so what's the problem we discuss here? |
| 18:21:36 | apotheon | Yeah, there shouldn't be any such problem with *compilation*. It's runtime. |
| 18:21:40 | Araq | there is a problem with a runtime version of 'eval' |
| 18:21:58 | Araq | (which doesn't exist yet) |
| 18:22:18 | apotheon | zahary: Think "eval" like in Perl and Ruby (for example). |
| 18:22:57 | apotheon | zahary: I don't know of a way to make that work with binary compilation that doesn't involve including a runtime parser of the language. |
| 18:23:06 | zahary | aha, so you are discussing something as libnimrod |
| 18:23:08 | apotheon | zahary: . . . or equivalent trickery. |
| 18:23:42 | zahary | LGPL would be good for that indeed |
| 18:24:44 | apotheon | LGPL definitely applies to single-file works, which would include things like a binary executable -- so, as I said, I'm not sure it applies in this case. |
| 18:25:06 | zahary | back on the macros issue, I think standard GPL prevents the idea of closed source plugins for GPL programs. one can easily call the macro system a form of plugin |
| 18:26:11 | zahary | I meant, LGPL for a libnimrod library which allows you to compile, analyse and execute nimrod code at runtime. this library is linked with your executable |
| 18:26:25 | apotheon | What -- dynamically linked? |
| 18:26:33 | zahary | yes |
| 18:26:56 | apotheon | . . . so the only way people are allowed to use runtime eval is with a dynamically linked library being lugged around with the binary? |
| 18:27:29 | zahary | considering the fact that it will weight at least 1MB, it's good idea to not link it statically anyway |
| 18:27:47 | apotheon | Sure, unless you *need* a single-binary distribution scenario. |
| 18:27:55 | apotheon | Those do happen. |
| 18:34:23 | zahary | the need for runtime eval is rare enough. you add another rare need on top of that. obviously, more permissive license will solve the problem here, but it should also be obvious why it's beneficial for us to retain some control over the code with a copyleft license |
| 18:36:50 | Araq | zahary: using nimrod as a scripting language has been requested here and I'm working on improving both the features and the speed of the evaluation engine |
| 18:37:05 | zahary | what is the exact request? |
| 18:37:36 | Araq | embedding nimrod like lua |
| 18:37:36 | zahary | I think it's a good idea to have a "run" mode for the compiler that caches the compiled program somewhere |
| 18:37:46 | zahary | but embedding nimrod, why? |
| 18:38:23 | apotheon | It's obvious that people think it's important to maintain such control. |
| 18:39:08 | apotheon | zahary: Maybe because someone likes the language enough to want to use it in a case where an embedded language is needed. |
| 18:39:09 | Araq | because a statically typed scripting language is cool? :-) |
| 18:39:37 | apotheon | It sure is. |
| 18:40:01 | libMAN | Araq: "a statically-typed scripting language" that you can trust and use for whatever you want "is cool". |
| 18:40:02 | apotheon | I like the way OCaml can be binary compiled, bytecode compiled and run in a VM, or interpreted. |
| 18:40:45 | libMAN | OCaml - yet another example of a GPL language going nowhere. |
| 18:41:28 | Araq | for instance you have an AI script, tune it, interpret it in your engine and once it's too slow or finished you compile it into the core |
| 18:41:34 | libMAN | See how its popularity compares to Haskell. |
| 18:41:35 | zahary | but why should I compile the my code? I have plans for plugin system that's very easy to use. that's what we should suggest as end-user extensibility path. why should end users have the degraded performance that will come from an interpreter? |
| 18:42:11 | zahary | * but why shouldn't I compile my code? * |
| 18:42:30 | libMAN | A programming language is a relationship. People don't like having their options closed. |
| 18:42:39 | Araq | the key difference are the REPL features here IMO |
| 18:42:58 | Araq | in a REPL the global state is kept for you |
| 18:43:22 | zahary | I have a plans for REPL too - it's part of the IDE, not the shipped software |
| 18:43:41 | zahary | the IDE does the REPL stuff and it communicates with the running program |
| 18:44:22 | zahary | shipping interpreters to end users just strikes me as a inefficient solution |
| 18:44:47 | Araq | well but many games ship with Lua, right? |
| 18:45:24 | q66 | [19:40:45] <libMAN> OCaml - yet another example of a GPL language going nowhere. |
| 18:45:27 | Araq | and it's often also the base for a modding community |
| 18:45:28 | q66 | but not because of the GPL |
| 18:45:37 | apotheon | libMAN: Yeah, the licensing for OCaml is kind of a problem. |
| 18:45:38 | q66 | more like because of a global lock in its runtime |
| 18:45:41 | zahary | due to lack of better alternatives, the driver for the decision is faster code-test cycle (you can reload the scripts without restarting the game) |
| 18:46:02 | zahary | but I want to change that in the way I described it above |
| 18:46:30 | Araq | yes exactly what I mean: the level is already running and you can tweak things on the fly |
| 18:46:37 | zahary | better plugin system and ongoing communication between the IDE and the running program with hot reloading of code |
| 18:46:47 | apotheon | Araq: . . . and I agree, re: importance of a REPL. I love those things. |
| 18:46:51 | q66 | Araq, typing is cool, but untyped languages give you a new degree of flexibility in a way |
| 18:47:04 | q66 | everything can be heterogenous, you can inject things dynamically, patch things dynamically |
| 18:47:06 | apotheon | zahary: IDE . . . ? I'm a vi user. No IDE here. |
| 18:47:13 | q66 | doing that with a type system gets tedious |
| 18:47:27 | Araq | q66: in my experience the "flexibility" mostly results in annoying uncaught typos |
| 18:47:58 | zahary | the "IDE" mechanics are built-in in the compiler service - vim or any other editor talks to a long-running nimrod compiler process |
| 18:48:06 | q66 | Araq, *shrugs* i barely make potential "type errors" in my code these days |
| 18:48:15 | q66 | stuff has to be written a bit differently |
| 18:48:21 | q66 | and you need strict rules |
| 18:48:22 | Araq | I make typos all the time :P |
| 18:48:49 | Araq | with dynamic typing I spend considerably more effort to ensure I did spell everything right |
| 18:48:53 | q66 | Araq, i write code modularly enough so that you can evaluate the whole script easily and catch various errors |
| 18:48:53 | apotheon | Araq: In my experience, the "flexibility" is very flexible. Of course, I'm speaking of certain dynamically typed languages, which q66 insists on calling "untyped", and not languages like JavaScript where you have to suppress a snicker to suggest it has anything like a meaningful type system. |
| 18:48:59 | q66 | Araq, tests help too |
| 18:49:04 | zahary | my opinion is that your requests for run-time eval are just because you haven't seen the better alternative that's possible |
| 18:49:24 | q66 | of course, it's more error prone, i'm not arguing that. |
| 18:49:38 | q66 | it gives you some benefits for some cost. |
| 18:49:43 | apotheon | Wow, this conversation has gotten really difficult to parse. |
| 18:51:01 | apotheon | I guess I'll just drop the extant threads of discussion and ask . . . is there a test framework for Nimrod yet? |
| 18:51:27 | Araq | apotheon: http://build.nimrod-code.org/ |
| 18:51:32 | q66 | [19:49:43] <apotheon> Wow, this conversation has gotten really difficult to parse. |
| 18:51:38 | q66 | no wonder, it doesn't seem too context free :P |
| 18:52:06 | libMAN | q66: maybe, but look at the data. Copyfree projects are outperforming copyleft ones. |
| 18:52:41 | q66 | apotheon, well, that was a shitty language grammar / parser joke. |
| 18:52:43 | q66 | :) |
| 18:52:59 | q66 | libMAN, huh |
| 18:53:12 | q66 | i don't think the license determines the success of majority of projects in any meaningful way |
| 18:53:19 | q66 | good software is popular because it's good |
| 18:53:37 | q66 | and bad software is sometimes popular because people consider it good :P |
| 18:53:43 | libMAN | http://en.wikipedia.org/wiki/List_of_Chinese_administrative_divisions_by_GDP_per_capita#GDP_per_capita_comparisons_with_sovereign_countries |
| 18:53:46 | libMAN | oops |
| 18:53:52 | libMAN | http://www.itworld.com/it-managementstrategy/233753/gpl-copyleft-use-declining-faster-ever |
| 18:54:02 | Araq | zahary: how does persistent state work with your scheme? the compiler emits 'getGlobal("varname")'? |
| 18:54:19 | libMAN | Sorry, I just switched to a console IRC client, and paste works a little differently... |
| 18:54:59 | q66 | libMAN, that just says people are leaving GPL |
| 18:55:18 | q66 | there is no relation to license directly affecting software popularity |
| 18:55:26 | zahary | Araq, you mean "how persistent state works with code reloading"? or how does it work with REPL? |
| 18:55:44 | Araq | how are these 2 different questions? |
| 18:55:45 | q66 | btw, it's annoying how often that article uses the acronym "FLOSS" |
| 18:56:17 | libMAN | Copyfree software is growing in market share too. (Except in the kernel department. Linux still has too much momentum.) |
| 18:56:31 | q66 | also, there are different copyleft licenses than GPL, too |
| 18:56:44 | q66 | most of them aren't as viral as GPL |
| 18:56:48 | zahary | well, code reloading is often just about changing the definition of some function - so you need indirection in function calls to make the body swappable |
| 18:57:23 | libMAN | q66: obviously. Look at the numbers. |
| 18:57:33 | zahary | next level of code reloading will be to reload a bigger "module" that may also have global variables |
| 18:57:54 | zahary | there are number of approach here that are not really different than what we do with lua |
| 18:58:32 | q66 | libMAN, still, as i said, the GPL is most likely not the reason ocaml isn't so successful |
| 18:58:39 | zahary | sometimes you have modifiers on the variable initialisations that say "[only the first time] globalX = ….." |
| 18:58:42 | q66 | your article just says new projects tend to use copyfree licenses more |
| 18:58:47 | zahary | "[every time] globalX = …. " |
| 18:59:17 | zahary | another tool is to reuse the game save mechanics to capture the state of an entire subsystem in the game |
| 18:59:48 | zahary | then reloading becomes "save world; reload; load world" |
| 19:00:33 | zahary | all of these are very project specific, I believe the programmer should a set of APIs that control the whole process |
| 19:00:59 | apotheon | q66: I thought it was a pretty good language grammar/parser joke. |
| 19:01:10 | zahary | REPL on the other hand is another thing - the main concern there is how do you find the address of the globalX that you used in your REPL expression |
| 19:01:30 | zahary | so, there needs to be some form of run-time reflexion registry |
| 19:02:10 | apotheon | q66: I suspect that language popularity affects license more significantly than license affects popularity. |
| 19:02:34 | q66 | apotheon, yes, exactly |
| 19:03:50 | zahary | it should go without saying that all of this is activated only in developer builds of the program |
| 19:03:55 | apotheon | I have a hypothesis about the shift in licensing trends, by the way. |
| 19:05:34 | * | gradha joined #nimrod |
| 19:06:39 | apotheon | Early on in the growth of open source software, there was not much critical examination of licensing, so people basically just used whatever was put in front of them. This meant that people writing stand-alone C libraries and programs often used the license that came with GCC, people writing X toolkits often used the MIT/X11 License, and people writing core tools for BSD Unix often used the BSD |
| 19:06:45 | apotheon | License. |
| 19:07:40 | apotheon | We still see a lot of the same stuff going on with language implementations -- a lot of software is written and released with a COPYING file that says "distributed under the same terms as $foo" where $foo is the language in which it was written. Perl modules and Ruby gems all over the place carry that kind of notice, for many examples. |
| 19:09:29 | apotheon | Over time, the "viral" nature of the GPL led to a lot of software that made use of existing libraries having to use the same license as the library, so that the GPL proliferated. Over time, though, awareness of licensing issues (license incompatibility, for instance) grew. The OSI, somewhat ironically (given its community's pro-copyleft bias, much of its community made up of FSF supporters who |
| 19:09:35 | apotheon | don't really write code and Linux coders who aren't very aware of much of the rest of the world of coding), contributed to this growing awareness. |
| 19:09:59 | zahary | also, permissive licenses are gaining market share because high-profile companies like Google and Apple now releasing software this way |
| 19:10:27 | zahary | it's easier to release something under BSD when you have hundreds of engineers working on it |
| 19:10:51 | apotheon | People started working on reimplementing some of the common GPLed and otherwise copyleft libraries out there, even as the GNU project and various Linux-related projects worked on reimplementing strictly EULA enforced proprietary systems, so that there was a small but growing trend in more-permissive license terms for new implementations of things that already existed. |
| 19:11:02 | zahary | our situation here is different, because we are just a bunch of guys working in our free time |
| 19:11:34 | apotheon | ( for obvious reasons: http://univacc.net/?page=license_simplicity_1 and http://blogstrapping.com/?page=2011.060.00.28.21 ) |
| 19:13:04 | apotheon | Big corporations and small enterprises were both involved in that sort of small-current, behind the scenes migration, as they wanted to have open source libraries available that were not subject to the restrictions of the GPL, though many of the larger corporations chose to use non-GPL copyleft licenses specifically because they wanted to keep others from competing with them using their own code. |
| 19:14:16 | apotheon | Over time, though, the dependence on early-written GPLed and even LGPLed libraries waned as copyfree and otherwise "permissive" (non-copyleft open source, anyway) licenses proliferated amongst dependency alternatives. As that happened, people who wrote code that depended on such things found they actually had licensing options. |
| 19:16:15 | apotheon | As such, the "Well, I really want to use license $foo, but I'm stuck with license $bar unless I want to cleanroom reimplement the libraries involved" problem became less and less of an impediment. The end result, as we're seeing, is faster and faster proliferation of less restrictive license terms in software, as every increase in available dependencies under such licenses enables more people to |
| 19:16:21 | apotheon | use the less restrictive licenses they want to use, creating a virtuous circle condition. |
| 19:17:25 | apotheon | Right now, the main direction of influence between popularity of a project and licensing seems to be (popularity -> licensing), such that the more popular it is the more pressure there is on changing the licensing to something less restrictive so that more people can make use of it. |
| 19:18:35 | apotheon | I think there'll come a tipping point, though, where that relationship will tend to reverse, becoming (licensing -> popularity), because there will be enough less restrictively licensed options in most cases that people won't care about changing the licensing of restrictively licensed projects; they'll just use a less restrictively licensed project that already exists, instead. |
| 19:19:10 | gradha | Araq, dom96: wrt github development branches, I don't see what's the problem with master being unstable, if people check out from git they will use the instructions, so lets add a "git checkout stable" step and be done with it |
| 19:19:46 | Araq | so you propose a stable branch and be done with it? |
| 19:19:56 | Araq | and 'master' stays the devel branch? |
| 19:20:13 | gradha | Araq, dom96: other than that, you can have multiple repos on github, and a "stable" repo "following" the development one, only being updated at specific milestones. I think this is overkill though |
| 19:20:16 | gradha | yes, not many people use git, those who do know "there may be dragons" |
| 19:20:47 | gradha | also, keeping master "stable" tends to be more error prone than a separate stable branch |
| 19:21:28 | apotheon | So . . . there's my hypothesis about shifting license popularity. |
| 19:21:43 | gradha | now, having said that, most of the repos I have use "master" as a stable, but only because I'm the only one using them so I presume to know what I'm doing |
| 19:22:19 | gradha | anyway we are going to use fossil, right? let's ditch github, they are so unprofessional |
| 19:22:45 | Araq | well we're not switching anytime soon |
| 19:22:55 | Araq | our build infrastructure now relies on github |
| 19:23:21 | Araq | you can't take my rants that serious :P |
| 19:23:39 | gradha | meh |
| 19:24:03 | gradha | so going back to licenses: i prefer licenses which require you to listen to kpop/jpop at least once a day, to keep the insanity level high |
| 19:24:43 | dom96 | nah, lets move back to launchpad. |
| 19:24:58 | dom96 | Use the good ol' bazaar :P |
| 19:25:05 | apotheon | Fossil's cool. |
| 19:25:15 | gradha | i dislike launchpad, they borked my email access and can't update any bugs I filed |
| 19:25:19 | apotheon | ugh, launchpad |
| 19:25:38 | apotheon | I've actually been (putting off) working on a project to set up a code hosting site that uses Fossil. |
| 19:25:57 | gradha | apotheon: doesn't fossil already have one? |
| 19:26:18 | gradha | http://chiselapp.com |
| 19:26:33 | apotheon | The Chisel site, frankly, *sucks*. |
| 19:26:44 | gradha | oh, in what ways? |
| 19:27:05 | gradha | ah, AGPLv3, hehe |
| 19:27:06 | apotheon | It's hard as fuck to use, comes without any of the handy "social coding" collaboration support of the others . . . |
| 19:27:13 | apotheon | Licensing, too, as you noticed. |
| 19:28:07 | dom96 | gradha: Araq: In regards to the dev branches, it seems like maintaining that 'stable' branch will be quite a chore and it will simply end up being quite old all the time. |
| 19:28:22 | apotheon | That whole "pull request" workflow for outside contributions greatly lowers the bar for people who want to contribute to projects, and lacking the smooth support for that kind of thing is kind of a deal-killer. |
| 19:28:34 | gradha | dom96: isn't that the point? something which doesn't change often and is really old |
| 19:29:23 | gradha | apotheon: I'd say that's the reason github got so big so fast, also probably because initially git commandline wasn't friendly at all |
| 19:29:54 | dom96 | gradha: Yes, but it should get the latest features as soon as they are stable. Otherwise people might as well 'git checkout v0.9.0' |
| 19:30:34 | gradha | AFAICS tags are just like keeping a stable branch, since you are going to merge into the stable branch at the same time you make the tag |
| 19:30:51 | gradha | unless you really want to keep development stuff in master and cherry-pick to stable, but then you wouldn't tag |
| 19:30:58 | apotheon | gradha: Git's command line interface still isn't the friendliest. |
| 19:31:34 | gradha | at least it's bereable, after several trips to man pages and forums |
| 19:32:09 | dom96 | gradha: So you basically want the 'stable' branch to be the latest released nimrod version? |
| 19:32:31 | gradha | isn't that the definition of stable? |
| 19:33:03 | apotheon | gradha: true |
| 19:33:16 | Araq | dom96: it's quite easy to know if a bugfix will break code or not |
| 19:33:25 | apotheon | gradha: It's kinda tricky sometimes if coming from another DVCS, though, because of the magical incantation extra steps that need to be taken sometimes. |
| 19:33:30 | gradha | in fact, I don't understand anybody using git (or any other scm) and wanting stuff to be stable, but then, github disabled downloads |
| 19:33:38 | Araq | so these bugfixes will be backported to the stable branch |
| 19:33:52 | dom96 | Ideally what would be nice is for the stable branch to contain trivial additions like my constant additions to the gtk wrappers. |
| 19:33:56 | apotheon | Wait -- what? Did GitHub really disable downloads? |
| 19:34:02 | * | apotheon goes to look at GitHub. |
| 19:34:21 | gradha | a repo/branch being stable really means: "I'm to lazy to bother with zip files but I like to be on the not so very edge version and run a single command to update all" |
| 19:34:24 | dom96 | But according to gradha's definition it will basically point to the latest nimrod version, which is IMO pointless since you can simply check out the tag. |
| 19:34:39 | apotheon | Holy crap, I think it disabled downloads. |
| 19:34:46 | dom96 | apotheon: yeah, they have. |
| 19:35:00 | gradha | apotheon: you can still use the gh-pages branch for binary files, until they notice |
| 19:35:24 | apotheon | I wonder if it's because the GitHub people didn't want to be on the hook for GPL violations if someone deleted a repository before the $foo_years requirement for maintaining source availability after the last binary download. |
| 19:35:29 | apotheon | . . . or something like that. |
| 19:35:58 | apotheon | I'm not sure that makes any sense, though. The downloads are automatically generated compressed archives of source -- right? |
| 19:36:01 | apotheon | hmm |
| 19:36:23 | gradha | sometimes you need the download files to have extra generated content, so the github automatic file doesn't really cut it |
| 19:36:40 | apotheon | I don't use GitHub enough to notice these things, I guess. |
| 19:36:54 | gradha | think of generated documentation |
| 19:37:20 | apotheon | How is the download not having generated documentation any different from the repo not having generated documentation? |
| 19:37:39 | gradha | dom96: has anybody complained about current github master not being stable enough? |
| 19:37:55 | gradha | apotheon: precisely, you want the download to contain the pregenerated files, in case the user doesn't/can't generate them |
| 19:38:06 | gradha | so the automatic packaging github does is not enough |
| 19:38:42 | dom96 | gradha: I think so yeah, mostly when Araq accidentally broke bootstrapping for a while or something like that. |
| 19:38:48 | apotheon | I don't see any facilities for non-automatically generated downloads either, though. |
| 19:38:58 | apotheon | Am I looking in the wrong place? |
| 19:40:03 | gradha | since they removed uploaded binaries now you are supposed to go anywhere and click the "zip" button, like at https://github.com/Araq/Nimrod |
| 19:40:14 | gradha | that will zip the current checkout and give it to you in a zip |
| 19:40:37 | gradha | some time ago you had a separate "Downloads" button where you could upload files as admin of the repo |
| 19:41:17 | gradha | so in theory you go to a tag or branch and click on the zip button |
| 19:42:02 | apotheon | I'm confused. How is this any different from the automatic downloads interface of the past? |
| 19:42:11 | gradha | it wasn't automatic |
| 19:42:25 | gradha | you had the automatic option, plus you could upload random files |
| 19:42:41 | gradha | say, a big jpg file of bill gates |
| 19:43:26 | gradha | github decided this feature was getting too much abuse (silly bill gates accolites) and thus we have only the automatic packaging of the source |
| 19:43:53 | apotheon | ah |
| 19:44:03 | apotheon | I thought it was the automatic stuff that was supposed to have been eliminated. |
| 19:44:17 | apotheon | I think eliminating the manual stuff is much worse than eliminating the automatic stuff, actually. |
| 19:44:38 | gradha | yes, because nobody cares for the automatic version |
| 19:45:27 | gradha | https://github.com/blog/1302-goodbye-uploads |
| 19:45:53 | gradha | "Supporting these types of uploads was a source of great confusion and pain ? they were too similar to the files in a Git repository" |
| 19:46:15 | gradha | yes, so they removed the feature Apple-like because developers are morons who don't know how to handle downloads <facepalm> |
| 19:46:36 | apotheon | Wow, that is a weaselish explanation of why they disabled it. |
| 19:47:28 | gradha | in defense of github, you wouldn't believe how many jpgs of bill gates I have around here |
| 19:47:45 | gradha | it's truly confusing |
| 19:47:51 | apotheon | weird |
| 19:47:59 | apotheon | Of course, that's not at all the explanation they gave. |
| 19:50:19 | gradha | dom96: whenever araq breaks again the master he could just paste a big warning to the readme saying to checkout a specific early revision, or tag the previous working revision with a "stable" tag |
| 19:51:44 | gradha | a stable tag instead of a stable branch would be really confusing, though |
| 19:54:08 | Araq | there are permanent breaking changes planned though |
| 19:54:28 | Araq | it's not just about bugfixes but about language evolution |
| 19:55:34 | apotheon | new branch for every release that receives support (bugfixes, et cetera) distinct from mainline development |
| 19:55:49 | apotheon | That seems reasonable. |
| 19:56:22 | apotheon | I don't know that there needs to be any separate branching beyond that for download/use purposes. |
| 19:56:49 | apotheon | Am I missing the point? |
| 19:57:05 | Araq | don't think so |
| 19:57:13 | dom96 | gradha: Better yet, I will implement a little travis-ci-like image which shows the current build status and we can have that in the readme :) |
| 19:57:32 | gradha | sorry, what is a travis-ci-like image? |
| 19:57:38 | gradha | is it a trap? |
| 19:57:59 | dom96 | https://github.com/github/linguist#testing |
| 19:58:13 | dom96 | See that little build status image? |
| 19:58:26 | gradha | yes |
| 19:59:32 | gradha | I can imagine how much work goes into implementing that with nobody caring about the image later |
| 19:59:52 | gradha | wouldn't a link to the build farm be enough? |
| 20:00:20 | gradha | btw, I don't undestand the colors for the build farm, what is orange? |
| 20:01:08 | gradha | argh, I just clicked a hash and it started a download, thought it would give me info about the hash |
| 20:02:11 | dom96 | lol |
| 20:02:24 | gradha | another confusing thing is that the documentation link takes you to nimrod's library documentation, rather than documentation about the build farm, what it is, how to use it, etc |
| 20:02:50 | dom96 | I guess I should add some sort of About page |
| 20:03:09 | dom96 | The table at the top gives you links to the compiler binaries |
| 20:03:21 | dom96 | if the button is green it means its up to date |
| 20:03:25 | dom96 | i.e. build of latest commit |
| 20:03:49 | gradha | so I can get a not up to date windows x86 binary? |
| 20:03:56 | dom96 | yep :P |
| 20:04:04 | gradha | hmm... what does that mean? |
| 20:04:35 | dom96 | That means it's a build of the compiler which is perhaps months old |
| 20:04:53 | gradha | is it just the compiler or also documentation and tools? |
| 20:05:11 | dom96 | just the compiler and stdlib IIRC |
| 20:05:48 | reactormonk | Araq, argh, connect won't work nicely - no way to disconnect signals :-( |
| 20:05:50 | gradha | ok, these last lines explaining the colors, maybe you should paste them to the right/below the table |
| 20:06:09 | dom96 | yeah, will do. |
| 20:06:38 | gradha | the thing about orange not being updated, maybe a date would be more informative than a hash, or hyperlink another table with the full description, github commit, build log and download |
| 20:07:01 | gradha | after all, if the color is telling you something is not up to date, you might be interested in "how old" |
| 20:07:09 | gradha | a hash is not really meaningful for that |
| 20:07:43 | dom96 | Yeah, well you are downloading the build of a commit with that hash. |
| 20:08:12 | reactormonk | Araq, ah fuck it, I'll add that later if needed. |
| 20:11:49 | dom96 | gradha: but yeah, I agree. I will get around to improving it. |
| 20:16:22 | gradha | dom96: Araq said https://github.com/nimrod-code/babel/issues/2 might be due to files not having an extension, could that be to some stdlib proc ignoring such files? |
| 20:20:04 | dom96 | oh, forgot about that issue. |
| 20:20:14 | dom96 | let me take a look |
| 20:22:26 | dom96 | ahh yes. I see the problem. |
| 20:29:10 | NimBot | nimrod-code/babel 9e33051 Dominik Picheta [+0 ±1 -0]: Fixed #2 |
| 20:29:10 | NimBot | nimrod-code/babel a77adb8 Dominik Picheta [+0 ±2 -0]: Changed the directory of where packages are installed to ~/.babel |
| 20:29:18 | dom96 | gradha: there you go |
| 20:31:01 | Araq | hey it was a feature that ignored files without extension |
| 20:31:18 | Araq | in fact it should ignore any filename not fitting the 8.3 format |
| 20:31:45 | gradha | all bytes should be 7bit ascii too |
| 20:33:16 | dom96 | Araq: The 8.3 format? |
| 20:33:34 | Araq | dom96: DOS compatibility |
| 20:35:30 | gradha | Araq: wasn't it meant to store stuff in ~/babel? It's copying now to ~/.babel |
| 20:35:44 | Araq | you all wanted .babel instead |
| 20:36:03 | Araq | I'm the only one left who dislikes the very idea of hidden files ... |
| 20:36:32 | gradha | didn't we actually want ~/.config/hidden_preferences/nimrod/youshouldnotlookhere/stable/babel ? |
| 20:36:52 | gradha | it mimicks the import package hierarchy nicely |
| 20:37:45 | gradha | so next feature for babel: uninstall |
| 20:38:44 | dom96 | gradha: Too hard to remove a directory? :P |
| 20:39:05 | reactormonk | ... dafuq. http://sprunge.us/gPYX |
| 20:39:22 | gradha | especially after I'll have to tell people to cd into ~/.babel/epak-version/ and run "make install" beforehand |
| 20:41:07 | dom96 | I guess babel should do that... |
| 20:42:17 | gradha | uff, that's really problematic, especially if make install typically requires admin priviledges, I wouldn't bother |
| 20:42:46 | gradha | but a "cd `babel latest_dir packagename`" feature as suggested in https://github.com/nimrod-code/babel/issues/3 would be nice |
| 20:42:56 | gradha | not sure how that would work in windows |
| 20:43:16 | gradha | maybe you can change the current directory of the shell? |
| 20:43:57 | dom96 | why not simply provide a script which runs 'make install' followed by 'babel install'? |
| 20:44:27 | dom96 | Then all you need to tell your users is to run install.sh |
| 20:44:53 | gradha | but "babel install" downloads the stuff, *then* you go into the ~/.babel/dir and type "make install" |
| 20:45:16 | dom96 | oh yeah. |
| 20:46:27 | gradha | such is the problem with C dependencies. I considered putting everything into a big {.emit.} but thought that would be horrible |
| 20:47:38 | Araq | gradha: I used to merge all the C code into one big .c file and add {.compile: "thestuff.c".} |
| 20:48:05 | Araq | that's at least better then misusing 'emit' for this purpose |
| 20:48:33 | Araq | and nimrod computes a crc of the .c file and only recompiles it should it change |
| 20:48:44 | gradha | interesting, might try that |
| 21:02:27 | gradha | Araq: I'm reading about .compileTime. but no .compile. pragma, old docs? |
| 21:02:58 | Araq | .compile is quite old I think I forgot to document it |
| 21:03:10 | Araq | .emit is much more recent |
| 21:08:32 | gradha | oh, it's documented in the compiler user guide, not the manual |
| 21:09:18 | Araq | it's in the index :P |
| 21:09:27 | Araq | don't you use it? |
| 21:09:56 | gradha | I feel "git grep" is more reliable |
| 21:10:17 | * | Araq considers his index a masterpiece |
| 21:10:53 | gradha | the problem is knowing something is in the index |
| 21:12:22 | Araq | it's quite complete |
| 21:17:00 | dom96 | NimBot needs a doc gen feature :P |
| 21:22:22 | * | gradha quit (Quit: Leaving) |
| 21:22:45 | dom96 | er, doc search |
| 21:22:55 | Araq | ah that makes sense |
| 21:23:04 | * | dom96 hits self |
| 22:59:43 | NimBot | Araq/Nimrod 3e0b043 Araq [+0 ±2 -0]: 'sort' for ordered tables |