IRC channel logs

2021-03-15.log

back to list of logs

<rlb>wingo: another option - I could take part of what I'd be contemplating wrt immutable texts, i.e. we could have "sparsely indexed stringbufs", which would allow us to swap atomically, and would help with other indexing operations. e.g. we could keep an array of sparse char offsets in the stringbuf, say every 32nd char or something. Then strings would go back to just using char offsets (not also byte offsets).
<rlb> We'd have to hunt though about half the sparseness on average to find a char offset, but that's way better than the whole string for arbitrary stringrefs, etc., and maybe it's good enough for the normal, most common, string operations. They won't be as fast as an exact offset, but pretty fast.
<rlb>I also imagine we *could* heavily optimize utf8 operations if we wanted to (if libunistring doesn't), i.e. tricks with wider ints, or even gcc/llvm intrinsics or vector ops, etc.
<rlb>i.e. the "finding part"
<rlb>We could even have more than one flavor, i.e. a uint8 offset index for shorter strings, uint32 or 64 for longer ones, etc.
<rlb>I wonder just what fraction of strings is typically < 256 bytes, utf-8 encoded (and isn't ascii).
<davexunit>goops woe: it's easy enough to define a custom setter for a slot accessor, but since each class defines getter/setter methods for all of its slots, there's no way to define a setter method for a superclass that also applies to the subclasses.
<sneek>Welcome back davexunit, you have 1 message!
<sneek>davexunit, wingo says: that's like racket's "prefab" structs. would be nice to support that
<davexunit>I think I remember the context for this... neat.
<davexunit>back to the goops thing: it feels reasonable to want to hook into a slot setter method to add custom behavior, but maybe I'm thinking about it wrong.
<davexunit>one solution is to define a new method entirely for this purpose, but it feels better to have the code look the same as any other slot modification.
<daviid>davexunit: fwiw, slot-set! is procedure, the only situation where you can customize slot-set! is for virtual slots, afaiu
<davexunit>yes I know but I'm talking about (set! (foo obj) bar)
<davexunit>using slot accessors and the generalized set! syntax
<davexunit>my current path of exploration is to use some metaclass magic to add a new slot option that specifies a post-set! callback method.
<davexunit>compute-setter-method can detect that and generate a special <accessor-method> instance.
<daviid>right, i don't think it is possible to customize the 'default' accessor(s), except as you said, using the mop or simply defining a method ...
<davexunit>I want the post-set! stuff to be transparent. I want the code to read like any other set! call
<daviid>davexunit: then i'd use the mop, and define a new slot-type
<daviid>a new slot allocation type i meant
<davexunit>I think a custom slot option will suffice
<davexunit>I tried messing with allocation types and it gets real hairy real fast
<davexunit>goops doesn't publicly export the procedures that allow you to get the struct field index for a slot, so implementing an allocation type that uses instance level storage is not possible without hacks.
<daviid>yes, it's not exactly 'a piece of cake' (to answer your previous sentence) - maybe a slot option would be enough, never tried, i use the mop and allocation type (in g-golf)
<davexunit>does your allocation type store data on the instances of that class?
<daviid>no, all are precisely not allocating, but using/refering to GObject properties
<davexunit>got it
<davexunit>yeah a new allocation type makes perfect sense there
<davexunit>for my case, I want to use the #:instance allocation type, but decorate the accessor methods
<davexunit>well, that's enough playing around for one night. thanks daviid. byeeee
<daviid>davexunit: right, I think the best route is to define a metaclass and detect treat the new allocation type in a customized compute-slots methods, then decorate slot-set! (note that you would not decorate the accessor method(s), but slot-set!)
<rlb>wingo: do you happen to know if we have many/any free bits in the stringbuf tag field (cell_0)?
<tohoyn>hello
<tohoyn>what's the status of Guile Potluck?
<manumanumanu>ahoy!
<wingo>o/
<wingo>janneke: why does mes need a gc? would a bump-pointer allocator that never reclaims memory be sufficient?
<wingo>i guess it means bootstrap allocates lots of memory :)
<janneke>wingo: yes, i even tried it without, initially; minding the remarks in SICP about memory
<janneke>wingo: also, bootstrap is x86, 32bit
<wingo>ah yeah.
<ArneBab>rlb: that sounds like a useful fix: O(1 + something-32-chars) would be great.
<davexunit>daviid: just fyi, what worked for me was adding a new slot option #:watch? that my metaclass knows how to handle. any slot with #:watch? #t has a special setter that calls an on-change method when a new value is set.
<davexunit>for example, I have a class that draws text on screen. by watching for changes to the slot that contains the string, I can now automatically recalculate text alignment based on the new dimensions of the text.
<wingo>heya davexunit
<davexunit>hi wingo
<leoprikler>Yeah, GOOPS has some nice features like that.
<leoprikler>If you deal with raw records, things can get ugly pretty fast.
<spk121>wingo: w.r.t JIT. Yeah I set the threshold=0 and ran it on MinGW. Seems OK.
<wingo>grand
<davexunit>spk121: jit on mingw? that rules!
<davexunit>now, do threads work? am I asking for miracles? ;)
<spk121>davexunit: maybe? building with threads enabled does succeed and the test suite does run. I haven't hit it enough to check if threads are actually working or if it will hang eventually like before
<davexunit>well that's promising, at least.
<davexunit>I'll have to revive my guix mingw code sometime
<spk121>the last remaining huge hurdle is disambiguating sizeof(long) vs sizeof(void *) in the VM and in numbers.c
<spk121>(or alternately rewriting VM an numbers.c to use uint64_t for long)
<chrislck_>spk121: :-O
***chrislck_ is now known as chrislck
<janneke>spk121: sounds awfully related to the x86_64 work
<janneke>i've been trying to port my 2.2 patches this weekend
<spk121>janneke: I do mean the work you're doing, of course. I did peek at your tree to see what you've done
<janneke>great!
<janneke> https://gitlab.com/janneke/guile.git @ wip-mingw now cross-builds on guix,
<janneke>but running it fails in an interesting way
<janneke>unknown location: unexpected syntax in form ((@ (ice-9 control) %) (begin ((@@ (ice-9 command-line) eval-string/lang) "(display \"hello\\n\")") (quit)))
<janneke>not sure how to go about that
<spk121>janneke: are you running on wine?
<davexunit>I had issues back in the day where the resulting exe would fail on wine but work on windows
<spk121>yeah, I can't get it to run on wine, but, my understanding of how to use wine is rudimentary
<janneke>spk121: yeah, i do my testing on wine
<civodul>looking at the Guile code, i'm wondering how one can get: Wrong type (expecting finalized smob): #<cairo-context 7ffff5b60090>
<civodul>(from <https://issues.guix.gnu.org/47115>)
<civodul>looks like finalized_smob_tc16 is private, never used anywhere in type checks
<civodul>what am i missing?
<wingo>civodul: ot
<wingo>it's the first smob type and has value 0
<wingo>when a smob is finalized, its smobnum is reset to 0
<wingo>see clear_smobnum
<wingo>civodul: if you get "expecting finalized smob", that means that somehow the scm_assert_smob_type is getting passed 0 as the smobnum
<wingo>hum, i wonder if you have somehow hit the smob limit
<wingo>more than 255 smob types defined, overflow to 0
<civodul>and tags would wrap and you'd get a zero tag?
<civodul>uh
<wingo>i mean i would expect there to be an error
<wingo>but it's a way i could see that to happen
<civodul>though memory corruption may be more likely in this case
<wingo>yeah that is what i am thinking
<wingo>weird to think it though :P
<civodul>i'll see if i can reproduce
*civodul feels like a fire fighter these days :-)
<wingo>or somehow something overwrote that tc16 value with a value for which (v & 0xff00) == 0
<civodul>yeah, so many possibilities
<jackhill>,
<jackhill>oops, soory
<jackhill>civodul: thanks for looking at that bug. Somehow I have a nack for turning up wierd errors :)
<[-_-]>hello
<[-_-]> http://ix.io/2SWp
<[-_-]>Can someone tell me what those display statements doing in that file?
<[-_-]> i can't understad what to expect
<[-_-]>This is where i got the file
<[-_-]> https://www.nongnu.org/xbindkeys/xbindkeysrc-combo.scm.html
***rekado_ is now known as rekado
<rekado>[-_-]: “display” prints a string to a port
<rekado>if no port is given it prints to stdout
<tohoyn>[- -]: the display statements seem to be some debug output to the console
<rekado>or it could be called within a (parameterize ((current-output-port …)) …) context and write these things to a file
<[-_-]>oh... rekado thank you for explaining
<rlb>wingo: I roughed in the indexing approach, so far it looks promising, if the (tunable at powers of 2) index overhead is acceptable, i.e. say ~6% size and the cost to regenerate it after changes (plus the code complexity). And wrt your more general utf8 question, another thing I imagine we might get with utf8 is much more heavily optimized paths for things like memchr, etc.
<rlb>wingo: for now I packed the index inline in front of the string bytes, but we could do "something else".
<rlb>...and I also set up dynamic "widths", i.e. one-byte index entries for strings < 256 chars, two-bytes for < 2^16, etc. For now I didn't cover the case of size_t > 64-bit :)
<rlb>(and the index skip-factor is also dynamic -- larger for longer strings)
*rlb shrugs, not sure, and only roughed in the creation -- haven't touched the rest of the code yet, so there'd sill be a lot to do...
<davexunit>random note: I started reading "software design for flexibility" and I encountered examples code that looked like (define ((iterate n) f) ...). this syntax appears to be mit/gnu scheme's way to create curried procedures. anyone ever implement this for guile?
<davexunit>example*
<davexunit>to work with the example code in guile I've just been manually expanding like (define (iterate n) (lambda (f) ...)) so I can keep my focus on the book itself
<leoprikler>ice-9 curried-definitions IIRC
<dsmith-work>Monday Greetings, Guilers
<sneek>It's the 15th of March. Look out for ides
<dsmith-work>davexunit: Guile used to have curried definitions by default. Removed in 2.0.
<davexunit>leoprikler: will check there, thanks.
<davexunit>dsmith-work: do you remember any context around why it was removed?
<leoprikler>It was not removed it was simply made non-default.
<leoprikler>So you need to explicitly say that you want them now.
<dsmith-work>Nope. It's in the NEWS file. I noticed becuse scwm used that in some places.
<dsmith-work>The NEWS doesn't say why.
<davexunit>so I guess there's no scheme standard that includes them
<janneke>WINEPREFIX=~/.wine64 wine64 cmd /c guile.cmd -c '(display "hello\n")'
<janneke>hello
<janneke>\o/
<leoprikler>nice
<janneke>yeah -- i was about to give up, and of course, more interesting tests fail
<janneke>oh wait, my scripts have 2.2 hardcoded, it's not that bad
***drakonis- is now known as drakonis
<wingo>moo
<lampilelo>so arch still didn't upgrade to guile 3
<wingo>lampilelo: is it because it just didn't happen yet, or was there a reason?
<lampilelo>wingo: i don't think there's an actual reason, probably just because there's not much push for it from the community
<fnstudio>hi, sorry, i suppose there's no way around this but just in case... in terms of the shebang string at the start of my guile script... /usr/local/bin/guile doesn't seem to do it (guix on a foreign distro here and guile is elsewhere)
<lampilelo>or maybe the fact that autogen, a dependency of gnutls, doesn't compile with guile3 because the version in the repos is from 2018 and it has a hardcoded check for guile version
<fnstudio>i wouldn't be very keen to hardcode my home path, on the other hand i suppose there's no other option that maintains generality
<fnstudio>(generality = a standard path like the one in /usr)
<fnstudio>unless i create a symlink which also doesn't look clean
<fnstudio>yeah there must be no alternative i guess
<lampilelo>fnstudio: does '#!/usr/bin/env guile' work?
<fnstudio>lampilelo: brilliant, that works :) although i had to get rid of the "-e main -s" bit
<fnstudio>but there might be a way of putting it back if i escape things properly
<fnstudio>also i don't think i need -e main -s now
<fnstudio>lampilelo: so that works brilliantly for me, thanks! :)
<wingo>fnstudio: if you want to preserve the ability to load the file and not "run" it, you can end the file in (when (batch-mode?) (apply main (program-arguments)))
<lampilelo>fnstudio: no problem
<wingo>batch-mode? returns true when you would want to run main
<lampilelo>wingo: i think it's just too much work for the maintainer, and my guess is it's the autogen problem, they use a version from the website, which didn't get any updates since a long time, they release new versions only on savannah
<lampilelo>i marked autogen as out of date some time ago but i see that the flag was removed
<lampilelo>i have no idea how to make this happen
<lampilelo>probably write and email to maintainers
<lampilelo>an*
<wingo>sounds frustrating
<lampilelo>maybe i'll get around to doing that if i ever get tired of compiling guile and gnutls by hand ;)
<wingo>:)
<wingo>rlb: scheme@(guile-user)> (use-modules (ice-9 i18n))
<wingo>scheme@(guile-user)> (list "⇒a" "⇒b")
<wingo>$1 = ("⇒a" "⇒b")
<wingo>scheme@(guile-user)> (map (lambda (s) (substring/shared s 0 1)) $1)
<wingo>$2 = ("⇒" "⇒")
<wingo>scheme@(guile-user)> (apply string-locale-ci=? $2)
<wingo>$3 = #f
<wingo>you found a nice bug :)
<civodul>does string-locale-ci=? compare beyond the end of string?
<wingo>yep
<civodul>compares the stringbuf instead of the string or something
<wingo>because it uses u32_strlen
<civodul>uh
<wingo>so could read anything
<civodul>woow, good catch
<wingo>very exciting stuff :P
<civodul>yup
<civodul>does string-take use substring/shared actually?
<civodul>seems not
<civodul>if we had immutable strings, it could, and that'd be nice...
<wingo>related bugs in string-locale=? and friends
<civodul>ouch
<wingo>but that's the extent of it afaiu
<wingo>rlb: regarding use of u32_strcoll which doesn't have a variant that takes a number of codepoints --
<wingo>i wonder if u32_normcoll could substitute
<wingo>i don't know much about normalization tho
<wingo>maybe that doesn't work, normcoll has a different interface
<wingo>interestingly the implementation of u32_strcoll just converts to the locale encoding and calls strcoll
<wingo>so i suppose we should do that.
<rlb>is there a strncoll or something?
<rlb>Oh, though I guess if we're converting it doesn't matter.
<rlb>i.e. we can null terminate, unless we're supposed to dtrt even with embedded nulls?
<rlb>i.e. unicode null is a thing.
<rlb>U+0000
*rlb has had to deal with that before, elsewhere.
<rlb>(in json contexts -- pg does *not* support it, but unicode does)
<rlb>pg -> postgresql
<rlb>hah "(This is really a POSIX/C problem, but that doesn't mean we can't solve it out-of-spec) It would be nice if there were a variant of strcoll() that took a length, "strncoll()", or didn't use null-termination at all. Then PostgreSQL wouldn't have to allocate extra copies of strings just to call strcoll() in some scenarios where it has a non-NT string. ICU can do this."
<rlb>-- https://wiki.postgresql.org/wiki/FreeBSD
*wingo nod
<rlb>I'm a little surprised glibc doesn't have something like strncoll...
<wingo>so many layers of bad
<rlb>:)
<wingo>hum i wonder why the test i added fails
***RhodiumToad__ is now known as RhodiumToad
***scs is now known as Guest75682
<ArneBab>on building community and momentum (a view on Clojure by a former user): https://gist.github.com/wildermuthn/c783ed4f6735fa66c4e7ad34830b3977
<flatwhatson>re: Guile 3 on archlinux, I think a number of people are using Guix for this
<flatwhatson>it's not so different to using rustup or nvm/npm or pyenv etc. (if you squint)
<leoprikler>Except you can install Guile without Guix and (partially) use Guix as replacement for rustup, npm and pyenv :)
<leoprikler>Arch folk ditching pkgbuilds for Guix sounds kinda out of character as well. Where's the fun in breaking your system if you can trivially recover?
<flatwhatson>Arch folks playing with shiny toys is perfectly in character :P