<rlb>OK, thanks, and right, so our Z is not at all "bugfix only". <rlb>Just realized I hadn't thought carefully about it in a while, though I also hadn't been in a position to need to as much :) <spk121>I know we've added API in 3rd level fairly often, as I recall <rlb>Right, I suppose past a certain point, that might make my job with the debian stable release managers harder, in theory, but it hasn't yet been an issue in practice. <spk121>And again, I'm not a maintainer, just a long time lurker, haha <RhodiumToad>mwette: my version actually uses a bytevector rather than a plain vector, for speed <rlb>I noticed that when I set up a custom repl for a dialect, it works fine until there's an exception. Then, when it enters the new prompt, it's back to the default repl. I wondered if that's considered preferable, or if there's a way I should be specifying that new prompts should also be custom? <rlb>lokke@lokke.user> (x) <rlb>;;; <unknown-location>: warning: possibly unbound variable `x' <rlb>Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. <rlb>lokke@(lokke ns lokke user) [1]> <rlb>You can see that the initial prompt has the module name reported in clojure namespace syntax i.e. lokke.user, but after the error it's the guile module name list. <rlb>iirc the printer's back to the scheme printer too, which is a bit more of an issue, i.e. when debugging. <RhodiumToad>that's presumably an artifact of what the exception handler is doing? <plattfot>Hi, already asked this in the #guix channel, so sorry in advance for double posting. But I didn't get much help, and therefore I'm testing to ask here as well. The issue I've is with that I'm trying to stamp in the load and compile path for my script. What I did was to use `(eval-when (load expand eval) (set! %load-path (cons "@guilemoduledir@" %load-path)) (set! %load-compiled-path (cons "@guileobjectdir@" %load-compiled-path)) <plattfot>@guilemoduledir@ and @guileobjectdir@ are set in the configure.ac file. <plattfot>I thought it was working as my package worked fine on my machine, but turns out it only works on my machine and everyone else gets an error about guile not finding the module. <plattfot>Ok, think I got something that works. It's not as elegant I was hopeing but it seems to work. ***apteryx is now known as Guest91811
***apteryx_ is now known as apteryx
<leoprikler>how do I create an immutable vector? (other than reading it) ***hugh_marera63 is now known as hugh_marera
***jonsger1 is now known as jonsger
<rlb>leoprikler: there are also wingo's fector.scm (though I think there may be a bug in the pop method I haven't tracked down yet), and lokke's vector (both are O(log_32(N)) bagwell-style structures: https://hypirion.com/musings/understanding-persistent-vector-pt-1 The latter's a C extension, though, so perhaps not worth the complexity. And both are I think intended to be thread-safe. I know lokke's is. <RhodiumToad>I _believe_ it's the process of compiling it that makes it immutable <leoprikler>That's all a bit too high for what I actually need (which would be closer to static arrays, but I solved the problem in which I've used them through other means). <leoprikler>Still, I feel as read-only array( view)s are something guile lacks <RhodiumToad>(let ((v (with-input-from-string "#(1 2 3)" (lambda () (read))))) (vector-set! v 1 4) v) ;; #(1 4 3) <RhodiumToad>(let ((v (compile (with-input-from-string "#(1 2 3)" (lambda () (read)))))) (vector-set! v 1 4) v) ;; error <RhodiumToad>(let ((v (compile #(1 2 3)))) (vector-set! v 1 4) v) ;; error <RhodiumToad>(let ((v (compile (vector 1 2 3)))) (vector-set! v 1 4) v) ;; also error <rlb>...I've thought I'd also like to have good support for immutable goops class instances with some way to copy/change one fairly quickly, i.e. to make a fast copy with a few specified slots changed. <rlb>(ideally in a way that promises to be "thread safe", i.e. final pointer isn't visible to any thread unless the fully initialized contents are) ***apteryx_ is now known as apteryx
***zimoun` is now known as zimoun
<daviid>rlb: goopd itself isn't thread safe, class-redefinition ... <daviid>but someone wrote slot-fset, dustyweb i think <rlb>That's potentially I separate issue? i.e. whether or not you need thread-safety for class redef might be different from whether or not you need thread-safety for creating new instances? <rlb>But either way good to know -- thanks. <rlb>For me the latter would be more important in the short/medium term. <daviid>i think i have a copy, let me see <rlb>Ahh, thanks -- I suspect I'd eventually want a bulk operation, but that's a great starting point. <rlb>modify multiple slots at once for one clone. <rlb>i.e. (foo object 'bar 1 'baz 2) or something <daviid>ah ok, i wrote a syntax to do that in g-golf <rlb>or rather (adjusted-clone object 'bar 1 'baz 2) or something <rlb>I wonder how close the current compiler can get that to a "memcpy followed by some assignments" in perf, or maybe it can (or eventually can be taught to) do even better. <rlb>(But first of course, have to see whether it's already "good enough" before worrying about it.) <mdevos>I'll propose exporting extra O_* flags. Should the e-mail go to bug-guile@gnu.org or guile-devel@gnu.org? <rlb>Personally, I'd be inclined to say patches to guile-devel, for review, but if we'd rather do that somewhere else, then no worries. <daviid>rlb: actually, I forgot that in 3.0, classses are non redefinable 'by default', so if you' using 3.0 and use slot-fset, or mslot-fset, then it should be thread safe <mdevos>rlb: it's not a patch, only a description of what O_* flags I would like to see in new versions of guile. <rlb>Ahh, then maybe a bug at least, i.e. might be more likely to not forget about it. <rlb>(I suspect I'm in favor of the additions.) <mdevos>rlb: gah, I accidentally sent it to -devel instead of bugs. <rlb>that's fine too, though we might still want a bug for tracking unless someone has time to work on it more immediately.