***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 ***michel_mno_afk is now known as michel_mno
<ArneBab_>sneek: later tell mark_weaver: sorry for being away, my homeserver died (so I do not have a backlog) <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: https://www.btcdlc.com/shop/drak/py2guile (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 <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 <b4283>most likely in SRFI-1 , but i didn't find one <b4283>maybe i chose the wrong container to do the job <b4283>ArneBab_: thank you for helping out <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 <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_>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 <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 <taylanub>paron_remote: oh, you meant the specification? <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>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 <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 <wingo>taylanub: do you work on applications at all? <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?” <wingo>ArneBab_: it's a useful question but the answer doesn't always have to be "yes" <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) <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 <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 <wingo>then if it needs fixes/extensions i want to be able to do so without asking for permission from another project <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: http://paste.lisp.org/display/146470 <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]? <davexunit>Chaos`Eternal: dynamic link opens shared libraries <mark_weaver>ArneBab_: unfortunately, our current method of attaching source properties doesn't work for immediate values (such as '1') or symbols. <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. <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. <davexunit>do the other ffi functions actually work with the object returned from dynamic-link? <taylanub>wingo: to give a concrete example: as a Guile user I can't currently use https://github.com/ktakashi/r7rs-postgresql 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. <ArneBab_>mark_weaver: it copies the information in both directions, but only if there wasn’t information before. <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 <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 <wingo>it doesn't solve any significant problems for us, and introduces new ones needlessly <wingo>inability to fall back to libfoo.so.1.2.3 <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… <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 <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>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>did we land support for minimal gmp via gnulib, btw? <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 :) <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 going to try guix when i get a new laptop <wingo>is a 256GB SSD too small for guix? <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? <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! <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>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) <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>I'm currently on a Novena, which I hope to run GuixSD on in due time. <davexunit>yeah, I got the model with the case and a nice IPS LCD screen. *mark_weaver is envious :) <davexunit>and I can't find the WIP driver for 2d/3d graphics <mark_weaver>davexunit: the debian system that came pre-installed should have had the etnaviv driver already installed. <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. <mark_weaver>they might have even disabled some of it by default because of bugs <mark_weaver>mine came with 2D acceleration enabled, but I saw display corruption bugs. <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 <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 ***michel_mno is now known as michel_mno_afk
<mark_weaver>paron_remote: also: ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-514.pdf <mark_weaver>"Design of LISP-based Processors or, SCHEME: A Dielectric LISP or, Finite Memories Considered Harmful or, LAMBDA: The Ultimate Opcode" <civodul>dsmith-work: libtool does more than just portability <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 <jao>it's still something based on dororango? <jao>is that ijp's server <jao>i like the call-with-current-musing moniker :) <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_>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_>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 <jao>yes, it'd be a nice project <jao>i think clojars.org 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.