| mikolajw | progress so far: finished Robert Baruch's tutorial, watched Luke's video about Libre-SoC, completed the "First steps" tutorial, superficially examined the Nmigen simulator code | 01:22 |
|---|---|---|
| mikolajw | now I'm going to try to write some small Nmigen simulations | 01:23 |
| mikolajw | and I ordered an Icebreaker FPGA board to be able to run my code | 01:25 |
| mikolajw | (I don't know if I can run Libre-SoC on it, probably not, but will still be useful) | 01:27 |
| mikolajw | made a blinker in Nmigen. It works, I can see the waveforms with GTKWave | 03:59 |
| mikolajw | Now I'm going to see the Python code Nmigen generated to simulate it | 04:00 |
| programmerjake | :) | 04:02 |
| mikolajw | ok, so it turns out all you need to do to get the code generated for the simulator is to set `NMIGEN_pysim_dump` environment variable, but it's only available in Nmigen development branch at the moment | 04:35 |
| mikolajw | Now I'm going to try to monkey-patch Nmigen to generate C code instead by reimplementing _pyrtl.py contents, as requested | 04:36 |
| mikolajw | and yeah, getting the C unsigned integer types to properly represent signals that aren't necessarily byte-aligned or less than 64 bits in size is going to be the hard part. I remember this was not fun when connecting Verilator-generated code with SDL2 | 04:44 |
| mikolajw | less than 65 bits in size* | 05:12 |
| programmerjake | imho the hard part is the >64 bit signals and/or the signed signals...signed overflow is UB cuz C is annoying | 05:14 |
| programmerjake | <= 64-bit unsigned signals can just be done with unsigned long long (or uint64_t -- probably better) and masking off the top bits | 05:15 |
| programmerjake | you can use cxxrtl for a reference for implementing the required bigint types: | 05:20 |
| programmerjake | https://github.com/YosysHQ/yosys/blob/d186ea7a2d74f859972746e03996e9eddc6a5157/backends/cxxrtl/cxxrtl.h#L110 | 05:20 |
| programmerjake | assuming we're targeting gcc/clang, you can use the builtin add/sub/mul overflow instructions to implement bigint arithmetic more efficiently (cuz it will use the cpu's carry flag): | 05:33 |
| programmerjake | https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html | 05:33 |
| programmerjake | functions, not instructions. oops... | 05:34 |
| programmerjake | they also fix the signed overflow is UB issue | 05:34 |
| mikolajw | I wonder if using https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html for signals between 64 and 128 bits could improve performance | 05:48 |
| mikolajw | if we're into microoptimization | 05:49 |
| mikolajw | or even worse: https://clang.llvm.org/docs/LanguageExtensions.html#extended-integer-types | 05:54 |
| mikolajw | I don't know what are your portability requirements | 05:56 |
| programmerjake | iirc we're targeting the linux kernel, so __int128 is out cuz it's only supported on 64-bit cpus...we'd likely want to run 32-bit powerpc at some point | 05:59 |
| programmerjake | clang extended int types are out cuz gcc doesn't support them | 06:00 |
| programmerjake | it'd be nice to target all gcc/clang supported targets, but that isn't a requirement | 06:01 |
| programmerjake | linux kernel is an intended target, but it'd be nice to work outside the kernel too | 06:03 |
| programmerjake | though double-check with lkcl cuz he may have something else in mind | 06:04 |
| programmerjake | if you run into issues, i may be able to help cuz I've implemented bigint libraries before, as well as arbitrary-constant-bitwidth integers | 06:06 |
| programmerjake | though that was in Rust and C++ | 06:06 |
| mikolajw | ok, sourcing the simulator engine from the current directory works, all I had to do is copy `pysim.py` and `_pyrtl.py` and pass `engine=` argument in `Simulator` constructor | 06:37 |
| mikolajw | Now analyzing `_FragmentCompiler` class | 06:45 |
| mikolajw | I'm going to just patch _pyrtl.py to output C instead of Python -- not going to rewrite it from scratch, as this will probably introduce less errors | 07:00 |
| programmerjake | sounds good! | 07:00 |
| ghostmansd-pc | Hi folks. I'm trying to push the upstream changes from gdb into our local repository (we're 8 months behind). However, upon $(git push origin master) I get "FATAL: W any binutils-gdb dmitry3mdeb DENIED by fallthru". | 07:31 |
| ghostmansd-pc | I cloned the repo via $(git clone gitolite3@git.libre-soc.org:binutils-gdb.git), and $(git remote -v) shows exactly this (plus upstream branch I added to vanilla binutils-gdb). | 07:32 |
| ghostmansd-pc | Basically all I did is: | 07:33 |
| ghostmansd-pc | git remote add upstream git://sourceware.org/git/binutils-gdb.git | 07:33 |
| ghostmansd-pc | git fetch upstream | 07:33 |
| ghostmansd-pc | git merge ustream/master | 07:33 |
| ghostmansd-pc | git push origin master | 07:33 |
| ghostmansd-pc | The last one breaks, with "FATAL: W any binutils-gdb dmitry3mdeb DENIED by fallthru". | 07:33 |
| programmerjake | it means you don't have write permission to that git repo, lkcl will have to fix that once he wakes up | 07:41 |
| ghostmansd-pc | OK, thanks! I suspected that, but still had to check it. :-) | 07:59 |
| octavius | mikolajw just be aware, as good as Robert Baruch's tutorial files are, they are a little out of date, so there may be things used in our nmigen files that need further clarification. I'm not an expert by a long shot (only started a few months ago), but if you have questions I'll try to answer them XD | 08:46 |
| lkcl | mikolajw, good progress on the nmigen tutorials. if you're used to verilog/vhdl/gate-level, always always use yosys "show top" on the .il file | 11:36 |
| lkcl | read_ilang {insert filename} | 11:36 |
| lkcl | show <press tab twice to get full list of modules> | 11:36 |
| lkcl | ahh please don't monkey-patch nmigen. please follow the instructions i gave here https://bugs.libre-soc.org/show_bug.cgi?id=665#c12 | 11:37 |
| lkcl | programmerjake, greater than 64-bit is specifically off the table for the first version | 11:37 |
| lkcl | there are no types greater than 64 bit in PowerDecoder2 which is the primary (exclusive) target of focus | 11:38 |
| lkcl | adding more than 64-bit - which is unnecessary and will take much longer than the budget allocated for the task - is unnecessary | 11:39 |
| lkcl | please do not give other developers just starting out the confusing impression that the tasks they are being given are much larger than necessary | 11:39 |
| lkcl | because mikolajw is just starting out i very specifically limited the scope that he does not get completely overwhelmed | 11:40 |
| lkcl | if he follows your advice he will get completely overwhelmed with too much to do in one go | 11:41 |
| lkcl | and it is scope-creep, doing far more than is actually needed | 11:41 |
| lkcl | mikolajw: just so you are aware - programmerjake does not have the experience to make project management / planning decisions, and frequently will design things "far in advance of what is actually needed" | 11:42 |
| lkcl | i have to be very strict with him about this because he keeps doing it. jeapordising our ability to complete within reasonable time-frames in the process. | 11:43 |
| lkcl | programmerjake, sorry to have to mention this (again) | 11:43 |
| lkcl | mikolajw, take a complete copy of _pyrtl.py as i described https://bugs.libre-soc.org/show_bug.cgi?id=665#c12 | 11:43 |
| lkcl | pick a location in the openpower-isa repo (a new subdirectory, suitably named) | 11:44 |
| lkcl | call the copy of _pyrtl.py .... i dunno... _crtl.py or something | 11:45 |
| lkcl | programmerjake, no it most definitely is not a goal to target all gcc/clang variants, that is massive scope-creep | 11:46 |
| lkcl | no, bigint libraries are not required here, that is massive scope-creep | 11:46 |
| lkcl | it would turn a 1.5-to-2-week task easily into a 3-5 week task, particularly when unit tests get involved | 11:48 |
| lkcl | ghostmansd-pc, done, added you to binutils, binutils-gdb and gcc | 11:55 |
| lkcl | there's supposed to be a stack of tutorials here https://libre-soc.org/3d_gpu/tutorial/ | 11:56 |
| lkcl | but linking through to lambdaconcept it's been removed | 11:57 |
| lkcl | archive.org still has it | 11:57 |
| lkcl | https://web.archive.org/web/20210123052724/http://blog.lambdaconcept.com/doku.php?id=nmigen:nmigen_install | 11:58 |
| lkcl | mikolajw, you'll see the extremely bad practice of wildcard imports has, unfortunately, infected the entirety of the HDL community | 11:59 |
| lkcl | this comes unfortunately from m-labs migen, over 15 years ago, when the scope of migen was absolutely tiny and they weren't ever expecting to have 100+ thousand line projects | 12:00 |
| lkcl | wildcard imports are great for tiny projects, one file, maybe a thousand lines | 12:00 |
| lkcl | for a massive codebase involving multiple developers, multiple libraries, and hierarchical layouts, they are an absolutey f*****g nightmare | 12:00 |
| lkcl | litex is one of the worst offenders here (one of the best examples of how not to organise a large project): they have deep nested hierarchical class layouts, with Factory classes (data structures that generate classes) | 12:02 |
| lkcl | where wildcard imports bring in classes *of the exact same name*, from different locations deep inside the file hierarchy... *across multiple code-repositories* | 12:02 |
| lkcl | bottom line is that hardware engineers are not properly trained as software engineers, and as a community simply haven't had the time (or enough really truly painful experiences) yet to learn from these kinds of mistakes | 12:04 |
| lkcl | navigating litex is almost impossible because even the normal practice of "recursive grep" for a class that you see used, you find that for example there are 50 different implementations of class "Platform" | 12:05 |
| lkcl | which one is used? you absolutely cannot tell and so have to examine all of them, looking at the full contents of the class, searching for function names and properties that look reasonably / vaguely like the ones being used | 12:06 |
| lkcl | so please, please, for god's sake, don't follow that practice when writing nmigen. there are very few circumstances where wildcard imports are useful. | 12:07 |
| programmerjake | > programmerjake, no it most definitely is not a goal to target all gcc/clang variants, that is massive scope-creep | 16:09 |
| lkcl | holy cow the i-cache / mmu stuff is complex. | 16:11 |
| lkcl | am barely keeping up with how the microwatt code works | 16:12 |
| lkcl | but... i now have a (first) unit test which walks through the process of loading an instruction when virtual memory is enabled | 16:13 |
| programmerjake | it may be scope-creep, however it is extremely easy to do (and in fact what any decent C programmer will likely do by default)...just don't use stuff not in the latest version of gcc/clang -- aka. use portable C (as well as optionally the gcc builtin overflowing functions -- they're still the best option for wrapping signed arithmetic) | 16:13 |
| programmerjake | lkcl: yay! | 16:14 |
| lkcl | again: (1) it's easy *for you* (2) it's extra work (3) this is mikolajw's very first contribution and it's (4) far more important that he not be overloaded than "extra features be added" and (5) reminder - again - of the incremental code-development policy | 16:15 |
| lkcl | yeah, i had to hack things to communicate to the MMU | 16:15 |
| lkcl | after it returns "fetch failed", the MMU has to be triggered to do a RADIX page-walk | 16:15 |
| lkcl | with a special notification "iside" (instruction-side) | 16:16 |
| lkcl | that's not been used before (and isn't supported by LoadStore1 or by the MMU FSM) | 16:16 |
| lkcl | yeah it's a big deal. | 16:17 |
| lkcl | frankly i'm astounded it worked | 16:17 |
| programmerjake | i'd argue that writing mostly portable C is just about as much work as for you to avoid importing winreg when writing python...soo easy you could do it in your sleep...basically don't go out of your way to depend on platform-specific stuff | 16:19 |
| lkcl | yeah that's fairly normal practice. | 16:21 |
| lkcl | basically the real target is the linux kernel. | 16:23 |
| lkcl | the entire output has to be useable inside the linux kernel. | 16:23 |
| lkcl | therefore, even depending on <stdio.h> etc. is completely out of the question | 16:23 |
| programmerjake | soo...why are you arguing that "fairly normal practice" is out of scope? | 16:23 |
| lkcl | i'm not. | 16:24 |
| lkcl | i thought you were advocating "support this version of a compiler AND support that version of a compiler AND support version X on platform Y times Z" | 16:24 |
| lkcl | which would require autoconf or other such system and that's a definite "No" at this extremely early stage | 16:25 |
| programmerjake | "support all the compilers...": well, yes (more or less), but just cuz that's how portable C works, not cuz you'd actually add anything extra to do that | 16:26 |
| programmerjake | no autoconf | 16:26 |
| lkcl | whilst it would be nice at some point to auto-generate python c-based modules (done that before, for python-webkit) and actually have simulations actually really running | 16:29 |
| lkcl | that's definitely on the "nice-to-have" list so not a priority | 16:29 |
| lkcl | unless... it becomes so damn awkward to test the auto-generated code that it turns out to be easier to do that | 16:30 |
| lkcl | in which case, the budget gets upped... | 16:30 |
| programmerjake | oh, if we're doing that, we should target https://cffi.readthedocs.io/en/latest/ | 16:31 |
| lkcl | yyeah that's pretty dreadful. as is ctypes | 16:32 |
| lkcl | ctypes i used with pyjamas-desktop on w32 to access the entirety of the MSRPC interface in IEXPLORE.DLL | 16:33 |
| programmerjake | from what i heard cffi is by far the best way to portably connect C with Python | 16:33 |
| lkcl | portable, yes, fragile yes. | 16:34 |
| lkcl | it's based on calling functions by creating the function call stack... *by hand* | 16:34 |
| programmerjake | cuz it depends on the c compiler to resolve the ABI, so is portable and fast, unlike ctypes | 16:34 |
| lkcl | mmm ok. | 16:35 |
| programmerjake | cffi is what i'm planning on using for the python rewrite of pia | 16:36 |
| programmerjake | to be specific, i'm referring to the cffi mode of operation that just calls the c compiler to compile against python's headers, not the mode that uses libffi | 16:44 |
| tplaten | now having a look at test_loadstore1_ifetch.vcd | 18:30 |
| lkcl | tplaten: i'm amazed it works | 18:30 |
| lkcl | the key signal to keep an eye on is mmu.iside (instruction-side) | 18:30 |
| lkcl | and "itlb_load" | 18:31 |
| lkcl | some cesar-style gtkwave/css for this would be real handy | 18:31 |
| tplaten | I saw that yesterday when I compared parts of libre-soc with microwatt | 18:38 |
| tplaten | I am asking myself how would this be integrated into core and issuer, as issuer does the instruction fetch. | 18:39 |
| tplaten | I agree with the cesar-style gtkwave/css | 18:40 |
| ghostmansd-pc | for anyone interested, here's the progress so far for gas: https://git.libre-soc.org/?p=binutils-gdb.git;a=shortlog;h=refs/heads/svp64 | 18:57 |
| ghostmansd-pc | for now, we're able to parse many bits, except for stuff marked as is_bc; we're not doing anything after parsing | 18:58 |
| ghostmansd-pc | That's mostly a sketch for now, we parse stuff but drop it; I'm interested to hear you opinions, if I'm going into the wrong direction, please let me know now, before it's too late. :-) | 18:59 |
| tplaten | I recently saw the commit | 18:59 |
| octavius | ghostmansd-pc, I looked at your commitdiff. I roughly understand it (looks similar to parsing code I wrote for my project a while back), and at least from a syntax point of view, I didn't see any obvious mistakes/issues | 19:16 |
| octavius | A lot of macro use, but that's almost expected in C, right? :) | 19:17 |
| ghostmansd-pc | octavius, thank you for taking a look! basically what we do is simple: whenever we encounter something that starts with "sv.whatever", we try to gather all stuff separated by SVP64_SEP (currently '/'); we have tables of such stuff, and mostly it boils down to converting string into something integer-like. | 19:18 |
| ghostmansd-pc | Well, I actually don't like how it looks, but I tried to stick to binutils-gdb style. I personally don't like it, but they use it there. :-) | 19:19 |
| octavius | So is your code going to take the SVP64 instructions, and convert them to just the OpenPOWER ISA? | 19:19 |
| ghostmansd-pc | So macros to e.g. define one entry in array of structures are direct reflection of other bits of code I saw there. | 19:19 |
| octavius | hehe fair enough | 19:20 |
| ghostmansd-pc | Yes, for now this. Actually we should remap these, but this is for later. | 19:20 |
| ghostmansd-pc | So we take instructions, grab everything we can decode, but don't bother after that. :-) | 19:21 |
| ghostmansd-pc | This, of course, is somewhat an intermediate stage. Once we're able to decode, I'll squash the subsequent patches. | 19:21 |
| octavius | Yeah given that time limit that makes sense. Still very cool. Also nice to see a bit of C, even if I appreciate Python a lot more XD | 19:22 |
| ghostmansd-pc | I guess at this stage this is simply "OK, now we can parse some bits, but don't really consider these at all" | 19:22 |
| ghostmansd-pc | :-D | 19:22 |
| ghostmansd-pc | That's actually an awful C. I'd have written many bits differently. | 19:22 |
| ghostmansd-pc | Welcome to GNU coding style, lol | 19:23 |
| octavius | Well, better than some of what I've seen. At least it's not trying to cram too much | 19:23 |
| octavius | In general I try to avoid macros in my stuff, just so the compiler actually works for me | 19:23 |
| ghostmansd-pc | I tried gas on some stuff like `sv.extsw./sm=r3/dm=r3 5, 31`, and it's able to eat this, so we're now at least somewhere. :-) | 19:24 |
| octavius | But real projects probably can't escape from them | 19:24 |
| octavius | Nice! | 19:24 |
| ghostmansd-pc | I'm actually OK with macros as long as they're not abused, e.g. I'd use macros for intrusive linked lists, but not in place of inline functions. | 19:25 |
| octavius | Yeah, that makes sense | 19:25 |
| octavius | Very small, verbose bits of code | 19:25 |
| ghostmansd[m] | Yep. Actually some C++ people I saw around go to great lengths to avoid macros replacing those with templates. Well, in my experience, some templates were _much_ worse than macros. Really, I cannot recall a C macro I could not understand, but with templates, I saw quite a lot. | 19:29 |
| ghostmansd[m] | So I tend to treat dont-use-macros advice with a grain of salt if it comes from C++ programmer, but totally accept in from anyone else :-D | 19:30 |
| octavius | It's a shame that c++ is such a rabbit hole. Even the hello world is esoteric (to put it lightly). So much software I use is written in it, but I don't really want to even touch it. So my points on macros are valid eh? ;) | 19:31 |
| jn | one of the main issues (as i see it) with C++ is, that the language is so big that everyone only uses a subset of it. of course, this isn't the same subset for everyone | 19:33 |
| ghostmansd[m] | Lol, about hello world in C++, I recall one of my colleagues who told he was surprised as fuck when he saw they tried to do bit shifting on strings... | 19:35 |
| ghostmansd[m] | It took me some time to realize he was mentioning std::cout << "hello, world" << std::endl or something like this. | 19:36 |
| octavius | std::cout << "Hello World!"; | 19:36 |
| octavius | https://www.programiz.com/cpp-programming/examples/print-sentence | 19:36 |
| octavius | So this is a bitshift? I thought the string was sent to STDOUT | 19:36 |
| jn | yeah, this (ab/re)use of the leftshift operator was a bit of a weird choice | 19:36 |
| octavius | like a unix << | 19:36 |
| jn | octavius: that's the intention | 19:36 |
| jn | and the effect | 19:36 |
| octavius | Yeah | 19:37 |
| jn | but << is still primarily the leftshift operator in C++ | 19:37 |
| ghostmansd[m] | Maybe, lol. For him it was bitshift. :-) | 19:37 |
| octavius | Somehow I can separate the two in my head (in a terminal vs writing C code). In c++ I would probably also think of bitshift only | 19:38 |
| jn | eh | 19:38 |
| jn | you'd get used to the dual meaning | 19:38 |
| jn | at some point | 19:38 |
| octavius | sure | 19:38 |
| octavius | but that requires *using* c++ :P | 19:39 |
| ghostmansd[m] | Not the case for this project it looks like :-P | 19:40 |
| octavius | I guess at least untill there's more graphics development | 19:41 |
| programmerjake | well...for a lot of the graphics stuff we're planning on using Rust rather than C++, though there will still be a bit of C++ for the work on gcc and llvm | 19:48 |
| octavius | Ah ok | 19:56 |
| octavius | Which version of Rust will we use? Aren't there fairly frequent release? Or is this not going to be a major issue? | 19:57 |
| *** tplaten <tplaten!~isengaara@55d4844b.access.ecotel.net> has left #libre-soc | 20:00 | |
| programmerjake | rust changing versions isn't a major issue because they test against *all* published crates and public projects on github...the compiler is very reliable (as long as you just use stable features) | 20:06 |
| octavius | Ah ok, good. | 20:08 |
| octavius | Do you have any good recommendations for how to get started with rust? Just pick a project to implement and start using it? At some point I'd like to get round to using it | 20:09 |
| programmerjake | i'm assuming that whatever distros decide to package our graphics driver will end up using a rust compiler released around the same time as our driver, so us using newer rust features won't be an issue till then, at which point we can limit ourselves to the features of that rust release | 20:11 |
| programmerjake | i'd suggest trying: https://doc.rust-lang.org/book/ | 20:12 |
| programmerjake | i learned rust in a pretty unusual way: i read all the library and language docs for months then actually used it waay later...so if you want to learn rust, following my approach may not be the best idea | 20:14 |
| programmerjake | if you have questions feel free to ask here or on https://users.rust-lang.org/ or somewhere else... | 20:16 |
| programmerjake | the rust community is quite friendly (one of their strongest points) | 20:17 |
| octavius | Hehehe, I don't think I read full documentation for anything that I've used before (perhaps wishbone is one of the few exceptions), so I'll probably do a bit of both | 20:24 |
| programmerjake | :) | 20:25 |
| lkcl | ghostmansd[m], try to keep in a branch for binutils-gdb, it will make review and pull requests easier when merging upstream (upstream will like branches) | 20:39 |
| lkcl | it's looking pretty good | 20:40 |
| lkcl | octavius: the official Power ISA 3.0 and 3.1 does not have SVP64. | 20:42 |
| lkcl | if i can reword the question (to clarify, to one for which the answer is "yes") - "is this going to take SVP64 assembly instructions and turn them into binary-formatted output"? the answer to that is "yes" | 20:43 |
| lkcl | that's what gnu-gas does: turns assembly mnemonics (of any supported language) into executable binary object format. | 20:44 |
| lkcl | octavius: c++ was fantastic when i was using it 20+ years ago. the prevalent use of standard templates is now quite insane. | 20:45 |
| octavius | Yeah, I didn't word it too well. From my limited reading, SVP64 instructions essentially become for-loops, or similar instructions to make vector operations from scalars | 20:46 |
| octavius | by iterating over a set of registers | 20:46 |
| lkcl | ghostmansd[m], ah, saw the bugreport message, it's a branch already. whewww | 20:47 |
| lkcl | basically.... yes. | 20:47 |
| lkcl | fascinatingly, this is not a novel idea. | 20:47 |
| lkcl | Peter Hsu, the designer of the MIPS R8000, came up with the exact same concept in 1994. | 20:47 |
| lkcl | like: to the letter. prefix on a MIPS scalar-instruction as a suffix, the prefix covering src and dest regs, marking each individually as either scalar or vector, predication - everything. | 20:48 |
| lkcl | they were even going to do it as a multi-issue out-of-order execution engine | 20:49 |
| octavius | It seems to me that most ideas are reused/recycled. That's what happened with coding theory in electronics (when it became to run complex algos from the 50s/60s on embedded hardware). I'm sure there's plenty of good research we haven't rediscovered yet | 20:49 |
| lkcl | the *only reason* they didn't go ahead - back in 1994-1995 - was because MIPS could not work out how to do multi-issue out-of-order | 20:49 |
| octavius | Yes, always some issue preventing the overall idea from being used (due to efficiency I guess) | 20:50 |
| ghostmansd[m] | lkcl: I had an experience with FSF, I know the rules, lol :-D | 21:06 |
| lkcl | ghostmansd[m]: :) | 21:06 |
| ghostmansd[m] | Well, at least in general, I for sure forgot some details over the years, bit still the main course is known | 21:06 |
| ghostmansd[m] | Branch for the win | 21:06 |
| lkcl | they have to be very strict about it (and the copyright assignment) | 21:06 |
| lkcl | managing enormous projects, you just... have to be | 21:07 |
| ghostmansd[m] | Yeah, I went through copyright assignment once, perhaps it's still there in mail, will check | 21:07 |
| ghostmansd[m] | I will check bc and ldst in the next days. Then, I think, we can go to remap. | 21:08 |
| ghostmansd[m] | What's in branch is really a sketch. The code will likely be updated based on my understanding. | 21:09 |
| ghostmansd[m] | For now this is what I was able to understand and collect, I hope that my understanding will improve, so will the code. | 21:09 |
| ghostmansd[m] | But don't really rely on that: regardless of how deeply I understand the original code, it will still be consumed by the coding style I adopt. :-) | 21:10 |
| lkcl | ghostmansd[m], ah cool, if you've done it already it'll still be on file, but worth checking with the copyright clerk | 21:48 |
| lkcl | programmerjake, octavius jn cesar rsc toshywoshy meeting 10min | 21:49 |
| toshywoshy | Is Alain joining the ISA WG meeting? | 22:06 |
| toshywoshy | I won't be in the weekly meeting as the ISA TWG meeting is also now | 22:08 |
| lkcl | ahh ok | 22:09 |
| lkcl | will caall him | 22:09 |
| lkcl | toshywoshy, left a message, i think he's asleep :) | 22:22 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!