| octavius | Did add some insulation inside the tin can? | 00:58 |
|---|---|---|
| octavius | *did you add | 00:58 |
| programmerjake | left the arty in it's box...that's good enough. i did dent in the side of the tin so the wire won't accidentally get cut. | 01:11 |
| * klys joins ##openfpga/libera | 01:40 | |
| lkcl | klys, _another_ fpga channel? :) | 09:44 |
| lkcl | ahh apparently it's "by invite only" | 09:45 |
| lkcl | "* You have been kicked from #openfpga by ChanServ (Invite only channel)" | 09:45 |
| lkcl | ok ##openfpga | 09:45 |
| lkcl | xmas tin fpga lol | 09:47 |
| programmerjake | :) | 09:51 |
| programmerjake | it's what i had available | 09:52 |
| lkcl | i'll suggest it to UOregon as a technique for keeping their Arty A7-100t's safe when the server's in the rack | 09:58 |
| programmerjake | i put the arty inside its original box inside the tin...otherwise you'd have to worry about shorting. too bad it has no mounting screw holes. | 10:00 |
| tplaten | I watched https://www.youtube.com/watch?v=8hrIG7-E77o | 18:03 |
| * lkcl forgot about that. it accompanies this page https://libre-soc.org/openpower/sv/biginteger/analysis/ | 18:17 | |
| lkcl | i don't think it includes the divide-analysis that jacob and i have been discussing for the past few days | 18:20 |
| lkcl | just add and multiply | 18:20 |
| lkcl | add is almost laughably simple: sv.adde *is* a big-integer add. | 18:20 |
| Chaul-Jhin-Kim | Dear GOD/GODS and/or anyone else who can HELP ME (e.g. TIME TRAVELERS or MEMBERS OF SUPER-INTELLIGENT ALIEN CIVILIZATIONS): | 20:43 |
| Chaul-Jhin-Kim | The next time I wake up, please change my physical form to that of FINN MCMILLAN formerly of SOUTH NEW BRIGHTON at 8 YEARS OLD and keep it that way FOREVER. | 20:43 |
| Chaul-Jhin-Kim | I am so sick of this chubby Asian man body! | 20:43 |
| Chaul-Jhin-Kim | Thank you! | 20:43 |
| Chaul-Jhin-Kim | - CHAUL JHIN KIM (a.k.a. A DESPERATE SOUL) | 20:43 |
| *** Chaul-Jhin-Kim <Chaul-Jhin-Kim!~Chaul-Jhi@115-189-130-170.mobile.spark.co.nz> has left #libre-soc | 20:43 | |
| lkcl | programmerjake, when you add new dependencies it has such major implications can you *please* ensure it's done as its own single-purpose commit | 21:41 |
| lkcl | diff --git a/setup.py b/setup.py | 21:41 |
| lkcl | + "cached-property", | 21:41 |
| lkcl | ] | 21:41 |
| programmerjake | iirc it was its own commit, if not, sorry | 21:41 |
| lkcl | i'd really very much prefer that wasn't added | 21:41 |
| programmerjake | why not? you were fine with it for utils.git and it was later added to the python stdlib< so imho it should be fine | 21:42 |
| programmerjake | https://docs.python.org/3/library/functools.html?highlight=cached_property#functools.cached_property | 21:44 |
| lkcl | mrhrmrm, i wasn't... these "retrospective" changes to python make me jittery | 21:45 |
| lkcl | the pace of change is getting out of hand, it'll have consequences (already has) | 21:45 |
| programmerjake | retrospective? it's a commonly used simple utility...imho it's good they added that to python | 21:46 |
| lkcl | is it necessary to have? | 21:48 |
| lkcl | if removed, would anything break? | 21:48 |
| lkcl | bear in mind we use python 3.7 (not latest-and-greatest-that-has-not-been-battle-tested) | 21:49 |
| programmerjake | yes...it would break goldschmit division...i use it to cache expensive-to-compute properties | 21:49 |
| lkcl | would the unit tests fail if it was removed? | 21:49 |
| programmerjake | yup, the pip package is fallback for old python versions that don't have it in stdlib | 21:50 |
| programmerjake | yes, it would fail | 21:50 |
| lkcl | why? it's simply cacheing properties | 21:50 |
| lkcl | why would the *cacheing* of properties cause the unit tests to produce the wrong results? that doesn't make sense | 21:50 |
| programmerjake | ok...technically it wouldn't fail but would increase the runtime from a few min to muuuch longer | 21:51 |
| lkcl | ok, then it's not necessary, it's an optimisation. | 21:51 |
| programmerjake | only if all mentions of cached_property were replaced with property | 21:51 |
| lkcl | so then, what would make me much happier is this: | 21:52 |
| lkcl | * remove cached_property from setup.py | 21:52 |
| programmerjake | yes, but an important optimization...iirc it would change the algorithm to O(n^2) rather than O(n) | 21:52 |
| programmerjake | or similar | 21:52 |
| lkcl | try: | 21:52 |
| lkcl | import cached_property | 21:52 |
| lkcl | except ImportError: | 21:52 |
| lkcl | cached_property = property | 21:53 |
| lkcl | and then have, in the README, a note that if people want to speed up that unit test they should do "pip3 install cached_property" | 21:53 |
| lkcl | or - i know. | 21:54 |
| programmerjake | https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/div/experiment/goldschmidt_div_sqrt.py;h=3af5320d83373e106db74bb7c5394e356036b10d;hb=HEAD#l15 | 21:54 |
| lkcl | add cached_property to the test requirements [or extras] in setup.py | 21:54 |
| programmerjake | it's required by goldschmidt division, not just tests | 21:55 |
| lkcl | i'd prefer a 2nd nested ImportError around that | 21:55 |
| lkcl | try: | 21:55 |
| lkcl | from functools import cached_property | 21:55 |
| lkcl | and full comments explaining what's going on | 21:55 |
| lkcl | try | 21:56 |
| lkcl | from cached_property import cached_property | 21:56 |
| lkcl | except ImportError | 21:56 |
| lkcl | except ImportError | 21:56 |
| lkcl | any dependencies like this make me really jittery. | 21:57 |
| lkcl | utils, not so much. | 21:57 |
| programmerjake | imho if you don't like having the cached_property import, i'd rather implement it myself again rather than replace with property...it's that important | 21:57 |
| lkcl | yeah that'd work | 21:57 |
| lkcl | i know it sounds bizarre to say that, but due to pip3 being all over the place, the less dependencies the better | 21:57 |
| lkcl | utils i couldn't care less, it's not part of the HDL | 21:58 |
| programmerjake | imho implementing it myself rather than using the pip package is totally terrible...why can't you just be ok with that simple dependency? | 21:58 |
| lkcl | because when it comes to other developers installing this, and that "simple" dependency turns out to have changed | 21:59 |
| lkcl | and that change - by being external - totally f***s things up for us | 21:59 |
| programmerjake | well..,then we pin the version, not remove it | 21:59 |
| lkcl | and a post-mortem after we've missed a USD 16 million mask charge window with the Foundry shows it was a "simple" dependency | 22:00 |
| lkcl | we've already had one screw-up from i think.. what was it... pygdbmi | 22:00 |
| programmerjake | pygdbmi is waay more complex...cached_property is <1kloc | 22:01 |
| lkcl | yes i pinned pygdbmi to a specific release, for that, and didn't worry about it, because it's not part of the HDL | 22:01 |
| lkcl | ah then pffh, include it | 22:01 |
| lkcl | just grab a copy and drop it in. | 22:02 |
| programmerjake | as i said before...terrible... | 22:02 |
| lkcl | solves that one and leaves you free to do more important things | 22:02 |
| lkcl | i would be _delighted_ and actively encourage you to put in code-comments that say "this is truly dreadful" :) | 22:03 |
| lkcl | if this wasn't HDL i would be going "absolutely no problem at all, go for it" | 22:04 |
| programmerjake | k | 22:04 |
| lkcl | it's the fact that we're doing high-level programming, generating verilog, where for paranoia reasons we have to have full reproducibility, that makes me really jittery | 22:05 |
| lkcl | Jean-Paul really impressed it on me that the procedures he recommends, you should have reproducible build scripts that literally, at the end of more than one run on separate hardware, the actual hard drives should be bit-level identical | 22:05 |
| lkcl | i knew someone on the arm-netbooks mailing list that provided 20-year customer support | 22:06 |
| lkcl | he only used KiCAD because of it | 22:06 |
| lkcl | but | 22:06 |
| lkcl | he didn't just take a snapshot of the KiCAD source code | 22:07 |
| programmerjake | well...unless you're doing clock and crypto random shenanigans, that's impossible | 22:07 |
| lkcl | he took a snapshot of the *entire* source code of the *entire* operating system | 22:07 |
| programmerjake | every fs i know of stores the time on it | 22:07 |
| lkcl | because there is no guarantee in 20 years time that the versions of libraries or the linux distros at the time would be capable of even compilng 20-year-old KiCAD source code | 22:08 |
| lkcl | yehyeh. it's an "ideal" scenario. | 22:08 |
| programmerjake | well...i'm planning on doing something similar to that at some point for my Voxels game: running the code in a Wasm sandbox with access to the clock and secure rng and internet removed...ultimate reproducible compilation. | 22:15 |
| programmerjake | lkcl: now that i think about it, i'd prefer if, instead of embedding cached_property in soc.git, we have our own cached_property.git and the pip dependency can just be changed to point at our git repo...can you create a cached_property.git repo? | 22:19 |
| programmerjake | see https://stackoverflow.com/a/54794506/2597900 | 22:21 |
| lkcl | yes i was just thinking that. | 23:35 |
| lkcl | that's a much better idea | 23:35 |
| lkcl | programmerjake, done | 23:36 |
| programmerjake | pushed everything from upstream, lkcl: please set the repo to be publicly visible | 23:51 |
| lkcl | ack 1 sec | 23:58 |
| lkcl | programmerjake, done | 23:59 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!