<spk121>civodul: ok I tried building with mini-gmp. AFAICT, only one missing function, mpz_get_d_2exp, which one could approximate using mpz_get_d for the mini-gmp case <spk121>no time to day to write a func to convert mpz_get_d to mpz_get_d_2_exp, so that's all I've got ***chrislck_ is now known as chrislck
<chrislck>spk121 - thx for your work -- following with great interest. what's wrong with gmp that requires mini-gmp? what are the limits of mini-gmp? <chrislck>spk121 - are you targetting mingW 32-bit only? <spk121>chrislck: as I understand it, there are functions that one call in gmp that changes its behavior, so if a program loads guile (expecting behavior #1) and gnutls (expecting behavior #2) hijinks ensue. Not sure of the details. But I got interested in it because it would get rid of a dependency, and these dependencies are a bit of a pain when trying to port Guile <spk121>mini-gmp has no assembly and may be as much as 10 times slower for some cases <spk121>Plus it is missing that one function that we use mpz_get_d_2exp <mwette>I've had issues with libgnutls for guile as well. Can I ask what issue is going on w/ guix? <mwette> I see; the memory allocation issue. <mwette>So one ugly workaround based on what I often use for loadable .so's is to do something like this: build libgnutls.a and libnettle.a w/ -fPIC then link guile-gnutls.so with something like "ld -o guile-gnutls.so guile-gnutls.o libgnutls.a libnettle.a". (This allows me to distribute the .so to a few close friends w/o all the dependent libxyz.so's.) <RhodiumToad>arguably it's extremely rude for an embedding library like guile to mess with the global state of a library that the app itself might be using <rlb>chrislck: the issue is that we currently change gmp to use libgc for allocation (good for performance) but that may then lead other things (i.e. libraries) in the process to unknowingly allocate (directly or indirectly) pointers libgc that they then stick into normally malloced blocks. libgc won't know anything about them, and so won't sweep when collecting. (I think.) <dadinn>I am looking for a built-in / SRFI function which does something similar to this bda (hash ret) <RhodiumToad>called with a key and some variable number of hashtables, you want to return just the first match? <RhodiumToad>(define* (hash-ref* key #:rest hash-maps) (any (cut hash-ref <> key) hash-maps)) ;; any is from srfi-1, cut from srfi-26 <dadinn>if I macro-expand it into nested hash-ref (with defaults) calls, that wouldn't be the same... bacause of eager evaulation, it would try to evaluate on all hash-maps <dadinn>this way with the fold, it quits on the first hash-map it finds a result <dadinn>hmm, the or thing doesn't sound bad actually! <RhodiumToad>the hard part of the macro version is to not multiply evaluate the key <dadinn>I am not too much of a pro with define-syntax :/ <dadinn>what does the <> stand for in the any example? <RhodiumToad>(cut foo <> bar) is shorthand for (lambda (x) (foo x bar)) <dadinn>RhodiumToad: thank for the recommending `any` it's actually much nicer <RhodiumToad>a macro version could avoid evaluating unneeded hash-maps expressions, fwiw <dadinn>RhodiumToad: and I already depend on srfi1 so why not <RhodiumToad>(define-syntax hash-ref* (syntax-rules () ((_ key hash hash* ...) (let ((key key)) (%hash-ref* key hash hash* ...))))) <RhodiumToad>(define-syntax %hash-ref* (syntax-rules () ((_ key) #f) ((_ key hash hash* ...) (or (hash-ref hash key) (%hash-ref* key hash* ...))))) <dadinn>hmm, I don't really understand how syntax-rules works :/ <dadinn>it does some pattern-matching thing and then the ... always confuse me :P <RhodiumToad>here the %hash-ref* one is the one that does the work, the other one just wraps in a (let) to avoid multiple evaluation <RhodiumToad>and (%hash-ref* key hash blahblah...) expands to an (or ...) expression <RhodiumToad>so the result is like (or (hash-ref key hash1) (or (hash-ref key hash2) (or (hash-ref key hash3) #f))) <dadinn>hmm, but what if your hash-ref* like this: (let ((or #nil)) (hash-ref "hello" map1 map2 map3)) ? <dadinn>how does it avoid variable the variable capture by or? <RhodiumToad>the "or" in the macro means the binding in effect for or at the time the macro is defined, not at the time it's expanded <dadinn>RhodiumToad: but don't you have to declare in the syntax-rules somewhere that or shouldn't be captured? <dadinn>RhodiumToad: if i remember correctly define-syntax takes some argument of symbols... and I don't know what it's for :/ <RhodiumToad>the () in those syntax-rules is a list of identifiers that are to be treated as syntactic atoms, like "else" or "=>" are <dadinn>RhodiumToad: yeah that's what I meant... what does "syntactic atom" mean? <dadinn>RhodiumToad: what are they used for? <dadinn>ah I see, so you declare them, so that they don't throw an error as undefined symbols in the lexical scope, but you can use them for pattern matching! <RhodiumToad>yes, and they match themselves literally, rather than binding the way that other symbols in a pattern match do <dadinn>ah, maybe not just to not throw an error as undefined, but to don't actually capture anything from the context where the macro is defined? <RhodiumToad>(_unless_ the symbol has a different lexical binding in the macro definition and the point of expansion, and then they don't match) <RhodiumToad>the point is that unless you deliberately break the hygiene rules (e.g. with datum->syntax etc.), every symbol in the macro refers to its lexical binding _where the macro is defined_, not where it's used <dadinn>I am more used to gensym+syntaxquote common-lispy style, but with namespaces (a'la Clojure) <dadinn>when you say "every symbol in the macro" you mean: every symbol in the macro *definition*? <RhodiumToad>and the symbols in the macro arguments always refer to their lexical bindings at the point of use <RhodiumToad>i.e. it all Just Works and you never have to worry about stuff being accidentally bound to the wrong thing <RhodiumToad>(except for a small issue with top-level identifiers, for which you can read the gory details in the docs) <dadinn>what do you think about Clojure's macro system? It is more common-lisp style, but due to namespaces, it kinda achieves hygiene, no? *RhodiumToad not clojure expert *rlb would say (very roughly) that clojure is pretty close to common lisp or guile's define-macro macros, but the automatic symbol expansion (i.e. namespacing) handled maybe surprisingly by the *reader* in clojure jvm, helps in many cases make sure you get the binding you probably meant. <dadinn>anyways, thanks for the `any` suggestion... it definitely looks much better: (define* (hash-ref* key #:rest hash-maps) <rlb>But in a lot of cases, I'd think scheme syntaxes are likely a lot "better". <RhodiumToad>dadinn: the thing I'd be wary of there is that rest args always end up consing a new list. <RhodiumToad>the advantage of a macro here is that you can have a variable number of hash-maps without needing to cons a list on every single call <rlb>(many of clojure's macros written as scheme syntaxes) <rlb>Though some of it you'd want to ignore for a pure scheme version of them (i.e. the support for set/map/vector literals). <RhodiumToad>I wrote a set of macros here a while back for someone who wanted a cartesian-product apply / fold for variable numbers of lists; avoiding consing was a key requirement <dadinn>RhodiumToad: what do you mean by consing? Does it have too cons together the args 1-by-1 to get a list argument? <dadinn>is this some behind-the-scenes detail? <RhodiumToad>i.e. a list which is guaranteed not to share structure with any other, and therefore all the cons cells have been newly allocated <dadinn>hmm, true... never thought about it! So on every function call, a new list is created? <RhodiumToad>premature optimization is the root of all evil, and so on, but it's still worth bearing in mind the possible overhead <dadinn>so if I would map trhough a list of a trillion triplets of hashmaps, calling my hash-ref* on each triplet, then that would create a trillion lists :/ <dadinn>yeah, I think I will put the premature optimization genie in the bottle for now... if it ever gets out, I know how to put it back ;) <rlb>daviid: hmm, does that file exist? <rlb>here it's in libltdl-dev <rlb>(at least according to dlocate) <daviid>rlb: i have libtool-dev:amd64 installed, it is not part of the package it seems <daviid>dpkg -L libltdl-dev:amd64 -> ... /usr/lib/x86_64-linux-gnu/libltdl.so ... but no .la <daviid>this is a 'new' error, never happend before <daviid>and the error disapeared, 'alone', no idea what happened <daviid>but running make a few times failed, then it worked again <daviid>i just did run another aptitude update U, g, g, but didn't see anything related to this <daviid>the file still does not exist, but the error disapppeared ***chrislck_ is now known as chrislck
<fnstudio>hi all, `guix environment --container ...` gives me an error (unprivileged user cannot create user namespaces), which i think is expected since i'm running guix on debian <fnstudio>i understand this can be fixed by `echo 1 > /proc/sys/kernel/unprivileged_userns_clone` <fnstudio>ooops sorry, this was meant for #guix... <ArneBab>in the current Guix wisp seems not to work. It installs its language files in .guix-profile/share/guile/site/3.0/language/ — should this be guile/3.0/language? <civodul>that matches the GUILE_LOAD_PATH spec of guile ***amiloradovsky1 is now known as amiloradovsky
<rlb>wingo: any notable likely perf difference between a char-set:contains?, memv? and a case guard? <rlb>(for say ~1-20 possibilities) <leoprikler>ArneBab: guile vs. guile/site is to distinguish between guile itself vs. other packages built on guile <rlb>Are you running the build as root? <rlb>If so, then random guess -- maybe something in the g-golf build is messing with that .la file. <rlb>Also, what version of libltdl-dev do you have (i.e. dpkg --status libltdl-dev) <rlb>and what does "dpkg -S libltdl.la" say? <daviid>dpkg -S libltdl.la -> dpkg-query: no path found matching pattern *libltdl.la* <daviid>rlb: so, if i run make clean, make fails, then another make incantation runs fine <daviid>i am trying to get some help on #debian-next, but they didn't answer my yesterday's msg, nor the ones i sent today ... (til now, but there are generally very responsive and quick ... let's see) <rlb>hmm, I have 2.4.6-14 -- let's see if we can see what changed... <daviid>it is really strange, that 'make clean', 'make' fails, then 'make' again pass <rlb>Not sure what that means wrt expected usage. <daviid>RhodiumToad: it always look strange, to me, that something fails, then pass ... <rlb>I'm very rusty wrt libtool, la files, etc. -- do you have to have it? And if not, does something else need adjustment? <daviid>with no manual changes in between i mean ... <rlb>(I'm hoping the removal was approprate/viable.) <daviid>i have zero knowledge about all this <rlb>Or rather, I suppose either g-golf or something else needs an update, or that removal isn't viable... <rlb>No idea offhand which one. <rlb>daviid: if you're in a hurry, and want to defer, I suppose you might be able to grab -14 from snapshot.debian.org and manually install it (or set up the relevant sources.list). <spk121>daviid: if you recreate the error using "make V=1" it could provide more information <rlb>daviid: just a random guess -- I wonder if there's any chance that you might need newer versions of the relevant auto* sources and/or an "autoreconf -fi" or similar, i.e. if libtool changed to support not having .la files or something (assuming this isn't just currently unworkable situation). <rlb>and/or a newer libtool, etc. <rlb>(Completely wild guess...) <spk121>daviid: can you point me to the makefile.am file, so I can take a look. Sorry for jumping in at the end of this conversation... <daviid>rlb: i did run autoreconf -vif, it doesn't seem to solve the problem <daviid>rlb, spk121 - tx both of course, i am just 'blind', and #debian-next keep quite :) <rlb>Another option might be to file a bug against libltdl-dev and have a discussion there -- since I don't see any rationale in the changelog entry. Of course it might also be that g-golf could change. And/or if there's a repo for the deb, might look at the recent commit messages. <rlb>(old discussion, maybe or maybe not related) <daviid>rlb: i don't understand the last part of the setnence above '... Of course it might also be that g-golf could change. And/or if there's a repo for the deb, might look at the recent commit messages.' - and wrt reporting, i feel totally unconfortable because i don't understand enough, even to just express 'things' <rlb>I just meant if libtool has a repo on say salsa.debian.org, and the maintainer keeps it up to date, might be some additional information in the recent commits leading up to -15. <rlb>But I didn't see a Vcs header in the --status output, so not sure if there is a repo. <spk121>daviid: I have a possible fix to test. In your Makefile.am for libg-golf, you're using the _LIBS target. Try swapping _LIBS for _LIBADD ***Noisytoot is now known as [
***[ is now known as ]]
***]] is now known as [[
<spk121>so it would be libg_golf_la_LIBADD = $(GUILE_LIBS) etc ***[[ is now known as Noisytoot
***Noisytoot is now known as [\
***[\ is now known as Noisytoot
<daviid>spk121: it didn't seem to solve the problem <daviid>after i changed, fiwiw, i did clean, run autoreconf -vif, configure and make <daviid>spk121: so, only one change right? here is what i have <daviid> $(GUILE_LIBS) $(GLIB_LIBS) $(GOBJECT_LIBS) <daviid>then the autogen, configure make danse <daviid>spk121: rlb, tx again, have to go afk, bb in an hour or so ... tx for the help, if any other suggestion pings while away, yoiu may write, i'll read when back ... <spk121>daviid: sorry, out of ideas. Good luck! <ArneBab>leoprikler, civodul: thank you for your answer! I’m helping someone find out why wisp does not work. I now turned to strace to dig deeper: strace wisp |& grep wisp *wingo has "read" port to scheme almost done, respecting reader options and everything <ArneBab>wingo: worried question: does wisp still work? <wingo>ok zzz, see yall tomorrow @ fosdem <wingo>ArneBab: the bits that are in read.c should still be there <wingo>i assume there are tests; haven't banged at this thing in anger yet