IRC channel logs
2025-09-28.log
back to list of logs
<old>ArneBab: it looks like window 64-bit defined `long' type to be 4 bytes as opposed to linux that defines it to be 8 bytes. <old>Since uintptr_t is 8 bytes on a 64-bit architecture, I suppose this is what this change is trying to do <old>looks good to me overall <dsmith>Using uintptr_t is the right thing, IMO. But there are *lots* of places to change... <ArneBab>old, dsmith: so all we need to check is whether it’s done consistently? <ttz>Hi all! Is there some SRFI specifying homogeneous-vector operations like f32vector:f32vector-add ? It seems to me that Guile -- since it sells itself as a C extension language -- should have a good SIMD story but I cannot find anything of the sort. Has someone some experience in using SIMD from Guile? <identity>ttz: SRFI 4, “Homogeneous numeric vector datatypes”, and others <ttz>I cannot find any addition in SRFI-4 <identity>ttz: SRFI 160 (an extension to SRFI 4) defines an @vector-fold procedure that you can use with the usual addition operators to get the sum of an @vector <ttz>indeed, but I don't think the fold semantics is really SIMD-friendly (it would need to be able to recognize SIMD-able function) <ttz>while a plain vector:vector-add could be implemented as a call to an C function with SIMD without too much trouble <identity>you would need to do that with any kind of theoretically-SIMD-able-loop, anyway <ttz>sure, making the compiler clever-enough to convert loops into SIMD would be great, but the experience report on the Java world is rather disappointing and they seem to be turning toward adding special functions with SIMD semantics in order to guarantee the optimization <old>ArneBab: Well what this integers are encoding? I find it awkward to use uintptr_t for encoding numeric values that you can to express as 32-bit or 64-bit depending on the architecture <old>but they are not actual address <old>If they are address, I think it makes sens to use uintptr_t. Otherwise, it's probably wiser to use a typedef <identity>there is uint64_t, (or something like that) anyways <old>well it depends if you want atomic access to the value or not <old>also uint64_t is slower on 32-bit architectures <old>so really what are these integers encoding and what are the accesses made to them and in what context <old>but if these integers do not need atomic access and the overhead on 32-bit architectures is not something important, yeah just use uint64_t <identity>if the value does not fit in a 32-bit integer, then you should ensure it is (at least) 64 bits in size <old>it depends on the usage again <old>if they are hashed values, you can rotate the bits on overflow <old>and it seems to me that it's already 32-bit values on 32-bit architectures so that does not seem a problem <old>The problem seems to be that on 64-bit windows, pointers are 64-bit but unsigned-long are 32-bit so when hashing pointer you loose bits <old>this is not a problem on 32-bit systems <old>anyway, TLDR; uintptr_t is fine, just awkward if nothing with pointer addresses directly and I would recommend to typedef a type explaining the rationale or just use uint64_t if performance for 32-bit architecture is not important <old>ArneBab: and yeah make sure the change is consistant across the code-base I guess <ArneBab>old: I quoted your earlier answer in the PR; can I quote your longer comment now, too? <mwette>uintptr_t is not necessarily a pointer, but is big enough to hold a pointer or an int (or long?) <Arsen>(and uintptr_t is *never* a pointer, it is always an integer type) <lxsameer>hey folks, do I need to register a language after defined it using `define-language`? running `guile -l 'the-lang-file.scm' --language='foo' main.scm` can't find the language <dpk>mwette: uintptr_t is an integer which can be safely cast from and to a pointer <rlb>lxsameer: I forget the exact requirements, but is your definition in a (language FOO spec) module in the load path? I know that works. <rlb>(or it did -- can't double-check it right now) <dpk>this was the C committee’s compromise between pesky people like Lisp implementers who wanted to go in and mess with the bit patterns of pointer vs the other pesky people like people implementing C on Lisp machines where pointers weren’t bit patterns to begin wish <mwette>lxsameer: what rlb said: spec.scm needs to be in language/FOO/spec.scm where the parent to language is in GUILE_LOAD_PATH <lxsameer>mwette: rlb thank folks i'll give it a try <mwette>(actually %load-path, which includes $GUILE_LOAD_PATH) <dpk>rlb, ArneBab, others: would it be too late to make a request for Guile 3.0.11? <dpk>i want to propose that Guile’s historical non-R6RS/non-R7RS lexical syntax (just unicode escapes without terminating semicolon, i think) get a deprecation notice, as part of trying to move towards R6RS/R7RS conformance by default <dpk>(i will make a more thorough proposal for this on guile-devel if you agree it’s not too late for Guile 3.0.11 to do this) <rlb>From my perspective at least, 3.0.11's in a holding pattern now -- there's still a bit to do, but I believe it also awaits a bit of bandwidth from Ludovic, if nothing else. <dpk>hmm, okay. do you think there’ll be a Guile 3.2 or 3.0.12? it would be nice to use the opportunity of a major 4.0 version release for a change like that <old>ArneBab: I commented the issue myself but you can add to it by quoting if you want <dpk>and the release before that would be the logical time to start warning about it <old>As a side note, it would be nice to have a merging windows for bug fixes released that is "official" <old>I think that lots of us have fixed for some bugs they have found that could benifit everyone, but we just need the good timing to get it merged. Perhaps this will be easier now with the migration to Codeberg <rlb>dpk: my current understanding is that we'll have a 3.0.11 in the near term, and possibly some further Z releases after that, and that a 4.0 is in the wings, pending Andy's work on whippet. <rlb>...no idea if that's what we want -- just noticed those oversights wrt the last Y/X release while poking around. <rlb>(I do like being able to manipulate bug trackers via chosen tools (e.g. either directly within emacs (notmuch), or via other tools of your own choosing), and I like the resiliency of having all the data in a standard distributable format, but there's no reason why in theory you couldn't provide much of that for another sufficiently open system (e.g. codeberg).) <rlb>(...asssuming, of course, a lot of bespoke work, per-system)