IRC channel logs


back to list of logs

***cluck` is now known as cluck
<turbofail>huh. i had guile 2.0.9 installed on my OS X laptop and didn't even remember doing it
<nalaginrut>morning guilers~
***michel_mno_afk is now known as michel_mno
<civodul>Hello Guilers!
<wingo>moin :)
<ArneBab_>sneek: later tell mark_weaver: sorry for being away, my homeserver died (so I do not have a backlog)
<ArneBab_>sneek: botsnack
<ArneBab_>does anyone have a working version of scwm?
<ArneBab_>I’m thinking about selling the epub/mobi/pdf versions of py2guile, so people who don’t want to build them themselves can get them conveniently. First experiment: (I have some other services to test on my TODO, including LULU for printed versions)
<ArneBab_>idea: provide a free licensed HTML version with the full sources, sell the book/pdf/epub/mobi (which people can build from source via `./configure; make` when they want to)
<b4283>hello, is there a modify-at which replaces the Nth element in list L with value X ?
<b4283>and returns a list, of course
<ArneBab_>I think list-set!
<b4283>yes, i'm looking at it right now in emacs info page
<b4283>i was planning on doing something like this: (let-values (((a b) (split-at x n))) (append a (list s) (cdr b)))
<b4283>ArneBab_: wonder why there isn't a non-inplace version
<b4283>maybe i'm crazy to write non-efficient programs :P
<ArneBab_>maybe you’ll find something in an SRFI
<b4283>most likely in SRFI-1 , but i didn't find one
<b4283>split-at is in SRFI-1
<ArneBab_>stackoverflow talked about SRFI-17
<b4283>maybe i chose the wrong container to do the job
<b4283>meh, back to coding
<b4283>ArneBab_: thank you for helping out
<ArneBab_>glad to ☺
<ArneBab_>happy hacking!
<ArneBab_>some things discussed in 1998 are reality today ☺ →
<paron_remote>hello, *
<wingo>greets paron_remote
<paron_remote>ArneBab_: wow, ian bicking wrote that!
<paron_remote>I inherited much of his code at a former job and a lot of his writings influenced me a lot
<ArneBab_>paron_remote: wow - the legacy of people actually lives on
<paron_remote>btw, nice thing I realized today:
<paron_remote>srfi documents open really nicely in eww
<paron_remote>hm, maybe it's time to make a open-srfi command :)
<davexunit>do share
<davexunit>if you write it
<taylanub>ArneBab_: I wonder what's meant with "short descriptive names"? IMO, the <type>-<action> pattern in Scheme is a good balance of descriptiveness and terseness. transparent code is being continuously worked on by moving things from C to Scheme, and keyword arguments are supported and used well from what I can tell. also, argument order is usually quite consistent in Scheme isn't it?
<ArneBab_>paron_remote: nice!
<davexunit>paron_remote: awesome!
<paron_remote>now, I need to read srfi-64 :)
<paron_remote>(and figure out how to turn that into a make check)
<ArneBab_>taylanub: there are some functions where I stumbled several times over the order of arguments, and when there are more than 2 arguments to a function, it becomes unwieldy, I think.
<taylanub>paron_remote: the SRFI-64 reference implementation is quite unreadable IMO. my trim-down of it is about half the size and might be easier on the eyes. making a Guile module from it should be easy; tell me if you're interested / have issues.
<ArneBab_>taylanub: there are really nicely named functions in scheme, where it’s obvious what they do
<davexunit>paron_remote: guix has a good reference
<paron_remote>davexunit: will look at it
<paron_remote>taylanub: link?
<paron_remote>there was no example of how to do things in the guile reference I found
<mark_weaver>taylanub: I think he meant that he needs to read the document, not the source code
<davexunit>paron_remote: and, perhaps simpler:
<paron_remote>davexunit: hm?
<taylanub>paron_remote: oh, you meant the specification?
<paron_remote>oh nice
<ArneBab_>taylanub: and <type>-<action> shouldn’t be needed in Guile in most cases: why have list-ref, array-ref, ... instead of simply a generic ref (implementation issues aside)
<mark_weaver>taylanub: does your implementation even work with released versions of guile?
<davexunit>paron_remote: just another example of a project with a test suite
<taylanub>mark_weaver: I think it should be a matter of prepending a Guile module definition to the body (which is separated from the R7RS library definition)
<paron_remote>davexunit: oic :)
<paron_remote>taylanub: yes, you said you had a simpler verison; could you link it?
<taylanub>paron_remote: it's in the Gitorious repo above, under the srfi directory, as 64.body.scm
<paron_remote>taylanub: ah okay, thanks!
<mark_weaver>taylanub: it's a rewrite from scratch of SRFI-64 ?
<taylanub>feedback welcome :-) note that I remove some features that were in the reference implementation, like reporting line numbers; I saw that as fairly unimportant given test-cases have names/labels anyway
<wingo>line numbers are important, yo
<taylanub>mark_weaver: I started with the reference implementation and did a big cleanup
<mark_weaver>wingo +1
<wingo>taylanub: do you work on applications at all?
<wingo>maybe that sounds rude.
<taylanub>no problem, you have a point. :-) I haven't used it for many things.
<wingo>i would note though that you have been around for a long time and i think your interest is like more in the language than the things that can be done with it :)
<wingo>i would be delighted to work more with your code but respectfully i think you need to use it more first :)
<mark_weaver>taylanub: I don't see what the advantage is for a user to switch to a less featureful rewrite of SRFI-64 that has surely seen much less testing.
<taylanub>I really want to be able to do things in standard Scheme, and we're just not there yet :(
<wingo>see i must really really disagree with that sentiment
<mark_weaver>if you want your work to be useful, how about trying to get some of your cleanups made to the upstream SRFI-64 reference implementation?
<wingo>that (a) scheme programs *must* be standard scheme
<davexunit>I'd like to be able to ask my srfi-64 test suite to run a single test given a line number, but perhaps I should just be using the REPL for one-offs.
<wingo>and that (b) the langauge must be changed/enhanced in order to build things
<ArneBab_>wingo: one question my SRFI editor asked was “can this be done in standard scheme?”
<ArneBab_>(or portable scheme)
<wingo>ArneBab_: it's a useful question but the answer doesn't always have to be "yes"
<wingo>e.g. srfi-18
<ArneBab_>taylanub: I’ve been searching for an example of inconsistent naming, but I’m unable to find it right now…
<ArneBab_>wingo: my answer was “because I know guile best and I use some guile-specific functionality. There is no general portability problem.” He accepted that.
<davexunit>paron_remote: just took open-srfi for a spin. very nice. :)
<taylanub>mark_weaver: the reference implementation was not conforming to the specification on something; I don't remember what right now but I'll look into getting it fixed upstream
<mark_weaver>ArneBab_: I think it's possible to implement a portable reader for wisp, but not one that also accepts whatever non-portable reader extensions are available in the user's scheme implementation
<mark_weaver>(not to mention propagating source location properties, etc)
<ArneBab_>mark_weaver: that sounds logical, yes.
<mark_weaver>taylanub: I can sympathize with your feeling "this source code is messy, I could rewrite it cleaner".
<taylanub>wingo: I think it would be great if hackers of Racket, Chicken, Guile and all could share libraries, and not by copy-pasting
<mark_weaver>taylanub: but IMO, that is more often than not a counter-productive impulse
<ArneBab_>mark_weaver: it would be nice to have a portable core which is wrapped by specific functionality
<ArneBab_>mark_weaver: but what keeps me from trying is that I use guile match, and I don’t want to stop using match ☺
<davexunit>I've come to recognize the various Schemes as unique languages in their own right.
<mark_weaver>ArneBab_: 'match' is itself written in portable scheme
<mark_weaver>ArneBab_: you can use 'match' in portable code
<wingo>taylanub: i think we do much better to share ideas. i don't want to depend on code from racket, or any other scheme -- i want to incorporate it
<ArneBab_>that could make it this much easier…
<wingo>then if it needs fixes/extensions i want to be able to do so without asking for permission from another project
<ArneBab_>mark_weaver: do you have a few minutes?
<mark_weaver>(well, almost portable; how to load the 'match' module itself varies between implementations)
<wingo>if the original bit of code is great and the fix is great then it goes upstream
<wingo>and they incorporate it or not
<wingo>but in the context of guile i certainly (personally, imho, etc etc) don't want e.g. a build-dep on some module of srfi code
<ArneBab_>wingo: are there testsuites which scheme implementors can use to inform developers about compatibility?
<mark_weaver>ArneBab_: a few minutes, but not much more. what's on your mind?
<wingo>ArneBab_: not sure i understand the question :)
<ArneBab_>mark_weaver: I managed to propagate some source information, but not for every part of the source: Sometimes I get the line number for the function, sometimes the line number of surrounding code. In short: this:
<ArneBab_>(two example backtraces - the backtraces don’t matter, only how they display the line numbers)
<ArneBab_>mark_weaver: do you have an idea why I don’t get line numbers for [write 1 1]?
<Chaos`Eternal>i am trying use dynamic-link to open a executable
<davexunit>Chaos`Eternal: dynamic link opens shared libraries
<Chaos`Eternal>but only if i rename the executable with .so
<Chaos`Eternal>the works
<mark_weaver>ArneBab_: unfortunately, our current method of attaching source properties doesn't work for immediate values (such as '1') or symbols.
<Chaos`Eternal>the executable is complile with -pic -fPIE -rdynamic
<mark_weaver>ArneBab_: so when you read an individual symbol or fixnum, guile's 'read' will not attach any source location information to that.
<ArneBab_>mark_weaver: I got that error, so I tricked and attached the source properties to the sourrounding list.
<Chaos`Eternal>davexunit, so if i rename it with .so suffix, it will work
<mark_weaver>ArneBab_: so that will have to be your job.
<Chaos`Eternal>without .so, it will say can't find file
<ArneBab_>what I don’t understand is why I get source information for a misspelled function name, but not for a function call with the wrong number of arguments - I had expected it to be the other way round.
<davexunit>Chaos`Eternal: I'm confused. An executable program and a shared library are different things.
<Chaos`Eternal>davexunit, but if you compile with -pie -fPIE -rdynamic
<davexunit>do the other ffi functions actually work with the object returned from dynamic-link?
<Chaos`Eternal>it can run, and also can be dlopen
<davexunit>okay, didn't know that.
<taylanub>wingo: to give a concrete example: as a Guile user I can't currently use if we support SRFI-19, 60, and 106, I could, but by copy-pasting and adding Guile library definitions, and maintaining them along with changes in upstream...
<davexunit>Chaos`Eternal: the file name thing is likely not due to guile code, but how libltdl works
<mark_weaver>ArneBab_: I took a brief look at your code to propagate source properties, but in the couple of minutes I had was unable to understand its theory of operation. it seems to be copying information in both directions, which I found a bit baffling.
<davexunit>though I'm not sure.
<Chaos`Eternal>the problem is, guile uses lt_dlopenext
<Chaos`Eternal>and lt_dlopenext will check suffix first
<ArneBab_>mark_weaver: it copies the information in both directions, but only if there wasn’t information before.
<mark_weaver>why both directions?
<ArneBab_>mark_weaver: the reason is that symbols cannot keep the source information, but if a sublist is added, I can add it to that.
<davexunit>Chaos`Eternal: do you have a proposal for how we can make dynamic-link work for your case without breaking the existing API?
<wingo>we should stop using libltdl
<davexunit>wasn't expecting that :)
<davexunit>why? (I don't know anything about it)
<ArneBab_>mark_weaver: and when I add some information to a variable, I use the surrounding list to keep the information in case I have to change the variable (losing the information).
<Chaos`Eternal>davexunit, my suggest is use lt_dlopen(filename) first, and if it fails, try lt_dlopenext
<Chaos`Eternal>wingo, why?
<wingo>it doesn't solve any significant problems for us, and introduces new ones needlessly
<davexunit>Chaos`Eternal: perhaps reverse the order.
<wingo>e.g. bad error messages
<davexunit>wingo: what would we use instead?
<wingo>inability to fall back to
<Chaos`Eternal>davexunit, why?
<ArneBab_>wingo: an example would be that I could get warnings in geiser when I use something which won’t work in racket — sorry for answering late…
<mark_weaver>wingo: how about improving it upstream?
<wingo>davexunit: our own portability layer, possibly
<Chaos`Eternal>and the document of libtool is not consist to the code, wingo
<wingo>mark_weaver: i've tried before, didn't work
<Chaos`Eternal>just as in my case
<wingo>essentially unmaintained
<davexunit>Chaos`Eternal: because the order you suggested gives an edge case priority over the common case.
<wingo>sharing code means unfixable bugs
<wingo>and it's a super-small library that doesn't do hardly anything
*wingo full of opinions today it seems
<wingo>even if you fix a bug in libltdl you need to wait for it to hit distros, etc to use
<wingo>ridiculous given that the entire library should get essentially compiled out at configure-time
<wingo>and! you get twice the stats
<wingo>first for .la files, then for .so files
<Chaos`Eternal>davexunit, but i think open a precise filename is not edge case.
<ArneBab_>wingo: or maybe a compatibility matrix - though “supports SRFI X” already gives part of that - or rather would give it if all special functionality were available as SRFIs.
<ArneBab_>mark_weaver: I have to admit, though, that my use of source-properties mostly stems from experimenting until it worked and not from clear design.
<ArneBab_>I wanted to avoid having to keep a secondary datastructure with the source properties
<wingo>ArneBab_: the current compilation pipeline is not quite right tho
<mark_weaver>wingo: I can sympathize with the distro-time-lag problem, but of course that argument could be used to argue against using any library
<wingo>read should produce a syntax object with embedded source info
<wingo>or have a mode to do that
<wingo>mark_weaver: yes :)
<wingo>in this specific case we're better off without libltdl
<mark_weaver>it might be reasonable for libltdl. I'm not strongly opposed to rewriting its functionality internally.
<wingo>in the case of libunistring, i'm happy to punt to its maintainer :)
<ArneBab_>wingo: I found syntax-source, but didn’t know how to use it
<wingo>likewise for gmp
<mark_weaver>but libltdl should still be fixed
<ArneBab_>and whetehr to use it
<mark_weaver>wingo: gmp? what about gmp?
<mark_weaver>oh, happy to punt, right
<wingo>did we land support for minimal gmp via gnulib, btw?
*wingo doesn't remember
<mark_weaver>but really, libltdl needs a maintainer, so its problems can be fixed and benefit all applications that use it.
<wingo>mark_weaver: i'm just not certain about that. if there is a place for libltdl it's in gnulib, not as a standalone library.
<mark_weaver>wingo: I believe I removed all of the road blocks to using minigmp, but then no one tried using it :)
<wingo>mark_weaver: hehe :)
<mark_weaver>wingo: sure, libltdl as a gnulib module sounds good to me.
<ArneBab_>wingo: are there plans to make read return syntax-objects? (if yes, I would just delay perfecting the source-properties till then - the current support doesn’t always look pretty, but it already helps a lot in debugging)
<mark_weaver>but really, the distro-time-lag problem is a problem with distros that should not cause us all to bundle all of our libraries and/or avoid using libraries.
<wingo>ArneBab_: no concrete plans
<mark_weaver>with GNU Guix we don't have this problem :)
*wingo going to try guix when i get a new laptop
<wingo>is a 256GB SSD too small for guix?
<mark_weaver>we'd love to have you on the team :)
<davexunit>wingo: not at all
<mark_weaver>wingo: that should be fine
<davexunit>I use a 128gb ssd in my main laptop
<wingo>should be in a few weeks then
*mark_weaver currently runs GuixSD on a 40G partition.
<wingo>mark_weaver: do you build in that partition?
<wingo>do you dual-boot or is that in a vm?
<mark_weaver>wingo: yes
<mark_weaver>wingo: yes I build in that partition
<davexunit>if nothing else, guix is handy tool to have alongside your host distro for the latest and greatest versions of stuff.
<ArneBab_>wingo: I’ll think about whether I’ll try harder or accept the partial support. Thank you for the background!
<mark_weaver>I don't dual-boot and don't use VMs
<wingo>i would like to install guix as the native distro, dunno if that will be too much of a hassle tho
<mark_weaver>I have some other partitions with some other distros that I've not booted into in over a month
<davexunit>wingo: depends on what your needs are. I'm sure you're aware that we're in alpha. :)
<mark_weaver>wingo: it works well, the only issue is that we might be lacking packages you need.
<mark_weaver>our only real DE at this point is XFCE
<mark_weaver>but I've been using GuixSD as my primary system for many months
<ArneBab_>mark_weaver: is there a planned time for 2.0.12? (with the readline adjustment to keep newlines)
<ArneBab_>mark_weaver: that sounds great
<mark_weaver>ArneBab_: no planned time for 2.0.12, but I agree that we should get moving on that.
<davexunit>I need to add a SIP phone to guix, and then I think it would have everything I needed to do FSF work.
<davexunit>well, I guess I'd need to figure out the issues with my PHP package, too. (ew)
<ArneBab_>davexunit: once you’re at that point, that warrants a press release “Guix now ready for my work machine at FSF”
<davexunit>hehe :)
<davexunit>I'm currently on a Novena, which I hope to run GuixSD on in due time.
<mark_weaver>davexunit: nice!
<mark_weaver>I still need to build a case for mine
<davexunit>yeah, I got the model with the case and a nice IPS LCD screen.
*mark_weaver is envious :)
<davexunit>my current issue is that sound doesn't work
<davexunit>and I can't find the WIP driver for 2d/3d graphics
<davexunit>so the desktop experience is slow
<mark_weaver>davexunit: the debian system that came pre-installed should have had the etnaviv driver already installed.
<davexunit>need to research. things are really slow.
<davexunit>just dragging a window around is very laggy.
<davexunit>I must be missing *something* because anything using webgl in icecast refuses to work.
<davexunit>which leads me to believe I have to no OpenGL support.
<mark_weaver>davexunit: I'm not sure if the 3D driver (currently a work in progress) is installed by default.
<davexunit>ah, makes sense.
<mark_weaver>they might have even disabled some of it by default because of bugs
<mark_weaver>You might have a look in their forums:
<mark_weaver>ah, I see "Re-enable 2D acceleration" in their TODO
<mark_weaver>mine came with 2D acceleration enabled, but I saw display corruption bugs.
<davexunit>yeah, just read that.
<davexunit>thanks for the link.
<davexunit>I don't know how I missed their forums
*mark_weaver goes afk
<nalaginrut>davexunit: well, you got Novena, which is what I dream for...
<davexunit>nalaginrut: it's really cool, I just need to start doing cool things with it.
<davexunit>like writing a guile interface for the accelerometer or something
<dsmith-work>Morning Greetings, Guilers
<cluck>or implement a hw lisp (scheme) machine atop the fpga ;)
<davexunit>cluck: I'm certainly interested in learning more about the fpga, especially what steps need to taken to have a free toolchain for it
<dsmith-work>sneek: later tell wingo I'm with you on libltdl
<dsmith-work>Is libtool still needed? Like on hpux or something?
***michel_mno is now known as michel_mno_afk
<paron_remote>davexunit: from elsewhere: <nickdaly_w> paron_remote:
<paron_remote>I wish I knew more about what that was
<paron_remote>looks cool.
<paron_remote>is it an oldschool scheme on a chip?
<paron_remote>looks like it
<mark_weaver>paron_remote: here's a paper about the SCHEME-79 chip:
<mark_weaver>here's a reference to a paper about the SCHEME-81 chip:
<paron_remote>mark_weaver: very cool
<mark_weaver>paron_remote: also:
<mark_weaver>"Design of LISP-based Processors or, SCHEME: A Dielectric LISP or, Finite Memories Considered Harmful or, LAMBDA: The Ultimate Opcode"
<paron_remote>haha, lambda the ultimate opcode
<civodul>dsmith-work: libtool does more than just portability
<bipt>i found some code recently that might be related to the scheme chip
<bipt>hmm, it might be simulation code for steele's 1978 chip, since it has separate gc and evaluator registers as mentioned in the history section of the scheme-79 paper
<dsmith-work>Next question (probably already asked here), are there any decent Free fpga tools?
<taylanub>mark_weaver: it seems SRFI-64 only records line numbers of whole test expressions (e.g. the line `test-assert' appers in a `(test-assert ...)' expression). in that case they seem like a minor convenience at most to me, since test expressions are labeled. (and my implementation displays the whole expression if no label was given.)
*jao observes ludovic is around and takes the chance to wonder again about the status of guildhall
*jao whistles and mentions civodul, just in case
*civodul searches for ijp, the real person responsible for that
<civodul>hi jao!
<jao>heya civodul :)
<civodul>i don't know what the status is
<jao>it's still something based on dororango?
<civodul>i have "" in ~/.config/guildhall/config.scm, works well
<jao>aha, i see
<jao>is that ijp's server
<jao>i like the call-with-current-musing moniker :)
<civodul>heh :-)
<jao>dorodango/guildhall: A package manager for Guile and other R6RS Schemes. Needs more love.
<ArneBab_>jao: I use guildhall, but it has far too few packages.
<ArneBab_>jao: what I’m missing is a frontend like marmalade:
<jao>yes, exactly
<ArneBab_>in marmalade it’s just uploading a single elisp file whose comments are used to extract metadata. No additional walls between writing simple code and sharing it.
<ArneBab_>having the same for guildhall would be cool
<jao>well, my expectation is that scheme libraries will be most of the time more than one file (elisp libs already are), but even so
<ArneBab_>jao: for bigger libraries marmalade supports *.tgz, but I think it’s the simple files which make a big difference: That makes it possible to start sharing with the smallest possible effort.
<ArneBab_>and that would be a cool use for Artanis from nalaginrut:
<ArneBab_>sneek: later tell nalaginrut: A cool usecase for Artanis would be something like marmalade for Guile: in marmalade it’s just uploading a single elisp file whose comments are used to extract metadata. No additional walls between writing simple code and sharing it. for bigger libraries marmalade supports *.tgz, but I think it’s the simple files which make a big difference: That makes it possible to start sharing with the smallest possible
<sneek>Will do.
<ArneBab_>sneek: botsnack
<jao>yes, it'd be a nice project
<jao>i think could also be used as a source of inspiration
<dsmith-work>jao: Hey my jazzer friend. My wife and I found this local band that we just can't resist. Named "Velvet Voyage". Been going to see them every Monday night for almost 2 years now.