<zv>is there any special meaning to the '<symbol> symbols? <ijp><foo> often gets used in goops for classes <ijp>some people also use it for record type names <zv>ijp: so i'm familiar with the use of <x> for GOOPs stuff, this is something thats actually in (and unexplained) by SICP <zv>in the function defn "user-print" <ijp>weird, why not just link to the mitpress version <zv>because im not as smart as you ijp <zv>and i require the fancy layout :) <ijp>I don't think there is much significance to it here <ijp>probably just to distinguish it visually <cluck>and the average of 12 words per line makes it a breeze to speed read <DeeEff>ecraven: I wanted to discuss arrays with John because I am incredibly interested in using them to create something like numpy. It's a bit of a side project for me but I need to really dig down into what he's done so far to see if I have any suggestions or questions. <cluck>nevermind, that's a lucky accident of my current screen resolution <wingo>okeydoke, both 2.0 and master are updated for gnulib <wingo>so, we can release a 2.0.12 i guess <wingo>i do want to fix a thing though -- if we aren't cross-compiling we should ignore any GUILE_LOAD_PATH that is set when building guile, not add to it. uninstalled-env can keep the adding behavior but a build environment will set it unconditionally. <lloda>wingo, can you remind me why handle is needed in something like scm_vector_elements()? as long as the SCM is around the elements pointer can't be collected, can it? <wingo>i think it's not guaranteed that the SCM would be around, is the thing. the compiler could remove it. pairing vector_elements with array_handle_release does in practice guarantee that the elements won't be collected. <wingo>but that's a tenuous argument :) you could just as well use the remember_upto_here thing on the SCM <wingo>of course i could be wrong here <wingo>btw lloda i was wondering the other day about memory models and what we should do in guile <wingo>if you have any thoughts they are welcome <wingo>one option would be to make guile use acquire/release atomic ops on all loads and stores <wingo>i believe that would not cause any fences on x86 and would not inhibit optimizations either by the C compiler or by the Scheme compiler but i haven't really thought it through <wingo>it would be nice to have a robust threading/memory model story <lloda>tbh I don't know much about this. How would those those atomics be implemented? C11? loads and stores of immediates/SCM? <lloda>a lot of the Guile library is still C, too. What do we do with that? <wingo>and i guess it would be (to a first approximation) all loads and stores in libguile <lloda>so we'd need to wrap every *p = x; in libguile <lloda>well, it's a motivation to move more stuff to Scheme, which I'm all for <wingo>the nice thing about it is that it would more or less automatically give a memory model to all scheme programs <wingo>without having to change those programs <wingo>and without having to introduce an atomic reference data type, or a panoply of atomic reference operators <wingo>which operate on vectors, structs, pairs, variables, and so on <wingo>though you do still want compare and swap i think, at least. <galex|713>wingo: hi, we were discussing something on this channel some days ago: a <galex|713>*wouldn’t be quicker to make guile use gcc to produce native code, before to start trying to make our own native compiler in scheme? <ijp>wingo: if you remember, when was the last time guile found a gnulib bug? <wingo>but ludo found it and paul fixed it <wingo>so we're good currently i think <ijp>ah, that makes it easy to remember <ijp>I need to start paying more attention to th list <ijp>btw, do you have a good primer on ELF <wingo>ijp: the man page is not terrible <wingo>and ian lance taylor's linker articles go deeeeeeeep <wingo>i think those are the two references that i can think of <wingo>so, atomics. turns out in guile programs we do a lot of reads but not a lot of stores and very few read-modify-write sequences. <wingo>if we used the "relaxed" memory order for loads, on x86 that's just MOV, on POWER just ld, on ARMv7 ldr, on ARMv8 ldr. <wingo>for "acquire" semantics there would be additional penalties on POWER (a lot i think), on ARMv7 (some), ARMv8 (a little). <wingo>mark_weaver: ^ you might be interested in this. <wingo>i think the biggest problem guile has in a practical sense is making sure to make fences after allocation. <ijp>those slide transitions are a little offputting <davexunit>galex|713: it's been discussed here in the past. it doesn't make sense to use gcc. <davexunit>compiling Scheme is very unlike compiling C, so GCC doesn't really provide anything worthwhile. <galex|713>davexunit: yeah but gcc also compile other languages… <davexunit>galex|713: right, languages that are all very different from the dynamic nature of Scheme. <davexunit>I don't know details, but the folks around here that know their compilers have determined that using GCC isn't a great idea. <davexunit>it will be much better to have the compiler written in Scheme, too. <galex|713>but is it “using GCC for all guile/scheme” or could gcc work for a subset of scheme (Stalin does that right?) or maybe using a subset of gcc for it, like only the backend, so we factorize the architectures support? <wingo>i guess also we would be prevented from hoisting (car x) out of a loop; humm. <wingo>galex|713: dunno, at some point we could use gcc or llvm or something for a backend. but we want things gcc can't give us <wingo>like control over stack layout, expandable stacks, gc and other debug info... <wingo>in the end gcc or llvm would give us great instruction selection but not a whole lot else <wingo>so, probably it's not worth it in the end <wingo>because you also have to pay the cost of a complicated dependency that most people will not have installed, while still dealing with version skew bugs <wingo>and dealing with impedance mismatches <wingo>and it's a big pile of c++. *shrug* <ijp>and guile already gets enough flack for its dependancies <thomeith>have you guys checked out parrotvm? parrotvm <thomeith>it is for dynamic languages like perl, scheme, python, etc. <wingo>i looked into parrot a while back; they do interesting stuff but ultimately i prefer a vm that i can ship and be responsible for :) ***cluck` is now known as cluck
<rekado>Using “scandir” from (ice-9 ftw) on a directory containing files with names like “AC_Raíz_Certicámara…pem” scandir reads “AC_Ra??z_Certic??mara…pem” <rekado>I’m doing this in a Guix build phase. <rekado>because the file name is corrupted somewhere “file-system-fold” says the file does not exist. <rekado>I’ve set the locale to “en_US.UTF-8” and tried (with-fluids ((%default-encoding…))) but to no avail. <ecraven>DeeEff: cool! the proposal seems good to me, though I was wondering whether column/row-majority might be specified, to make things easier for a possible FFI with external code <ijp>rekado: I think you need to use setlocale rather than change the encoding <ijp>maybe both, I'm not sure <ijp>I'll have a look in a minute <ijp>yeah, it will be setlocale. The only encoding fluid is for ports, and wouldn't be consulted here <ijp>you'll notice that you can scandir from the REPL just fine, that's because it does the setlocale call for you <rekado>I thought it had something to do with reading the directory node which appears to be using ports. <DeeEff>ecraven: IMO colmajor storage should be default to comply with BLAS conventions however I don't think it should be specified in the document itself as this sort of pertains to your storage class <DeeEff>of course, I also think rowmajor interfaces should be used <DeeEff>anyone coming from anything but fortran will expect rowmajor behaviour <ecraven>DeeEff: well, almost everything *except* FORTRAN seems to use rowmajor <DeeEff>which is part of why fortran is faster than most everything <DeeEff>colmajor has better data locality in most matrix operations <ijp>it's really a matter of perspective <DeeEff>really, lists vs vectors vs cyclic graphs is a matter of perspective