| *** tpb has joined #yosys | 00:00 | |
| *** dys has quit IRC | 01:30 | |
| *** kraiskil has joined #yosys | 02:07 | |
| *** citypw has joined #yosys | 02:41 | |
| *** _whitelogger has quit IRC | 03:15 | |
| *** _whitelogger has joined #yosys | 03:17 | |
| *** craigo has quit IRC | 03:56 | |
| *** PyroPeter has quit IRC | 04:00 | |
| *** PyroPeter has joined #yosys | 04:13 | |
| *** _whitelogger has quit IRC | 05:12 | |
| *** _whitelogger has joined #yosys | 05:14 | |
| *** _whitelogger has quit IRC | 05:36 | |
| *** _whitelogger has joined #yosys | 05:38 | |
| *** _whitelogger has quit IRC | 06:06 | |
| *** _whitelogger has joined #yosys | 06:08 | |
| *** Jybz has joined #yosys | 06:26 | |
| *** Jybz has quit IRC | 06:35 | |
| *** _whitelogger has quit IRC | 06:54 | |
| *** _whitelogger has joined #yosys | 06:56 | |
| *** emeb_mac has quit IRC | 07:08 | |
| *** _whitelogger has quit IRC | 07:30 | |
| *** _whitelogger has joined #yosys | 07:32 | |
| *** m4ssi has joined #yosys | 09:06 | |
| pepijndevos | ZirconiumX, my script has an assert, so I don't think I need grep. What I ended up doing is specifying everything except -modules | 09:08 |
|---|---|---|
| pepijndevos | ZirconiumX, What exactly are you doing with test/arch/common? I made them work for gowin recently, so maybe I know _something_ | 09:09 |
| ZirconiumX | pepijndevos: you'll still need grep :P | 09:11 |
| pepijndevos | Hmmm, question of my own: how do I implement a Nextpnr constraint for the generic target in Python? Some of my slices in a tile don't have a DFF. | 09:11 |
| pepijndevos | ZirconiumX, to do what? That only limits what is considered a crash, any my assert perfectly describes the crash I want. | 09:12 |
| ZirconiumX | Great, and what if you find a Yosys bug in the process? | 09:14 |
| ZirconiumX | That's a crash | 09:14 |
| pepijndevos | sure... | 09:14 |
| ZirconiumX | And now bugpoint is going off to minimise something entirely different to your target | 09:14 |
| ZirconiumX | In fact, I bet that's why you needed to ignore modules; because pruning the top-level module produced a different error, no? | 09:15 |
| *** kraiskil has quit IRC | 09:15 | |
| ZirconiumX | Anyway. | 09:17 |
| pepijndevos | Oh... you're saying it deleted *everything* and decided that was the most minimal case... yea ok... | 09:17 |
| ZirconiumX | Honestly I think -grep should be required | 09:19 |
| daveshah | pepijndevos: in a real arch it would be a simple validity check problem | 09:20 |
| daveshah | But that isn't exposed to Python, and Python code in the placer hot path wouldn't be great in any case | 09:21 |
| daveshah | imo, just ignore those cells for now | 09:21 |
| pepijndevos | Right haha | 09:21 |
| pepijndevos | I'll just have 6 slices | 09:21 |
| ZirconiumX | pepijndevos: I just pushed the broken test to the better-flow branch of prjmistral | 09:22 |
| pepijndevos | link? | 09:22 |
| ZirconiumX | Make sure to clone it in your home directory, because I don't yet have the luxury of the + path, so put it in ~ instead :P | 09:22 |
| ZirconiumX | https://github.com/ZirconiumX/mistral | 09:23 |
| tpb | Title: GitHub - ZirconiumX/mistral: Cyclone V bitstream reverse-engineering project (at github.com) | 09:23 |
| ZirconiumX | It's mistral/flow/test/intel/shifter.ys | 09:28 |
| *** flaviusb has joined #yosys | 09:48 | |
| pepijndevos | ZirconiumX, the problem is in @(posedge CLK or negedge ACn) | 09:59 |
| ZirconiumX | Ugh. | 10:00 |
| ZirconiumX | That's awkward. | 10:00 |
| pepijndevos | Not sure how you'd solve that or why I didn't have this problem (yet) | 10:00 |
| daveshah | Yeah, that `if` pattern doesn't correspond to any of the allowed 1364.1 patterns | 10:00 |
| daveshah | The `en` needs to be inside the `if(!ACn)` and/or `else` not outside of it | 10:00 |
| daveshah | The rule is that the async set/reset(s) must always be top level if branches inside the `always` | 10:01 |
| pepijndevos | Huh, interesting... | 10:02 |
| daveshah | See page 9/10 of http://www.iuma.ulpgc.es/~nunez/clases-FdC/verilog/Verilog-IEEE-1364.pdf | 10:03 |
| ZirconiumX | This is me trying to interpret the vendor FF model | 10:03 |
| daveshah | It's one of the few parts of Verilog that's actually well defined | 10:03 |
| daveshah | rather than being left up to the synthesis tool to decide what patterns it does/doesn't infer | 10:03 |
| daveshah | Although many tools allow more than 1364.1 but Yosys follows it exactly | 10:03 |
| daveshah | I guess that model is intended for simulation; so they didn't pay attention to synthesis rules | 10:04 |
| ZirconiumX | ERROR: Async reset \ACn yields non-constant value 1'm for signal \Q. | 10:04 |
| daveshah | Yeah, actually the enable is still dodgy | 10:04 |
| ZirconiumX | Presumably it has to be unconditionally reset then? | 10:04 |
| daveshah | Try gating ACn with enable outside of the always | 10:05 |
| ZirconiumX | https://github.com/AmeerAbdelhadi/Verilog-Quartus-Mapping-VQM-Netlist-Parser/blob/master/sim/cyclonev_atoms.v#L394 | 10:06 |
| tpb | Title: Verilog-Quartus-Mapping-VQM-Netlist-Parser/cyclonev_atoms.v at master · AmeerAbdelhadi/Verilog-Quartus-Mapping-VQM-Netlist-Parser · GitHub (at github.com) | 10:06 |
| ZirconiumX | Here's the vendor model I'm trying to replicate | 10:06 |
| daveshah | I don't think the async clear is gated by the enable at all? | 10:07 |
| daveshah | So just have the enable as an if statement in the clocked 'else' part | 10:07 |
| ZirconiumX | I must have gotten it confused with synchronous clear then | 10:07 |
| ZirconiumX | Okay, so now proc_arst doesn't complain | 10:08 |
| ZirconiumX | It fails to prove equivalence though | 10:08 |
| ZirconiumX | Which is annoying. | 10:09 |
| ZirconiumX | On the other hand | 10:09 |
| ZirconiumX | Warning: No SAT model available for cell $techmap$auto$simplemap.cc:420:simplemap_dff$56.$procdff$167_gate ($adff) | 10:09 |
| ZirconiumX | I should probably find/fix this | 10:09 |
| daveshah | You probably need a techmap and clk2fflogic or sync2async in there | 10:09 |
| ZirconiumX | I'm basing this off the iCE40 script | 10:11 |
| ZirconiumX | 5.45. Executing EQUIV_STATUS pass. | 10:15 |
| ZirconiumX | Found 8 $equiv cells in equiv: | 10:15 |
| ZirconiumX | Of those cells 8 are proven and 0 are unproven. | 10:15 |
| ZirconiumX | Equivalence successfully proven! | 10:15 |
| ZirconiumX | Woo! | 10:16 |
| *** craigo has joined #yosys | 10:53 | |
| pepijndevos | Niiice | 10:55 |
| pepijndevos | ZirconiumX, Micko recommended I based mine of the Efinix tests because they don't have any arch-specific tests in them yet | 10:56 |
| pepijndevos | Curious if fsm.ys works for you... I'm stuck on that one with a weird equivalence bug. | 10:56 |
| ZirconiumX | First I've got to get my LUTs in order | 10:57 |
| pepijndevos | (which seems unrelated to my techmap, rather wreduce just deletes a few too many bits) | 10:57 |
| *** wifasoi has joined #yosys | 10:57 | |
| ZirconiumX | I mean, that's indicative of a bug if anything | 10:58 |
| *** rohitksingh has quit IRC | 11:18 | |
| *** rohitksingh has joined #yosys | 11:24 | |
| pepijndevos | Probably, maybe. | 11:26 |
| pepijndevos | Hmmmmmmmmm, do cell port names have to map to bel port names? I'm currently just using Gowin bel port names, but it's not happy about that. | 11:33 |
| pepijndevos | And the generic packer does a weird thing where the Q is either the LUT F or the DFF Q, while on Gowin they are different things. So maybe I just need to bit the bullet and make my own Python packer. | 11:36 |
| ZirconiumX | daveshah: I have a really stupid idea. Quartus accepts a Routing Constraints File that lets you map signal paths, and the Quartus Settings File lets you place cells in exact positions. So nextpnr would produce a solution that constrains Quartus to the point where nextpnr's solution is the only valid solution for PnR, and then it can produce a bitstream from there. | 11:46 |
| *** rohitksingh has quit IRC | 11:51 | |
| mwk | tbh that seems to be the obvious correct way to use quartus as bitgen-only | 11:56 |
| mwk | not pretty, but Should Work™ | 11:56 |
| *** vidbina_ has joined #yosys | 11:57 | |
| ZirconiumX | mwk: it's a stupid idea, you're not meant to *agree* with me :P | 12:01 |
| mwk | ZirconiumX: it's what I would actually do :p | 12:02 |
| mwk | we work with the tools we're given | 12:02 |
| mwk | or well | 12:02 |
| ZirconiumX | The main question is how long it will take Quartus to realise I've given it the solution | 12:02 |
| mwk | what I'd really do is use the same path, but to build a lot of fuzzers | 12:03 |
| ZirconiumX | Indeed, but I'm not as smart as you, mwk :P | 12:03 |
| mwk | you're severely overestimating the complexity of a routing fuzzer, given device map and control over routing :p | 12:10 |
| *** kraiskil has joined #yosys | 12:12 | |
| ZirconiumX | No, I'm not :P | 12:17 |
| pepijndevos | If you know all the wires that exist, and have control over them, you can just fuzz them like any other feature, no? Turn wire off, collect bits, turn wire on, collect bits, compare. | 12:19 |
| ZirconiumX | *If* you know all the wires that exist | 12:20 |
| mwk | pepijndevos: correct | 12:21 |
| pepijndevos | Uh, you have control over them, but you can't observe them? | 12:21 |
| ZirconiumX | I have little knowledge of the internal routing | 12:21 |
| daveshah | I'm also not sure if Quartus can just turn arbitrary wires on and off | 12:21 |
| mwk | ZirconiumX: this is also a requirement for getting P&R working, though | 12:21 |
| daveshah | I think it still needs a full routed path | 12:21 |
| mwk | so if you can do a nextpnr backend, you can also do a fuzzer | 12:22 |
| daveshah | And I presume will create one around constraints if an rcf isn't complete | 12:22 |
| ZirconiumX | Yep | 12:22 |
| ZirconiumX | So I can observe them, but control is questionable | 12:22 |
| daveshah | The simple correlation approach that xray does would probably suffice | 12:22 |
| ZirconiumX | mwk has automated fuzzers for these bits and I calculated them all by hand | 12:23 |
| ZirconiumX | Well, by manual binary diffing | 12:23 |
| *** vidbina_ has quit IRC | 12:37 | |
| *** kraiskil has quit IRC | 12:43 | |
| *** wifasoi has quit IRC | 12:46 | |
| pepijndevos | daveshah, IIRC you mentioned yesterday you could do basic packing with a techmap, could you elaborate a bit? | 13:01 |
| pepijndevos | It seems actually more like extract | 13:01 |
| daveshah | That was mwk I think | 13:01 |
| daveshah | Not so much the combining cells together side of packing, but more the converting cell types | 13:02 |
| pepijndevos | But I'm struggling to make it work due to the init parameter... or at all | 13:02 |
| daveshah | Which is a lot of what nextpnr packing is about as validity checks often mean not so much combining is needed | 13:02 |
| daveshah | eg converting various lut primitives to a single common LUT, same for FF and IO | 13:02 |
| daveshah | For packing involving merging cells probably a custom pass would be best | 13:03 |
| tnt | daveshah: btw, thanks for ecp5 compressed bitstream, that's really nice \o/ | 13:04 |
| daveshah | Oh glad it's useful, lmk if you hit an issues | 13:04 |
| *** vidbina_ has joined #yosys | 13:07 | |
| pepijndevos | Hmm | 13:07 |
| mwk | pepijndevos: I said yosys passes in general, not just techmap | 13:18 |
| mwk | pmgen might be useful as well, for one | 13:19 |
| mwk | (though I have to admit I haven't fully figured out how pmgen works yet, so take it with a grain of salt) | 13:19 |
| *** wifasoi has joined #yosys | 13:22 | |
| pepijndevos | mwk, ERROR: No such command: pmgen (type 'help' for a command overview) | 13:25 |
| mwk | it's not a command, it's a... framework/code generator to build commands | 13:31 |
| mwk | have a look at passes/pmgen | 13:31 |
| pepijndevos | Currently trying to use extract, but seems a dead end due to parameters. | 13:33 |
| mwk | yeah, extract sucks | 13:33 |
| mwk | it's a very one-trick pony | 13:33 |
| pepijndevos | This is the second time I'm trying to use it and run into the parameter thing. | 13:33 |
| mwk | what you need is a more general pattern-matching engine | 13:34 |
| mwk | which pmgen tries to be | 13:34 |
| pepijndevos | Sometimes I wonder how normal people use Yosys... maybe they just run synth_ice40 and live happily. | 13:34 |
| mwk | (pattern matcher generator) | 13:34 |
| mwk | well yes | 13:34 |
| mwk | that's exactly how most people use yosys :p | 13:35 |
| mwk | some days they even use *shudder* options to the synth_whatever pass | 13:35 |
| mwk | I'm not sure I can recommend pmgen though | 13:39 |
| mwk | it feels quite ugh to me | 13:39 |
| pepijndevos | I mean... what am I even doing... the generic packer is like a dozen lines of C, surely it can't be too hard to just hand-roll my own python packer using a slightly different primitive. | 13:42 |
| mwk | c++ | 13:43 |
| mwk | also, the amount of stuff you need to do in the packer heavily depends on your device and how well the incoming primitives match with the P&R sites | 13:44 |
| pepijndevos | cpedanticpedantic | 13:44 |
| pepijndevos | Right. Disregarding everything complicated, I would say pretty well hehe | 13:45 |
| mwk | it might not be so simple | 13:45 |
| mwk | there are a lot of decisions to make here | 13:45 |
| daveshah | In general, I am leaning towards minimal packing and more validity checking | 13:46 |
| mwk | are LUT and FF separate cells, or do you want to place a combined LUT+FF cell? | 13:46 |
| mwk | your FPGA has wide multiplexers — how do you represent that? | 13:46 |
| mwk | same for distributed RAMs | 13:46 |
| mwk | which also take up several LUTs | 13:47 |
| pepijndevos | mwk, I'm doing a silly PoC, I'm not considering anything like wide muxes. | 13:47 |
| mwk | fair enough | 13:47 |
| mwk | what about LUT+FF though? | 13:47 |
| daveshah | FWIW, both DRAM and wide LUTs can be represented in nextpnr using relative constraints | 13:47 |
| daveshah | (I know mwk knows that, for the benefit of pepijn) | 13:47 |
| pepijndevos | So right now I'm just trying to make the generic target pack a LUT+DFF in a slice. | 13:48 |
| daveshah | imo, LUT+FF should be separate cells/bels if they are separately useable (like Xilinx); combined if not (like iCE40) | 13:48 |
| mwk | agreed | 13:48 |
| mwk | FWIW, they're not separately usable | 13:48 |
| daveshah | A combined primitive makes sense as the placer can't really chose to place them separately in any case then | 13:48 |
| pepijndevos | I can *almost* use the generic packer, except Gowin has a seperate LUT and DFF output, so the cell doesn't match the bel | 13:49 |
| mwk | right | 13:49 |
| mwk | so you need to make a LUTFF cell | 13:49 |
| mwk | 4 inputs, two outputs | 13:49 |
| daveshah | I am actually tempted to change the generic cell to meet that spec | 13:49 |
| daveshah | Several FPGAs seem to follow the pattern | 13:49 |
| pepijndevos | I'll *hapily* make a PR for that, seems more useful and easy than some whacky yosys pass or Python mess | 13:50 |
| daveshah | Sure, would make a good first nextpnr PR. | 13:50 |
| pepijndevos | omg, on my way, brb | 13:50 |
| pepijndevos | hehe | 13:50 |
| mwk | of course eventually you'll need to extend your simple cell with more stuff to support muxes, ALUs, RAMs :p | 13:51 |
| mwk | but sure, it's a good way to begin\ | 13:51 |
| pepijndevos | What would you think about command-line parameters to make the cell names configurable? | 13:51 |
| daveshah | Well they wouldn't be command line parameters they'd be a Python function like how LUT K is set | 13:52 |
| pepijndevos | mwk, I'm not going to do any of those things in Python. So it's more like... do PoC in Python, then do the real thing properly in C++ | 13:52 |
| daveshah | Personally, I'd rather the generic flow core primitives stayed generic | 13:53 |
| pepijndevos | Okay, I'll do the other thing first... the parameters is more work and less important | 13:54 |
| daveshah | You could probably just translate them in the fasm export script | 13:56 |
| pepijndevos | also true | 13:56 |
| mwk | you'd need to convert them on input as well though | 13:56 |
| mwk | at least if you want to keep the yosys output netlist compatible with vendor | 13:57 |
| pepijndevos | Right, with renaming a few things, you could *maybe* (not super likely) use the actual synth_gowin pass with all the extras disabled, rather than the special synth_generic script. | 13:58 |
| pepijndevos | But yea, might as well just use the synth_generic script and rename the output to match | 13:58 |
| pepijndevos | daveshah, I think I got it working. I added a --write command to visualize it with Yosys, do you want that in the PR, or should I leave it the way it was? https://imgur.com/q3Ao1Dl | 14:30 |
| tpb | Title: Imgur: The magic of the Internet (at imgur.com) | 14:30 |
| daveshah | Yeah, add the --write too | 14:31 |
| daveshah | Make sure to update the example too | 14:31 |
| pepijndevos | Yes, I did, that's why I added the write, to verify the example actually looks more or less sane and doesn't have any disconnected Q or F outputs | 14:32 |
| daveshah | Great | 14:33 |
| *** vidbina_ has quit IRC | 14:39 | |
| pepijndevos | daveshah, https://github.com/YosysHQ/nextpnr/pull/350 | 14:58 |
| tpb | Title: Dedicated output for LUT in GENERIC_SLICE by pepijndevos · Pull Request #350 · YosysHQ/nextpnr · GitHub (at github.com) | 14:58 |
| *** alexhw has quit IRC | 14:59 | |
| *** alexhw has joined #yosys | 15:01 | |
| *** kraiskil has joined #yosys | 15:11 | |
| pepijndevos | daveshah, uhm, where does this int constructor live? I found this one https://github.com/YosysHQ/nextpnr/blob/master/common/nextpnr.h#L305 | 15:23 |
| tpb | Title: nextpnr/nextpnr.h at master · YosysHQ/nextpnr · GitHub (at github.com) | 15:23 |
| daveshah | https://github.com/YosysHQ/nextpnr/blob/master/common/nextpnr.cc#L137 | 15:24 |
| tpb | Title: nextpnr/nextpnr.cc at master · YosysHQ/nextpnr · GitHub (at github.com) | 15:25 |
| daveshah | pepijndevos: ^ | 15:25 |
| pepijndevos | huh, but does C++ just allows you to assign an into to that (ignoring the width) and it'll do the right thing? | 15:26 |
| daveshah | Yes, it calls the constructor because the constructor isn't marked as explicit | 15:26 |
| pepijndevos | I was looking for some operator= magic because I assign an int | 15:26 |
| daveshah | In this case, you want to fill the str with a string of [01] and then call update_intval# | 15:27 |
| daveshah | *update_intval() | 15:27 |
| pepijndevos | Ah, the width has a default value, is that why it works? | 15:27 |
| *** alexhw has quit IRC | 15:27 | |
| daveshah | Yes | 15:27 |
| pepijndevos | Sometimes I think I know C++... | 15:28 |
| pepijndevos | Sometimes I'm an idiot haha | 15:28 |
| pepijndevos | I had a job writing C++... don't tell anyone I was really just writing C | 15:30 |
| *** alexhw has joined #yosys | 15:30 | |
| daveshah | I mean nextpnr's codebase isn't that C++y | 15:30 |
| daveshah | There's not a large amount of templating or polymorphism | 15:30 |
| pepijndevos | True | 15:31 |
| pepijndevos | Let's see what's the most C++y way I can find to make a string of 10 | 15:33 |
| *** wifasoi has quit IRC | 15:34 | |
| pepijndevos | nvm, writing C hehe | 15:49 |
| *** dys has joined #yosys | 15:49 | |
| pepijndevos | I think I fixed it but uuuhhh testing testing... how is this supposed to work.. | 15:56 |
| daveshah | The generic architecture isn't really tested at all (the infrastructure wasn't there at the time I wrote most of it) | 15:56 |
| daveshah | Feel free to write something that uses the back annotated JSON in a simple test | 15:57 |
| pepijndevos | Currently crashing because !is_string | 15:57 |
| daveshah | where? | 15:58 |
| daveshah | is_string should be false | 15:58 |
| pepijndevos | Property::Property(const std::string &strval) : is_string(true), str(strval), intval(0xDEADBEEF) {} | 15:59 |
| pepijndevos | If you make it from a string it sets is_string | 15:59 |
| daveshah | That is where the property is storing an ASCII string rather than a string representation of a bitvector | 15:59 |
| daveshah | i.e. the former is isomorphic to "ABCD" in Verilog, the later to something like 8'b10101010 | 16:00 |
| daveshah | if that example makes any sense | 16:00 |
| daveshah | You want to use from_string rather than the string constructor here | 16:01 |
| *** Jybz has joined #yosys | 16:02 | |
| pepijndevos | ok | 16:02 |
| pepijndevos | Huh... it's the K parameter that's a string, wtf? | 16:04 |
| *** Thorn has quit IRC | 16:04 | |
| daveshah | That's broken | 16:05 |
| daveshah | It's probably a legacy from before Property existed | 16:05 |
| daveshah | where everything was a string (don't blame me on that one...) | 16:05 |
| daveshah | probably just a stray std::to_string that needs to be removed | 16:05 |
| daveshah | yeah, just remove the to_string here https://github.com/YosysHQ/nextpnr/blob/master/generic/cells.cc#L45 | 16:07 |
| tpb | Title: nextpnr/cells.cc at master · YosysHQ/nextpnr · GitHub (at github.com) | 16:07 |
| pepijndevos | Yes, that was it... now it's back to bein broken in my own code | 16:08 |
| *** Jybz has quit IRC | 16:11 | |
| *** Jybz has joined #yosys | 16:12 | |
| *** citypw has quit IRC | 16:13 | |
| pepijndevos | woookring | 16:13 |
| pepijndevos | okay, even formatting took only two tries this time -.- | 16:19 |
| daveshah | LGTM! | 16:29 |
| pepijndevos | OMG yay | 16:29 |
| pepijndevos | ty | 16:29 |
| *** X-Scale` has joined #yosys | 16:30 | |
| *** X-Scale has quit IRC | 16:31 | |
| *** X-Scale` is now known as X-Scale | 16:32 | |
| *** FabM has quit IRC | 16:34 | |
| *** kraiskil has quit IRC | 16:46 | |
| *** gkh has quit IRC | 16:52 | |
| *** m4ssi has quit IRC | 16:59 | |
| *** rohitksingh has joined #yosys | 17:04 | |
| *** rohitksingh has quit IRC | 17:51 | |
| *** rohitksingh has joined #yosys | 17:56 | |
| *** emeb has joined #yosys | 18:13 | |
| *** pie_ has quit IRC | 18:16 | |
| *** kraiskil has joined #yosys | 18:31 | |
| *** dys has quit IRC | 18:47 | |
| *** attie has joined #yosys | 19:18 | |
| *** kraiskil has quit IRC | 19:30 | |
| *** pie_ has joined #yosys | 19:30 | |
| *** attie has quit IRC | 20:34 | |
| *** emeb_mac has joined #yosys | 20:36 | |
| *** rohitksingh has quit IRC | 21:02 | |
| *** Thorn has joined #yosys | 21:05 | |
| *** rohitksingh has joined #yosys | 21:10 | |
| *** Jybz has quit IRC | 21:30 | |
| *** Jybz has joined #yosys | 21:31 | |
| *** Jybz has quit IRC | 22:04 | |
| *** rohitksingh has quit IRC | 22:15 | |
| *** adjtm has quit IRC | 22:16 | |
| *** adjtm_ has joined #yosys | 22:17 | |
| *** emeb has left #yosys | 22:54 | |
| *** somlo has quit IRC | 23:44 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!