Sunday, 2022-04-03

*** alMalsamo is now known as littlebobeep02:21
programmerjakelkcl, markos, if you're talking about SVP64 stuff (CR vectors, etc.) at a tuesday meeting, please wait till the official meeting start time since I (and probably others) will want to join in and am unlikely to remember to join 15-20min early07:42
programmerjakefor all those who are having fun with ABI things:
tplatenI'm having a look at the verilator gtkwave files, it stops after 5 clock-cycles10:27
lkclthat's very obviously someone who doesn't understand the history of computing.  thinks "everything should be as simple as {insert my favourite high-level language}" and has no idea of the reality of how things actually work underneath10:33
lkcl my guess is that they're under... probably... 27 years old.10:33
lkclthere's a beautiful section in Neal Stephenson's Snowcrash about telephone exchanges10:33
lkclwhere anyone starting as an employee first working on a given exchange's source code literally goes into shock.10:33
lkclthey look at the millions of lines of code in utter horror, going "jaezus christ surely this isn't necessary, i can't possibly understand it"10:33
lkclafter one year they are still trying to get over their initial shock10:33
lkclafter two years they at least have a handle on the source code10:34
lkclafter three years they have enough knowledge to FINALLY understand why the code is as complex and as comprehensive as it is10:34
lkclthe hilarious bit about the story in Snowcrash is that, in the "far future", this "complexity" due to all telephone exchange software becoming Open Source was then "wrapped"10:35
lkclin APIs10:35
lkclwhich of course then became just as complex as the original10:35
lkclwhich then required further wrappers10:35
lkclin APIs10:35
lkclwhich then became just as complex as the original wrapper10:35
lkcli sympathise with the author, but ultimately he's clueless... and/or encountering a problem that *was* fixed decades ago, with CORBA, DCE/RPC, DCOM, and in Apple's case with Objective-C, Objective-J, and Objective-M (from when Steve Jobs worked on NextSTEP)10:37
lkclbut of course, that's "far too complex"10:38
markossuch posts are exactly the stuff that proves to me that AI taking over software development jobs is the biggest joke of all. I actually pity the AI that will take up the task of replacing a human coder10:38
lkclsurely we, the Open Source Community, in our ignorance and self-righteous arrogance, don't need all that proprietary shit?10:38
lkclsuuurely we can do better, right? we're better than them10:38
programmerjakeimho it's more like gankra (she btw) is observing the broken mess that is C ABIs of today, and hoping something will replace C as the de-facto-standard for interop between languages10:38
lkclnot a snowball in hell's chance :)10:39
markoslkcl, well I don't know about "fixed", none of those systems actually stayed around long enough10:39
lkclmarkos, Objective-C/M/J is still the core basis of MacOSX10:39
lkcland DCOM and DCE/RPC are still the core fundamental basis of Windows NT10:39
lkclwhich hilariously microsoft's marketing team tried to rename to "windows NT Technology" and then just "Windows"10:40
lkclcompletely forgetting that NT *stands* for "New Technology"10:40
markosI know no single MacOS X developer that programs in ObjC, even those that do UI, they all use Qt or Swift now10:40
markos^right now10:40
programmerjakeuuh...libsdl uses objective c for macos still10:41
programmerjakewhen i wrote half of the PR for adding vulkan to liksdl, the other person wrote all the macos bits using objective c10:42
markosoh I'm sure there are people that still code in objc, but I wouldn't call it a prevalent platform of choice for MacOS10:42
lkclthat will turn out to be a costly mistake.10:42
lkclit will result in exactly the kinds of API fragmentation and community fragmentation that DCE/RPC, CORBA, Objective-* and DCOM were specifically designed to cater for10:43
lkclyou can't have it both ways10:43
lkcl"i wanna program everfink easy, waaa waaa"10:43
lkcl"all my APIs suck and are incompatible now, waa, waa, i want my mummyyyy"10:43
lkclmmm :)10:44
markosI do agree that eventually, some kind of simplification and cleaning house for C will happen, probably throwing away support for platforms/ABIs that make it difficult, but this won't happen soon10:44
lkclthere's Active-X components that are 25 years old, the company long gone, source code obliterated, that can be dropped onto a Windows desktop and still used10:44
lkclmarkos, basically yes.10:45
lkclit's not about "c the language", it's about ABIs10:45
markosyes exactly10:45
lkcllanguages *have* to conform to the ABIs, as defined by the hardware-software architects - we're literally going through this right now10:46
markosand I hope that by that time, they will finally agree on the standard int types, for good this time10:46
markosthe current situation is ridiculous10:46
programmerjakeimho the better-than-C common ABI will be needed since C has no higher-level features, such as string types, vectors (resizable array), hashtables, etc...10:46
markosthe one proposed by D devs?10:46
markosI really liked D10:47
programmerjakelibsdl commit I wrote part of that added vulkan support:
markospity it didn't pick up pace10:47
lkclno and it's never going to, because those still all have to thunk down onto actual hardware10:47
programmerjakei never heard of the D ABI proposal...10:47
markosbetterC was a D subproject10:47
lkclwhich in most cases will be int and FP registers of varying sizes10:48
markosmaybe there was/is another one?10:48
programmerjakewell...the latest i'm aware of is WebAssembly-specific...10:48
markosI remember betterC in D since 2015? 2016?10:49
markosI used to be the ldc maintainer in Debian for a few years10:49
markosD had the opportunity to replace C, but they messed up with the licensing and the garbage-collector by default10:51
markosand then Rust came10:51
markosD is easier than Rust, and more obvious for C devs, but the closed license, along with garbage collection -by default, they changed it afterwards, but it was too late10:52
programmerjakehmm...I tried to use D (after trying C++ then Java then C++ again) for writing my 3d block game (Voxels), but ended up switching to Rust...GC was the reason.10:52
markosby that time, people whjo were looking for a C replacement already moved to Rust10:52
markosI tried to learn Rust, I liked the ideas behind it but the syntax proved too alien/different for me, I've been writing C/C++ for >20y10:53
lkclhooraay.  took far longer than it should have10:53
markosand without an actual project to actually force me to learn it, I never had the reason to learn it properly10:54
programmerjakealso D doesn't have the same nice memory safety features of Rust, or traits (like, but waay more powerful than Java interfaces)10:54
programmerjakethx lkcl!10:54
markosno, D has other interesting concepts, like mixin10:54
markosstill, for the foreseeable future, it's going to be C and C++ for me10:55
lkclprogrammerjake, i had to set a different top-level directory, similar to the openpower-isa has a top-level /openpower which is the underlay10:56
programmerjakewell...if you liked D's inline assembly, you'll probably like Rust's inline assembly, except it works everywhere, rather than just x86/x86_64 iirc10:57
lkclikiwiki underlays can't cope with anything else and i'm not sure that git sparse-checkout can do half-way-down-a-tree10:57
markosprogrammerjake, that's also one of the things that put me off D, too x86-centric10:57
lkclor if it can i don't want to be spending the time reading manpages10:57
markosstd.simd was basically all the x86 intrinsics10:57
programmerjakek, lkcl10:58
markosprogrammerjake, one of my long term project ideas, following that simd knowledge base that I'm working on is to provide a high-level SIMD interface for all arches and then autogenerate headers/modules for most languages automatically10:59
markosthat's a really long term project though10:59
markosfirst I have to finish simd.info10:59
markosonly a few thousand instructions left :D10:59
programmerjakeooh...rust will probably have a built-in high-level simd interface before then though...11:00
markosyes, I probably won't be doing Rust though, C/C++ in the beginning11:01
markosmy Rust knowledge is too limited11:01
programmerjakerust inline asm:... (full message at
programmerjakeadditional asm stuff:11:04
lkcl<programmerjake> rust inline asm:... (full message at
markosprogrammerjake, I hope is that Rust's simd interface is also not x86 centric11:04
lkcldo keep messages to under the limit so as not to trigger matrix truncating them11:05
markosso far most "high level" SIMD intefaces are just one architecture's intrinsics/instructions and wrappers for those for other architectures11:05
lkcli do wish matrix would switch that "feature" off11:05
lkclha :)
programmerjakeit's not...i'm specifically trying to get them to add libre-soc features too...they're aiming for the common stuff between x86, arm, riscv, powerpc, gpus, and all the other arches, except that all ops are available on all other arches with the compiler filling in the gaps.11:08
lkclthey _do_ know that SVP64 will be one of the most brain-dead-simple ports they'll ever do, right? :)11:10
programmerjakerust is specifically trying to avoid x86-isms, if you want x86-isms, use std::arch::x86_64 instead (x86 intrinsics)11:10
markosthank you!11:10
markosthis is also something that -at least when I was looking at it- std::simd for C++ also failed11:10
markoswell, std::experimental::simd11:10
programmerjakethe way they're doing it, they generate llvm's arch-independent IR, llvm is responsible for generating asm11:11
markosdunno if it's been merged11:11
markosyes, that's the right way11:11
markosideally, I would like to have C/C++ do that as well11:11
markosbut the case is lost there11:11
markosit would essentially be a new language11:12
programmerjakealso, cuz rustc targets all of llvm, cranelift, and gccjit, everyone benefits11:12
markosI'm already convinced about Rust, it's just that I have to unlearn too much and currently it's C/C++ that pays the bills, I have little time to learn Rust11:13
markosand noone is going to pay me just to learn Rust :D11:13
programmerjakewell...if you want to work on Kazan, we might...11:14
markoswhat's that?11:15
markosI am already juggling 3 projects I would lie if I said I can take another one11:15
programmerjakeKazan is the original Vulkan for Libre-SOC, it's written in Rust11:15
programmerjakeVulkan driver*11:15
markosright, that would mean I would have to learn Vulkan as well11:16
markoslet me finish the 2 projects first and then I'll tell you if I can :)11:16
programmerjakemaybe? you could work on the compiler part11:16
markosone is adding further Arm NEON optimizations to Google's VP9 codec11:16
markosalready got 2 patches acceted11:17
markosaccepted even11:17
tplatenI had a look at gtkwave, the core is reading from memory, but always zero11:17
markosthe other is vectorscan, and the 3rd is ofc media codecs for SVP6411:17
markosthankfully I don't do any coding for the simd kb stuff, only coordinating11:18
lkcltplaten, that means you likely actually have zeros11:21
tplatenI know, zeros at the reset vector11:21
programmerjakeKazan has mostly stalled for now, I'm in the middle of creating the IR and the SPIR-V to IR translator, basically everything else has to wait on that since, without an IR, compiling is not really possible. I've been busy with HDL and SVP64 and stuff.11:22
lkcllook in the bram.dump file generated by microwatt-verilator.cpp and if it's showing LDs at 0x00000 with contents 000000 then you've likely forgotten to specify a boot filename on the command-line11:22
lkcl./microwatt-verilator {insert_name_of_standalone_boot_binary}11:23
tplatenI'll try that, in the meanwhile I found out that the first three reads seem to be ok.11:25
lkclahh ok11:25
programmerjakewell, good luck with your projects markos!11:25
lkclthen you've likely not completed the port from microwatt-verilator, because that actually shouldn't happen11:25
lkcla full port of microwatt_verilator you *have* to provide a command-line argument for the boot binary11:26
programmerjakegn all, it's nearly 3:30am here11:26
markosprogrammerjake, have a good night :)11:30
tplatenI'm providing a boot binary sdram_init.bin.11:32
lkcltplaten, that's... ah you want to boot linux, don't you11:32
lkclthen you need a 2nd binary which *cough* gets loaded at a hard-coded addres 0x600000011:32
lkclit was a quick-and-easy hack, that11:32
tplatenYes I want, so the second binary may have the wrong adress.11:33
lkclbut for startup you don't want to try executing millions or hundreds of millions of cycles when the first few fail11:33
tplatenBut I had a look at sdram_init source code, it should print a message before booting linux. Or am I wrong here?11:33
lkclhave you added SYSCON support for SRAM_BOOT_ADDR like i did in the microwatt-verilator branch?11:34
lkclthere is a hell of a lot that went into the microwatt_verilator branch and you'll need absolutely all of it11:34
tplatenI agree, im just trying out to find out the things that I have not yet done.11:35
lkclgit diff against the branch-point will tell you that11:35
lkclthen sdram_init.c also needs to understand that (new) parameter11:36
markoslkcl, trying to get sv.fadds/mrr to produce the results I want but I'm definitely missing something12:55
markosthe loop I'm trying to replace is this:12:57
markosfor (i = 17; i >= 1; i--) { in[i] += in[i-1]; }12:58
markosthis is the asm I'm using:12:59
markossetvl 0,0,17,0,1,112:59
markos        # sv.lwz 8.v, 0(5)12:59
markos        # sv.fadds/mrr 9.v, 8.v, 8.v12:59
markos        # sv.stw 8.v, 0(3)12:59
markosI'm getting different results, I'm printing the 18 32-bit elements in each case and compare, I know this works if I leave out the sv.fadds13:01
markosdamn, I'm doing it on paper and it checks out right, sv.fadds/mrr *should* work but the numbers I'm getting are wrong13:26
markosI need to learn how to read the output of pypowersim13:36
markoshm, it's different even if I comment out the fadds13:55
markosthis should be essentially a memcpy:13:57
markossetvl 0,0,17,0,1,113:57
markos# sv.lwz 8.v, 0(5)13:57
markos# sv.stw 8.v, 0(3)13:57
markosbut I'm still getting different results13:57
tplatenI'm running the hello_world program on the verilator_trace branch, where I get START_BIT/BITS error from the uart. I've already verified the baud-rate it is 11520015:15
markoscorrection, the data is the same, "memcpy" works fine, the buffer was different because of different length of bytes stored in the output files, so that's done and the buffers are identical15:37
markosstill working on the fadds though, data is still not identical in this case15:37
markosplease ignore that15:40
markosI can't believe I'm so dumb15:40
markosusing lwz/stw to load/store floats...15:40
markosof course, it works fine with lfs/stfs15:40
markosso, one single instruction to replace an entire for loop15:43
* markos is very impressed15:43
markoslkcl, curious, if you need to set the vector length in a dynamic manner, at runtime, what should be the correct way to do it?15:45
markosif that's possible, then an "optimized" libc for SP64 would be *tiny*15:46
markosoh comeon15:46
markosok, I will start committing stuff now15:47
lkclyes one instruction to replace an entire for-loop! :)16:40
lkclthis is the beauty of Cray-style Vector ISAs16:40
lkclmarkos, sigh, dynamic setting of VL, well, it's complex (as far as ABIs are concerned)16:42
lkclwe'll need to make up some conventions at some point (caller-save, callee-save)16:45
lkclbut if you need to change it then set it back later, give a register which saves the old value16:46
lkcl"setvl r0,..." is simply used to say "yeah i can't be bothered with that" :)16:47
lkclwhich you would normally do when writing an immediate value because, duh, you already know the immediate value to be stored in VL16:47
lkcltplaten, that's good news.  it means you haven't set the SYS CLK frequency to 50 mhz16:49
lkclifeq ($(FPGA_TARGET), verilator)16:50
lkclhello_world does not check SYSCON (i don't think) in console_init()16:52
lkclah, correction, it *does* read it16:53
lkcleverything has to match16:55
markosyes, that's fine, I would use the number of iterations in a register, and if setvl can use a register that would be also fine, but I guess there would have to be some restrictions on that17:05
markosie it should be smaller than the max registers17:06
lkclok so this is one of the weirdities of Cray-style Vectors, there is a hard-coded MAXVL as well as a VL17:09
lkclin Cray YMP-1 (or whatever it was) and in RVV, MAXVL is the "Number of hardware Lanes"17:10
lkclalthough, in theory, you could actually make that a virtual MAXVL, such as how Broadcom VideoCore IV has a "pretend" SIMD length of 16 but actually it does 4x loops on a 4-wide FP32 SIMD back-end ALU17:10
lkclno matter, the point is, you *have* to have a hard limit against which VL "hits", and in SVP64 that hard limit is 6417:11
lkcl(for a 32-bit Power ISA core that hard limit would be 32 but that's another story)17:11
lkclso, in Cray-style Vectors (in general) you do:17:13
lkcllet us assume MAXVL=6417:13
lkclthen you call "setvl r3, r5"17:13
lkclVL will be set to MIN(r5, 64)17:13
lkclr3 will be set equal to r317:13
lkclso VL=64 and17:14
lkclobviously if r5 is any value less-or-equal to 64, then r3=VL=r517:14
lkclBUT.... butbutbut... SVP64 is not a traditional Cray-style ISA :)17:14
lkclspecifically: there are no actual Vector Registers, the "vectors" sit on top of the *scalar* regfile17:15
lkcltherefore, what the heck is the definition of a MAXVL?17:15
lkcland that's why you *also* have to set MAXVL.17:15
lkclso MAXVL becomes the "maximum allocation of scalar registers that can be used for subsequent operations"17:16
lkclor more accurately17:16
markosyes, what I mean is that the limit is the number of scalar registers, I guess we would have to add some preample code to manage the loops in multiples of eg. 32 registers17:16
lkcl"maximum allocation of scalar registers divided by elwidth"17:16
lkclahhh yes.17:16
markoswould be fun implementing a memcpy implementation where it would use 32 registers to copy data, I wonder how that would perform17:16
lkclthat's entirely down to the hardware17:17
lkclif the microarchitecture has a 32-wide ALU then one clock cycle per 32-registers copying17:17
lkclwhich would also require 32-wide LD and ST which gets real hairy17:17
lkclbut not outside the realm of possibility17:17
lkclif the microarchitecture had an *8-way* 32-wide ALU (and associated memory paths) then the possibilities are completely insane17:18
lkcland quite impractical in the year 2022 :)17:18
lkclwhat that in turn means is that the main CPU - instruction fetch and decode - will be sitting idle. including L1 cache17:19
lkclL1 I-Cache17:19
lkclwhereas the back-end ALUs, the L1 D-Cache, and Memory, will be screaming flat-out17:19
lkclbut even the fact that fetch, decode, and I-Cache have basically spammed the back-end execution to their absolute max means that fetch, decode and I-Cache are *not using any power*17:20
lkclmore than that, the reduction in program size means that a smaller L1 I-Cache could be used, which has O(N^2) power-savings when the load on L2 cache is also taken into account17:21
lkclok, so the "pre-amble" is laughably small.17:22
lkclan implementation of daxpy (saxpy) shows how17:22
lkclthe RVV example there of daxpy is really important to study and grasp17:28
markosit's not just the speed17:28
lkclfor-loop is 0 to 100,000,000,00017:28
markosit's the fact that the same code can be implemented in an order of magnitude -possibly more- smaller codesize17:28
markoseg. glibc right now is a beast with all those unrolled optimized functions17:29
lkcland on entry to the for-loop, 100,000,000,000 values are requested but because MAXVL=64, VL is set to only 6417:29
markosin SVP64 a fully optimized implementation could just be a few MB tops, just like old Linux libcs of the early 90s17:29
lkclmillions of loops later, the "remaining count" is finally at or below 64.17:29
lkclyes basically17:30
markosthis is a huge paradigm shift17:30
lkclit's going to be a pain in the ass :)17:30
markosnot for us :D17:30
lkcleven jacob was hunting for "optimised SIMD code" for demo / reference implementations17:31
lkcland i had to explain, "sorry, that's really not helpful precisely because of the optimisations"17:32
lkclwith the headlong rush to optimise-into-SIMD, the history of the *scalar* implementations are being lost!17:32
lkclwhy would you ever keep those around, right?17:32
lkclbecause performance will automatically equal s***, right?17:33
openpowerbot[mattermost] <lkcl> <lkcl>
openpowerbot[mattermost] <lkcl> <lkcl> but we *need* those scalar implementations as reference because those are the closest to what can be turned into SVP6417:42
openpowerbot[mattermost] <lkcl> <lkcl> *not* the insanely-optimised-SIMD-variants17:42
openpowerbot[mattermost] <lkcl> <lkcl> but here's the really fascinating bit: the different direction that REMAP takes, it separates out the looping as an "abstraction" from the execution17:42
openpowerbot[mattermost] <lkcl> <lkcl> the last major design which did that was Zero-Overhead-Loop-Control17:42
openpowerbot[mattermost] <lkcl> <lkcl> and REMAP is remarkably close in concept to ZOLC.  the Matrix and DCT/FFT REMAP requires near-identical "stacking" and Priority Pickers in the back-end hardware17:42
tplatenI now have a working hello world program, it says libre-soc, it works. I use that to compare the outputs of the two verilator branches.17:46
lkcltplaten, fantastic!18:18
tplatenI now found out whats going wrong18:25
tplatenThe first instruction is fetched correctly from rd @ 00000000 di         4800012c sel ff ...H....18:25
tplatenThe second one should be rd @ 00000001 di                0 sel ff ........18:26
tplatenbut in the failing example it is rd @ 00000008 di                0 sel ff ........18:27
tplatenSo likely bram_addr is wrong, with a const factor of 818:38
tplatenso when bram_addr is zero, the correct data will be fetched in this case18:39
tplatenSo I will have a look at wishbone_bram_wrapper18:45
lkclno that's down to the inclusion of the 3 zeros due to the non-compliance of microwatt with wishbone18:51
lkcl2<<3 == 818:52
lkclyou can "sort" that by stripping off the first 3 LSBs18:53
tplatenI'll have a look18:54
tplatenFixed one of two bugs, I had found comparing verilator outputs18:58
openpowerbot[mattermost] <lkcl> <lkcl> which makes those 3 zeros not just redundant but "a problem".19:00
openpowerbot[mattermost] <lkcl> <lkcl> basically cut those three zeros and the problem "goes away"19:00
openpowerbot[mattermost] <lkcl> <lkcl> paul fixed the entirety of the microwatt master branch wishbone problems a few months back19:00
tplatenMaybe I accidently reverted a change, that fixed that bug.19:01
tplatenThe second one is pc              700 insn        0 msr 8000000000000001, this looks like an exception, as 700 is an exception vector which acts as an infinite loop19:07
openpowerbot[mattermost] <lkcl> no you didn't19:07
lkclno you didn't19:08
lkclthe problem *had* to be "fixed" by being *exactly* compatible with the broken-ness of microwatt's older HDL19:08
lkclbut you are now forward-porting to a WB-*compliant* version of microwatt19:09
lkclbut still using a *NON*-compliant WB external_core_top.v19:09
lkclonly *compliant* WB external_core_top.v can talk to *compliant* WB microwatt19:09
lkclonly *NON*-compliant WB external_core_top.v can talk to *NON*-compliant WB microwatt19:09
lkclthe exception occurs because an illegal instruction was attempted to be executed19:10
lkclthat illegal instruction execution is correct19:10
tplatenI agree, I just was not aware of recent changes, in both microwatt and libre-soc19:10
lkcl*because* the wrong instruction *was* in fact executed19:10
lkcli have been mentioning this for months!!19:11
lkclrepeatedly! :)19:11
lkclit's not recent at all! :)19:11
lkcli think the first time i mentioned it was over 18 months ago when i first had to hack in the 3 zeros on the first simulations19:12
lkclit just took Paul over a year to get the time to fix microwatt to non-broken (WB-compliant) behaviour because it's  a massive change19:13
lkclevery single use, every single peripheral, every single memory access inside Microwatt was wrong19:13
lkclbut _consistently_ wrong, hence why they never noticed :)19:13
tplaten18 month is a long time, I still remember some things, but other I have forgotten19:13
lkclit's like many things: you never really pay attention until _you_ actually have to deal with it :)19:14
lkclas a "bad hack" you can simply take out those 3 zeros19:15
lkclthat will "sort" it19:15
*** alMalsamo is now known as littlebobeep20:56
programmerjakelkcl: can you try and fix the underlay, it doesn't show up and when i push nmutil-gf it says:21:30
programmerjakeremote: error: cannot pull with rebase: You have unstaged changes.21:30
programmerjakeremote: error: please commit or stash them.21:30
programmerjakeiirc it worked until you added gf_reference/index.mdwn in libreriscv.git21:31
programmerjakelkcl fixed it, your local checkout of nmutil-gf was missing COPYING.LGPLv3, if you don't want that in the checkout, remove it from .git/info/sparse-checkout, don't just delete it.21:59
programmerjakei did `git restore COPYING.LGPLv3`22:01
programmerjakemay I suggest changing sparse-checkout to:22:01
programmerjake(didn't check if it works)22:02
programmerjakemoved all the .../bitmanip/ files to nmigen-gf and updated bitmanip.mdwn22:30
lkclprogrammerjake, you removed gf_reference from the ikiwiki repo23:04
lkclif you had checked the commit messages you would have seen that i discovered that this destroys the underlay23:04
* lkcl checking23:05
lkclinteresting. apparently not.23:05
lkclsomething else at play.23:05
lkcl is still present23:05
programmerjakei'm guessing you forgot to update libreriscv and openpower-isa's git hooks to include nmigen-gf23:06
lkclno i did, there's a command being run, i simply added "git pull" on both repos to that23:07
lkclit's quite... complex, all told23:08
lkclgit push on one repo triggers *two* git pulls on another23:08
lkclfollowed by an ikiwiki rebuild23:08
lkcllet's see how it goes23:12
lkclthere are options in btw which allow python code in weird places to be "dropped in" to a hierarchy of module imports23:12
lkclso the fact that the reference code is in gf_reference should not be a problem at all23:13
lkclit can - in theory - be brought back in despite being in a weird location23:13
lkclthe other option is a symlink but that's... ah... yeah23:13
programmerjakedon't worry about, i'll figure that out later...23:19
lkclat least you're off, and can drop the gf src back in23:21
lkclnote: the checkouts are sparse.23:21
lkcl*only* the gf_reference/ subdirectory is checked out23:21
lkclnot gf_reference.mdwn23:22
programmerjakeunless you changed it since i last checked23:22
lkcllikewise for openpower-isa, only /openpower is checked out. i couldn't even remember that i'd done that :)23:22
programmerjakethat's from nmigen-gf.git/gf_reference.mdwn23:23
lkclshouldn't be!!23:23
programmerjakeit is...23:24
programmerjakeiirc look in /var/www/nmigen-gf/gf_reference.mdwn23:26
programmerjakethe sparse-checkout you had only filtered out dirs, not files in nmigen-gf.git23:27
lkclsomething to do with sparse-checkout "cone" setting23:30
lkclngggh. not going to worry about it23:31
programmerjakeit will likely cause problems later, since we'll want to add a bunch of files to nmigen-gf's root: readme,, etc. they'll probably conflict with files already on the wiki23:34
programmerjaketo fix it, edit /var/www/nmigen-gf/.git/info/sparse-checkout, and then git checkout/clean23:48

Generated by 2.17.1 by Marius Gedminas - find it at!