IRC channel logs

2021-01-28.log

back to list of logs

*rlb vaguely wonders if guile works fine in WSL on the windows side... (Someone just reported that bup "works fine" there.)
<daviid>fwiw, on win, guile works quite well on msys2 - 2.2.7 (64bits vers), not sure there is a 3.0 yet, didn't check in a while - so, not a 'native' version, but it has threads, which i need
***metro is now known as metreo
<daviid>sneek: later tell tohoyn G-Golf depends on module-use!, which 'indirectly' raises exception(s) (see bug#43025 - the first message, the attempt to solve is a 'naive work arround', that would only work for static modules ... G-Golf needs a 'real' module-use! fix (under the f
<sneek>Got it.
<daviid>*a real fix 'under the hood', the module-use! code hasn't change, but changes have been made in 3.0, to the module system, that 'breaks' module-use! ...
***wxie1 is now known as wxie
<DadeBonetti1>Hi!
***Server sets mode: +nt
<wingo>probably easier to extend something like "fmt" with that
<chrislck>Thursday greetings o/
<apteryx>I just had the following test failure, building Guile 3.0.5 on Guix: https://paste.debian.net/1183102/
<apteryx>It's probably non-deterministic, as I've built 3.0.5 many times in the past.
<civodul>apteryx: o/ could you see higher in the log which test failed?
<apteryx>hmm, perhaps something happened on the machine during the build; the build log appears truncated
<apteryx>or reused? it said 'changed on disk' when I tried to view the log file in Emacs.
<apteryx>(I've relaunched the build after it first failed)
<apteryx>sorry! I'll be more careful if it occurs again
<civodul>heh np!
***Aurora_iz_kosmos is now known as Aurora_v_kosmose
<Sheilong>Hello
<Sheilong>I am trying to import a procedure from a file to another, but I am always getting the error ERROR: In procedure scm-error: no code for module xyz...
<tohoyn>when statprof reports the total time is the time spent in GC excluded from it?
<sneek>Welcome back tohoyn, you have 1 message!
<sneek>tohoyn, daviid says: G-Golf depends on module-use!, which 'indirectly' raises exception(s) (see bug#43025 - the first message, the attempt to solve is a 'naive work arround', that would only work for static modules ... G-Golf needs a 'real' module-use! fix (under the f
<tohoyn>Sheilong: do you have the module and the file using it in the same subdirectory?
<Sheilong>tohoyn: I do.
<tohoyn>Sheilong: do you have a linux system?
<Sheilong>tohoyn: Yes.
<tohoyn>Sheilong: try "export GUILE_LOAD_PATH=.:"
<tohoyn>before you run the guile code
<Sheilong>First file I did (define-module (xyz...) #:export (abc); Second file I did (add-to-load-path "./") and (use-modules (x y z))
<tohoyn>Sheilong could you paste the files to Debian pastezone?
<Sheilong>tohoyn: https://paste.debian.net/1183110/ and https://paste.debian.net/1183111/
<tohoyn>Sheilong: tx
<tohoyn>Sheilong: guile probably searches files 1-1.scm and 1-2.scm in subdirectory cryptopals. is this correct?
<tohoyn>Sheilong: I mean, do you want this behaviour?
<tohoyn>Sheilong: what filenames do you have for these modules?
<Sheilong>tohoyn: the directory name is Set1 and the filenames are c1 c2 c3...
<tohoyn>Sheilong: do you execute the code in directory Set1 or in the parent directory of Set1?
<tohoyn>Sheilong: the module names should be the same as the file names without the .scm extension
<Sheilong>tohoyn: I execute in the directory Set1
<Sheilong>tohoyn: something like (define-module (Set1 c1))?
<tohoyn>Sheilong: you should ensure that the files have the extension .scm and change the module names so that the module name for file MOD.scm is (MOD)
<tohoyn>Shielong: maybe without Set1
<Sheilong>It looks like it did work with (add-to-load-path "./") and Set1 c1
<tohoyn>Sheilong: ok
<Sheilong>I exported only one procedure but it seems like when I import c1 module it runs all code
<tohoyn>Sheilong: I think that is the correct behaviour if you have executable statements (not definitions) in your modules
<tohoyn>Sheilong: are we talking about module 1-1?
<Sheilong>I defined it as (define-module (c1) #:export (encode-hex)); Shouldn't only encode-hex be imported?
<tohoyn>Sheilong: yes but...
<tohoyn>Sheilong: if you have other definitions than encode-hex in module c1 they are not imported
<tohoyn>Sheilong: but if you have executable statements in the moduled they are executed when the module is imported even though you don't export them
<tohoyn>s/moduled/module/
<tohoyn>Sheilong: what is the code you think should not be run?
<tohoyn>Sheilong: the assert statements?
<Sheilong>tohoyn: that's right
<Sheilong>tohoyn: When I use #select they are not executed
<Sheilong>tohoyn: Thanks so much for your help
<tohoyn>Sheilong: I recommend putting the tests in to a procedure / some procedures instead of having them in the toplevel
<tohoyn>Sheilong: you are welcome
<manumanumanu>DadeBonetti: You should probably have a look at srfi-166 (not yet implemented in guile what I know of, though... sorry). That is an extensible string formatter
<manumanumanu>I had a repo somewhere of the precursor of it, but that is dead currently
<DadeBonetti>@manumanumanu thanks
<manumanumanu>I don't know if any scheme has it built in yet (except chibi), but it is probably the future standard formatting utility for guile
<manumanumanu>s/guile/scheme
<manumanumanu>I did _not_ mean to say anything about guile there.
<manumanumanu>What it is lacking is that the reference implementation is about 3x slower than (ice-9 format). If one can make (show ...) a macro, one can then make a "compiler" that makes the common cases fast.
<manumanumanu>much like (ice-9 format) does
<manumanumanu>I don't think there is anything that has to make srfi-166 slow, except the overhead of the combinators and the environment monad, much of which can be removed.
<DadeBonetti>I just take a look to srfi166, but id don't seems to have formatters for cardinals and ordinals numbers, like ice-9 has
<manumanumanu>(famous last words?) how hard can that be to implement?
<leoprikler>it's a long chain of modulo 10 combined with LUTs
<leoprikler>s/modulo/div-mod/
<manumanumanu>leoprikler: now internationalize it! :D :D
<leoprikler>there is no i18n with latin numerals
<leoprikler>but you *could* do the same approach for other counting systems, e.g. japanese
<manumanumanu>I only know languages where it works as in english, but there must be others. Danish? 75 = "five and half-eighty". I don't know about ordinal numbers
<leoprikler>hmm, perhaps I can implement something, that just needs ahash table
<manumanumanu>And that is still indo-european
<manumanumanu>or heck, germanic.
<leoprikler>I'm not talking about stuff like einundzwanzig here
<leoprikler>We use arabic numbers here in Europe.
<manumanumanu>BBL: reading about internationalizing ordinal numbers :)
<leoprikler>but for instance in Japan you can write 2021 as 二千二十一
<leoprikler>and in Roman it would be MMDDI if I'm not mistaken
<RhodiumToad>MMXXI
<leoprikler>thanks
<davexunit>any GOOPS MOP wizards here? trying to make a metaclass that automagically does special things in a slot's getter and setter. I've tried a few different things that haven't worked.
<justin_smith>in danish they count by twenties rather than ten, with some features reminiscent of roman numerals (eg. using "-5" to indicate 15)
<leoprikler>heh, that's how we count hours in German. "Halb neun" = 8:30
<RhodiumToad>davexunit: what did you try?
<davexunit>the most promising thing was adding a special #:allocation type and handling it in compute-get-n-set, but for instance allocation you have to return a struct field index and can't use a getter and setter.
<RhodiumToad>davexunit: and do you have an example of the kind of magic you want to do?
<manumanumanu>leoprikler: the more I think about this the more I get vertigo :) I remember that there are so many slight differences between swedish and german. Regarding the clock, many things are similar (viertel nach/vor), but I got bitten once or twice just after I moved there due to slight inconsistencies.
<davexunit>RhodiumToad: I need to put together a contrived example that doesn't use all the special library code I have. the gist of the problem is: I want the slot to store a box, and have the slot getter and setter transparently handling boxing/unboxing.
<davexunit>it sounds silly when explained that way, but in the context of the real project it makes sense to introduce this indirection.
<davexunit>(define-class <foo> () (bar #:allocation #:boxed #:accessor bar) #:metaclass <my-metaclass>)
<leoprikler>davexunit: can you not define your accessor as a method with setter?
<leoprikler>Doing so from a metaclass might still be hard tho.
<davexunit>leoprikler: the trick is in doing this automatically without every slot that is like this having to repeat tons of boilerplate.
<leoprikler>ah, I see
<leoprikler>how about a macro?
<davexunit>maybe, but I want to exhaust my other options first.
<leoprikler>[you can tell I'm not very used to GOOPS and want to avoid it as much as possible]
<davexunit>leoprikler: since you are a fellow game dev, this might make sense: I have a data type called <asset> for storing data loaded from the file system (textures, audio, etc.). the asset system places watches on asset files via inotify and automatically reloads them when the file is modified. so, <asset> is a box with some inotify goodies tacked on.
<RhodiumToad>and you want normal accessors to transparently unbox it
<RhodiumToad>?
<davexunit>yes, that is one desired feature. there's another thing I want in the setter but we don't need to get into it.
<davexunit>now, I *can* get this to work but I'm not happy with the implementation.
<leoprikler>ahh, so everywhere you use an asset as a field type, you want to directly unbox it
<davexunit>yes.
<davexunit>the other feature is that the asset has a hook that runs when the asset is reloaded. this can be used to say, recompute a bounding box when a sprite's texture is reloaded (the image size may be different)
<leoprikler>Chickadee is adding some crazy features I see.
<davexunit>so far I've been unable to store the data in the instance itself. I've had to create a weak key hash table keyed off the instance.
<davexunit>leoprikler: this is actually for a library on top of chickadee. I stay away from goops entirely in chickadee.
<leoprikler>Okay, makes sense.
<davexunit>since it's kind of divisive. some use it, some don't.
<leoprikler>FWIW you could implement your own slot-ref
<leoprikler>wait, how do accessors work again in guix? there's no direct slot-ref, is there?
<leoprikler>s/guix/goops/
<davexunit>there is slot-ref
<leoprikler>okay, but people are not expected to call it, are they?
<davexunit>but to go that route would require a lookup table in the class that has all the slot names
<leoprikler>No, it wouldn't
<davexunit>I don't think a slot getter/setter/accessor uses it
<leoprikler>you first do a slot-ref and then typecheck the result – if it's an <asset> unbox it, otherwise return as is
<davexunit>assuming the getter/setter/accessor methods used slot-ref/slot-set! under the hood (not sure they do), there's the big downside of adding overhead to every slot access.
<leoprikler>I think if you generically implement all your accessors in terms of this supposed slot-ref*, you'll have an easier implementation. Question now is how to insert custom accessors into fields
<leoprikler>That is true, but it's the overhead you already have for <asset> access anyway, is it not?
<davexunit>the goops implementation is a little tricky to decipher, since it has to go through this whole bootstrapping sequence.
<davexunit>leoprikler: but that overhead would now apply to all slots that inherit from the base class, the vast majority of which are not asset slots.
<davexunit>I'd rather keep using a weak key hash table, but there's overhead in that, too, so I'd really much prefer just storing the data I need in the instance itself.
<leoprikler>okay, so you need to distinguish between asset and non-asset slots by some heuristic and on top of them install accessors transparently
<leoprikler>But I still think my proposal has some value: First try to find out how to override all accessors. Once you got that figured out, filtering based on a predicate should be comparatively simple.
<davexunit>leoprikler: it should be possible without a heuristic. you can use slot options to mark the slots with a special keyword that the metaclass can discover and do the right thing with. that part turned out to be pretty easy. it's storing the data in the desired location that is hard. I'm a MOP noob so I'm sure I just haven't leveled up enough to see the solution.
<leoprikler>The documentation seems to have add-method!, but not much on fields.
<davexunit>the docs are good for an overview but the goops source is the best resource once you know the basics
<leoprikler>Okay, so it seems if you want to define the setter of an accessor, you want to do (define-method (setter accessor) something)
<leoprikler>I suggest following the path that this setter syntax takes inside GOOPS.
<leoprikler>perhaps it invokes a primitive, that you can use from your metaclass
<leoprikler>cross your fingers, that it's also exported
<davexunit>I've done custom setters that way. (define-method ((setter my-accessor) (object <foo>) ...) ...)
<davexunit>that's good for one-off specialization.
<davexunit>thanks for the brainstorm. I'll just keep digging into the source and fiddling after work.
<leoprikler>Hope you get that to work. On another note, what is the rationale behind allowing the asset to change at runtime in your case?
<Sheilong>Is there a way to populate a bytevector with values fom a list at creation?
<RhodiumToad>uint-list->bytevector
<RhodiumToad>or sint-list->bytevector
<leoprikler>there are conversions from lists, as RhodiumToad posted, but if you need to splice them you'll have to trick the reader
<RhodiumToad>or u8-list->bytevector
<davexunit>leoprikler: it's a "development mode" feature so I can, say, edit a tileset in an image editor and have the game instantly update when I save changes.
<davexunit>it's been really useful to have that (when I actually try making a game, that is)
<davexunit>and besides the hot swapping, I like having syntax like (define-asset tileset (load-tileset "foo.png")) for defining all the external assets.
<leoprikler>Interesting. I just abuse Tsukundere's save states :)
<davexunit>whatever works :)
<leoprikler>but yeah, novels are of course very different from RPGs
<davexunit>the 3 big productivity features I have, though in rather primitive form, are 1) live asset reloading 2) emacs-like minibuffer and 3) in-game repl
<leoprikler>sounds rad
<davexunit>I also want to take advantage of goops features to add an inspector/editor where you can click on game objects and see all their fields and maybe even edit them
<davexunit>for those times where it's a lot easier to edit visually than fiddle with numbers in code.
<davexunit>using a metaclass I'll be able to add special slot options that mark a slot as inspectable/editable. goops is very cool. 8)
<leoprikler>I must admit it is, and yet I'll probably prefer handcrafted records for the rest of my life.
<leoprikler>Don't ask me why.
<davexunit>I like those, too :)
*leoprikler → afk for about an hour
*davexunit wishes goops had before/after/around methods like clos