IRC channel logs


back to list of logs

<RhodiumToad>rlb: it's only capturing the closure on each object creation?
<oni-on-ion>$ guile \n guile: symbol lookup error: /usr/local/lib/ undefined symbol: GC_move_disappearing_link
<RhodiumToad>build mismatch between guile executable and library?
<oni-on-ion>hmm. it was all just installed together from git a couple days ago and workign fine. will have another clean compile+install and see what goes on
<oni-on-ion>ok so i did 'make uninstall' -- then apt-get install guile-3.0 because i realise its provided in debian now. however, same error ! is it ldconfig ?
<oni-on-ion>guile-3.0: symbol lookup error: /usr/lib/x86_64-linux-gnu/ undefined symbol: GC_move_disappearing_link
<mwette>I get "ldd guile" generates " => /lib64/". How about you?
<oni-on-ion> => /usr/local/lib/ (0x00007f896fb5d000)
<oni-on-ion>im truly stuck. it was working the other day and i havent done any system stuff since then except reboot
<RhodiumToad>oh good point, that symbol is in libgc and not guile itself
<RhodiumToad>you haven't reinstalled or removed the boehm-gc package, whatever it gets called on debian?
<RhodiumToad>maybe try nm -D /usr/local/lib/ | grep GC_move_disappearing_link
<mwette>the symbol is in /usr/include/gc/gc.h
<mwette>so guessing it's in
<mwette>and it's found using "nm -D"
<dustyweb>hello #guile
<RhodiumToad>greetings to you
<drakonis>greetings, friend.
<dustyweb>do I remember correctly that recently there's a more simple guile build / packaging tool? (not guix, more like something simple-guile that's an alternate option to automake)
<dustyweb>I think civodul told me about there being something newer in the last couple of years
<drakonis>looks like that one's up on gsoc?
<drakonis>yep, its a gsoc project that has been up in the air for a few years?
<dustyweb>oh maybe
<dustyweb>what's its name?
<drakonis> no name yet
<dustyweb>oh I think that's not what I meant, that one's more using guix as a replacement to autotools
<drakonis>ah, i see.
<wleslie>are you thinking of guild?
<drakonis>guild hasnt been touched in years
<drakonis>targets guile 2.0?
<dustyweb>maybe, though yeah guild hasn't been touched in some time afaict so not so sure...
<daviid>dustyweb: it's akku i beleive
<rlb>RhodiumToad: sure, but with persistent data structures, every operation creates a new instance, i.e. adding a new key/value to a persistent hash-map, etc.
<rlb>So you have to allocate the new "spine" of the hash map, *and* the new closure to handle the #:procedure.
<RhodiumToad>ah, I see what you mean
<RhodiumToad>I don't know the internals well enough to know whether that's a reasonable change.
<rlb>*If* there really is sufficiently more overhead (don't know), I wonder if something like a #:procedure-self or something might be an acceptable addition (perhaps with a better name).
<rlb>or even a different class for that, I guess.
<RhodiumToad>right, the question is how feasible that is in terms of the underlying implementation.
<RhodiumToad>because "applicable structs" are a pretty low-level concept
<rlb>yeah, though at the time you're "applying" them, I'd imagine you have the instance pointer, so offhand, I'd guess the bigger question would be whether it'd introduce an unacceptable extra predicate into a hot path, or whether we don't have any more tag-bits, or something.
*rlb speculates wildly
<RhodiumToad>there's some code to do with smobs that does something like the right thing.
<rlb>hah, fixing the guile keyword hashing issue may now have exposed a *different* bug in pfds.
<RhodiumToad>looking at the apply-non-program operation in the VM
<RhodiumToad>for an applicable struct, the struct is simply replaced by the value of its procedure slot, which means the instance pointer is lost
<RhodiumToad>but for an applicable smob, the procedure value is inserted rather than replaced, which leaves the instance as the first arg
<rlb>I finally forked pfds and created a branch with some changes I want, but what's the preferable thing to do for a more conservative set of changes that others might want? i.e. should I make my "master" branch that, or name it something else,, so that my master could always in theory track the upstream master, if it becomes active again?
<rlb>(i.e. the "changes I want" includes an egregious hack to handle the testing (for now) just with srfi-64, rather than wak... -- and is definitely not suitable for broad use)
<rlb>RhodiumToad: oh, and the #:procedure issue isn't critical for me right now, fwiw, I have a workaround, but I appreciate the discussion.
***apteryx is now known as Guest77775
***apteryx_ is now known as apteryx
<civodul>hi wingo, hi Guilers!
<chrislck>does anyone know how exactly to import/load srfi-180 json work-in-progress? confused about the various .scm .sld files
<weinholt>chrislck, i haven't tried it myself, but i would take the .sld file and rename it to srfi/srfi-180.scm, change the library name to (srfi srfi-180), then use 3.0 and run guile --r7rs
<chrislck>hmm. will do. much fragmentation and confusion for users.
<chrislck>so will it be incompatible with guile 2.2?
<chrislck>or, will it be compatible with non-r7rs guile?
<weinholt>chrislck, since it's just a reference implementation, i expect that someone will eventually port it to guile
<chrislck>ok. thx for pointers. i want to experiment aiming to use in gnucash instead of guile-json. gnucash devs won't accept a weird library.
<oni-on-ion>RhodiumToad, mwette : hey guys - sorry i slept. i did nm -D for GC_move_disappearing_link and nothing shows
<kbw2222>i bumped into a line in a guix package definition (? string? config)
<kbw2222> and I can't figure out what the first ? is. It doesn't seem to be bound
<sneek>Welcome back kbw2222, you have 1 message.
<sneek>kbw2222, NieDzejkob says: You can do something like (package (inherit some-other-package) (native-inputs `(("my-new-input" ,hello) ,@(package-native-inputs some-otherr-package))))
<kbw2222> to anything when i try it in the repl and i can't find any reference to
<kbw2222> a predicate called just ?. Anybody can tell me what it is?
<wingo>kbw2222: probably that's a part of a "match" clause
<wingo>i.e. part of a CLAUSE in (match EXPR (CLAUSE BODY ...) ...)
<chrislck>kbw2222: this is the best tutorial I've found:
<wingo>nice link chrislck :)
<chrislck>yeah the guile manual on match is rather anemic
<kbw2222>ah, it is. thanks, I'm still new to guile and it's pretty hard to look up for such terse terms
<mwette>oni-on-ion: odd, I don't know what to make of that
<shader>do y'all have any examples, tutorials or references on how to wrap a C++ library for use in a guile module?
<shader>I'm specifically thinking of
<shader>I suppose another option would be to implement their spec from scratch...
<str1ngs>shader: would use a guile extension. but don't manually create the procedure defines snarf them and use SCM_DEFINE macros
<str1ngs>I would*
<shader>so, manually write the wrapper according to the example, but use SCM_DEFINE and the snarfing tool to generate the code that loads the definitions?
<str1ngs>that's right
<str1ngs>here's a C++ example
<str1ngs>and the
<str1ngs>shader: that code is no longer used. but it might be useful for a C++ example
<shader>str1ngs: thanks
***Server sets mode: +nt
<rlb>ok, so I'm not completely positive, but unless I'm misunderstanding things a good bit, pfds hamt's aren't really reliable right now. I've found and fixed (assuming my understanding of the data structure is correct) some more things that cause set and ref on even fairly simple maps to do the wrong thing.
<rlb>Though I'm also a bit concerned that my expectations wrt the masking/bitmaps/etc. might be slightly different, and so in some cases, I'm just changing the code to match my approach rather than the original one...
<rlb>What I'd really like to add is some generative testing for hamts, because the existing tests only test some very simple maps.
<wingo>rlb: did you try fash.scm ?
<wingo>gotta change that name, unfortunately fascism is a thing again :P
<rlb>wingo: no -- didn't know about it.
<rlb>any idea offhand about whether it might just be preferable to pfds hamts? i.e. wondering if I should just try switching, or it's worth trying to finish up fixing pfds...
<rlb>(pfds hamts are 32-way persistent maps, i.e. 5-bit mask of the hash for the content at each level, but I'm not sure it's handling collisions the way I'd expect in some cases)
<rlb>(trie-ish bsed)
<wingo>fash is pretty much the same i think
<wingo>but may be faster. haven't checked recently
<rlb>ok, thanks much -- perhaps I'll give it a try. Is it just "copy paste" right now, or is there some more official repo for the code?
<wingo>naw it's copy-paste :P
<rlb>ok, thanks again.
<rlb>wingo: are transient and persistent used there in the same sense as clojure? i.e. you can convert to a transient, do some bulk work, and then convert back?
<rlb>hmm, does fash have any kind of dissoc (i.e. delete)?
<jcowan>wingo: If it's a HAMT, then you could change it to hamt
<jcowan>or even if it walks like a hamt, it could be hamtoid