***wxie1 is now known as wxie
***jonsger1 is now known as jonsger
***wxie1 is now known as wxie
***jonsger1 is now known as jonsger
***sneek_ is now known as sneek
<roelj>I see there's a new ‘pipeline’ function :D. Is it equally fast/efficient as using pipes in bash? <roelj>(I want to pass 100+ GB through a pipe..) <wingo>civodul: good job on 3.0.3 release :) <wingo>civodul: excepting one thing tho. pretty sure chris vine is right, that the change to the libtool version was incorrect <wingo>we should clarify that --disable-deprecated builds do not have stable ABI, and that symbols of such binaries may disappear at any thing <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, efraim says: I'll test the JamVM patches on aarch64 but I don't want to be responsible for breaking other architectures :) <civodul>but thought we'd rather be safe than sorry <civodul>but yeah, dunno, we don't have a documented procedure for that <wingo>civodul: pretty sure all through 2.2.x we deprecated things <wingo>between keeping those changes and changing the soname, i would have reverted the bitvector changes on 3.0, fwiw <wingo>i.e. i only made them thinking that it would preserve ABI compatibility <civodul>i don't see changing the SONAME as that big a deal (to me it's less serious than not changing it when it should have been changed) <civodul>Debian for instance will have to rebuild all the dependents of guile-3.0 <civodul>from then on, i'm find with the policy you suggest: ignoring --disable-deprecated ABI stability <civodul>what course of action would you suggest now? <wingo>i don't know. i would suggest reverting, tbh <wingo>i mean releasing a quick 3.0.4 with CURRENT reset to what it was, and adapting the other two versions appropriately (I always have to look at the manual to see how to do it) <wingo>like it's not simply that debian would have to rebuild guile-3.0; it means they would have to have libguile3.0-42 vs libguile3.0-43 <wingo>which is not what we intended i think <wingo>AGE and REVISION or whatever <wingo>if you have the cycles, yeah <civodul>well, i don't, but if it has to be done... <wingo>well let's try between the two of us, in the meantime would you mind following up to the list with a note saying that we're going to release 3.0.4? <wingo>like we should avoid a cascade of problems with distributions <wingo>so maybe sending a note will give us the time to take care of it <civodul>probably best to avoid having distros get into troubles <wingo>not all distros are as advanced as guix ;) <civodul>actually there's a new scm_bitvector_position <wingo>i guess we should add some comments there. basically in a stable series we either increment both CURRENT and AGE -- that being the default option -- but if we know that nothing was added ABI-wise, we can just increment REVISION <civodul>i end up rereading the Libtool manual every time and going through git log <civodul>perhaps we should just use libabigail <wingo>thanks for working through this with me and apologies again for the bother <civodul>well, in hindsight, it was undoubtedly a mistake <wingo>lots of guile is a mistake in hindsight ;-)) ***wxie1 is now known as wxie
<dsmith-work>wingo: Did you happen to see the clang/arm breakage in the jit? <wingo>(also, are you using clang for your guile builds?) <dsmith-work>Yes, that case. Not using clang. That's RhodiumToad using fbsd on rpi. <wingo>that's a very interesting bug <wingo>i wonder why it doesn't cause more problems <wingo>do other abis not require writing the full word? <wingo>i would guess not but apparently all this is paged out of my brain :P <dsmith-work>wingo: x86 doesn't require zero padding I think. The abi doc I was looking didn't say for chars/shorts, but *did* mention bools. <dsmith-work>Bit 0 is 0or1, bits 1-7 must be 0, other bytes are don't-care. <wingo>yeah that is what i found too (of course looked at the abi doc but i wanted interpretation about something it was silent about) <RhodiumToad>wingo: gcc doesn't seem to assume that the caller of a function is following the ABI strictly. this is probably not really intentional, just an artifact of how it deals with data <RhodiumToad>whereas clang for whatever reason assumes that the ABI is followed <RhodiumToad>x86 requires bools are padded to bytes because it's easier and faster to check a byte for zero than a bit <RhodiumToad>but x86 doesn't otherwise require padding because, at least historically, forcing sign-extension or zero-extension slowed things down <RhodiumToad>whereas arm (at least in 32-bit, I haven't done anything with aarch64) tends to favour word-size accesses everywhere <wingo>i guess lightening should (a) assume that its registers are properly extended, e.g. that loading a u8 zero-fills any high bits, and (b) add "_abi" variants for the various store APIs, which backends can implement <wingo>generally speaking we will make them equivalent to word-size stores for values <= word-size <wingo>or maybe we can simplify and just use `jit_str` to store the values (i.e. the word-size variant) <RhodiumToad>_assuming_ that loading a value fills the high bits is a bad idea <wingo>from looking at the code in firefox, that is what it seems to do <wingo>RhodiumToad: pretty sure it is guaranteed by construction in the jit <wingo>from what i can tell it's general at least across x86/x64/arm/aarch64/mips32/mips64 <wingo>could be another platform is different but it sounds unlikely and we can cross that bridge later i guess <wingo>alternately we could emit extz / exts calls for "small" data types <wingo>could break some dependency chains too... <RhodiumToad>hm, yeah, I see that x86 is using movzx / movsx to generate byte loads <wingo>RhodiumToad: yeah consider, you do ldr_c (R0, addr); jnz(R0, L0). there i think the lightening API really means that loading an int8_t does sign extension <wingo>otherwise the result of the comparison would be undefined, if the high bits weren't defined <RhodiumToad>well I'm fairly new to lightening, hadn't looked at it before tackling these bugs <wingo>lol, i used to know lightening, but apparently i forgot everything about it; high five to the lightening newbies club <RhodiumToad>so I think the approach that feels best to me is to have an _abi variant for stores, meaning "store a value of this size in the way that the platform ABI expects" <wingo>"good" news would be that the fix to this bug is straightforward: just use jit_str instead of jit_str_c when passing stack args. similarly for _s and _i <wingo>assuming that is compatible with all platform ABIs, which i think it is for the ones that lightening supports <wingo>from firefox things i know that writing u8 args as word-size values isn't incompatible; whether it's required or not, i don't know. <wingo>(i wonder why armv7 is loading the whole word from the stack instead of just the byte; easier to encode?) <RhodiumToad>clang on aarch64 is _not_ loading or testing a whole word, just a byte *RhodiumToad finds the aarch64 abi doc <RhodiumToad>ok. so aarch64 explicitly does _not_ do the same padding that 32-bit arm requires <RhodiumToad>an integer value smaller than 8 bytes is passed in the low order N bits of an 8-byte slot (register or memory), but the remaining bits are unspecified ***ChanServ sets mode: +o civodul
***civodul changes topic to 'Welcome to #guile. See https://gnu.org/s/guile for more information. Guile 3.0.4 is out! <https://www.gnu.org/software/guile/news/gnu-guile-304-released.html>. This channel is logged, see <http://logs.guix.gnu.org/guile/>. Bug database at <https://bugs.gnu.org/guile>.'
<zig>Thanks whoever fixed the bug in guile 3.0.3 my project works again :) <civodul>dsmith-work: tag pushed, thanks for the reminder! *dsmith-work bows with a flourish ***sneek_ is now known as sneek
<sneek>rlb was in #guile 6 days ago, saying: Though I still need to think through whether or not that really makes sense here.... <sneek> 17:42:55 up 2 days, 5:35, 0 users, load average: 0.19, 0.06, 0.06