<mwette>civodul: yea, pretty cool quote; guix will generate more lisp fans, for sure <rbarraud>[While building guix on high-core-count/huge-RAM b0[r]xen] <rbarraud>I looked at the [archived mailing-list] threads around it to some extent, didn't see a resolution... to what extent has it been investigated? Who is/was looking into it? <rbarraud>Confession: I have been [slooowly] thinking/working on an x86-64 [eventually] on-the-metal Scheme for a while... thinking Guile 3.x might make it moot. <rbarraud>..but intending to bootstrap it by some means or other [fair or foul? ;-) ] <rbarraud>To my mind, Scheme [thru Racket et al, and now from the looks of it, Guile] subsumes pretty much everything else in the languages space, semantically. <rbarraud>In my mind I anecdotally/vaguely (?) feel some sort of congruence with FORTH at some level too. <rbarraud>[Yeah I know, the Devil is in the Details :-)] <rbarraud>I've had it running the SICP metacircular evaluator [to some extent at least], so kinda getting there... between dealing with Real Lif Issues [MMMV :-/ ] <rbarraud>Anyhoo I'll say no more here about it at this stage... since it's essentially related but strictly OT. <rbarraud>I see that 3.0.[01] has some included language-y bits ... incl brainf*** <wleslie>from the start guile was supposed to be a multi-language runtime <rbarraud>Can't only be as a bootstrap mechanism for building Guile per se ... as I find it hard to imagine it actually depends on anything useful written *in* BF :-) <rbarraud>That confirms mu hunch re subsumption of languages :-) <wleslie>well, there was this point the maintainers hit where they thought, we don't really have any good examples of how to do this in-project <rbarraud>So it's somewhat vestigial at this point? <rbarraud>...potentially something which people could take up again should Guile be sufficiently popular? <wleslie>" that lived on guile at the time, in the form of lilypond, but guile broke lilypond significantly with the 2.0 release <wleslie>so guile needed a good "here's how to do it, this is the way we support building different languages" <rbarraud>And on FreeBSD at least, you can't have 1.8.x and 2.2.x at the same time - @ least not using the vanilla pkg's <wleslie>my understanding is that the small included languages are a sort of sample for how to integrate <wleslie>and a bit of a test suite for compiler changes <rbarraud>I shall explore it some more in non-[LazyIRC] mode then :-) <rbarraud>Another Q for any takers: What is the relationship between MIT Scheme and Guile, both in terms of the codebase, and personnel (teams, leadership, philosophy) from the POV of denizens in here? <wleslie>guile is effectively a large language, with a good C integration story and modern compiler <rbarraud>Is MIT/GNU Scheme still being maintained ? Separately from Guile? <rbarraud>I'm more aware of MIT-Scheme Hx, looked fairly intensively at it... but not sure what the 'modern'/current situation is for it. <rbarraud>Apologies if this is not the place to ask :-/ <wleslie>tbh I'm actually quite ignorant of the latest in the MIT/GNU Scheme space, but it looks like it's had recent fixes and updates <rbarraud>So presumably there'll be an active MIT-scheme IRC channel... ***jonsger1 is now known as jonsger
<ZombieChicken>Is 3.0 compatable with 2.2? Just want to know if there are any breaking changes <wleslie>Goops classes are not redefinable by default, so that's at least one breaking change <dsmith>rbarraud: I've noticed parallels between Scheme and Forth too. Not so much at the language level. <dsmith>rbarraud: I can't really put it into words very well. It's like how you approach thinking about solutions. <dsmith>IN both, you end up writing some kind of domain-sepecific language, and work the problem domain with that. <rbarraud>But there are some more basic congruences. <rbarraud>OTOH there is no intrinsic (necessary) equivalent of FORTH's data stack <rbarraud>...but there could be an implementational correspondence. <rbarraud>I see Andy W's comment (from 2009) re gdb et al (and debuggers generally?) not being able to deal with a non-C-style interleaving of control-flow and data stacks... <jcowan>The mutable-stack view of Forth has a dual: the purely functional view in which all Forth words take a stack as their only argument and return a stack. <jcowan>I'm a pretty good Scheme programmer, a terrible Forth(-like) programmer, but I did write a Forth-like (Joy) in Scheme. <rbarraud>My Scheme 'plan' if you can call it that, is/was going to experiment with that congruence, so I need to find out whether he is right or not. <jcowan>where a Forth stack is just a list <rbarraud>I'm just about trembling - recognized the name... <Humbled/> <rbarraud>I shouldn't be I guess... While not in the UeberKlass, I have earned my neckbeard ;-) <rbarraud>And have a supply of nickels at the ready ;-) <rbarraud>I would think the implementational difference would amount to whether one chases a list to walk the (synthetic) stack(s) <rbarraud>jcowan: BTW as an aside, a friend (now working in .ca for Amazon) and I *almost* met Slave when he was in Wellington... we flew down from AKL. He blew us off :'( <rbarraud>We had a good trip though, despite that. <rbarraud>I'll remind him if I ever do get to meet him :-/ <rbarraud>...so anyhoo, the assertion that it's impossible/impractical for debuggers (gdb specifically?) to grok a non-C-style stack fpr Guile bewilders me a bit. <rbarraud>[ADHD moment: Wonders whether I should call Seth Green and ask whether Robot Chicken wanna make an episode of Celebrity DeathMatch with Factor vs. Julia...] <jcowan>The only people who have to *earn* a beard are transmen. Everyone else either doesn't get one or just has to let it happen. <jcowan>anyhoo, I have no idea who Slave is <rbarraud>Perhaps I've earned the right to retain it though :-) <rbarraud>"Two kinds of people have no beards: Women and Boys. I am neither" ;-) <apteryx>how do I sort strings in decreasing length? <apteryx>ok, this works: (sort '("/" "gnu" "/gnu/store") (lambda (x y) (< (string-length y) (string-length x)))); anything simpler? <apteryx>err, decreasing length would be a string>? <rbarraud>jcowan: Yeah sorry, I kinda misplaced the links... been a while. <jcowan>In my case, my wife was for it, which seems to be unusual in the US. When I talk to other men about why they don't wear beards, they always point to their significant others <spk121>All the young male techies in my part of Los Angeles seem to be rocking a constant 7-day stubble. <rbarraud>Mine prefers [well preferred, I'm not there at the moment :'( ] me to have it but not too long. <rbarraud>I suspect many of the SO's have never gone beyond the short-term local optimum. <rbarraud>Any relation to Andrew, the rally driver? <rbarraud>He drove a Mini in NZ to great effect back in the day... <rbarraud>...and not one of the ersatz BMW modern knockoffs either :-) <rbarraud>For my part re not-mainstream langs, I'll confess to confusing Julia with Joy <rbarraud>Joy is I believe a FORTH-like / contatenative lang <jcowan>rbarraud: From and in the U.S. My grandfather immigrated from Ireland (native Irish, not Ulster Scots). <jcowan>Cowan is Mac Eoghain, the son of Owen, and appears in both Ireland and the Scottish Highlands. <jcowan>Joy is very like Forth except that instead of gotos it has substacks. <rbarraud>French by way of England (Huguenot exodus, 1704) <rbarraud>...and I feel kinda stranded down here :-/ <rbarraud>Considering going to Canada for a while. <rbarraud>Never been past Nadi, Geelong or Newcastle, NSW yet.. and until ~ 2 years ago, hadn't seen most of the South Island. <rbarraud>Sad eh - waited for Bro, friends etc to go with me on a M/C tour ... set too long a timeout (~30 years :-/ ) ... finally caught my own signal and did the tour :-) <jcowan>I traveled a lot during sumers with my parents, but I've only adulted in a few states, if you discount conferences <rbarraud>BTW not sure whether this is helpful since the Manual is avwoedly a WIP, but... <rbarraud>Ch 99 and 100 have the same title... and very-related content. <rbarraud>Also Ch 106 title is a little Meta for me... s/Documentation of// perhaps? <rbarraud>[Not that there's anything wrong with meta ... in the right places :-) ] <rbarraud>[Spot the Cryptic crosswords fanboi ;-) ] <rbarraud>Upside of Globally Homogeneous Monoculture: I can haz Uber Eats :-) <rbarraud>[Meta: That's about all by way of intro from me here ... will dial back the Chatty from here on out.] <rbarraud>[Meta: All welcome over @ #SICP ... more NZers in there too, not all as chatty as me. OT and meanderings tolerated/welcome. Cheers] <ZombieChicken>in Racket I was using a variant of vectors called growable vectors for something, but those seem specific to Racket. Is there anything in Guile that would allow for easy insertion/deletion of an entry at arbitrary points? <ZombieChicken>list feel kinda like crap for something like that (bad access time, need a new list anytime a change is made), and none of the other options seem like obvious options to me <rekado_>ZombieChicken: Guile has arrays, which give you better access times. <rekado_>doesn’t help with deletions or insertions, though ***jonsger1 is now known as jonsger
<spk121>Hmm. The C API for hooks never made it into libguile.h <spk121>Apparently, I'm the first person to ever want to try to use it. <spk121>civodul: ^ do you care if I add libguile/hooks.h into libguile.h? It looks like it was an oversight not to include it. <civodul>spk121: sure, it looks like an oversight <dsmith-work>jcowan: Thinking of Forth words as taking and returning one thing, the stack, and thinking of that stak as a list is *very* interesting. Never thought of it like that. <jcowan>dsmith-work: Check out http://www.kevinalbrecht.com/code/joy-mirror/j00rat.html by Manfred von Thun, who invented Joy. Joy itself is based on the insight that since nested lists are straightforward, so are nested stacks: an example of Joy's conditional is [3 4 +] [5 6 +] [1 0 =] if, which evaluates [3 4 +] and returns 7. <jcowan> Since there are no names except the global names of Joy functions (which are just abbreviations), there is no name-binding problem, and every Joy datum is also Joy code: [5 6 +] is a list that when evaluated becomes 11, and 11 considered as a function is one that accepts a random list q and returns q with 11 prepended to it. <wingo>omg civodul 7c17655cd3d859bf0c5a86d9782a7788205fc05a is amazing <chrislck>nly: sorry to ask about rastache... stalled? <rekado_>civodul: I’m very impressed with the macrology in guix/monads.scm — it’s a wonderful learning resource <civodul>apparently it's not the end of the story, i'm head-down in rr <rlb>civodul: this may not be acceptable, but I feel like I might really like to have some way to officially ask for a pointer to the string bytes in a specific width (and an official way to ask the current width). Use case: efficient pcre2 wrapper. And if/when we ever change the storage again, those functions could specifically not define whether they might transform/copy (though for now they wouldn't). <rlb>Then the process would be "ask the width", "request the pointer at that width" (which would be "free"), then call the pcre2 functions of the appropriate width. <rlb>Though I need to double check some things, i.e. the 1-byte case -- if pcre2 can't handle that as latin-1, then this might or might not pan out (for the common case). <civodul>there's scm_i_string_chars, but it's not good as a public interface <rlb>Yeah - I thought about just using that and accepting the risk. Which might be "just as good", i.e. if we changed our rep to require copying, then I might want to rewrite anyway. <rlb>or "good enough for now"... <wingo>fwiw you might be able to implement something using compiler interfaces <rlb>I *am* in favor of the current position of reserving the right to change the storage, since we've done that more than once :) <wingo>rlb: see module/language/tree-il/compile-cps.scm:1140 <wingo>it's really version-specific though :) <wingo>probably safest is to foreign-call some C function <wingo>the tail-pointer-ref gives you the pointer and there is some branchiness about how to know if it is narrow or wide <rlb>wingo: ahh, ok thanks. <rlb>fwiw, may be about to have 3.0 building on all the debian release archs finally -- so it can propagate to testing. I'm also thinking about relaxing the current mutual-exclusion between the various guile-X.Y-dev packages. I don't think it'd be hard these days (given the now solid --prefix support). <mwette>FYI, I've found that dynamic-link does not work reliably on Redhat, Centos, Fedora. So far, I have traced this back to libtool's lt_dlopen. In standalone C program, I can load with native dlopen, but lt_dlopen segfaults on same filename argument. <mwette>scratch that; found error in C code <tohoyn>daviid: gtk-container-add isn't there either <daviid>tohoyn: hello! did you import "Gtk" <tohoyn>I wrote a small script to print all the names of imported baseinfos <tohoyn>daviid: do you want to look at it? <daviid>tohoyn: let me paste an example we use, I and users, that is a simple hello-world ... <daviid>tohoyn: when you want to see what has been imported, use the cache, not the ifo <daviid>or any other cache key og course ... <tohoyn>daviid: is it so that gi-import-by-name imports the methods belonging to the classes, too? <daviid>so, in this case you'd do: (gi-cache-ref 'function 'gtk-container-add) <daviid>tohoyn: you cam iport the all namspace of course, (gi-import "Gtk"), but that may take a few seconds on 'old' not so powefull machines ... <tohoyn>daviid: I have to leave now. thanks for help. <daviid>sneek: later tell tohoyn did the example work on your side then? ***catonano_ is now known as catonano
<mwette>So I found the problem with dynamic-link on Fedora et al: Fedora does not use .so as extension on shared library objects, and guile uses lt_dlopenext (i.e., not lt_dlopen), which slaps on .so and never finds the file. What to do? <weinholt>mwette, will using lt_dlopen fix the perennial problem that (dynamic-link "libcurl") requires the -dev package? <mwette>weinholt: I don't know. Are you on Fedora? Is that a libcurl specific issue? <weinholt>mwette, i'm on debian. it affects curl because the .so file is in the -dev package; otherwise you just have e.g. libcurl.so.4 and libcurl.so.4.5.0 <weinholt>hmm. or perhaps the real issue is that (dynamic-link "libcurl.so.4") doesn't work <mwette>weinholt: Ah. Thanks. Let me see ... <tohoyn>daviid: hello again. is there any way I can obtain all the methods belonging to some imported class? <sneek>Welcome back tohoyn, you have 1 message! <sneek>tohoyn, daviid says: did the example work on your side then? <weinholt>mwette, strace says that (dynamic-link "libcurl.so.4") searches for "libcurl.so.4.so" <tohoyn>I tried to import namespace Pango but I can't find the PangoAttribute class. <tohoyn>I have tried <attribute> and <pango-attribute> <tohoyn>also Attribute and PangoAttribute <mwette>weinholt: indeed, dnf install libyaml-devel installs a .so file, but I can't get the standalong C code to load it (yet). <tohoyn>daviid: it says in the documentation that there can be only one instance of GIRepository in one process. Is it still possible to import several namespaces, e.g. Gtk and Pango? <rekado_>I’m trying to write two cooperative macros. Can I access the *expansion* of the first macro in the second one? <tohoyn>gi-cache-show seems to be what I need <tohoyn>I still can't access the Pango attribute classes <mwette>rekado_: not sure, but maybe the syntax transformer lambda is the way to go (using syntax-case) <dsmith-work>weinholt: Does (dynamic-link "libcurl") find the file? <tohoyn>(gi-cache-show 'boxed) shows pango-color but neither <pango-color> or <color> work <tohoyn>class pango-attribute is not listed at all <weinholt>dsmith-work, (dynamic-link "libcurl") does not find libcurl.so.4 unless a -dev package is installed. according to strace it looks for "libcurl.la" <dsmith-work>And indeed, using apt-file, libcurl.so is only in libcurl4-gnutls-dev, libcurl4-nss-dev, or libcurl4-openssl-dev <dsmith-work>Things have changed I think, but the way it used to work on Solaris, is you pass the .so to the linker, but the .so.x.y.z gets encoded into the executbale. <dsmith-work>So when a new version of the .so is install, things linked against the older lib still work. <dsmith-work>With that in mind, I guess it does make some sense for the .so to be only in the -dev package. <dsmith-work>There are two kinds of dynamic loading. I don't know the right words to differentiate them. <dsmith-work>One kind is encoded into the exectable, and it won't start unless it can be loaded. You can see these with ldd. <dsmith-work>The other kind are loaded under program control. Like plugins. <dsmith-work>The first kind need to be in the LD_LIBRARY_PATH (or known to ldconfig?) and need to be named "lib*.so*". <dsmith-work>The second kind can be anywhere and can be named anything. ***jao is now known as Guest99024
<mwette>dsmith-work: thanks. The behavior is odd in that strace shows file openeing but then lt_dlopen returning null ; <mwette>openat(AT_FDCWD, "/usr/lib64/libyaml.so", O_RDONLY|O_CLOEXEC) = 3 ***Guest99024 is now known as jao
*dsmith-work shakes fust at libtool *dsmith-work shakes his fist also <mwette>but then goes to open /usr/lib64/libyaml.0.so.2, a symlink, so odd; so I thought maybe libyaml.so is a hardlink to libyaml.0.so.2, but it's not ; go fiture <dsmith-work>I am really puzzled why that .so is only in the -dev. It's only a symlink, so just a few bytes. <dsmith-work>Maybe it's becuse there could be several different implementations? (gnutls,openssl) <sneek>file not found is use strace -efile or set LD_DEBUG=all <dsmith-work>rlb: Did you recently trace through dynamic loading for that misleading "file not found" message? <mwette>lol, /usr/lib64/libyaml.so is a text file w/ entire content: INPUT(libyaml-0.so.2) <rlb>dsmith: hah, I'd forgotten about that -- yeah, though I didn't really do much other than figure out that was the problem, fix it the missing symbol, and move on... <nly>chrislck: stalled? yes, stopped? no <rlb>I don't know -- I mean it was guile's load-library that I was calling, so likely going through libtool at some point? <rlb>I don't recall for sure, but I think may have just been that the syscall was returning ENOENT (maybe meaning the symbol?) and so the sys_errlist string just said "no such file or directory". <ZombieChicken>Uh, got a backtrace when compiling chickadee. Weird thing is this line: no code for module (gl)