<rlb>lloda, dsmith-work: looks like it's there in newer debs <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 <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 ... <dsmith>spk121: Hah! Another donut protcol. <dsmith>spk121: So far, so good. got though all the C compiles. <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))) <rlb>wingo: vaguely wondered if strports string_port_write might be able to use (and get any potential benefit from) a realloc. <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 <wingo>on the other hand, there are no sscanf vulnerabilities in guile ;-) <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
***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>is guile-next already guile from git? <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 <ArneBab>Why don’t we have guile-next anymore? <ArneBab>/home/arne/eigenes/Programme/guile/meta/guile --version → guile (GNU Guile) 3.0.5.92-bd93e <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 <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 <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) <soda__hobart>so i'm seeing this: "./libmuncherguileapi.so: 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++ <nly>Does this output site-dir? 'pkg-config --cflags --libs guile-2.2' <spk121>nly: pkg-config guile-2.2 --variable=sitedir <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 asked wingo for how to use it so that's your best bet <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>lloda: thanks a thousand times! that is exactly what I want. <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"). <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 <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>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? <wingo>leoprikler: truly, the galaxy brain take :) <lloda>fortran uses () for indexing arrays <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>it makes a lot of sense to think of certain data structures as functions <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>I need to investigate further, but some speedups for sure - not surprising as none of the benchmarks make heavy use of map