IRC channel logs


back to list of logs

<rlb>lloda, dsmith-work: looks like it's there in newer debs
<rlb> $ dlocate gmp.pc
<rlb> libgmp-dev:amd64: /usr/lib/x86_64-linux-gnu/pkgconfig/gmp.pc
<rlb> $ dpkg --status libgmp-dev | grep Version
<rlb> Version: 2:6.2.1+dfsg-1
<spk121>ok, I pushed a patch for configure so it works like it did before without using the gmp.pc
<spk121>I verified it works on fedora 33 and ubuntu 20.04 so hopefully that works for debian
<spk121>this multi-platform autoconf stuff is always a pain
<spk121>I'm pretty embarrassed that I broke the main branch. If this was $dayjob pre-covid, I'd owe the team doughnuts
<rlb>mmm doughnuts...
<daviid>spk121: you should be proud, not embarrasted, you are doing so much for guile, 'all over the place' ... this lack of pkg-config for mini-gmp, really, we all would have 'falled in the trap', and you fixed it at the speed of light, so really, congratulation for all this work ...
<spk121>daviid: aww, thanks!
<dsmith>spk121: Hah! Another donut protcol.
<dsmith>spk121: So far, so good. got though all the C compiles.
<chrislck>+1 agree with daviid o/o/o/o/ spk121
<dsmith>FAIL: srfi-105.test: curly-infix: (equal? (quote a) (quote ($nfx$ a . z)))
<dsmith>FAIL: srfi-105.test: curly-infix: (equal? (quote a) (quote ($nfx$ a . t)))
<dsmith>FAIL: srfi-105.test: curly-infix: (equal? (quote (a b . t)) (quote ($nfx$ a b . t)))
<dsmith>Expected? (at this time)
<rlb>wingo: vaguely wondered if strports string_port_write might be able to use (and get any potential benefit from) a realloc.
<wingo>dsmith: yeah expected atm
<wingo>rlb: i doubt it; overhead isn't in the strport write function
<wingo>rather it's in all the interactions in the port layers
<wingo>and general VM overhead (poor regalloc, calls are still a bit too expensive)
***apteryx_ is now known as apteryx
<wingo>rlb: while i am thinking about it -- i think there is room for significant speedup in readers if we get "closer" to the port buffers. like for whitespace, you should be able to do (port-drop-while p (lambda (ch) (case ch ...))), which should be able to dig down and operate directly on the port buffers
<wingo>similarly for strings, one should be able to do (port-take-while p pred), which would avoid consing intermediate chars, instead just leaving them in the port buffer
<wingo>some questions to resolve relative to concurrent reads but i think you see where i'm going -- in the end in many cases we could bottom out to (utf8->string buf start len)
<wingo>i.e. no intermediate character collection
<wingo>would have to add args to utf8->string of course ;)
<wingo>for iconv i think you would need to use the same strategy as we currently have tho
***drmeister_ is now known as drmeister
***hunzelstrunz_ is now known as hunzelstrunz
<wingo>obvs if we change string representation to utf8 then that means making a token will usually be just a number of predicate invocations, then malloc + memcpy
<chrislck>there's no sscanf in guile :-/
<wingo>on the other hand, there are no sscanf vulnerabilities in guile ;-)
<chrislck>exactly :)
<lloda>thanks for the quick fix spk121
***DadeBonetti1 is now known as DadeBonetti
***roptat is now known as roptat_
***roptat_ is now known as roptat
<dsmith-work>Thursday Greetings, Guilers
***efraim_ is now known as efraim
<ArneBab>wingo: to test the reader with a few edgecases, you could run the wisp testsuite
<wingo>if there are any edge cases guile should care about, they should be in the guile test suite i think
<wingo>would you mind running the wisp test suite with guile from git ?
<ArneBab>can I get that directly from guix?
<ArneBab>is guile-next already guile from git?
<wingo>probably not the latest
<wingo>you check it out from git, and then to build:
<wingo>guix environment guile --ad-hoc autoconf automake texinfo gperf libtool gettext readline -- autoreconf -vif
<wingo>guix environment guile --ad-hoc autoconf automake texinfo gperf libtool gettext readline -- ./configure
<wingo>guix environment guile --ad-hoc autoconf automake texinfo gperf libtool gettext readline -- make -j40
<civodul>we're missing guile-next, it'd be nice to have
<civodul>we could use --with-branch & co.
<ArneBab>thank you!
<ArneBab>Why don’t we have guile-next anymore?
<ArneBab>/home/arne/eigenes/Programme/guile/meta/guile --version → guile (GNU Guile)
<ArneBab>Test suite passes
<ArneBab>wingo: how can I verify that this has the new reader?
<spk121>wingo: readers differ about what to do when reading expressions that are just one single-quote character or just one backtick character
<spk121>new reader is probably more correct. error instead of (quasiquote <eof>)
<spk121>wingo: same for syntax and quasisyntax and unsyntax on lines by themselves
<spk121>also, there is this "#tR"
<apteryx>what can I use to discover the target a .go file was built for? the 'file' utility on a .go doesn't yield information about that
<apteryx>perhaps the architecture flag of the ELF? e.g., objdump file.go | grep architecture -> architecture: UNKNOWN!, flags 0x00000150:
<soda__hobart>blargh, i cannot figure out why i can't use dynamic-link with this shared library i created. it keeps telling me file not found, but i know that i used the correct absolute path. can you not dynamic-link with a shared lib that defines SCM procedures with scm_c_define_gsubr?
<soda__hobart>i compiled another file in my project as a shared lib, and dynamic-link worked just fine--the main difference i can see is that the lib that worked properly didn't include libguile
<spk121>soda__hobart: the infamous 'file not found' error is a famously unhelpful error message from libltdl. What it usually means is that a dependency of your shared library is not in the shared library path. if you re-run, add the environment variable LD_DEBUG=all, somewhere near the bottom of all that spew will be your answer
<spk121>likewise, you could try running with 'strace', e.g. strace guile myfile.scm
<soda__hobart>libtldr ;)
<dsmith-work>Which should be much improved as of Guile 3.0.5
<dsmith-work>(the file-not-found nonsense)
<soda__hobart>i'm using guile 3.0.5
<dsmith-work>Hm. Maybe my version memory is mixed up.
<rlb>wingo: regarding utf8 - would you think that (at least non-ascii) strings might add a byte-count(s) in addition to the existing char count(s)? (that's one option I was toying with here -- adding a byte count to non-ascii substrings and maybe for the (sub)string offsets).
<soda__hobart>i'm pretty sure that cmake is responsible for messing everything up haha
<dsmith-work>There are changes in git to no use libltdl (libtldr, nice!)
<soda__hobart>cronenberg's existenz is on tv! fun movie to do some game programming to :)
<civodul>fun fact: if you do ",break current-error-port" or similar, you set a breakpoint on all the parameters, not just that one
<civodul>(which makes sense in hindsight, but that got me surprised)
<spk121>wingo: also try "#fa"
<soda__hobart>so i'm seeing this: "./ error: symbol lookup error: undefined symbol: _ZTIN2sf6SocketE (fatal)" in LD_DEBUG=libs
<spk121>soda__hobart: that looks like a C++ mangled name to me. I could be that you've mixed C and C++
<soda__hobart>ah, yup that is the case
<soda__hobart>it probably doesn't like the namespaces?
<soda__hobart>dang it, now i got a name collision haha
<soda__hobart>libguile does not love namespaces so much?
<nly>Does this output site-dir? 'pkg-config --cflags --libs guile-2.2'
<spk121>nly: pkg-config guile-2.2 --variable=sitedir
<spk121>fuzzing the reader has been fun. here's the rest of the nonsense I found
<manumanumanu>I remember that we were talking about applicable structs not too long ago. I lost my logs though. Where should I go digging to find out how to use it?
<lloda>anything you call from Guile should be extern "C" soda__hobart
<lloda>i have a library that uses applicable structs. e.g.
<lloda>i asked wingo for how to use it so that's your best bet
<civodul>"newra" heheh :-)
<justin_smith>manumanumanu: oh wow, I was interested in applicable structs a while back, but I didn't even know that was the correct terminology (in clojure it would be defrecord implementing IFn)
<rlb>manumanumanu: it may be sufficient to add <applicable-struct> as a superclass and then (slot-set! 'procedure (lambda (x) ...)) in an initialize method.
<manumanumanu>can I do it without goops?
<lloda>i don't use goops so yes
<manumanumanu>lloda: thanks a thousand times! that is exactly what I want.
<lloda>my pleasure!
<rlb>And of course it won't help right now for things like <symbol> or <keyword> (which a clojure dialect also needs -- i.e. no way currently to make existing types "applicable").
<manumanumanu>you could do it like racket using an %app macro?
<manumanumanu>which would incur a dispatch cost, of course
<wingo>we already have a dispatch cost fwiw
<wingo>like applicable structs and applicable smobs aren't free
<wingo>the same mechanism could allow keywords to be applicable
<leoprikler>applicable lists :)
<manumanumanu>i didn't mean like that: I was telling RLB to use something akin to %app to sense whether something is in the current module and dispatch anything in there at runtime
<manumanumanu>since something like clojure-on-guile probably already has it's own reader it shouldn't be too much of a fuzz
<manumanumanu>together with syntax-local-binding it should be about 100 LOC max
<manumanumanu>not counting the hard stuff
<manumanumanu>:D :D
<manumanumanu>the more I think about it the less I want to implement it
<leoprikler>btw. since smobs have been deprecated for a while now, when will applicable smobs be replaced by applicable foreign objects?
<manumanumanu>how do you mean applicable foreign objects?
<wingo>leoprikler: truly, the galaxy brain take :)
<wingo>wrt applicable lists
<leoprikler>it's like Scheme within Scheme!
<lloda>fortran uses () for indexing arrays
<lloda>nobody thinks that's bad
<leoprikler>doesn't octave do that too?
<wingo>so smobs & foreign objects.... dunno. honestly i think both will coexist for another 10 years at least :p
<lloda>yeah octave is based on fortran
<lloda>well m****b but you know
<lloda>same thing
<lloda>it makes a lot of sense to think of certain data structures as functions
<leoprikler>All data structures are functions.
<leoprikler>Booleans and integers included.
<wingo>ah booleans, the best data structure
<manumanumanu>wingo: btw, the patch I submitted with an updated vector-map cuts about 10% from the quicksort.scm benchmark from ecraven.
<manumanumanu>and doing what some other schemes do and not check for cycles in (map ...) is a pretty good strategy over all :D :D
<wingo>manumanumanu: i will apply it!
<wingo>need to make a guile-devel sweep
<wingo>just finished with the reader stuff. only a couple more NEWS things to flesh out
<lloda>i still have to change all of my 20 year old code to use fobs instead of smobs
<dsmith-work>No more smobs! Oh no! I guess it must happen sooner or later. Probably *much* later.
<manumanumanu>just out of curiosity I am now running some benchmarks just to see how much better guile fares if I don't check for equal length lists or cycles.
<manumanumanu>not done yet though
<manumanumanu>I need to investigate further, but some speedups for sure - not surprising as none of the benchmarks make heavy use of map