| programmerjake | lkcl: you assigned payments of 750+250 but a total budget of 800 for https://bugs.libre-soc.org/show_bug.cgi?id=882 | 08:42 |
|---|---|---|
| programmerjake | please fix it....not sure which you intended | 08:43 |
| lkcl | programmerjake, working on it. i reopened it, just emailing you a pdf screenshot | 08:55 |
| lkcl | i'll do a review of the non-HTTP-submittable ones | 08:56 |
| lkcl | so you can put something in | 08:57 |
| programmerjake | ok...was i not supposed to submit the cryptorouter one via email 2 weeks ago? | 08:59 |
| lkcl | that's one that has a secret URL, now | 09:00 |
| programmerjake | did it have a secret url 2 weeks ago? | 09:02 |
| lkcl | yyyyes, something like that | 09:02 |
| programmerjake | hmm, maybe we should email someone at nlnet so they can make sure it doesn't get lost | 09:03 |
| lkcl | errr which seems to now be broken. er | 09:03 |
| lkcl | i reviewed 3, all good | 09:04 |
| programmerjake | thx! | 09:06 |
| programmerjake | lkcl, do you think i should send an email to prevent that rfp i sent 2 weeks ago from getting lost? | 09:38 |
| programmerjake | i'll work on the new stuff in #882 tomorrow | 09:39 |
| lkcl | programmerjake, no, they'll be dealing with it | 09:39 |
| programmerjake | ok | 09:40 |
| lkcl | sensible. bit late tonight | 09:40 |
| programmerjake | lkcl, one more rfp for you to check -- 2019-10-032-MoU-Jacob Lifshay-The Libre RISC-V SoC, Formal Correctness Proofs | 09:47 |
| lkcl | that one's quite big, so would best have the totals | 09:47 |
| lkcl | nuts. 2019-10-046 is the one that i've got the secret URL for | 09:48 |
| lkcl | email already sent so don't worry about it | 09:48 |
| programmerjake | i'll manually calculate totals for it then...don't want to wait for writing a bunch of code | 09:49 |
| programmerjake | actually, they're all part of #196, so i don't think a separate total is necessary | 09:51 |
| programmerjake | lkcl, sound good? | 09:51 |
| lkcl | ah! well spotted | 09:59 |
| lkcl | then yes, put that at the end of the notes. | 09:59 |
| lkcl | let me review it | 10:00 |
| lkcl | programmerjake, yep all good. | 10:03 |
| programmerjake | sent for review | 10:04 |
| lkcl | explicitly put | 10:06 |
| lkcl | "total EUR 7450 is part of Milestone 196" | 10:06 |
| lkcl | otherwise they have to hunt in a separate place for the amount | 10:06 |
| lkcl | look at the PDF screenshot i sent you | 10:06 |
| programmerjake | ok, though they can just read the total further up... | 10:07 |
| lkcl | that's what they have to manually fill in, and if the. | 10:07 |
| lkcl | nooo, that's precisely and exactly what is inconvenient | 10:07 |
| lkcl | "they can just" | 10:07 |
| programmerjake | k | 10:07 |
| lkcl | means they have to exert energy and spend time doing so | 10:07 |
| programmerjake | is this fine: | 10:10 |
| programmerjake | everything (eur 7450) is part of MoU Milestone | 10:10 |
| programmerjake | [Bug #196](https://bugs.libre-soc.org/show_bug.cgi?id=196) | 10:10 |
| programmerjake | lkcl ^ | 10:11 |
| lkcl | perfec | 10:20 |
| lkcl | t | 10:20 |
| lkcl | maarnin octavius | 13:49 |
| lkcl | oh wait, it's 2pm :) | 13:49 |
| octavius | morning lkcl | 13:49 |
| octavius | Ah, good afternoon | 13:49 |
| lkcl | octavius, i'm updating the pinmux submodule after that gpio error is fixed | 14:23 |
| octavius | lkcl, added a few more links to the spec, however "svfparith" and "svfixedarith" are pointing to page 1 (I've seen this issue with other links). Do you know how to fix this? | 16:03 |
| octavius | Also, what do you want to do with links for pages that aren't in the spec (sv/implementation, sv/fcvt, etc.)? | 16:04 |
| octavius | Ah, I think I'm figuring out why the links are going to page 1, will fix now | 16:13 |
| octavius | An interesting issue in the hyperlink naming I noticed, is that the expected name is different if there's a reference to it from another directory | 16:32 |
| octavius | for example, svp64/appendix turns into "svp64ux2fappendix" and sv/svp64/appendix turns into "svux2fsvp64ux2fappendix" | 16:35 |
| octavius | But it looks like the issue might be with the branches.mdwn file (it uses both links) | 16:36 |
| octavius | So for every dir level, the auto-gen link adds the [dir]ux2f prefix | 16:37 |
| lkcl | so add the extra hyperlinks to the top-level .tex | 16:41 |
| lkcl | some of these double-names i am removing | 16:42 |
| octavius | sure | 16:57 |
| lkcl | yes, you can't control what hyperlinks pandoc creates, but you can add extra hyperlink targets (multiple if necessary) | 17:04 |
| lkcl | "/" in any markdown pagelink is substituted "ux2f" | 17:05 |
| lkcl | therefore you can work out precisely and exactly what hyperlink to put into the top-level .tex | 17:05 |
| octavius | Yep, thanks | 17:06 |
| octavius | As for links to pages we haven't added, what to do with those? | 17:06 |
| octavius | For example: sv/example_dep_matrices | 17:07 |
| octavius | sv.tex, Other section has a bunch of links | 17:08 |
| lkcl | ignore them | 17:14 |
| lkcl | if you look at the contents you'll find they're not useful | 17:14 |
| lkcl | i.e. "are not a specification" | 17:14 |
| octavius | Ah ok | 17:14 |
| lkcl | i.e. "in no way would you ever submit them to the OPF ISA WG for inclusion in the Power ISA Specification" | 17:14 |
| ghostmansd | Hi folks. What's the official way to update our sources? | 17:59 |
| octavius | What sources? | 18:00 |
| ghostmansd | openpower-isa in particular, plus anything related. | 18:00 |
| ghostmansd | Any fucking time I try to run tests I meet erros like `ModuleNotFoundError: No module named 'nmigen.sim'`, or `ImportError: cannot import name 'GTKWColor' from 'vcd.gtkw' (/usr/local/lib/python3.7/dist-packages/pyvcd-0.1.7-py3.7.egg/vcd/gtkw.py)`. | 18:00 |
| lkcl | ahh ok. | 18:00 |
| ghostmansd | I mean, it's been a while, and since then I only did git pull origin master --rebase. | 18:00 |
| lkcl | "officially", use the dev-env-setup scripts | 18:00 |
| ghostmansd | But won't it mean that I have to reinstall all from the scratch? | 18:01 |
| octavius | Once it's installed you usually just "git pull" | 18:01 |
| ghostmansd | I mean, I'm aware of dev-env-setup, but it starts the whole process. | 18:01 |
| ghostmansd | > just git pull | 18:01 |
| ghostmansd | apparently not | 18:01 |
| lkcl | that will almost certainly be because of the fucking irritating fact that the Trademarked github nmigen repository is being cyber-squatted | 18:01 |
| ghostmansd | FWIW, I'm on Talos | 18:02 |
| ghostmansd | But this also is a problem on my usual box | 18:02 |
| lkcl | you'll almost certainly have been hit by pip3 fucking well pulling in shit that you didn't ask for | 18:02 |
| lkcl | yes it's very irritating, but you just have to be very patient, there's not a lot we can do about it | 18:02 |
| ghostmansd | anyway, I checked the only test which launched successfully: test_caller_svstate.py | 18:02 |
| ghostmansd | And I did a change which allows crap like *fv0 | 18:03 |
| ghostmansd | That is, any macro can be used as register name | 18:03 |
| lkcl | you *must not* let pip3 go and do arbitrary random downloads off the internet | 18:03 |
| ghostmansd | As long as it can be expanded to integer. | 18:03 |
| ghostmansd | (I mean 884) | 18:03 |
| ghostmansd | I needed this, because I need the svp64.py to be on par with binutils | 18:04 |
| lkcl | ghostmansd, run this command: | 18:04 |
| lkcl | $ pip3 list | grep nmigen | 18:04 |
| ghostmansd | ...and guess what? binutils can already handle it! | 18:04 |
| lkcl | it should be something like: | 18:04 |
| lkcl | nmigen 0.3.dev361+g9ce40c1.dirty | 18:04 |
| lkcl | nmigen-boards 0.1.dev203+gacb0280.dirty | 18:04 |
| lkcl | nmigen-soc 0.1.dev47+g5ba0d25 | 18:04 |
| lkcl | nmigen-stdio 0.1.dev6+gaf01aba | 18:04 |
| lkcl | it should **NOT** have "nmigen 0.2" | 18:04 |
| ghostmansd | here's the fucker: nmigen 0.2 /usr/local/lib/python3.7/dist-packages/nmigen-0.2-py3.7.egg | 18:04 |
| lkcl | yyep. | 18:04 |
| lkcl | trash it | 18:04 |
| ghostmansd | done `sudo pip3 uninstall nmigen` under chroot | 18:05 |
| ghostmansd | (BTW you dropped my admin powers, right?) | 18:05 |
| ghostmansd | so that I won't fuck stuff whilst not being under chroot | 18:06 |
| lkcl | then don't *whatever you do* use "python3 setup.py develop" *without* also adding "--no-deps" | 18:06 |
| lkcl | yyyeees i did | 18:06 |
| lkcl | so you should do "python3 setup.py develop --no-deps" | 18:06 |
| lkcl | you *can* still do "sudo bash"... *within* the chroot | 18:07 |
| lkcl | having had pip3 "damage" your environment, you may now need to check the dependencies listed in setup.py | 18:07 |
| lkcl | and explicitly restore the specific listed versions | 18:08 |
| lkcl | for that, you *can* use "python3 setup.py develop" in the nmigen directory | 18:08 |
| programmerjake | schroot generally copies /etc/passwd and stuff from outside the chroot, so if you lose sudo access there, you likely will lose it inside the chroot too | 18:08 |
| lkcl | and it should restore things like the correct version of pyvcd etc. | 18:08 |
| ghostmansd | perhaps it'd be simpler to install stuff from scratch, eh? | 18:09 |
| lkcl | ghostmansd, weeelll... it shouldn't be necessary. | 18:09 |
| ghostmansd | I pushed the commit for now, I checked it on a local mp3 assembly and est_caller_svstate.py | 18:10 |
| lkcl | oh nice. macro support in regs. | 18:11 |
| ghostmansd | also checking test_caller_svp64.py | 18:11 |
| ghostmansd | now | 18:11 |
| ghostmansd | lkcl, yeah I needed this | 18:11 |
| ghostmansd | I'm now checking how macros work in binutils | 18:11 |
| lkcl | it _shouuuld_ have just worked with the existing macro "support" in svp64.py | 18:11 |
| lkcl | confirmed, test_caller_svstate.py works | 18:12 |
| ghostmansd | and I converted this mp3_0_apply_window_float_basicsv.s into a "new" form | 18:12 |
| lkcl | cool! | 18:12 |
| lkcl | $ python3 decoder/isa/test_caller_svp64.py >& /tmp/f | 18:12 |
| ghostmansd | svp64.py is ok | 18:12 |
| ghostmansd | I guess I broke nothing | 18:12 |
| ghostmansd | (or should I say hope) | 18:12 |
| ghostmansd | OK let me know if this commit must go down the drain | 18:13 |
| ghostmansd | I'll continue with binutils for now | 18:13 |
| lkcl | works great | 18:13 |
| lkcl | i'll run a few more | 18:13 |
| ghostmansd | the approach is as idiotic and straightforward, but should work, yeah | 18:13 |
| lkcl | :) | 18:13 |
| ghostmansd | I mean, this was the most quick and dirty thing I managed to do to not waste time there :-) | 18:14 |
| lkcl | $ python3 decoder/isa/test_caller_svp64_fft.py >& /tmp/f | 18:14 |
| lkcl | yehyeh | 18:14 |
| lkcl | practical | 18:14 |
| ghostmansd | BTW we magically got ".machine libresoc" directive support :-) | 18:15 |
| lkcl | wha-hey! | 18:15 |
| ghostmansd | OK I found some discrepancy between binutils and pysvp64asm, I'll check this, but macros seem to work | 18:16 |
| lkcl | fft.py no errors | 18:16 |
| lkcl | no "damage" done, always a good thing | 18:16 |
| ghostmansd | I'll fix the discrepancy and make sure we're able to compile this mp3 assembly | 18:16 |
| lkcl | ack | 18:16 |
| lkcl | if that also compiles with binutils that's a big damn deal | 18:16 |
| ghostmansd | this already compiles :-) | 18:17 |
| lkcl | dang | 18:17 |
| lkcl | is the object file the same, though? | 18:17 |
| ghostmansd | that's the issue I meant | 18:17 |
| lkcl | ah :) | 18:17 |
| ghostmansd | this is the discrepancy, some bits differ | 18:17 |
| ghostmansd | I guess remap is doomed :-) | 18:17 |
| lkcl | dooomed, doomed i say | 18:18 |
| lkcl | https://www.youtube.com/watch?v=DoWtHqmITOM | 18:19 |
| ghostmansd | :-D | 18:29 |
| ghostmansd | updated media/audio/mp3/mp3_0_apply_window_float_basicsv.s to a new notation | 18:34 |
| lkcl | that looks alright | 18:35 |
| ghostmansd | verified this way: 1) run pysvp64asm on old version; 2) compile the output to a new object; 3) do the same for a new; 4) compare | 18:35 |
| ghostmansd | (compare objects obviously, either binaries or objdumps) | 18:35 |
| lkcl | nice | 18:35 |
| ghostmansd | I haven't switched to .machine libresoc yet, maybe later | 18:36 |
| lkcl | yyeah you'd need to get pysvp64asm to ignore that | 18:36 |
| lkcl | which is easy enough | 18:36 |
| ghostmansd[m] | I think pysvp64 is not an issue here. | 18:48 |
| ghostmansd[m] | It likely already ignores it. | 18:49 |
| ghostmansd[m] | The real issue is that we should compile this code with either binutils only... | 18:49 |
| lkcl | yyeah i'd prefer not to depend on it. | 18:49 |
| lkcl | but if it exists, and has -mlibresoc, carries out a binary comparison | 18:50 |
| lkcl | exactly as you just did, except automated | 18:50 |
| ghostmansd[m] | if we'd like to use either, we must be able to compile it with either libresoc or power9+pysvp64asm | 18:51 |
| ghostmansd[m] | I guess this should be done on build level: we must detect whether we have binutils | 18:51 |
| lkcl | markos is planning almost certainly to use binutils *not* pysvp64asm because of macro support | 18:52 |
| ghostmansd[m] | Well I'd use binutils everywhere as long as it can be ensured it has the same binary output as our etalon. | 19:04 |
| ghostmansd[m] | Because this is de facto standard. | 19:04 |
| lkcl | i'm just reticent to make it a hard dependency | 19:34 |
| lkcl | i'll likely get over it :) | 19:35 |
| lkcl | programmerjake, btw there's no build instructions anywhere for bitwuzla | 20:13 |
| lkcl | i got cvc5 installed manually a month ago | 20:13 |
| lkcl | ieee754fp proofs fail because bitwuzla isn't available | 20:14 |
| programmerjake | look in the .gitlab-ci.yml, those build instructions work just fine for me | 23:19 |
| lkcl | which .gitlab-ci.yml? | 23:20 |
| lkcl | which repository? | 23:20 |
| lkcl | nobody uses those to perform local machine installations | 23:20 |
| lkcl | we need *build* scripts | 23:20 |
| lkcl | not manual instructions | 23:21 |
| programmerjake | in ieee754fpu | 23:21 |
| programmerjake | also see: https://github.com/bitwuzla/bitwuzla#linux-and-unix-like-os | 23:21 |
| openpowerbot | [slack] <github> signin | 23:21 |
| programmerjake | well, those instructions work just fine for me, they can be added to dev-env-setup | 23:22 |
| programmerjake | as a build script | 23:23 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!