| 00:01:38 | BitPuffin | hehe |
| 00:04:21 | BitPuffin | Araq: does not solve the issue |
| 00:04:49 | filwit | i remember when there was less than 100 issues in the tracker... |
| 00:07:27 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:09:13 | * | carum joined #nimrod |
| 00:10:43 | * | EXetoC joined #nimrod |
| 00:17:54 | * | musicalchair quit (Ping timeout: 260 seconds) |
| 00:18:22 | * | brson quit (Ping timeout: 260 seconds) |
| 00:18:37 | * | brson joined #nimrod |
| 00:19:07 | * | musicalchair joined #nimrod |
| 00:20:11 | * | io2 quit () |
| 00:20:23 | * | zahary1 quit (Quit: Leaving.) |
| 00:20:47 | * | darkf joined #nimrod |
| 00:23:07 | * | carum quit (Remote host closed the connection) |
| 00:33:13 | * | vbtt quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 00:35:33 | renesac | vbtt: it seems I need a function that expects a closure iterator to use it |
| 00:36:41 | renesac | EXetoC, I wan't to pass a seq[int] to a function that expects a openarray[float], so the inner type needs to be converted |
| 00:36:51 | renesac | sorry for the delay in answering |
| 00:37:34 | * | zahary1 joined #nimrod |
| 00:40:07 | * | zahary quit (Ping timeout: 260 seconds) |
| 00:40:50 | * | carum joined #nimrod |
| 00:45:41 | * | carum quit (Remote host closed the connection) |
| 00:46:48 | * | carum joined #nimrod |
| 01:00:05 | EXetoC | renesac: I think you should just convert the elements. that's what you'll be doing either way |
| 01:02:09 | EXetoC | and now we have a more convenient map function called mapIt, in sequtils |
| 01:04:10 | renesac | yeah, but it introduces a memory overhead |
| 01:04:44 | renesac | a whole new seq must be allocated, created and then discarded before returning from the called function |
| 01:04:44 | Varriount | Pfft, optimize later. |
| 01:04:44 | EXetoC | you'll need to modify the proc then |
| 01:05:21 | renesac | actually, the proc accepts any type, but I want to run it as float |
| 01:05:22 | renesac | :P |
| 01:05:52 | EXetoC | yeah. a lot is copied by default, and most of the time it doesn't matter |
| 01:05:58 | renesac | (calculate the mean of a int array/seq) |
| 01:06:07 | renesac | for math.nim |
| 01:06:31 | renesac | I basically reimplemented 'sum' inside mean |
| 01:06:46 | renesac | but maybe there is a better way |
| 01:10:36 | EXetoC | something involving 'expr' params perhaps |
| 01:11:43 | EXetoC | I don't think there are many options at the moment when it comes to lazy container operations |
| 01:11:54 | renesac | ok |
| 01:12:10 | * | q66 quit (Quit: Leaving) |
| 01:12:40 | NimBot | Varriount/NimLime master 694417a Clay Sweetser [+0 ±3 -0]: Added the clear error command |
| 01:13:19 | EXetoC | I've been wanting to do something about that, but I'm waiting for for user-defined type classes |
| 01:19:12 | Varriount | EXetoC: We have user defined type classes. |
| 01:20:33 | EXetoC | I recall it being documented but not working |
| 01:21:47 | EXetoC | so people have been awfully quiet about it if it has indeed been fixed by now :p |
| 01:24:27 | EXetoC | because it seemed like an anticipated feature. I'll have to see if it works then |
| 01:26:46 | Varriount | EXetoC: It works, mostly |
| 01:26:47 | EXetoC | Varriount: and I mean the new feature which doesn't have anything to do with the old one. T|U|V seems user-defined to me, so the terminology is confusing |
| 01:27:09 | EXetoC | ok |
| 01:28:29 | EXetoC | well, it needs to be pretty solid for most things I imagine |
| 01:30:50 | renesac | well, templates are supposed to be stable, but I'm encountering bug after bug |
| 01:31:14 | renesac | reporting a new one now |
| 01:31:20 | EXetoC | I don't know who claimed that, but ok |
| 01:33:20 | EXetoC | the situation was a little better a couple of months ago IIRC |
| 01:33:59 | renesac | before the new VM? |
| 01:34:34 | EXetoC | possibly |
| 01:36:33 | renesac | well I hope all those problems have a single root that is fixed soon |
| 01:36:37 | renesac | ^^" |
| 01:39:11 | EXetoC | around the end of the month (next release) if I had to guess |
| 01:41:47 | filwit | renesac: master (or at least 0.9.2) uses a different VM to execute template/macro code than devel. The new VM still has quite a few bugs in it. |
| 01:42:08 | * | carum quit (Remote host closed the connection) |
| 01:42:15 | renesac | right |
| 01:43:19 | renesac | there is some explanation of the differences between VM1 and VM2? besides irc logs? |
| 01:43:55 | filwit | no, it's still actively in development and subject to change |
| 01:44:18 | renesac | ok |
| 01:44:46 | filwit | and the functionality wont change as far as use-code goes. It's just a lot faster (apparently ~10-20x speed improvement, so i've been told) |
| 01:45:21 | renesac | how that translates in the time need for the compiler compiles itself? |
| 01:45:27 | renesac | *compile |
| 01:45:37 | renesac | (well, I guess I could benchmark that myself... |
| 01:47:56 | Varriount | renesac: I'm confident that your questions will be answered when these three conditions become true: 1) Araq is satisfied with the VM; 2) People ask him to explain its internals; 3) Araq finds the time to write a new blog post; |
| 01:48:27 | renesac | yeah |
| 01:49:37 | renesac | in the mean time, I'm writing yet another template issue (one I stumbled a few days ago, so I'm trying to recreate it) |
| 01:49:49 | renesac | ^^' |
| 01:51:04 | filwit | renesac: yes, compile-time performance. |
| 01:51:05 | EXetoC | people sure like metaprogramming |
| 01:51:26 | renesac | well, that is the nimrod diferential |
| 01:51:44 | renesac | also the nice syntax |
| 01:52:42 | renesac | it is always a bad idea start listing things like that, because you will aways forget something important... |
| 01:52:46 | renesac | :P |
| 01:52:54 | renesac | so forgive me |
| 01:53:47 | Varriount | Yay! I finally fixed the bug in my nimcheck code that was causing sublime text to pause |
| 02:00:45 | * | zahary joined #nimrod |
| 02:00:46 | * | zahary1 quit (Read error: Connection reset by peer) |
| 02:05:03 | * | DAddYE quit (Remote host closed the connection) |
| 02:05:37 | * | DAddYE joined #nimrod |
| 02:09:10 | * | brson quit (Quit: leaving) |
| 02:10:19 | * | DAddYE quit (Ping timeout: 253 seconds) |
| 02:22:29 | reactormonk | how do I prepare a statement with do_sqlite? |
| 02:22:42 | reactormonk | insert. |
| 02:28:36 | reactormonk | how is the string templating again? let's do it this way. |
| 02:32:31 | renesac | why do I need {.immediate.} templates for overloading, if I'm not introducing any new undeclared variable? |
| 02:32:40 | renesac | https://github.com/Araq/Nimrod/issues/110 |
| 02:34:22 | reactormonk | renesac, because templates are inserted into overload resolution at the end of the file IIRC |
| 02:34:35 | renesac | actually, why not make all templates immediate? |
| 02:34:39 | EXetoC | reactormonk: tryInsertId(db, sql"...", ...) ? |
| 02:34:46 | reactormonk | EXetoC, sounds good enough |
| 02:39:39 | renesac | the documentation don't makes it clear |
| 02:40:19 | renesac | and "An immediate template does not participate in overload resolution" sounds like I shouldn't use {.immediate.} when I'm overloading |
| 02:40:31 | renesac | but it is actually the inverse |
| 02:40:48 | fowl | not sure how that changed |
| 02:41:31 | fowl | when* |
| 02:41:51 | renesac | I'm lookin at the build.nimrod-lang manual |
| 02:41:57 | renesac | and that bug report |
| 02:41:59 | renesac | :P |
| 02:42:10 | renesac | and my own code... |
| 02:42:40 | renesac | that worked after I added {.immediate.} but I don't know why |
| 02:43:07 | renesac | and why I should't put {.immediate.} in every template I write |
| 02:50:09 | * | eridu quit (Ping timeout: 240 seconds) |
| 03:00:40 | reactormonk | any way to get table.keys.join(", ") to work? |
| 03:09:28 | EXetoC | that's a similar issue. no I don't think so |
| 03:09:33 | * | carum joined #nimrod |
| 03:11:32 | EXetoC | toSeq to the rescue |
| 03:16:08 | * | DAddYE joined #nimrod |
| 03:16:29 | * | DAddYE_ joined #nimrod |
| 03:16:29 | * | DAddYE quit (Read error: Connection reset by peer) |
| 03:24:53 | reactormonk | EXetoC, popped an issue to github |
| 03:24:59 | * | nequitans_ joined #nimrod |
| 03:25:39 | nequitans_ | I think I have a noob question when trying to compile in C++ mode, but I'm not sure what to do at this point |
| 03:29:27 | fowl | nequitans, shoot |
| 03:29:28 | nequitans_ | I have a file that is just echo("Hello world") |
| 03:30:19 | * | aftershave_ joined #nimrod |
| 03:30:23 | nequitans_ | I run $ nimrod --opt:speed --parallelBuild:1 cpp file.nim |
| 03:30:44 | nequitans_ | Error: execution of an external program failed; rerun with --parallelBuild:1 to see the error message |
| 03:31:20 | nequitans_ | In verbose mode there are many errors |
| 03:31:23 | nequitans_ | here is an example: |
| 03:31:45 | nequitans_ | error: no matching function for call to 'nimFrame' nimfr("file", "file.nim") ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 03:32:46 | fowl | nequitans, i recommend the latest from github |
| 03:32:59 | nequitans_ | I see -- will try that out |
| 03:47:37 | nequitans_ | So after compiling with devel, it seems like an architecture/compiler issue: |
| 03:47:39 | nequitans_ | Undefined symbols for architecture x86_64: "std::terminate()", referenced from: ___clang_call_terminate in Nimrod-devel_system.o "vtable for __cxxabiv1::__class_type_info", referenced from: typeinfo for NimException in Nimrod-devel_system.o NOTE: a missing vtable usually means the first non-inline virtual member function has no definition. "___cxa_allocate_exception", referenced from: open_10003(__sFILE**, |
| 03:49:25 | * | aftershave_ quit (Quit: Computer has gone to sleep.) |
| 03:49:30 | fowl | i cant attest to devel, i tried it on the master branch and hello world ran fine |
| 03:51:00 | reactormonk | nequitans_, any reason why cpp over c? |
| 03:54:30 | nequitans_ | reactormonk, i'm compiling with some cpp code i want to also include |
| 03:55:42 | nequitans_ | fowl, i tried it on OS X, maybe on linux it works? will try that too |
| 04:04:35 | * | nande left #nimrod (#nimrod) |
| 04:06:23 | nequitans_ | fowl: interesting, it works on unix |
| 04:06:27 | nequitans_ | (devel that is) |
| 04:08:56 | reactormonk | Error: unhandled exception: node.kind == JObject [EAssertionFailed] |
| 04:08:58 | reactormonk | muh |
| 04:09:02 | reactormonk | nequitans_, O.o |
| 04:09:05 | reactormonk | nequitans_, file an issue |
| 04:10:31 | * | Demos joined #nimrod |
| 04:20:18 | * | carum quit (Remote host closed the connection) |
| 04:29:23 | renesac | nequitans_, did you try it with clang on linux? |
| 04:33:28 | reactormonk | is it just me, or are the stacktraces kinda off? |
| 04:52:44 | reactormonk | dom96, how exactly do I get a string representation of a json element? |
| 04:54:59 | fowl | $/pretty() |
| 05:02:03 | Demos | does nimrod have something like C's restrict keyword. This is an interop related question btw, I could ofc just use ptr foo's for foo * restricts but I wanted to know if nimrod had something like restrict |
| 05:04:50 | fowl | never heard of restrict |
| 05:11:40 | Demos | it tells the compiler that a pointer passed as a parameter does not alias any other parameters |
| 05:12:30 | Demos | the compiler DOES NOT VERIFY this, passing in two aliasing pointers can result in undefined behavior |
| 05:13:46 | Demos | essentially C and FORTRAN are in a pissing contest that FORTRAN kinda walked away from, C has not realized this and continues to add stupid "features" that make C "faster" while fortran adds things like OOP, modules, and lowercase |
| 05:14:23 | Demos | so now you know about restrict |
| 05:15:36 | fowl | hm. i dont even know when that would be useful |
| 05:16:02 | Demos | void doSomeArrayStuff(int* arrayone, int* array2) |
| 05:16:29 | fowl | but they are the same array? |
| 05:16:58 | Demos | the compiler can generate better code for some such functions if it knows that array1 and array2 point to different locations and that all pointers derived from them also point to different locations |
| 05:17:01 | Demos | right |
| 05:17:45 | Demos | for void doSomeStuff(int* restrict arr1, int* restrict arr2) |
| 05:18:19 | Demos | if arr1 and arr2 point to the same location, OR if ANY pointer derived from arr1 points to any pointer derived from arr2 by pointer arithmatic within the function you get UB |
| 05:18:21 | fowl | if(array1==array2)return; |
| 05:18:42 | Demos | not good enough |
| 05:19:25 | Demos | what if I call doSomeStuff(arr, arr + 5) then in the function I access arr[6] |
| 05:19:42 | * | nequitans_ quit (Ping timeout: 252 seconds) |
| 05:19:48 | Demos | in the restrict case I think the compiler can optimize out that if statement |
| 05:31:30 | * | Demos quit (Quit: Leaving) |
| 05:58:08 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 06:25:35 | * | ics joined #nimrod |
| 06:43:41 | * | carum joined #nimrod |
| 06:47:59 | * | carum quit (Ping timeout: 240 seconds) |
| 06:54:20 | * | carum joined #nimrod |
| 06:59:53 | * | filwit quit (Quit: Leaving) |
| 08:01:39 | * | dmac joined #nimrod |
| 08:04:25 | * | wan quit (Quit: leaving) |
| 08:07:29 | * | dmac quit (Ping timeout: 240 seconds) |
| 08:11:29 | * | gour joined #nimrod |
| 09:07:29 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 09:08:48 | rixx | hm, is there a specific reason that .. can only replace countup() but not countdown()? |
| 09:14:02 | * | io2 joined #nimrod |
| 09:41:41 | * | DAddYE_ quit (Remote host closed the connection) |
| 09:42:09 | * | DAddYE joined #nimrod |
| 09:46:31 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 09:47:35 | rixx | "User defined operators are allowed. Nothing stops you from defining your own @!?+~ operator, but readability can suffer." -- yup, having fun reading the tutorial :D |
| 10:04:20 | * | profmakx joined #nimrod |
| 10:08:39 | Araq | hi profmakx welcome back |
| 10:09:58 | profmakx | hi Araq |
| 10:17:09 | * | carum quit (Remote host closed the connection) |
| 10:18:01 | profmakx | has anyone written some code to deal with serial ports (i assume using termios or similar) |
| 10:18:21 | profmakx | alhtough doing the ioctls directly is probably not a big issue either if it need be |
| 10:22:30 | * | carum joined #nimrod |
| 10:27:30 | Araq | profmakx: were you the guy using the AVR target? |
| 10:29:22 | profmakx | Araq no |
| 10:29:43 | profmakx | I am happily using linux/dragonfly and a serial adapter that's plugged into usb |
| 10:30:06 | profmakx | i _might_ be very interested in compiling for avr |
| 10:31:36 | profmakx | after being fed up with python and C I started doing my thing in nimrod last night |
| 10:33:15 | * | ics quit (Ping timeout: 260 seconds) |
| 10:33:38 | Araq | profmakx: what's wrong with labeling avr a 16 bit cpu? its pointers are 16 bits wide |
| 10:35:23 | * | ics joined #nimrod |
| 10:36:33 | profmakx | Araq probably that all registers are 8 bit and to access a 16 bit memory location you have to assemble it from 2 8 bit registers |
| 10:36:51 | * | profmakx has a vague memory of calling an architecture n-bit if the accumulator is n bits wide |
| 10:39:22 | Araq | meh, makes little sense, but ok. |
| 10:39:47 | profmakx | would you consider i386 with PAE a 36-bit architecture :P |
| 10:40:03 | * | iNode000 quit (Quit: iNode000) |
| 10:40:36 | profmakx | I think one can live fine without calling things "x-bit architecture" and just agreeing on what the general purpose register size and the pointer width is |
| 10:48:37 | Araq | the pentium 3 with its SSE registers it's a 128 bit architecture then :P |
| 10:49:05 | Araq | imho only pointer size makes some sense |
| 10:49:19 | Araq | as a defining criterion |
| 10:51:13 | profmakx | wikipedia seems to agree with you to some extent. not that that would mean a lot :P |
| 12:25:04 | * | BitPuffin joined #nimrod |
| 12:42:47 | EXetoC | reactormonk: that's a very specific suggestion for a single proc, but ok |
| 13:17:32 | * | darkf quit (Quit: Leaving) |
| 13:20:52 | EXetoC | reactormonk: well, you or someone else labelled it a feature. it's vague, but I'm going to ask some questions and make suggestions regarding user-defined type classes in a new issue, and I think I'll of some relevance |
| 13:24:54 | EXetoC | where is zahary's blog? |
| 13:25:12 | EXetoC | I need to look through that article and see if it covers anything not in the manual |
| 13:33:25 | EXetoC | actually I think someone else wrote it |
| 14:05:34 | * | nequitans_ joined #nimrod |
| 14:13:56 | * | [1]Endy joined #nimrod |
| 14:15:26 | BitPuffin | ping Araq |
| 14:17:01 | * | [2]Endy joined #nimrod |
| 14:19:23 | * | [1]Endy quit (Ping timeout: 265 seconds) |
| 14:21:25 | Araq | BitPuffin: pong |
| 14:26:12 | * | [1]Endy joined #nimrod |
| 14:29:26 | * | [2]Endy quit (Ping timeout: 245 seconds) |
| 14:34:21 | * | brihat quit (Quit: Leaving.) |
| 14:35:41 | * | nequitans_ quit (Ping timeout: 245 seconds) |
| 14:35:45 | * | EXetoC quit (Ping timeout: 272 seconds) |
| 14:58:13 | BitPuffin | Araq: mark and sweep bootstrapping didn't help |
| 15:00:37 | Araq | BitPuffin: the better, bbl |
| 15:22:20 | * | dom96 quit (Excess Flood) |
| 15:23:54 | * | dom96 joined #nimrod |
| 15:26:36 | * | EXetoC joined #nimrod |
| 15:31:45 | zahary_ | so, Araq, the new VM is not reentrant? why is having a global reusable VM context considered a benefit? |
| 15:31:49 | BitPuffin | Araq: oh, I thought it would be a bad thing |
| 15:32:09 | BitPuffin | Araq: because I thought that was your one suspicion or something haha |
| 15:47:31 | * | [2]Endy joined #nimrod |
| 15:48:43 | * | Varriount|Mobile joined #nimrod |
| 15:50:16 | * | [1]Endy quit (Ping timeout: 245 seconds) |
| 15:53:27 | reactormonk | EXetoC, I labeled it a feature. |
| 15:53:46 | reactormonk | fowl, nope, $ returns a string as "foo" instead of foo |
| 16:03:38 | * | Demos joined #nimrod |
| 16:06:37 | * | nande joined #nimrod |
| 16:09:47 | Varriount|Mobile | Hi Demos |
| 16:09:51 | Varriount|Mobile | Hi nande |
| 16:12:07 | reactormonk | how exactly do I get a string of a json element? `$` gives me a string representation, not a string. |
| 16:12:14 | reactormonk | aka "foo" -> ""foo"" |
| 16:12:46 | dom96 | '.str' |
| 16:12:55 | * | hihihihi joined #nimrod |
| 16:12:58 | reactormonk | dom96, negative |
| 16:13:10 | reactormonk | that doesn't work on floats etc. |
| 16:13:35 | dom96 | case node.kind |
| 16:14:27 | reactormonk | that sounds... annoying. |
| 16:16:02 | reactormonk | dom96, any reason why `$` on a string node doesn't behave like `$` on a string? |
| 16:16:11 | EXetoC | what's the deal with the pipe symbol in doc comments? is it used mostly in comments that were written a long time ago? |
| 16:17:45 | dom96 | Because that is the most popular use case. |
| 16:18:08 | reactormonk | dom96, hm. |
| 16:18:34 | EXetoC | dom96: it is? |
| 16:18:53 | EXetoC | I haven't used the module much |
| 16:19:50 | EXetoC | anyway, using a case statement doesn't seem to be that much of an effort, because you only need two branches in this case |
| 16:19:52 | reactormonk | dom96, and what do you use the json representation for? |
| 16:20:14 | reactormonk | EXetoC, 7. |
| 16:20:32 | EXetoC | what kind of special-casing do you need for the remaining ones? |
| 16:20:50 | EXetoC | I don't know exactly what it is you |
| 16:21:20 | EXetoC | ... you're doing, but add a shortcut if you feel it's necessary |
| 16:21:21 | dom96 | reactormonk: Nimrod isn't a dynamically typed lang, it sounds to me like you are trying to it into one. |
| 16:21:34 | dom96 | *to turn it |
| 16:21:53 | renesac | dom96, err, he want's a single output type |
| 16:22:18 | EXetoC | what do you mean? you already get that with `$` |
| 16:22:24 | reactormonk | EXetoC, nope. |
| 16:22:25 | renesac | I agree that $ on a string node should behave the same as $ in a string |
| 16:22:36 | renesac | if you want repr(string) you should call it |
| 16:22:45 | reactormonk | renesac, it's not repr(string) |
| 16:22:48 | reactormonk | it's json_rep(string) |
| 16:23:03 | EXetoC | reactormonk: yes, string |
| 16:23:18 | reactormonk | EXetoC, it's the same _type_ but not the same semantics. |
| 16:23:21 | dom96 | Perhaps. |
| 16:23:36 | dom96 | Perhaps it shouldn't be an alias for pretty() |
| 16:23:41 | EXetoC | dom96: what was the verdict before? BitPuffin complained about json.`$` before |
| 16:23:46 | dom96 | but it's a bit late to change it now |
| 16:24:09 | reactormonk | dom96, it is? O.o |
| 16:24:09 | renesac | dom96, why it should't be an alias for pretty()? |
| 16:24:35 | EXetoC | reactormonk: yeah, we hit 1.0 yesterday |
| 16:24:41 | reactormonk | EXetoC, ... fuck |
| 16:24:57 | dom96 | Because people want it to act just like $node.whateverTypeItHolds |
| 16:25:16 | reactormonk | EXetoC, https://github.com/Araq/Nimrod/releases yeah, yeah. |
| 16:25:27 | EXetoC | :p |
| 16:25:34 | renesac | why not call repr() when you mean repr()? |
| 16:25:47 | reactormonk | renesac, because it's _not_ repr() |
| 16:26:02 | reactormonk | repr is strictly human-readable output. |
| 16:26:03 | renesac | I was asking dom96 |
| 16:26:13 | reactormonk | renesac, because it's not repr(), but json_repr() |
| 16:26:36 | dom96 | Well apparently I missed this really important use case. I thought aliasing $ to a single-line pretty() was wise. |
| 16:27:41 | dom96 | But let me ask this. What should $ print when it gets a JObject PJsonNode? |
| 16:27:49 | dom96 | s/print/return/ |
| 16:27:50 | renesac | reactormonk, wasn't it about $ ? |
| 16:37:54 | nequitans | Hi all, I'm using the importc pragma and was wondering what the best way to obtain a seq[int] in Nimrod as the return value from a C routine |
| 16:40:18 | * | pmullin joined #nimrod |
| 16:40:52 | BitPuffin | "too late to change it" I think the 67 people using nimrod can deal with it |
| 16:40:56 | BitPuffin | not only that |
| 16:41:06 | BitPuffin | the 7 people using json with nimrod |
| 16:41:26 | reactormonk | dom96, a json representation of the node |
| 16:41:34 | Demos | nequitans: you write a nimrod wrapper |
| 16:41:44 | reactormonk | nequitans, you importc it as an array |
| 16:41:53 | dom96 | nequitans: If I understand you correctly what you want to do is return an array from your C routine and then convert that to a seq manually. |
| 16:41:55 | reactormonk | ... then you write another proc using the importc'd one |
| 16:41:59 | Demos | reactormonk: but you may not know the size |
| 16:42:09 | dom96 | nequitans: Similar to the way it's done here: https://github.com/Araq/Nimrod/blob/78761f0b4bd3b7240ed7db84203fb393a648910e/lib/system.nim#L2112 |
| 16:42:09 | reactormonk | Demos, hm. |
| 16:42:24 | Demos | the C library will provide a way to get a pointer to the first element and the size |
| 16:42:54 | dom96 | reactormonk: Please tell me your use case. |
| 16:43:22 | reactormonk | dom96, reading stuff from json and putting it into sqlite |
| 16:44:20 | dom96 | So why not just store it as a JSON compliant representation anyway? |
| 16:44:25 | * | aftershave_ joined #nimrod |
| 16:44:33 | BitPuffin | if there is any time we should change things it is now |
| 16:44:40 | reactormonk | because I want to be able to query it with SQL |
| 16:45:28 | EXetoC | possibly add an unquotedStr or something |
| 16:45:41 | Demos | I think you can take a C pointer that you know is an array and cast it to like array[type, 0..100000] then access it using indexing |
| 16:45:42 | dom96 | I don't see how $ makes that a problem. |
| 16:46:01 | reactormonk | dom96, because varargs[string] will hopefully escape the " |
| 16:46:17 | reactormonk | ... in insertID |
| 16:46:39 | dom96 | still don't see the problem. |
| 16:46:46 | * | hihihihi quit (Quit: Page closed) |
| 16:46:51 | dom96 | It makes your job easier, you can then use the JSON module to read the data back. |
| 16:47:18 | dom96 | Without having to check manually whether the data is a float, int, bool or string. |
| 16:47:35 | nequitans | Demos -- thanks. Do you know how I would obtain the # 100000 (it can return variable length arrays depending on the input) |
| 16:47:56 | Demos | that was just a "large number" |
| 16:48:38 | dom96 | nequitans: What C proc are you wrapping? |
| 16:48:50 | EXetoC | `$` does apply to the node, which isn't the same as accessing the elements directly |
| 16:49:51 | nequitans | Demos -- thanks. Do you know how I would obtain the # 100000 (it can return variable length arrays depending on the input) |
| 16:50:47 | * | pmullin left #nimrod ("Textual IRC Client: www.textualapp.com") |
| 16:50:59 | Demos | gah I gotta go. the length of the array in my example is just a maximum, the actual array better by shorter than that. You are not actually allocating all the memory since it is just a cast. Accesses beyond the end of the "real" array would just be undefined behavior |
| 16:51:43 | EXetoC | so in this case you're getting the representation of a node, and I don't mind it behaving differently for that reason |
| 16:51:47 | Demos | C does not really specify a maximum length of an array, so a max value is just a ballpark. I think nimrod only allows up to like 2^32 for int literals |
| 16:52:07 | EXetoC | dom96: so you're claiming it is too late to change it, which I disagree with, but do you think the current behavior is correct? |
| 16:52:07 | nequitans | dom96, it's a procedure I wrote using the Lemon Graph C++ library. It takes as an input an array of doubles and outputs an array of integers |
| 16:52:11 | EXetoC | BitPuffin: what is your argument? |
| 16:52:49 | * | Demos quit (Quit: Textual IRC Client: www.textualapp.com) |
| 16:52:50 | BitPuffin | EXetoC: consistency |
| 16:53:22 | dom96 | nequitans: Well I think you should expose the size of the array you are returning. |
| 16:53:33 | BitPuffin | EXetoC: When you use $ you expect a fucking nimrod string that is comparable with other fucking nimrod strings |
| 16:53:37 | BitPuffin | not some bullshit string |
| 16:54:01 | dom96 | As far as I'm concerned when you use $ you are expecting a string. |
| 16:54:29 | dom96 | That is the only requirement that $ has. |
| 16:55:03 | BitPuffin | Yeah and you expect that if you use $ on a thing that has the value "hello" it should == "hello" |
| 16:55:08 | BitPuffin | as in the literal |
| 16:55:20 | BitPuffin | not the json encoding thing whatever |
| 16:55:32 | BitPuffin | and what's worse iirc is that if you echo it, it looks like you think |
| 16:55:34 | BitPuffin | so you are like |
| 16:55:45 | BitPuffin | well okay I'll just compare it to what it should be then, "hello", and nope |
| 16:55:47 | BitPuffin | false |
| 16:55:56 | BitPuffin | and then you punch the computer and start hating nimrod |
| 16:56:00 | BitPuffin | we don't want that for people |
| 16:56:44 | nequitans | dom96, I see, so maybe a clean way to do it is to return a struct of int nels and int * rvals. Does nimrod have a nice way of reading in C structs? Alternatively I could encode the size as the first element |
| 16:57:34 | nequitans | but i may also want to include a double in that struct |
| 16:57:38 | nequitans | so a struct would be ideal |
| 16:59:13 | dom96 | You can just importc structs, just create an object with the same fields and use the importc and dynlib/header pragmas. |
| 16:59:23 | EXetoC | BitPuffin: so only when a json aggregate is converted to a string should it represent the corresponding JSON string? |
| 17:00:30 | EXetoC | echo node -> {"x": 1, "y": 2} |
| 17:01:47 | BitPuffin | EXetoC: I can barely even remember what it was that happened but it was stupid. But yeah I guess if a node is a json string $ should give you a string |
| 17:02:20 | BitPuffin | so I should be able to do $node["str"] == "noob" |
| 17:02:27 | BitPuffin | if the node is "str" : "noob" |
| 17:02:35 | BitPuffin | I think that's what didn't work iirc |
| 17:03:49 | * | aftershave_ quit (Quit: Computer has gone to sleep.) |
| 17:05:31 | EXetoC | One might argue that since a string *type* is expected, ".str" should be called directly. Otherwise it's very inexact if you consider the fact that you might do $node == "123", but where the underlying type might be an int |
| 17:07:57 | BitPuffin | It's "123" if it is "123", and 123 if it is 123 |
| 17:08:00 | BitPuffin | do you know json? |
| 17:08:03 | BitPuffin | it has numbers |
| 17:09:34 | * | gour quit (Quit: WeeChat 0.4.2) |
| 17:14:19 | EXetoC | I never said otherwise |
| 17:15:34 | BitPuffin | what did you mean then |
| 17:15:46 | dom96 | Why would you compare the value of a node like that? |
| 17:15:52 | dom96 | What if it's a float? |
| 17:16:06 | EXetoC | do you not care whether a node is an int or a string whenever you're doing $node == "123"? |
| 17:16:11 | dom96 | node.fnum == 123.0 will work, but $node == "123.0" will not. |
| 17:16:18 | BitPuffin | well no I can't even remember what it was |
| 17:16:26 | BitPuffin | because it was so long ago |
| 17:16:32 | BitPuffin | we should have had the conversation then |
| 17:16:36 | BitPuffin | when it was fresh |
| 17:16:40 | EXetoC | dom96: it won't? |
| 17:16:42 | BitPuffin | go back in the logs or something |
| 17:16:53 | nequitans | dom96, thanks -- i created a struct and am returning it from the c function. i was looking around in the docs a little but am a little confused as to how to declare the type in nimrod, right now i'm doing this noob thing: |
| 17:17:03 | * | aftershave_ joined #nimrod |
| 17:17:07 | BitPuffin | or yeah wait |
| 17:17:07 | EXetoC | dom96: isn't that the JSON representation of a float? |
| 17:17:08 | * | Demos joined #nimrod |
| 17:17:12 | nequitans | type TSubgraph {.importc: "subg_t".} = object |
| 17:17:14 | BitPuffin | Okay so I think I was right |
| 17:17:26 | BitPuffin | you get back a json node with [] right |
| 17:17:34 | BitPuffin | and if you know that what you will be getting is a string |
| 17:17:42 | Demos | does the nimrod library wrap C's setjmp/longjmp functions? Again asking for interop reasons |
| 17:17:43 | BitPuffin | then you think, hmm, how do I get a string in nimrod |
| 17:17:47 | BitPuffin | $ comes to mind |
| 17:17:54 | BitPuffin | not fucking str |
| 17:17:57 | BitPuffin | or whatever it was |
| 17:18:06 | EXetoC | that'd be the representation, and not an actual string |
| 17:18:36 | BitPuffin | Okay so does str exist for numbers too? |
| 17:19:10 | nequitans | Demos, was that directed to me? :) |
| 17:19:46 | Demos | no, directed at anyone who might know |
| 17:19:52 | EXetoC | BitPuffin: I asked you whether or not you care what the underlying type is when you do $node == "123" |
| 17:20:10 | BitPuffin | EXetoC: not really |
| 17:20:30 | BitPuffin | EXetoC: because generally I know what the structure of the json will be |
| 17:20:35 | BitPuffin | so I will know that it's a string |
| 17:20:48 | BitPuffin | and for example |
| 17:21:00 | BitPuffin | what is the behaviour if you call str on a node that isn't a string? |
| 17:21:02 | BitPuffin | A crash? |
| 17:21:16 | EXetoC | an exception is raised |
| 17:21:19 | EXetoC | but then surely you're only working with JSON strings that you've constructed |
| 17:21:21 | BitPuffin | That adds unnecessary checks that you have to perform otherwise if so |
| 17:21:24 | BitPuffin | yeah so exactly |
| 17:21:37 | BitPuffin | If I know I am expecting a string and want to compare it to my string |
| 17:21:48 | EXetoC | it's not unnecessary if you have correctness in mind |
| 17:21:56 | * | Varriount-Mobile joined #nimrod |
| 17:22:18 | BitPuffin | then I want it to be false if I compare it to "sthoet" when it's 38.29382938e-2 |
| 17:22:42 | BitPuffin | Actually what I think would be the most intuitive way to do it is to have a comparison operator for all the json node types |
| 17:23:28 | BitPuffin | basically proc `==`(node: PJSONNode, s: string) |
| 17:23:31 | BitPuffin | for example |
| 17:23:35 | BitPuffin | ofc for numbers and so on too |
| 17:23:59 | BitPuffin | I can just do node == "hello" |
| 17:24:14 | BitPuffin | and if the value happens to be a float value |
| 17:24:15 | reactormonk | dom96, I can't use $() on a string node, because it gives me incorrect data. |
| 17:24:22 | BitPuffin | well then it catches the exception and returns false |
| 17:24:28 | BitPuffin | because then they sure as hell are not equal |
| 17:25:42 | * | Varriount|Mobile quit (Ping timeout: 252 seconds) |
| 17:28:19 | Skrylar | well I think I have 1/4th of a decent GUI system done in nimrod now |
| 17:28:36 | renesac | is there some work in making a bigint library for nimrod? |
| 17:28:47 | renesac | ventor3000 said he wanted to work on it sometime ago in the nimrod forum |
| 17:29:02 | EXetoC | reactormonk: A node representing a string is not the same as a string, which is why I don't consider the current behavior to be incorrect |
| 17:29:47 | EXetoC | BitPuffin: that might be a reasonable addition |
| 17:31:47 | dom96 | EXetoC: I was talking about if we change the behaviour of $. |
| 17:31:51 | BitPuffin | EXetoC: that way we can even keep backwards compatibility for lazy people like dom96 :) |
| 17:32:05 | dom96 | bbl |
| 17:32:18 | EXetoC | dom96: yes but I wanted to know what behavior you think is correct |
| 17:32:56 | EXetoC | But then I don't think I'd use it that much. I'd just access the str field, and if it is indeed not a string, then it'll fail, in which case I can either catch the exception, or just let everything blow up |
| 17:33:23 | dom96 | BitPuffin: And then we'll need === just like JavaScript :P |
| 17:33:43 | dom96 | bbl4real |
| 17:34:45 | renesac | ok, there seems to be some work: https://github.com/ventor3000/nimrod-lab |
| 17:34:56 | renesac | but frozen |
| 17:35:26 | BitPuffin | dom96: lol no |
| 17:35:31 | BitPuffin | dom96: not even related |
| 17:35:46 | BitPuffin | dom96: I didn't say that == should try and convert a number into a string and then compare it |
| 17:35:49 | EXetoC | BitPuffin: lazy? |
| 17:36:01 | BitPuffin | What I'm saying is, if it is a string, compare them, if not, return false |
| 17:36:08 | BitPuffin | how is that anything like == in js |
| 17:36:51 | runvnc | hello |
| 17:37:03 | runvnc | Is the JavaScript compilation target compatible with templates and macros |
| 17:38:19 | reactormonk | EXetoC, I'll check what others do |
| 17:38:23 | reactormonk | runvnc, sure |
| 17:38:32 | runvnc | reactor awesome |
| 17:38:39 | reactormonk | runvnc, templates and macros are done before the code generation |
| 17:39:02 | runvnc | oh duh |
| 17:39:04 | runvnc | thanks |
| 17:40:08 | reactormonk | dom96, I see. Other languages (ruby/python) solve this by converting it to `native` data types |
| 17:40:12 | BitPuffin | dom96: in fact if anything it is like === |
| 17:40:15 | BitPuffin | the way it should be |
| 17:40:32 | reactormonk | ... which you can't do with static typing. |
| 17:41:39 | BitPuffin | reactormonk: well no |
| 17:41:43 | BitPuffin | but that's not related |
| 17:41:51 | BitPuffin | I didn't mean that it should work like that for the general types |
| 17:41:54 | BitPuffin | just for json nodes |
| 17:42:20 | reactormonk | BitPuffin, a parse[someType] should work theoretically |
| 17:42:50 | reactormonk | via https://github.com/backchatio/jerkson |
| 17:49:34 | EXetoC | I've done something similar in the new db_mongo interface, but it's limited |
| 17:51:38 | EXetoC | though I'm not sure if that lib supports arbitrary structures |
| 17:52:36 | * | io2 quit () |
| 17:55:41 | reactormonk | ~. |
| 17:55:59 | reactormonk | emdr.nim(64, 2) Error: selector must be of an ordinal type, float or string |
| 17:56:13 | EXetoC | so a basic impl based on overloading should be possible, but support for arbitrary inputs would require better reflection support I think |
| 17:56:15 | reactormonk | can I use case <something> and check for the type? |
| 17:56:39 | EXetoC | reactormonk: not for things like typedesc's if that's what you mean |
| 17:56:45 | reactormonk | http://dpaste.com/1638748/ |
| 17:56:58 | * | vbtt joined #nimrod |
| 17:57:03 | EXetoC | hm |
| 17:57:11 | EXetoC | node.kind |
| 17:57:34 | vbtt | hello, wondering if there is any interest in making the tutorials, manuals etc. match the website theme. |
| 17:58:03 | EXetoC | reactormonk: "case kind*: TJsonNodeKind", so that's a field that you need to access explicitly |
| 17:59:43 | reactormonk | EXetoC, nah, works |
| 17:59:46 | Varriount | vbtt: I might be, if I haven't already donated my time to something else. |
| 18:00:12 | Varriount | I have no practical experience in web design though. Just stuff I've read. :/ |
| 18:00:45 | Varriount | If you want to do it though, by all means go ahead. |
| 18:00:47 | EXetoC | reactormonk: didn't you say it didn't? |
| 18:00:59 | Skrylar | are the source files for that lying around somewhere? |
| 18:01:02 | EXetoC | that might've been something else |
| 18:01:11 | vbtt | Varriount: I've already come up with the css to reuse the website's style.css and adapt it to the tutorials. |
| 18:01:16 | Varriount | Skrylar: source files for what? |
| 18:01:31 | Skrylar | Varriount: the other pages that vbtt is wanting the styles converted on |
| 18:01:50 | Varriount | Skrylar: It's in the docs and website directories |
| 18:01:50 | Skrylar | its not that hard to chuck them in to nanoc unless they're stored in some weird format |
| 18:02:22 | Skrylar | (amusingly yes, you can tell nanoc to use 'nimrod rst' as a processor) |
| 18:02:51 | * | Demos quit (Ping timeout: 272 seconds) |
| 18:03:01 | * | BitPuffin quit (Ping timeout: 246 seconds) |
| 18:03:53 | vbtt | Skrylar: yes the sources are rst files. |
| 18:04:02 | * | Varriount can't wait to see the pretty |
| 18:04:03 | Skrylar | vbtt: i might be able to look at it later |
| 18:04:26 | Skrylar | I seem to remember discussions earlier that nimrod's reST processor was broken right now though |
| 18:04:53 | vbtt | no, it seems to work just fine. |
| 18:05:02 | Skrylar | guess its a non-issue then |
| 18:05:10 | * | Skrylar was here a day or two ago when they were discussing nimweb having trouble generating docs |
| 18:05:11 | vbtt | also, they just rebuilt the website so I assume it works at least for everything on there. |
| 18:05:32 | vbtt | yes I was having trouble, finally figured out how to pass in the right arguments to nimweb. |
| 18:05:53 | Varriount | All I had to do was turn generation of PDF's off |
| 18:06:05 | * | [2]Endy quit (Ping timeout: 260 seconds) |
| 18:06:06 | Skrylar | Varriount: lol |
| 18:06:13 | Varriount | I don't have the whole LaTeX package thing installed. |
| 18:06:21 | Varriount | Nor do I want to, for that matter. |
| 18:06:24 | * | q66 joined #nimrod |
| 18:06:25 | * | q66 quit (Changing host) |
| 18:06:25 | * | q66 joined #nimrod |
| 18:06:27 | reactormonk | EXetoC, works if I add .kind |
| 18:06:29 | Skrylar | i keep one of those around but i don't use it often |
| 18:06:46 | reactormonk | Varriount, I use latex exclusively ;-) |
| 18:06:47 | Skrylar | all though lately Anki has decided to screw up using latex, so I have to go in to openoffice and screenshot math formulas -_- |
| 18:07:02 | EXetoC | k |
| 18:07:03 | reactormonk | Skrylar, muahahaha |
| 18:07:26 | Skrylar | reactormonk: yeah well. lol |
| 18:07:48 | Skrylar | ConnectedText? Has no problem prodding miktex and generating formulas. Anki? *used to* Suddenly, "HERP AMSMATH IS BORK" |
| 18:08:44 | Skrylar | admittedly i know nothing about nimweb and may or may not be really endeared to nanoc's pipeline method of working that none of the site generators seem to copy :( |
| 18:09:02 | Skrylar | it does a really good job of being exactly a middleman that just pipes text through other programs |
| 18:09:25 | reactormonk | Skrylar, org-mode \o/ |
| 18:09:42 | * | Skrylar burns your emacs |
| 18:10:04 | Skrylar | Nah I actually used org-mode for a while. |
| 18:10:50 | Varriount | I wish there was a choose-your-own guide for linux command line tools |
| 18:11:06 | Skrylar | But I'm spoiled to the days that I had a macbook, and had access to these neat database-backed outliners with pretty GUIs |
| 18:11:09 | Skrylar | Varriount: ... Hm. |
| 18:11:23 | Varriount | Skrylar: There's already one for git, that I know of. |
| 18:11:32 | Skrylar | Varriount: You are standing in front of a black screen with a series of small rocks. Do you pick up the zsh rock or the bash rock? |
| 18:11:41 | Varriount | bash |
| 18:11:58 | Skrylar | The bash rock hurts your head as it smacks in to you. You have died. |
| 18:12:04 | Skrylar | </pun> |
| 18:12:55 | Skrylar | Varriount: someone could probably make one of those in twine |
| 18:13:26 | Skrylar | I've wondered if theres a correlation to linux having some of the worst information organizing tools and the lack of information organizing though :o |
| 18:13:57 | Varriount | Linux has a lot of information.. just not very straightforward |
| 18:14:09 | Skrylar | It's not organized though, which is what I said. |
| 18:14:12 | * | Demos joined #nimrod |
| 18:14:36 | Varriount | Skrylar: Although, there's one thing you should always do, if you can - use the dry run option |
| 18:14:51 | Skrylar | Mac data tends to be highly indexed / centralized, and oddly they have things like Tinderbox / Notebook / OmniOutliner / etc and some amazingly rock solid word processors like Mellel that can eat 500 page documents like candy |
| 18:15:02 | Skrylar | Linux has.. maybe org-mode |
| 18:15:32 | Skrylar | Freemind/plane are good when your data fits in the mindmap model, I will give credit for that |
| 18:16:22 | * | DAddYE joined #nimrod |
| 18:16:38 | Skrylar | Varriount: i usually don't dry-run... all though I memorized most of the commands i care about on a regular basis by now :( |
| 18:19:37 | Demos | well windows has HANDS DOWN the best information organising tool (OneNote) and it is not like windows is organised |
| 18:20:38 | Demos | speaking of, I just finished making my libpng wrapper compile and at least load. It is suprising how many funciton are in the libpng manpage that don't actually exist |
| 18:21:07 | vbtt | http://vocalbit.com/tmp/manual.html |
| 18:21:15 | vbtt | http://vocalbit.com/tmp/httpserver.html |
| 18:21:26 | vbtt | what do you think? I think there should be a back link for 'docs' |
| 18:21:29 | Varriount | Why isn't there a single consistant way of doing things in opengl? I swear, I've found 4 different ways of settings up things. |
| 18:22:08 | Demos | Varriount: because cruft |
| 18:22:20 | Demos | limit yourself to OpenGL 3.2 core profile and things are better |
| 18:22:59 | Varriount | vbtt: Looks nice. Though, the sides margins could be lessened a bit |
| 18:22:59 | reactormonk | Demos, yeah, some information organizer would be nice to have, but it should run on linux :-/ |
| 18:23:10 | Araq | vbtt: it looks very nice but I'm not sure it's the way to go |
| 18:23:12 | Demos | even then there are uniforms with both glUniformi/glUniformiv as well as UBOs and the wierd UBO API |
| 18:23:29 | Demos | reactormonk: Org mode is really quite good |
| 18:23:45 | Araq | the docs are part of the distribution |
| 18:23:53 | Varriount | Demos: Is there some hidden tutorial site I'm missing? |
| 18:23:55 | Araq | and not part of the website really |
| 18:24:02 | Demos | hell no |
| 18:24:15 | Demos | most opengl tutorials are really, really, REALLY, terrabad |
| 18:24:20 | Varriount | Why? |
| 18:24:24 | Demos | Direct3D ones are worse |
| 18:24:26 | Demos | I have no idea |
| 18:24:30 | Varriount | And what are my alternatives? |
| 18:24:36 | Varriount | Cairo? |
| 18:24:38 | Araq | Demos: support for 'restrict' is planned and hopefully we can insert assertions to make it safe |
| 18:25:02 | reactormonk | Demos, let's take some more looks into that then |
| 18:25:40 | Demos | Araq: sweet, for now I just used regular pointers, the c code is in a shared/static lib so the "restrict" has already done its job |
| 18:25:49 | Demos | Varriount: http://www.opengl.org/wiki/Main_Page is good |
| 18:25:52 | vbtt | Araq: fair point. even then, is there a reason the docs shouldn't match the theme of the website somewhat? |
| 18:26:07 | Demos | as is the OGL spec/manual |
| 18:26:22 | Demos | I hear Cairo is quite good |
| 18:26:30 | vbtt | either way, I didn't put that much work into it so I can let it go. |
| 18:26:53 | Demos | and like I said limiting yourself to openGL 3.2 core makes things better |
| 18:27:04 | vbtt | Varriount: the margins are the same as the website. |
| 18:27:09 | vbtt | but they can be changed. |
| 18:29:12 | * | brson joined #nimrod |
| 18:29:18 | Skrylar | Demos: I like Notebook more than onenote :( |
| 18:29:41 | vbtt | Araq: or do you think the current presentation is better than the new style? |
| 18:30:58 | Skrylar | Demos: partly because Notebook actually has the full app themed as a moleskine, you can throw in index tabs and whatnot, and its essentially a database-backed outliner with a neat metaphor. Evernote and OneNotes UI to me.. egh. Also, Onenote isn't really accessible to most Windows users either; its difficult to get a stand-alone copy of it and its heinously expensive when you do manage to find it |
| 18:31:34 | Skrylar | last time i had office suites it wasn't stock with those either |
| 18:31:45 | Araq | vbtt: I personally like the current presentation but apparently nobody else |
| 18:31:56 | Demos | it is part of almost all office distributions. I like onenote because of its tablet PC support. I can take notes with my pen (includeing maths) and it will run OCR on them and make em searchable |
| 18:32:17 | Araq | I think it has style and the table of contents as a side menu make sense |
| 18:32:35 | Skrylar | they must have made it standard after i stopped using office completely then; i remember having a standalone disc for onenote years ago |
| 18:32:53 | Skrylar | i'm trying to build a database-backed outliner in nimrod, just takes time to deal with the GUI sadly |
| 18:33:11 | Demos | yeah, this is true. the other thing is that it is easy to access the notes (incl maths) on my windows phone :D |
| 18:33:31 | Demos | I actually really like how org-mode is all just text |
| 18:33:56 | Skrylar | I think Taskpaper pulled off the "outline as text" paradigm better IMHO |
| 18:34:10 | Demos | is there a place where I can download nimrod related images in various formats (the crown and whatnot) |
| 18:34:33 | * | Varriount-Mobile quit (Ping timeout: 260 seconds) |
| 18:34:37 | Demos | yeah, org-mode does a ton of other stuff as well though |
| 18:34:45 | vbtt | Araq: the toc can be put on the side. the issues with the current presentation are: looks out of place on website, no syntax highlighting, 100% width, grey toc box too big. |
| 18:35:35 | vbtt | Araq: don't you want the toc to be always visible, irrespective of scroll position? |
| 18:35:39 | * | brson quit (Ping timeout: 252 seconds) |
| 18:36:07 | Skrylar | Demos: it does, but how many people can actually use it? |
| 18:37:04 | Skrylar | Demos: i remember reading some of the really longwinded documents about how you can jank org-mode in to doing all of this extensive day planning (and pinky destruction), and by that point the heavy org-mode users were complaining the "everything as plain text" became a liability because emacs had to crunch through text files to generate their calendars |
| 18:37:12 | * | Varriount-Mobile joined #nimrod |
| 18:37:28 | vbtt | g2g, bbl. |
| 18:37:35 | * | vbtt quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 18:38:00 | Demos | yeah, I guess. I found it easy to make a calender in org-mode after a few hours of dicking around. But it was still a bit annoying |
| 18:38:04 | * | io2 joined #nimrod |
| 18:38:23 | Skrylar | in connectedtext i can do a calendar by just saying view->calendar :( |
| 18:38:24 | * | carum quit (Remote host closed the connection) |
| 18:39:34 | Skrylar | that program is weird though |
| 18:39:50 | Skrylar | its basically a desktop wiki stored in a Firebird database |
| 18:40:56 | Skrylar | i think my favorite organizer was Notational Velcoity, simply because its basically a folder of .txt files with 'grep' run on them |
| 18:43:36 | Discoloda | "note" discussion would have been perfect in #nimrod-offtopic |
| 18:43:50 | Demos | this is true |
| 18:44:00 | * | Skrylar shrugs |
| 18:50:04 | Skrylar | i'm not sure offtopic channels have ever really worked. in my IRC experience pointing towards an offtopic channel is usually interpreted as telling people who were talking to STFU, half the people who do/might've commented on the OT topic aren't even in them and it tends to just make the main channels more idle |
| 18:50:11 | Skrylar | but thats just my impression of ~10 years on IRC |
| 18:50:12 | * | Skrylar shrugs |
| 18:51:36 | Araq | Skrylar: I agree |
| 18:51:39 | * | aftershave_ quit (Quit: Computer has gone to sleep.) |
| 18:51:47 | Demos | acpi |
| 18:52:01 | * | Demos quit (Quit: leaving) |
| 18:52:03 | Araq | who authorized that offtopic channel anyway |
| 18:53:59 | Skrylar | i'd have to check the log |
| 18:54:21 | * | sale4one joined #nimrod |
| 18:57:28 | sale4one | So quiet here :/ |
| 18:58:32 | runvnc | why do you guys use rst instead of markdown |
| 18:59:04 | Skrylar | i guessed because python uses reST and nimrod is styled after python |
| 18:59:31 | runvnc | is there a way to get nice colored syntax highlighting for different programming languages using rst |
| 18:59:56 | Skrylar | runvnc: i think nimrod's built in rst processor does it |
| 19:00:06 | Skrylar | they don't use the docutils or sphinx versions |
| 19:01:19 | runvnc | oh that sounds awesome |
| 19:01:51 | * | profmakx quit (Ping timeout: 272 seconds) |
| 19:02:00 | runvnc | I see this ipsumgenerator thing seems to be doing something specific related to the language you specify |
| 19:02:31 | runvnc | for code blocks |
| 19:03:36 | runvnc | It seems like nimrod is the best language ever |
| 19:04:21 | Araq | runvnc: markdown didn't even exist when I implemented the RST parser |
| 19:04:25 | runvnc | so easy for me to understand most of the code, and yet it has the most powerful templating, and very fast execution |
| 19:04:30 | Araq | or at least I wasn't aware of it |
| 19:05:10 | runvnc | I have been using this ToffeeScript/CoffeeScript thing because it is very pythonic, lets you do nice classes compiled to JavaScript, and I can use all of the node modules |
| 19:05:13 | Araq | RST is not that far away from markdown anyway |
| 19:05:21 | runvnc | but nimrod code is even clearer than toffeescript |
| 19:05:31 | * | ehaliewicz joined #nimrod |
| 19:05:41 | runvnc | and the built in modules take care of most of the things you would use third part modules for in node |
| 19:06:06 | runvnc | the only thing I dont have with nimrod is everything being async and event based transparently |
| 19:06:18 | runvnc | which I am not even sure thats possible probably not |
| 19:06:28 | runvnc | anyway its not transparent in node |
| 19:06:40 | Skrylar | async as in nodejs? |
| 19:06:45 | Skrylar | i don't see why that couldn't be done |
| 19:06:54 | Skrylar | nodejs just does it with closures and i think nimrod has those |
| 19:07:09 | Araq | runvnc: we almost have a new async core |
| 19:07:19 | Araq | be patient, it's nearly there |
| 19:07:22 | runvnc | well in toffeescript you can use a sync syntax that is more convenient than javascript closures |
| 19:07:34 | runvnc | wraps them |
| 19:08:33 | runvnc | I just never thought that I would be enthusiastic about a language that had this kind of interaction with c |
| 19:09:15 | * | sale4one quit (Remote host closed the connection) |
| 19:09:25 | runvnc | always thought that that I was done with low level stuff. but this seems to be the best of both worlds. sorry I am rambling. but I must be missing something because I dont see that many people talking about the best new language ever |
| 19:09:41 | * | sale4one joined #nimrod |
| 19:09:44 | Skrylar | thats because rust has a better marketing team |
| 19:09:44 | runvnc | although nobody talks about toffeescript and a lot havent caught on to coffeescript and those both make big improvements over javascript |
| 19:10:43 | Skrylar | i was excited once that rust seemed like it had the backing that it could dislodge C++ somewhat, now i'm horrified that might actually be true |
| 19:10:46 | Skrylar | lol |
| 19:10:50 | runvnc | haha |
| 19:11:08 | Varriount | Just so I have a point of reference, what is bad with rust? |
| 19:11:14 | runvnc | give it 10 or 20 years and people won't be the main thing holding back technologies anymore |
| 19:11:27 | runvnc | because we will have artificial general intelligences that can keep up |
| 19:11:36 | Skrylar | Varriount: the syntax has had basically zero attention paid to it |
| 19:11:42 | runvnc | I don't think rust is bad |
| 19:11:51 | runvnc | but definitely syntax is not as nice for starters |
| 19:12:04 | runvnc | I think rust is way better than c++ for a lot of things for example |
| 19:12:27 | runvnc | I think nimrod is better though |
| 19:12:29 | Skrylar | rust is basically meant to vent frustration from using C++ for writing a browser, so they brought a bunch of haskell-y things over |
| 19:12:42 | dom96 | To bring back an old topic: I really like vbtt's docs. |
| 19:13:11 | Skrylar | dom96: which docs are specifically vbtt's? |
| 19:13:15 | dom96 | I think that the toc at the top is more stylish |
| 19:13:23 | dom96 | http://vocalbit.com/tmp/manual.html |
| 19:13:59 | Skrylar | maybe add a 'jump to header' after each section |
| 19:14:17 | dom96 | The headers are clickable. |
| 19:14:37 | Skrylar | thats not very obvious from a usability standpoint |
| 19:14:46 | * | aftershave_ joined #nimrod |
| 19:15:29 | dom96 | true |
| 19:15:39 | Skrylar | identifier keywords are a horrifying shade of blue on white |
| 19:16:03 | Skrylar | strings are orange on white |
| 19:16:32 | Skrylar | I'd say about 80%. |
| 19:16:47 | dom96 | brb |
| 19:16:57 | Varriount | I'll be nitpicky, and say that there needs to be a greater degree of seperation between headings and subheadings |
| 19:17:11 | Varriount | Also, collapsable TOC lists |
| 19:17:20 | Skrylar | Some of the code coloring needs to take hints from Solarized as far as contrasting, and I might like to see a chunked version of the page so it doesn't give the scrollbar chronic shrinkage |
| 19:20:49 | * | Varriount-Mobile quit (Remote host closed the connection) |
| 19:23:11 | Skrylar | I wonder what he's using to make that site though |
| 19:24:01 | Skrylar | makes me curious about using nokogiri to split the manual up at the heading level in to chunks, and some side-filters to make a lunr index so that thing becomes searchable |
| 19:24:33 | Varriount | Skrylar: Whatever search feature is chosen better support basic logic operators |
| 19:25:14 | Skrylar | i have no idea how lunr works, i only heard of it through this irc lol |
| 19:27:24 | reactormonk | Skrylar, I'll take care of lunr if someone gives me the data as JSON |
| 19:27:45 | Skrylar | reactormonk: i was talking about vvtb's manual that dom was mentioning |
| 19:28:11 | * | profmakx joined #nimrod |
| 19:28:35 | * | profmakx is now known as Guest79110 |
| 19:29:02 | Skrylar | reactormonk: is there a way to get lunr to use a pre-processed index? |
| 19:29:04 | * | Guest79110 quit (Changing host) |
| 19:29:04 | * | Guest79110 joined #nimrod |
| 19:29:20 | Skrylar | i noticed that they expect you to feed it the complete document contents, and i'm not satisfied with the javascript having to download every article on the site |
| 19:29:35 | reactormonk | Skrylar, I'll find out |
| 19:29:44 | runvnc | cant you run it in node |
| 19:30:04 | Skrylar | runvnc: yeah, if it supports exporting the processed index |
| 19:30:14 | * | Guest79110 is now known as profmakx |
| 19:30:20 | runvnc | https://www.npmjs.org/package/lunr |
| 19:30:34 | * | vendethiel quit (Ping timeout: 260 seconds) |
| 19:31:05 | runvnc | or is that supposed to actually run on the client for searching a big page full of manual |
| 19:31:15 | Skrylar | runvnc: lunr is meant to run on the client |
| 19:31:37 | Skrylar | if one wants a server-based search there is the solr project, which i think lunr is nodding to with the spelling |
| 19:32:03 | runvnc | how else is it going to index it without giving it the full text |
| 19:32:09 | reactormonk | Skrylar, https://github.com/olivernn/lunr.js/pull/19 |
| 19:32:12 | reactormonk | it's possible. |
| 19:32:34 | runvnc | oh |
| 19:32:39 | reactormonk | Skrylar, https://github.com/olivernn/lunr.js/issues/26 |
| 19:32:40 | Skrylar | runvnc: depends on how the algorithm works; one option is to run the stemmer ahead of time and only store that |
| 19:32:42 | runvnc | was just gonna say dont they have that |
| 19:33:03 | Skrylar | if you only care about keyword search (not keyword order) its really easy to do |
| 19:33:20 | runvnc | lunr.Index.load |
| 19:33:37 | reactormonk | https://github.com/assemble/assemble-contrib-lunr |
| 19:34:23 | reactormonk | Skrylar, yup, you can just JSON.stringify the index and load it later |
| 19:36:20 | Skrylar | reactormonk: well thats neat |
| 19:37:34 | reactormonk | Skrylar, don't forget to preprocess type sigs |
| 19:38:20 | Skrylar | i feel as though i have been dogpiled suddenly. xD |
| 19:38:44 | reactormonk | Skrylar, you give me the JSON with all the documents and I'll go for the rest. |
| 19:38:59 | Skrylar | reactormonk: i don't have any data to index for the time being |
| 19:39:10 | reactormonk | Skrylar, mess with the docgen? |
| 19:39:34 | Skrylar | I mentioned an interest in it; I haven't poked it yet |
| 19:39:57 | reactormonk | Skrylar, now you will :-P |
| 19:40:09 | reactormonk | a bit of NLP experience isn't bad. |
| 19:40:35 | Skrylar | natural language processing or neurolinguistic programming |
| 19:40:40 | reactormonk | a) |
| 19:40:56 | Skrylar | parser code makes me die |
| 19:41:03 | Skrylar | lol |
| 19:41:05 | reactormonk | it's not fucking parser code |
| 19:41:28 | reactormonk | that stuff (lucene/lunr) is just plain old bag-of-words approach which don't use parsers |
| 19:43:03 | Skrylar | lately i've been face-deep in GUI trees |
| 19:43:52 | dom96 | Skrylar: Are you writing a GUI toolkit in Nimrod? |
| 19:43:59 | Skrylar | dom96: correct |
| 19:44:07 | dom96 | Skrylar: Tell me more. |
| 19:45:05 | Skrylar | at the moment its backed by ncurses, the way widgets are composited is based on Morphic (display trees, composition of trivial widget types), i borrowed the CSS box model for some of the layout parts |
| 19:46:06 | dom96 | I'm playing with the idea of creating a GUI toolkit using libcef |
| 19:46:34 | Skrylar | hrm. |
| 19:46:39 | Skrylar | Chromium stuff |
| 19:47:04 | Skrylar | I tend not to touch chromium code because its a nightmare of a dependency to keep around |
| 19:47:06 | reactormonk | are there more hashes than md5 available? |
| 19:47:16 | Skrylar | reactormonk: in existence or in nimrod? |
| 19:47:22 | reactormonk | in nimrod |
| 19:47:30 | Skrylar | i didn't know we even had md5 |
| 19:48:43 | OrionPK | theres a sha1 package in babel |
| 19:48:58 | Skrylar | whirlpool is a neat hash |
| 19:49:21 | runvnc | skrylar is there a public repo for this awesome terminal gui |
| 19:49:35 | Skrylar | runvnc: no, its not usable enough to be worth publishing |
| 19:50:04 | Skrylar | i should probably go make a repo for the modules that are usable though |
| 19:50:11 | Skrylar | i have a gapbuffer and rectangle module |
| 19:50:14 | runvnc | I have been thinking of, after I build my tool as a command line, adding a dialog based UI for the terminal. like the dialog thing that uses ansi or whatever to make menus in bash |
| 19:50:54 | runvnc | dialog is not really that advanced or feature rich though |
| 19:51:10 | runvnc | or particularlyo flexible or integratable into nimrod |
| 19:52:01 | runvnc | I would like to use all of the stuff you geniuses make |
| 19:52:02 | runvnc | lol |
| 19:52:06 | Skrylar | heh |
| 19:52:15 | Skrylar | I would love to use this too, but it still doesn't have event processing :( |
| 19:52:39 | Skrylar | Actually my ncurses wrapper sucks right now; I only bound enough to use it like termbox |
| 19:53:38 | * | sale4one` joined #nimrod |
| 19:54:12 | Skrylar | so I'm told discardable is a thing |
| 19:55:36 | * | sale4one quit (Ping timeout: 245 seconds) |
| 19:56:40 | Varriount | dom96: Did you try using the libcef wrapper? |
| 19:56:56 | dom96 | Not yet |
| 20:01:54 | Skrylar | speaking of that, i probably ought to do a proper binding of ncurses and toss it on github |
| 20:03:15 | Araq | don't we have ncurses bindings in the stdlib? |
| 20:03:36 | Skrylar | i don't remember seeing it, though i could be blind |
| 20:03:53 | OrionPK | Varriount theres a libcef wrapper? |
| 20:03:56 | Skrylar | Araq: Nope, not listed on the lib page |
| 20:05:00 | Varriount | OrionPK: One that I hastily tried to put together |
| 20:05:09 | Varriount | It's untested. |
| 20:06:08 | OrionPK | :) |
| 20:06:11 | OrionPK | at all? |
| 20:06:23 | OrionPK | untested or unproven? |
| 20:09:20 | * | BitPuffin joined #nimrod |
| 20:16:29 | * | brihat joined #nimrod |
| 20:18:21 | * | brihat quit (Read error: Connection reset by peer) |
| 20:19:13 | Varriount | OrionPK: I think I got it to compile, but I didn't actually use anything |
| 20:19:27 | OrionPK | :D |
| 20:20:54 | * | brihat joined #nimrod |
| 20:21:59 | * | aftershave_ quit (Quit: Computer has gone to sleep.) |
| 20:22:12 | Varriount | OrionPK: I make no promises. If your computer disintegrates from compiling, running, or even touching any of that code, don't blame me. |
| 20:22:31 | OrionPK | heh, i have no time to try it out atm |
| 20:22:39 | OrionPK | but i would definitely blame you |
| 20:22:49 | Araq | Skrylar: we have pdcurses in lib/wrappers though |
| 20:28:45 | runvnc | is there a gui toolkit built on pdcurses |
| 20:32:40 | runvnc | its not hard to make a binary that is compatible on all os x is it? I was thinking of doing something in bash as a command line to connect to my saas/paas, but if it is realistic to give people a binary on osx and different linux, then I will do that |
| 20:40:29 | Skrylar | i don't think there is one for pdcurses |
| 20:40:37 | Skrylar | there is one for ncurses |
| 20:40:44 | Skrylar | they're fairly compatible libraries though |
| 20:42:46 | nequitans | thanks to everyone who's answered my questions so far :). i have a question about using importc. I have an array of integers in C that I returned from a function (in the form of a struct). the struct member is of a type ptr : int (inspired by the code in libuv.nim). the struct also has a member with the length of that array. in Nimrod-land, what is the best way to traverse the elements of this array represented by ptr int and convert it to a seq? |
| 20:43:49 | * | [1]Endy joined #nimrod |
| 20:45:17 | nequitans | (or is this even a good way to do what I want?) |
| 20:48:42 | * | vbtt joined #nimrod |
| 20:48:50 | Skrylar | i think you can have a struct in the nimrod side with a {.nodecl, importc: "name in c".} so nimrod can access the struct without adding extra code |
| 20:49:11 | Skrylar | converting to a seq would involve actually looping over the array and adding to the seq though, since they're different types |
| 20:51:35 | vbtt | following up on earlier comments.. my docs are only a proof of concept. it didn't take much to make the docs look more like the website. |
| 20:52:21 | vbtt | i just reused the same style.css |
| 20:52:46 | nequitans | Skylar, thanks: if instead of using a ptr int, i use array[0..100000,int] (but only go to the number of elements i know), it works. i presume this doesn't waste space since it is a pointer into already allocated memory? |
| 20:53:41 | Araq | nequitans: yes and there is a feature request to support array[int]{.unchecked.} or something similar |
| 20:54:01 | Araq | as it's so common when interfacing with C |
| 20:54:39 | nequitans | Araq, ah, I see. Thanks! |
| 20:54:53 | Skrylar | *sigh* just don't call high() on that fake array |
| 20:55:12 | Skrylar | code that actually trusts types are what they say they are will break with the 0..10000 thing |
| 20:55:53 | dom96 | Araq: Is there no efficient way to convert a C array into a seq? |
| 20:56:18 | Araq | dom96: no, it has to be copied |
| 20:57:21 | dom96 | Why? What does seq consist of? |
| 20:57:32 | Araq | it's allocated on nimrod's heap |
| 20:57:45 | Araq | the C array is allocated somewhere else |
| 20:57:52 | Araq | --> copy IS necessary |
| 20:58:13 | * | zahary1 joined #nimrod |
| 20:58:34 | dom96 | I see. |
| 20:58:36 | nequitans | yea, that would make sense if by def seqs are always garbage collected |
| 20:58:53 | Araq | nequitans: they are |
| 21:01:53 | * | sale4one` quit (Remote host closed the connection) |
| 21:02:00 | nequitans | is there a case to be made for non-garbage collected seqs where you have your own destructor? then seqs could be made with new() or alloc()? one option for that would be to have a function called something like fromCSeq[T](a: ptr T, n: int) where it is assumed alloc and you have to dealloc in nimrod land. (i'm not saying this is a great idea, just considering the possibility :)) |
| 21:03:59 | nequitans | on the other hand the 'unchecked' option makes sense because what is the case where you want to change an array allocated from a C function? |
| 21:04:11 | Araq | sure it's possible |
| 21:06:11 | Araq | ping Varriount |
| 21:06:51 | * | brson joined #nimrod |
| 21:09:09 | * | [1]Endy quit (Ping timeout: 252 seconds) |
| 21:10:45 | nequitans | iterator |
| 21:11:07 | nequitans | (sorry -- i meant that to be in a browser window!) |
| 21:15:28 | dom96 | WebGL is becoming impressive: http://madebyevan.com/webgl-water/ |
| 21:18:02 | OrionPK | it's been impressive :p |
| 21:23:01 | * | tinAndi joined #nimrod |
| 21:23:04 | nequitans | this is pretty awesome -- i'm doing so many things in nimrod now from pipelines to more 'meaty' procedures |
| 21:23:28 | * | skyfex joined #nimrod |
| 21:26:13 | * | tinAndi quit (Quit: ChatZilla 0.9.90.1 [Firefox 27.0.1/20140212131424]) |
| 21:27:31 | Skrylar | I love C headers where the function prototypes are neatly thrown against each other |
| 21:27:41 | Skrylar | its so much easier to just toss a vim macro at them all in one go |
| 21:28:37 | * | zahary1 quit (Quit: Leaving.) |
| 21:30:14 | runvnc | Can I build a binary that will work on most OS X if they put it in their path? Sorry if that is a dumb question |
| 21:31:21 | Skrylar | yeah |
| 21:31:37 | Skrylar | unless you're using dynamic linking, all of the nimrod runtime is embedded in the binary and only the parts you need |
| 21:32:15 | runvnc | so I just run the compiler on os x, or specify something to tell it to cross compile |
| 21:32:28 | runvnc | for x 64 or something |
| 21:32:36 | Skrylar | oh, doing fat binaries? |
| 21:32:43 | runvnc | trying to make a command line tool |
| 21:32:52 | runvnc | don't know what you mean fat binary |
| 21:33:11 | Skrylar | well if you're compiling to OSX, there are 32 and 64 bit versions |
| 21:33:15 | Skrylar | a fat binary has both packed in to it |
| 21:34:32 | runvnc | oh ok thank you |
| 21:34:44 | Skrylar | i figured thats what you were cross compiling for |
| 21:35:07 | runvnc | well maybe on my mint machine somehow I could make it spit out a command line tool for an os x machine |
| 21:35:20 | Skrylar | i don't know anything about cross compiling *to* osx though; seems like it would be hard to do since the headers aren't really worked on for that path |
| 21:35:21 | runvnc | probably 64 bit would be good for most people |
| 21:35:37 | * | zahary1 joined #nimrod |
| 21:36:04 | runvnc | so I could just install nimrod on os x and compile on there with nimrod and it would probably run on most people with any 64 bit osx |
| 21:36:38 | runvnc | if I am on 64 bit os x |
| 21:41:06 | dom96 | Yes. Unless you are using external libs. |
| 21:42:04 | runvnc | so awesome |
| 21:42:27 | * | BitPuffi1 joined #nimrod |
| 21:42:32 | runvnc | well what if I need to use the -d:ssl option that doesnt use openssl as an external lib or something does it |
| 21:42:38 | runvnc | need to do https requests |
| 21:42:41 | dom96 | it does sadly. |
| 21:42:43 | * | sale4one joined #nimrod |
| 21:42:56 | runvnc | dang |
| 21:43:02 | runvnc | maybe I dont need to do https then |
| 21:43:39 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 21:44:03 | dom96 | maybe you could include the dll with your binary |
| 21:48:06 | Varriount | Araq: You rang |
| 21:49:00 | Araq | Varriount: I want you to add babel support to the tester; the tester should get an option to download every babel package and ensures it still compiles |
| 21:49:50 | Varriount | Hm. |
| 21:50:39 | Varriount | Araq: Have you seen my PR yet? |
| 21:50:50 | runvnc | maybe dom. or maybe I can just shell out to curl or wget depending on which they have. then I dont have to do it in bash or worry about ssl |
| 21:52:12 | Araq | Varriount: yeah but I'm not too sure I want macro voodoo in winlean. IMO the bare bone stuff shouldn't depend on what currently still is fragile and in flux |
| 21:52:39 | Varriount | I understand. |
| 21:54:30 | Varriount | Araq: Just to be clear, you only want to make sure a package *compiles*, correct? |
| 21:54:40 | * | sale4one quit (Remote host closed the connection) |
| 21:54:48 | Araq | correct |
| 21:55:26 | * | sale4one joined #nimrod |
| 21:56:47 | Varriount | Araq: You mentioned a bloom filter for coroutines, there's actually one in babel |
| 21:57:55 | Araq | looked at it, doesn't fit |
| 21:58:10 | Varriount | Aw. |
| 21:58:32 | Araq | come on a bloom filter for the stack detection is like ~20 lines of code anyway |
| 21:58:36 | Araq | if at all |
| 21:59:15 | EXetoC | not that you have any control over those packages, but it gives you an overview I guess |
| 22:04:02 | Araq | EXetoC: actually after manual checking we can disable these babel packages or mark them as "broken" |
| 22:04:18 | Araq | if the tester fails at compiling them and it's not a compiler bug |
| 22:04:55 | * | brihat quit (Remote host closed the connection) |
| 22:05:01 | dom96 | I don't think this will work out. |
| 22:05:28 | dom96 | Although it all depends on how much broken code people actually commit. |
| 22:06:46 | * | brson quit (Quit: leaving) |
| 22:07:03 | * | brson joined #nimrod |
| 22:07:06 | sale4one | but I could be used on essential packages :) |
| 22:07:06 | EXetoC | one more reason to allow packages to be flagged as trusted, but then you should still compile in an isolated VM |
| 22:07:13 | Varriount | Araq: I will do it, however atm, I have a calc test to study for. |
| 22:07:51 | Varriount | dom96: What do you do when someone doesn't want to use git as a repository? |
| 22:08:58 | EXetoC | it's not just git that is supported though |
| 22:09:46 | dom96 | Varriount: What do I do? You should ask Araq what he will do. |
| 22:10:05 | Varriount | Huh? |
| 22:10:54 | dom96 | Varriount: Well Araq wants this feature in the tester so you should ask him, or am I misunderstanding your question? |
| 22:10:59 | Araq | Varriount: babel supports mercial too |
| 22:11:06 | Araq | *mercurial |
| 22:15:37 | Varriount | You know, this makes me think fondly of sandboxes |
| 22:15:51 | Araq | indeed |
| 22:16:07 | Skrylar | Varriount: vagrant? |
| 22:16:18 | Skrylar | http://www.vagrantup.com/ |
| 22:17:28 | dom96 | That's a good point. You will need to implement some sort of sandboxing since processes can be executed at compile-time now. |
| 22:17:37 | Varriount | ^ |
| 22:17:49 | Varriount | Vagrant will do for now. |
| 22:18:04 | Varriount | Just means another fun, interesting program to learn. |
| 22:18:51 | Araq | Varriount: ok but we should start with the official babel packages from the nimrod-code organization |
| 22:19:04 | dom96 | "For almost three years, Vagrant was a side-project for Mitchell, a project that he worked on in his free hours after his full time job." |
| 22:19:07 | dom96 | hrm, sounds familiar. |
| 22:19:59 | Skrylar | i've never actualy used vagrant; i just ran across it once when people were talking about testing web software |
| 22:20:32 | Skrylar | since you can tell it to load a stock arch + install nodejs + test the things |
| 22:22:51 | * | sale4one quit (Quit: Leaving) |
| 22:25:16 | Skrylar | you know what would be really great for dealing with wrappers/binds? |
| 22:25:20 | Skrylar | something like Leo that actually worked |
| 22:26:24 | Skrylar | Chunk a file in to nodes (leo puts in comment markers so it can find them later), made a side-node with the bound/wrapped code and mark them as related |
| 22:27:03 | Skrylar | they have this neat thing where it stores your node boundaries in the file itself as comments, and a shadow option which uses diff/patch to hide them |
| 22:27:17 | Skrylar | so if someone hands you a new C file, it tries to patch the plain text markers back and re-load it to the IDE |
| 22:30:30 | * | zahary1 quit (Quit: Leaving.) |
| 22:36:41 | Skrylar | heh that would be weird |
| 22:36:45 | Skrylar | source-code-in-database for nimrod |
| 22:39:14 | Varriount | Hm. Is it naive to think that sandboxing nimrod's VM would be as easy as allowing only certain wrapped OS calls to be executed at compile time? |
| 22:40:03 | Araq | yes |
| 22:40:41 | Araq | "naive" in relation to "sandboxing" always has "yes" as an answer |
| 22:40:48 | profmakx | gnihi |
| 22:41:01 | Varriount | profmakx: Come again? |
| 22:41:12 | profmakx | gnihi |
| 22:42:36 | Varriount | Gesundheit |
| 22:47:34 | * | filwit joined #nimrod |
| 22:48:38 | Varriount | It's filwit! |
| 22:48:43 | filwit | it's Varriount! |
| 22:50:56 | Varriount | Araq: http://www.chromium.org/developers/design-documents/sandbox |
| 22:52:46 | Skrylar | Well, er. |
| 22:52:49 | Skrylar | That *is* how you sandbox. |
| 22:53:52 | Skrylar | In the case of Lua, you only expose calls you want people to be able to use. Then you can set tracers on runtime cycles so infinite loops don't lock up the host, and finally hook malloc to impose a memory limit. |
| 22:53:59 | Skrylar | Depending on the nimrod VM it wouldn't be that different |
| 22:54:48 | Skrylar | (lua actually has a debugging API which allows you to tell it "break in X opcodes") |
| 22:57:49 | * | oxful_ quit (Quit: Leaving) |
| 22:58:01 | Skrylar | Huh, now there is an idea. Compile nimrod to luajit |
| 22:58:37 | Varriount | I think that's what Araq did, once upon a time. |
| 22:58:53 | Araq | Skrylar: the JS codegen still has the start of a luajit backend in it |
| 22:59:12 | Araq | Varriount: no, I only played with the idea but abandoned it |
| 22:59:16 | Skrylar | moonscript and nimrod would probably go well together |
| 22:59:33 | Skrylar | all though moonscript is hard to debug because its basically the 'coffeescript of lua' |
| 23:02:22 | Varriount | That's not much of an excuse, after all, nimrod compiles to C |
| 23:03:55 | Skrylar | Varriount: it means a lot when you pop open a stacktrace |
| 23:04:03 | Skrylar | all though in lua you don't tend to have stack traces, so. |
| 23:06:23 | Varriount | Is lua not stack based? |
| 23:06:54 | Skrylar | Varriount: Lua tends to be of the opinion that your scripts should be small enough that if something goes wrong you already know where to look |
| 23:07:23 | Skrylar | I think you *can* do stack tracing but it usually isn't done |
| 23:08:11 | * | Matthias247 joined #nimrod |
| 23:09:33 | EXetoC | Varriount: some people have complained about coffeescript for that reason, but I suppose it depends on how much is added etc |
| 23:10:03 | * | q66 quit (Quit: Leaving) |
| 23:11:00 | Skrylar | EXetoC: the problem with coffeescript is that say, nodejs tells you there is an error on line 127 |
| 23:11:29 | Skrylar | So you open broken.js on line 127, oh wait its full of crap |
| 23:11:45 | Skrylar | now you have to go find which line of coffeescript "line 127 in broken.js" actually is |
| 23:13:40 | Varriount | dom96: Every babel project I try installing gives me an error that the name attribute is missing in the babel file |
| 23:14:10 | dom96 | Varriount: Quote me the error plz. |
| 23:16:05 | Varriount | https://gist.github.com/Varriount/9103647 |
| 23:16:05 | EXetoC | :> |
| 23:16:26 | Varriount | dom96: FYI, I downloaded comandeer before that, and got the error, |
| 23:17:21 | dom96 | rm -r C:\Users\Clay\.babel\pkgs\commandeer-0.1.2 |
| 23:19:12 | Varriount | rmdir /S /Q |
| 23:19:24 | Varriount | Is what you should have said. |
| 23:20:45 | * | [Pete_27] left #nimrod (#nimrod) |
| 23:20:55 | Varriount | dom96: That is a bug, I presume? |
| 23:21:31 | dom96 | Kinda. Do you remember the error you got when you were installing commandeer? |
| 23:24:34 | Varriount | dom96: https://gist.github.com/Varriount/9103750 |
| 23:29:28 | dom96 | hrm |
| 23:29:53 | dom96 | you shouldn't be building it though |
| 23:29:59 | * | xtagon joined #nimrod |
| 23:30:19 | Araq | good night |
| 23:30:23 | Varriount | Then what is the build command for? |
| 23:30:27 | Varriount | Good night Araq |
| 23:30:31 | Varriount | Hello xtagon |
| 23:30:59 | dom96 | what are the contents of commandeer.babel? |
| 23:31:11 | dom96 | For binary packages |
| 23:31:18 | * | brihat joined #nimrod |
| 23:31:44 | xtagon | Hello Varriount |
| 23:33:35 | Varriount | dom96: https://github.com/fenekku/commandeer/blob/master/commandeer.babel |
| 23:34:12 | dom96 | You sure C:\Users\XXX\.babel\pkgs\commandeer-0.1.2\commandeer.babel contains that? |
| 23:34:52 | * | oxful joined #nimrod |
| 23:34:52 | * | oxful quit (Max SendQ exceeded) |
| 23:35:10 | Varriount | dom96: Yep |
| 23:35:39 | dom96 | Varriount: Recompile babel in debug mode and tell me the stack trace. |
| 23:42:13 | Varriount | Hmf. Now it works. |
| 23:42:49 | dom96 | now try it in release mode |
| 23:43:11 | dom96 | if it fails in release mode then we may have a corruption on our hands |
| 23:43:29 | Varriount | Let me try again. |
| 23:47:16 | Varriount | dom96: It must have been a fault on my part. I can't reproduce it. :/ |
| 23:48:17 | * | xenagi joined #nimrod |
| 23:48:30 | dom96 | No worries. Try the steps if you remember them from the very start again if you can, or if you don't feel like it that's fine. |
| 23:49:37 | Varriount | Eh, I have calc to do |
| 23:49:56 | * | zahary1 joined #nimrod |
| 23:50:02 | dom96 | yeah, that's what I figured. |
| 23:50:03 | Varriount | TBH, I was using babel in order to test out that NimBorg project |
| 23:54:35 | * | Matthias247 quit (Read error: Connection reset by peer) |