IRC channel logs

2020-03-13.log

back to list of logs

<mwette>civodul: yea, pretty cool quote; guix will generate more lisp fans, for sure
<jcowan>Or fewer guix fans, whichever
<mwette>jcowan: you have a point
<rbarraud>LOL :-)
<rbarraud>Maybe in here...
<rbarraud>Does 3.x have the malloc race bug?
<rbarraud>Or did we leave it behind in 2.2.x?
<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>Initially ASM-only, x86-64/amd64-only
<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>*On* topic though:
<rbarraud>I see that 3.0.[01] has some included language-y bits ... incl brainf***
<rbarraud>:-)
<rbarraud>[LazyIRL] did 2.2 have those?
<rbarraud>What's the philosophy?
<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>Ahhh OK
<rbarraud>So it's historic from way back?
<rbarraud>That confirms mu hunch re subsumption of languages :-)
<rbarraud>my*
<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?
<wleslie>no, not at all
<wleslie>there is one major "other language
<rbarraud>...potentially something which people could take up again should Guile be sufficiently popular?
<rbarraud>Sorry, crossing in the 'mail' there.
<wleslie>" that lived on guile at the time, in the form of lilypond, but guile broke lilypond significantly with the 2.0 release
<rbarraud>Yeah :-/
<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>Ah OK well that makes sense
<rbarraud>I shall explore it some more in non-[LazyIRC] mode then :-)
<wleslie> http://wingolog.org/archives/2009/02/25/callcc-and-ecmascript
<wleslie> http://wingolog.org/archives/2009/02/22/ecmascript-for-guile
<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?
<rbarraud>So I take it Andy is head honcho?
<rbarraud>[at least in a modulo-GNU sense] :-)
<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>What if any is the overlap?
<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
<wleslie>default gettext alias is G_
<wleslie>and check out new deprecations and removal of old deprecations in https://lists.gnu.org/archive/html/guile-devel/2020-01/msg00080.html
<ZombieChicken>ty
<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>Well, and having a REPL.
<dsmith>IN both, you end up writing some kind of domain-sepecific language, and work the problem domain with that.
<rbarraud>Yup
<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.
<rbarraud>I'm not entirely convinced...
<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>Hiya jcowan
<jcowan>hey ho rbarraud
<rbarraud>I'm just about trembling - recognized the name... <Humbled/>
<jcowan>pffft
<rbarraud>I shouldn't be I guess... While not in the UeberKlass, I have earned my neckbeard ;-)
<rbarraud>LOL
<rbarraud>And have a supply of nickels at the ready ;-)
<rbarraud>Ah yes - Basically a FORTH-monad
<rbarraud>?
<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>[FactorMan]
<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>for*
<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...]
<rbarraud><reality_stack_pop/>
<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>Slava*
<rbarraud>Author of Factor
<rbarraud>LOL yeah
<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" ;-)
<wleslie>also, those who shaved this morning
<rbarraud>Trudat :-)
<rbarraud>Your Shaveage May Vary
<rbarraud>[Mines's usually consistent == 0]
<rbarraud>Anyone written an HAP in Guile?
<rbarraud> * Hirsuteness Assertion Prover
<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>ah, string<? :-)
<apteryx>that's better
<apteryx>err, decreasing length would be a string>?
<jcowan>rbarraud: Oh, got it, thanks
<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>Heheh
<rbarraud>Mine prefers [well preferred, I'm not there at the moment :'( ] me to have it but not too long.
<rbarraud>Stubble is spiky.
<rbarraud>I suspect many of the SO's have never gone beyond the short-term local optimum.
<rbarraud>jcowan: Are you from the US originally?
<rbarraud>I'm from - and still in - NZ
<rbarraud>Good Scots name yours :-)
<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>But I digrees ;-)
<rbarraud>digress*
<rbarraud>For my part re not-mainstream langs, I'll confess to confusing Julia with Joy
<rbarraud>from time to time
<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>Right.
<rbarraud>My lot have been in NZ since ~1840
<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>:-)
<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 :-)
<rbarraud>Loved it.
<jcowan>I traveled a lot during sumers with my parents, but I've only adulted in a few states, if you discount conferences
<rbarraud>:-)
<rbarraud>Discounted confs sound good do me ;-)
<rbarraud>WWDC would be nice... ;-)
<rbarraud>Anyhoo... I snarfed julia<$v>.pdf
<rbarraud>so having a proper look
<rbarraud>Thanks :-)
<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>jcowan:
<rbarraud>Also Ch 106 title is a little Meta for me... s/Documentation of// perhaps?
<rbarraud>:-)
<rbarraud>[Not that there's anything wrong with meta ... in the right places :-) ]
<rbarraud>Phonetically, makes a great conductor.
<rbarraud>[Spot the Cryptic crosswords fanboi ;-) ]
<rbarraud>'Nite USA and Canada :-)
<rbarraud>Dinnertime here in Middle Earth...
<rbarraud>Upside of Globally Homogeneous Monoculture: I can haz Uber Eats :-)
<rbarraud>0mn0mn0m
<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
<ZombieChicken>nvm. I think I figured something out
<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.
<spk121>wingo: ^
<dsmith-work>Happy Friday, Guilers!!
<civodul>spk121: sure, it looks like an oversight
<civodul>hey ho, happy Friday!
<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.
<spk121>OK. I'm gonna push a patch.
<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.
<dsmith-work>jcowan: Thanks!
<wingo>hey hey!
<wingo>omg civodul 7c17655cd3d859bf0c5a86d9782a7788205fc05a is amazing
<wingo>my sincere apologies!
<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>rekado_: heh, glad you like it :-)
<civodul>wingo: np!
<civodul>here's another one for you to review: https://issues.guix.gnu.org/issue/28211#23
<civodul>lmk what you think!
<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
<civodul>i understand the need, though
<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 :)
<rlb>wingo: ?
<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>tohoyn: yes
<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: here http://paste.debian.net/1134822/
<daviid>try this and let's see ...
<tohoyn>daviid: thanks
<daviid>tohoyn: when you want to see what has been imported, use the cache, not the ifo
<daviid>(gi-cache-show)
<daviid>then (gi-cache-show 'function)
<daviid>or any other cache key og course ...
<tohoyn>ok
<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: yes
<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>btw, you might be intersted in http://www.tohoyn.fi/theme-d/theme-d-gnome.html
<tohoyn>daviid: I have to leave now. thanks for help.
<daviid>wc!
<daviid>sneek: later tell tohoyn did the example work on your side then?
<sneek>Got it.
***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?
<tohoyn>sneek: yes, it did.
<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>Ah
<dsmith-work>And indeed, using apt-file, libcurl.so is only in libcurl4-gnutls-dev, libcurl4-nss-dev, or libcurl4-openssl-dev
<dsmith-work>Debian Buster
<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
<mwette>s/fiture/figure
<dsmith-work>Yeah, usually the .so is a symlink to the .so.x.y.z
<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)
<dsmith-work>Maybe I just never noticed
<dsmith-work>sneek: file not found?
<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?
<dsmith-work>rlb: Where it's really a symbol that is not found?
<dsmith-work>Hhm. Never realized the bare .so symlink should only be in the -dev package: https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#development-files
<dsmith-work> https://www.debian.org/doc/debian-policy/ch-sharedlibs.html "However, there are some exceptions for unusual shared libraries or for shared libraries that are also loaded as dynamic modules by other programs."
<mwette>lol, /usr/lib64/libyaml.so is a text file w/ entire content: INPUT(libyaml-0.so.2)
<dsmith-work>heh
<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
<dsmith-work>rlb: Was it in libtool code? I
<dsmith-work>'d really like fix that.
<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".
<dsmith-work>Ahh, that may be.
<ZombieChicken>Uh, got a backtrace when compiling chickadee. Weird thing is this line: no code for module (gl)
<ZombieChicken>hold up
<ZombieChicken>Yep. Was missing a library path. Got it sorted out