| 00:31:49 | * | jbe_ quit (Quit: Leaving) |
| 01:33:15 | * | XAMPP-8 joined #nimrod |
| 01:37:19 | * | q66 quit (Quit: Leaving) |
| 01:37:57 | * | XAMPP-8 quit (Ping timeout: 276 seconds) |
| 04:22:11 | * | OrionPK quit (Quit: Leaving) |
| 04:57:01 | * | XAMPP-8 joined #nimrod |
| 05:05:50 | * | zahary joined #nimrod |
| 06:00:14 | * | XAMPP-8 quit (Ping timeout: 240 seconds) |
| 07:10:41 | vegai | now does nimrod do unicode? Are strings utf8? |
| 07:11:39 | vegai | https://github.com/Araq/Nimrod/issues/400 |
| 07:11:49 | vegai | looks like it's more or less like it's in go |
| 07:17:52 | Araq | vegai: it's utf-8 except for inputs where we don't guarantee anything |
| 07:17:55 | Araq | however! |
| 07:18:16 | Araq | you can use --taintMode:on and then you're forced to do input validation on your own |
| 07:27:23 | vegai | roger |
| 07:36:46 | * | Associat0r joined #nimrod |
| 07:36:46 | * | Associat0r quit (Changing host) |
| 07:36:46 | * | Associat0r joined #nimrod |
| 07:44:25 | * | EXetoC joined #nimrod |
| 08:57:54 | * | Associat0r quit (Quit: Associat0r) |
| 09:21:23 | NimBot | Araq/Nimrod master c542aa7 Araq [+1 ±6 -0]: implemented computed goto support |
| 10:10:47 | * | q66 joined #nimrod |
| 10:23:38 | * | BitPuffin joined #nimrod |
| 11:43:57 | * | Associat0r joined #nimrod |
| 11:44:01 | * | Associat0r quit (Changing host) |
| 11:44:01 | * | Associat0r joined #nimrod |
| 12:11:02 | dom96 | hello |
| 12:17:29 | NimBot | nimrod-code/packages master b04b95a Simon Hafner [+0 ±1 -0]: + kwin |
| 12:17:29 | NimBot | nimrod-code/packages master ae5c916 Dominik Picheta [+0 ±1 -0]: Merge pull request #23 from reactormonk/patch-2... 2 more lines |
| 12:40:21 | * | noam_ quit (Ping timeout: 264 seconds) |
| 13:28:51 | * | noam joined #nimrod |
| 13:38:10 | BitPuffin | Hmm |
| 13:38:24 | BitPuffin | How is the progress on passing values to generic parameters? |
| 13:38:43 | BitPuffin | cc @zahary @zahary__ |
| 13:57:58 | * | noam_ joined #nimrod |
| 13:59:53 | * | noam quit (Read error: Operation timed out) |
| 14:05:38 | zahary__ | this particular problem is actually very simple, but my branch is blocked on some other harder issues |
| 14:06:01 | Araq | what issues, zahary__ ? |
| 14:07:03 | zahary__ | ah, they are not that harder - I started the reform for compiling the generics in their defining module. this is required to fix the .globals. issue that fowl posted a long time ago |
| 14:07:36 | Araq | well I dunno |
| 14:07:54 | Araq | when .globals are to be assigned to is not well defined |
| 14:08:01 | Araq | I mean, it's in the spec |
| 14:08:23 | Araq | but what kind of behavior you need depends on the use case |
| 14:10:15 | Araq | perhaps the behavior should simply be "append at module's body" so that you have some control over it |
| 14:10:20 | zahary__ | I have couple of ideas how it should work. there will be an explicit initGlobals() magic giving you precise control when they should be initialized and before this I'll even improve the spec further by giving guarantees that the .global. vars will see the vars before them in the module and are visible from top-level code after their defining proc |
| 14:11:05 | zahary__ | this spec should be the least surprising imo |
| 14:20:46 | * | noam joined #nimrod |
| 14:22:09 | Araq | what's wrong with the current way again? |
| 14:22:38 | * | noam_ quit (Ping timeout: 246 seconds) |
| 14:23:12 | zahary__ | well, the current way is pretty random, because the globals will initialize in the first module that happened to reference their originating proc |
| 14:23:52 | zahary__ | and this ordering is changed in recompiles in unexpected ways |
| 14:23:52 | Araq | hmm I thought they are generated in the BModule they belong to |
| 14:24:15 | zahary__ | this information is lost, because the generic proc gets a new owner |
| 14:24:38 | Araq | that sounds easy to fix though |
| 14:25:14 | Araq | .global vars should get the current module as owner and the instantiation process shouldn't overwrite it |
| 14:25:40 | zahary__ | well, compiling generics in their first user is broken for other reasons too |
| 14:26:22 | Araq | arguably it's broken too if you compile them in the original module |
| 14:27:08 | Araq | instantiateHash(someNewHashFunction) # and now the original module gets all the stuff so that it can see someNewHashFunction ? |
| 14:27:22 | zahary__ | the breakage I'm referring to comes from symbol files and cass - if you stop using the generic funtion from the module it happened to be compiled to, this can break other modules |
| 14:27:35 | zahary__ | that's because the compiler doesn't attempt to "ref count" the usages of the generic |
| 14:28:26 | Araq | well symbol files do not even serialize your new generics stuff so I dunno |
| 14:28:49 | Araq | you simply never updated the serializers :P |
| 14:29:11 | zahary__ | yes, but they can be fixed with the new scheme (it would be harder with the old) |
| 14:29:23 | zahary__ | otherwise, I understand your point, but my long-term proposal is to compile them in a separate satellite module if you remember |
| 14:29:55 | zahary__ | that buys you predictable module sizes foo.part1.c / foo.part2.c and less recompilation |
| 14:31:20 | Araq | hmm, we should make it foo.1.c and foo.2.c instead |
| 14:31:41 | zahary__ | sure, I was using just illustative names |
| 14:31:47 | Araq | this also solves the "2 modules of the same name problem" then |
| 14:31:47 | zahary__ | illustrative |
| 14:32:03 | Araq | which we need to support for Babel |
| 14:32:39 | Araq | as everybody names his modules "utils" and "types" |
| 14:33:55 | Araq | but gah, this doesn't work anyway |
| 14:34:29 | Araq | I thought we can simply check if nimcache/utils.c already exists but then nimcache will grow for every recompilation |
| 14:48:34 | * | noam_ joined #nimrod |
| 14:51:45 | * | noam quit (Ping timeout: 264 seconds) |
| 14:58:12 | reactormonk | dom96, now how do I use babel in my project? |
| 14:58:33 | dom96 | well, sadly, currently you can't hah |
| 14:58:50 | dom96 | I need to implement the ability for you specify the compilation backend I guess |
| 14:59:03 | dom96 | I'll do that just for you :) |
| 15:00:52 | zahary__ | Sorry, was afk for a while. the same module name problem can be solved by appending the module numeric ID to the generated file name if there is a name collision. The module IDs are persisted in caas mode and are easy to persist with symbol files too |
| 15:02:39 | Araq | they already are persisted in symbol files iirc |
| 15:03:06 | * | noam__ joined #nimrod |
| 15:03:11 | zahary__ | no, I wanted to do it in order to avoid some string lookup during reading of rodfiles, but never got to it |
| 15:03:58 | zahary__ | all mentions of other modules are encoded as integers in the bulk of the data, but there is a map of int to path at the begining of the rod file |
| 15:04:26 | Araq | ah yeah |
| 15:04:30 | zahary__ | it's easy to move to global per-project map |
| 15:04:50 | zahary__ | sharing rod files from libraries interferes with this a little bit |
| 15:05:03 | Araq | that was the plan |
| 15:05:15 | Araq | but currently it's in project/nimcache anyway |
| 15:05:26 | Araq | so you can't share rod files easily |
| 15:05:40 | * | noam joined #nimrod |
| 15:06:24 | zahary__ | we've discussed the external interface of the libraries and how they should define "I depend on these definitions during compilation" in order to improve the potential sharing |
| 15:06:38 | Araq | did we? |
| 15:06:45 | * | noam_ quit (Ping timeout: 264 seconds) |
| 15:07:12 | Araq | all I remember is symbol obfuscation |
| 15:07:54 | * | noam__ quit (Ping timeout: 264 seconds) |
| 15:08:21 | zahary__ | yes, long time ago - didn't remember the specific reasons back then. but I'm mentioning it here, because it's related. if you use all the compilation settings of a project as a cache invalidation key for the shared rodfiles, you won't get much sharing anyway, because complex projects are likely to have minor differences in configs most of the time |
| 15:08:51 | BitPuffin | zahary__: so it's already finished or is it just that you haven't done it yet but it's simple? |
| 15:10:08 | zahary__ | the problem is that there are commits that follow it - I have to extract just this particular feature from the rest of the commits |
| 15:10:33 | zahary__ | also, haven't really done it yet :P |
| 15:10:50 | BitPuffin | zahary__: looking forward to it! So I can refactor my lib to be less stupid :P |
| 15:11:12 | zahary__ | what are you working on? |
| 15:11:17 | BitPuffin | zahary__: math library |
| 15:11:35 | BitPuffin | https://bitbucket.org/TheLonelyByte/linagl |
| 15:12:14 | BitPuffin | zahary__: right now I have to use ranges where I don't really want to have ranges |
| 15:12:46 | BitPuffin | brb |
| 15:13:03 | zahary__ | nice, I thought that is the case too. |
| 15:14:40 | zahary__ | for swizzle, we have another planned feature too - you'll be able to implement something like ruby's method_missing at compile-time |
| 15:15:08 | Araq | yeah I told him about it |
| 15:23:40 | * | Associat0r quit (Quit: Associat0r) |
| 15:25:53 | * | Associat0r joined #nimrod |
| 15:25:53 | * | Associat0r quit (Changing host) |
| 15:25:53 | * | Associat0r joined #nimrod |
| 15:47:29 | reactormonk | pry has more commits than nimrod. Hmm. ^^ |
| 16:00:48 | * | Mat2 joined #nimrod |
| 16:00:51 | Mat2 | hi @ all |
| 16:06:40 | reactormonk | Mat2, morning |
| 16:07:48 | Mat2 | hi reactormonk |
| 16:14:28 | * | BitPuffin quit (Read error: Operation timed out) |
| 16:31:44 | Mat2 | Araq: POSIX do not define the MAP_ANONYMOUS flag so using mmap for virtual-address space allocation is OS dependent (Linux for example support this behaviour only up kernel > 2.4) |
| 16:33:11 | Mat2 | valloc on the other side is supported from all xNIX variants since V7 and BSD 4.2 |
| 16:34:42 | Mat2 | hmm, first problem. I need to write a wrapper for valloc (don't included in there mmap library) |
| 16:57:17 | Araq | reactormonk: what's "pry"? and why should we care? |
| 17:05:02 | Mat2 | hi Araq |
| 17:07:35 | Araq | hi Mat2 I've implemented computed goto support |
| 17:07:48 | Araq | but it's not tested very well :P |
| 17:08:07 | Mat2 | great :D |
| 17:08:53 | Araq | use it like this: |
| 17:08:58 | Araq | while true: |
| 17:09:10 | * | darithorn_ joined #nimrod |
| 17:09:19 | Araq | {.computedGoto.} |
| 17:09:24 | Araq | case opcode |
| 17:09:27 | Araq | of ... |
| 17:09:29 | dom96 | hello darithorn_ |
| 17:09:39 | darithorn_ | hello |
| 17:09:43 | * | darithorn_ is now known as darithorn |
| 17:09:55 | Mat2 | hi darithorn |
| 17:10:22 | Mat2 | Araq: That's all ? nice syntax compared to C |
| 17:12:52 | Araq | well it's much less flexible ... |
| 17:13:22 | Araq | but as I said, this way of doing it is convenient and doesn't screw up the control flow analysers |
| 17:14:11 | Mat2 | I think the folk at LLVM would be interested in it (there have some problems supporting these GNU extension) |
| 17:16:27 | Araq | it doesn't help the LLVM guys, they want to support GNU C, so they need to do support it like GNU C does |
| 17:17:27 | Mat2 | hmm ok |
| 17:25:46 | * | BitPuffin joined #nimrod |
| 17:28:56 | Araq | Mat2: I can make the compiler emit NIM_COMPUTED_GOTO(JumpTable[i]) instead of goto *JumpTable[i] and then you can do some voodoo to make GCC generate some assembler labels that you can patch |
| 17:29:42 | Araq | so that 'call eax' instead of 'jmp eax' is produced |
| 17:30:09 | Araq | but I dunno how the 'ret's need to be inserted |
| 17:53:50 | * | Sergio965 joined #nimrod |
| 17:57:22 | Mat2 | ok, that would be nice |
| 17:57:59 | * | Mat2 struggling with yet another mmap bug |
| 18:02:37 | * | Araq is struggling with incomprehensible LaTeX error messages ... |
| 18:03:03 | dom96 | hrm, maybe #latex can help? |
| 18:03:36 | Mat2 | sadly, I only use AsciiDoc |
| 18:19:50 | * | Mat2 problem solved (though undocumented flag setting) |
| 18:31:38 | * | BitPuffin quit (Ping timeout: 268 seconds) |
| 18:37:44 | dom96 | gah, github killed the /languages page |
| 18:42:26 | Araq | "First of all: beamer does not provide any automatic scaling of text or diagrams like MS Power Point, because its author thinks that it leads to bad presentations. If the material doesn't fit on one slide unscaled simply make two or more slides out of it." |
| 18:42:30 | Araq | -.- |
| 18:42:48 | Mat2 | *argh* |
| 18:43:12 | Araq | maybe I should use power point instead ... |
| 18:43:46 | Araq | yeah, remain unhelpful and call it a feature instead |
| 18:45:09 | Mat2 | Araq: probably that's of use: http://www.methods.co.nz/asciidoc/slidy.html#%281%29 |
| 18:46:12 | Araq | well I'd prefer a PDF instead of a website |
| 18:46:28 | * | BitPuffin joined #nimrod |
| 18:46:54 | Mat2 | that's also possible (though docbook convertion) |
| 18:47:20 | Araq | meh, fullscreen via browser is good enough I guess |
| 18:51:12 | Araq | hmm this looks excellent, I can make nimrod's documentation generator generate HTML slides |
| 18:53:14 | Mat2 | better as struggling with SMaTex I think |
| 18:54:14 | Araq | latex is a never ending pita, unhelpful error messages, overflow hbox crap, packages are all incompatible with each other in various ways |
| 18:54:31 | Araq | insane quoting rules |
| 18:54:40 | Araq | broken macro system |
| 18:54:55 | Araq | etc. etc. how anybody can use it productively escapes me |
| 18:55:00 | dom96 | Araq: hah, after you left someone agreed with you. |
| 18:55:39 | Mat2 | *lol* |
| 18:55:45 | BitPuffin | zahary__: I guess this is encourages making a branch for every task you ever do for easy merging later on :) |
| 18:56:08 | Araq | dom96: in #latex? |
| 18:56:14 | dom96 | yes |
| 18:56:18 | Araq | lol |
| 18:56:45 | Mat2 | well, that's xNix tradition |
| 19:11:01 | * | Sergio965 quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 19:14:03 | reactormonk | Araq, repl for ruby. And it's awesome. |
| 19:15:23 | Araq | of course it's Ruby after all |
| 19:21:08 | * | Sergio965 joined #nimrod |
| 19:25:23 | BitPuffin | Araq: you like ruby? |
| 19:27:42 | Araq | BitPuffin: never used it, but I dislike dynamic typing enough so that I'll never try it |
| 19:28:26 | BitPuffin | Araq: ah, well you don't seem to love OO all that much either |
| 19:28:50 | Araq | well you know these things are related ... |
| 19:29:08 | BitPuffin | Araq: dynamic typing and OO? |
| 19:29:21 | Araq | why would I do all the painful work if there was something out there that I particularly like? |
| 19:29:58 | BitPuffin | Araq: because designing a programming language is an interesting challenge. But I guess out of spite is a good reason too :) |
| 19:35:24 | dom96 | BitPuffin: Do you like Ruby? |
| 19:35:47 | BitPuffin | dom96: yes, it's mighty fine, but it is too slow for most of my work |
| 19:36:08 | BitPuffin | dom96: I do too lean towards liking static typing more, and functional programming |
| 19:36:24 | BitPuffin | at least I am starting to |
| 19:46:57 | BitPuffin | Is it a good idea to convert ptr to ref? When binding to C |
| 19:48:23 | Araq | it's a good idea if you have control over the allocation |
| 19:48:34 | Araq | many C libraries do this: |
| 19:48:47 | Araq | proc createStuff(): ptr Stuff |
| 19:48:56 | Araq | proc freeStuff(s: ptr Stuff) |
| 19:49:06 | Araq | and then you CANNOT change ptr to ref |
| 19:58:51 | BitPuffin | ah |
| 19:59:04 | BitPuffin | what's the equivalent of size_t in nimrod? |
| 20:00:08 | Araq | int |
| 20:00:14 | BitPuffin | oh |
| 20:02:46 | BitPuffin | Hmm |
| 20:02:50 | BitPuffin | FILE |
| 20:03:16 | BitPuffin | TFile? |
| 20:03:23 | Araq | FILE* is TFile (I know, I know ...) |
| 20:03:49 | BitPuffin | so they are indeed equivalent, good |
| 20:04:00 | BitPuffin | shouldn't c2nim catch that? |
| 20:05:23 | Araq | sure |
| 20:08:55 | BitPuffin | So how does one deal with linking to static C libs with nimrod |
| 20:09:06 | BitPuffin | dom96: is there a babel option for this? |
| 20:09:29 | dom96 | nope |
| 20:10:03 | BitPuffin | dom96: hm, kind of need it probably |
| 20:10:21 | BitPuffin | dom96: I'm writing a binding to scrypt and a wrapper for using it for password hashing |
| 20:10:51 | dom96 | k, submit an issue. I'll do it ASAP. |
| 20:11:23 | dom96 | but hrm, wait. |
| 20:11:35 | dom96 | Shouldn't the .nimrod.cfg handle it? |
| 20:12:55 | BitPuffin | I dunno |
| 20:13:01 | BitPuffin | don't no jack about nimrod.cfg |
| 20:17:59 | BitPuffin | wait brb, we'll have a look soon |
| 20:19:56 | * | gradha joined #nimrod |
| 20:21:34 | Araq | hi gradha |
| 20:21:47 | Mat2 | hi gradha |
| 20:21:47 | gradha | hi Araq |
| 20:21:49 | Araq | your library doesn't export anything :P |
| 20:21:53 | Araq | so I can't use it |
| 20:21:55 | gradha | library? |
| 20:22:04 | Araq | the resource stuff |
| 20:22:50 | gradha | it's not meant to be used as a library yet |
| 20:22:50 | gradha | you are meant to compile, run it, then run the generated binary |
| 20:22:57 | * | BitPuffin quit (Ping timeout: 264 seconds) |
| 20:23:06 | gradha | it just tests if binaries with appended data have problems under other platforms than mine |
| 20:23:21 | gradha | I wouldn't expect this to be a problem, but since you mentioned having problems in the past I went the safer route |
| 20:23:32 | Araq | well I need a proc getResource(file: string): string |
| 20:24:08 | Araq | Mat2: using HTML for the slides works incredibly well :-) |
| 20:24:58 | gradha | Araq: sure, I was meaning to write that and make a pull request against Aporia using it |
| 20:25:08 | Araq | why aporia btw? |
| 20:25:41 | gradha | dom96 seemed to have problems with some resources used by Aporia not being available in the binary directory, IIRC for babel binary installation or something |
| 20:26:00 | gradha | it looked like a real world problem rather than my own imaginary problems |
| 20:26:09 | gradha | unless I dreamed all this Aporia resources stuff |
| 20:26:25 | Araq | let's ask dom96 ... dom96? |
| 20:26:40 | gradha | hi EvilAww |
| 20:26:53 | EvilAww | Hello |
| 20:26:58 | dom96 | If you're talking about the stuff that the gtksourceview depends on then I don't think gradha's solution can help. |
| 20:27:20 | dom96 | Unless I dunno, you embed it in the executable and then when aporia starts write it to the hard drive |
| 20:28:04 | Araq | that sounds aweful |
| 20:28:09 | gradha | urgh, so gtksourceview reads these resources and you can't control that? |
| 20:28:16 | dom96 | indeed |
| 20:28:29 | dom96 | You can set a search path for it. |
| 20:28:32 | dom96 | But that's about it. |
| 20:29:19 | gradha | then I'll make up my own imaginary problems |
| 20:29:41 | Araq | well nimrod needs it for system.nim |
| 20:29:58 | gradha | how does it need it? |
| 20:30:16 | Araq | so that "nimrod i" can be a single exe |
| 20:30:43 | gradha | ah, yes, I thought you wouldn't want to use it before "correct" use, meaning, not writing appended data to $TMP |
| 20:33:18 | Araq | if you can write to $TMP you can also return the contents in a string? |
| 20:33:52 | gradha | yes, why would you want a string though? |
| 20:34:16 | * | Araq always misuses strings as byte buffers |
| 20:35:49 | gradha | I guess you could export to nimrod the mmaped binary as a read only array |
| 20:36:41 | Araq | what's wrong with getResource("system.nim") ? |
| 20:37:04 | Araq | you need to add some indexing structure I guess |
| 20:37:38 | gradha | it's either building my own file format structure or reusing the zip module |
| 20:39:17 | Mat2 | Araq: good to know :D |
| 20:39:53 | Araq | you should have told me earlier, Mat2 ;-) |
| 20:56:27 | gradha | meh, I guess I'll leave the zip route for later, it's too tedious |
| 20:58:23 | gradha | getResource will also be case sensitive, rather than implement case insensitive matching it seems easier to lowercase all filenames when preparing the appended data |
| 20:58:51 | * | BitPuffin joined #nimrod |
| 20:59:54 | Araq | gradha: meh ... I'll patch it then ;-) |
| 21:00:22 | BitPuffin | okay so how do I link to a static C library in .nimrod.cfg |
| 21:00:43 | BitPuffin | dom96: should .nimrod.cfg be in src/ or in the same dir as foo.babel |
| 21:00:50 | gradha | Araq: I was thinking of using TTable, you may want to add a TCaseTable |
| 21:01:06 | dom96 | BitPuffin: src/ I think |
| 21:01:12 | BitPuffin | dom96: okay |
| 21:01:22 | Araq | gradha: there is newStringTable(modeCaseInsensitive) in strtabs.nim |
| 21:01:43 | gradha | also just saw hashes.hashIgnoreCase |
| 21:02:43 | Araq | I read about a guy who uses a.png for the thumbnail and A.png for the real image |
| 21:02:57 | Araq | and he complained this doesn't work on windows |
| 21:03:23 | gradha | wouldn't strtabs require two lookups? it maps to a string... so I first match the user input to the stored filename, then look up the filename? |
| 21:04:01 | gradha | I was expecting a hierarchy of TTables per directory, with filename mapping to an internal structure holding byte offset and length of the data |
| 21:04:46 | Araq | just map the full path/filename to some byte offset |
| 21:05:11 | BitPuffin | is it `l=ltarsnap` in .nimrod.cfg? |
| 21:05:25 | gradha | full path/filename looks scary given crossplatform path separators |
| 21:05:46 | Araq | why? '/' is the universal path separator anyway |
| 21:06:51 | gradha | maybe users will want to use os procs to build the filepath |
| 21:07:38 | BitPuffin | dom96: any idea? :( |
| 21:08:22 | gradha | using os.joinPath on windows would break then as input for getResource |
| 21:08:30 | dom96 | BitPuffin: huh? what are you trying to do? |
| 21:08:40 | BitPuffin | dom96: link to a static library in .nimrod.cfg |
| 21:08:46 | Araq | gradha: so do a x.nomalize.replace('\\', '/') on the path 'x' and call it a day |
| 21:09:15 | dom96 | BitPuffin: The stuff you put in the .cfg file is similar to what you would use as an argument on the cmd line. |
| 21:09:43 | dom96 | BitPuffin: I guess --passL:-ltarsnap is what you want? |
| 21:09:56 | BitPuffin | dom96: I hope so |
| 21:10:16 | gradha | Araq: so using strtabs, do you suggest storing the offset and length of each file as a string? |
| 21:11:33 | Araq | I suggest you normalize the path and then use a TTable[string, tuple[offset, length: int]] |
| 21:15:37 | gradha | now that you mention normalize maybe I could use UnixToNativePath when reading the index from disk |
| 21:17:53 | Mat2 | get some sleep, ciao |
| 21:18:06 | * | Mat2 quit (Quit: Verlassend) |
| 21:19:27 | BitPuffin | ulong would be uint64 right? |
| 21:24:42 | * | Sergio965 quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 21:25:17 | BitPuffin | what's the proper way to convert between string and ptr uint |
| 21:25:22 | BitPuffin | uint8* |
| 21:25:25 | BitPuffin | ptr unit8 |
| 21:25:30 | BitPuffin | and back |
| 21:30:21 | BitPuffin | "PPPPyObject" lol |
| 21:39:41 | * | q66 quit (Quit: Leaving) |
| 21:40:01 | * | q66 joined #nimrod |
| 21:57:08 | * | zahary__ is now known as zahary_ |
| 22:16:55 | * | EXetoC quit (Quit: WeeChat 0.4.1) |
| 22:18:37 | * | OrionPK joined #nimrod |
| 22:44:59 | * | Trix[a]r_za quit (Ping timeout: 240 seconds) |
| 22:45:15 | * | Trixar_zb joined #nimrod |
| 23:19:07 | gradha | good night |
| 23:19:11 | * | gradha quit (Quit: bbl, need to watch http://www.youtube.com/watch?v=OzrkmcBMPYo again) |
| 23:27:14 | OrionPK | https://github.com/google/gumbo-parser |
| 23:28:25 | OrionPK | good candidate for wrappage |
| 23:35:39 | * | BitPuffin quit (Ping timeout: 268 seconds) |
| 23:48:46 | * | Associat0r quit (Quit: Associat0r) |
| 23:50:01 | * | Associat0r joined #nimrod |
| 23:50:01 | * | Associat0r quit (Changing host) |
| 23:50:01 | * | Associat0r joined #nimrod |