IRC channel logs

2016-05-11.log

back to list of logs

***holomorph is now known as ammo
***ammo is now known as holomorph
***peterbrett_work1 is now known as peterbrett_work
<roelj>Can I save a record (SRFI-9) to a file, so I can later load it again?
<davexunit>no.
<davexunit>you'd need to write your own serializer and deserializer.
<random-nick>if you want the lazy route you can just make a function to dump all the record data into a list and then use read and write
<roelj>Right. Thanks :)
<amz3`>read and write ftw!
<amz3`>TIL: you can't serialize (write) an *unspecified* value
<amz3`>*undefined*
<amz3`>or whatever the name I don't recall
<taylan>*unspecified* it is
<amz3`>ah yes
<amz3`>thx
<amz3`>actually my code was writing something to the port, but the other end couldn't read it
<taylan>IIRC it's a symbol macro expanding to (if #f #f)
<taylan>seems it can be written and gives #<unspecified>
<roelj>Doesn't that itself evaluate to #f?
<taylan>roelj: nope, (if #f ...) is *unspecified*
<taylan>note it's a one-armed if
<roelj>Aha
<roelj>I didn't know that was valid Scheme..
<taylan>it's valid standard Scheme. IIRC Racket forbids it...
<taylan>probably 'when' and 'unless' are preferable most of the time
<roelj>ACTION wonders what the code for "if" looks like
<wleslie>guile's source is a delight to read, honestly
<roelj>Maybe publish it as a novel
<wleslie>I got belly laughs when I got to the allocator cache
<paroneayea>hello, *
<roelj>What's the opposite for basename? (get the path without the filename)
<wleslie>dirname
<roelj>wleslie: Great, thanks!
<wleslie>you're welcome
<roelj>It's right above basename in the manual.. How could I have missed that :)
<wleslie>because it's so often an argument name!
<roelj>Is there a function to determine whether a string is a directory or a filename path?
<wleslie>I guess you can always (eq? 'directory (stat:type (stat "/foo")))
<wingo>file-is-directory?
<roelj>Oh great
<roelj>Thanks again! Both of you :)
<paroneayea>so
<paroneayea>I did some tests last night with syncmud and using a nicer formatting system
<paroneayea>my idea of using skribilo so that I could write to both html and formatted plaintext... well, skribilo appears to be too slow
<paroneayea>fmt is reasonably fast
<paroneayea>so web interface crazy future ideas, not sure how I'd do it, I could use fmt... I might, in the glorious future that will probably never happen
<paroneayea>have a minimal sxml-like syntax that can just be transformed into either actually sxml or something format can spit out.
<paroneayea>and that's my small braindump of the morning.
<ArneBab>davexunit: did you see my message to guile-user? https://lists.gnu.org/archive/html/guile-user/2016-05/msg00009.html
<davexunit>ArneBab: yes
<ArneBab>davexunit: do you know the source of the problem?
<ArneBab>is my driver missing required support?
<davexunit>ArneBab: don't know, sorry.
<davexunit>it's not the usual error I'm used to seeing when folks don't have a GPU that can do OpenGL 3.0
<davexunit>you could try building without Guix.
<davexunit>I've had issues on an Ubuntu machine before with Mesa
<ArneBab>I hope I’ll find the time to experiment
<davexunit>in general I need to find a good way to distribute my games with all of this custom guile stuff.
<davexunit>if I can deal with the mesa isues, a guix binary "container" would work well.
<ArneBab>yes — distributing games is a much bigger challenge than I ever expected — except if you (a) go for C, or (b) use Javascript.
<ArneBab>or (c) use a readymade commercial game engine.
<ArneBab>it’s awesome that you’re trying to tackle it!
<davexunit>in the future, when guile has native compilation and/or static compilation, things will be easier for the "give me a big ol' binary blob" crowd
<davexunit>since all the guile code could be rolled up together. then it would be fairly simple to throw in guile itself and all the C libraries with a LD_LIBRARY_PATH hack
<roelj>davexunit: Are we ever going to get native compilation for Guile?
<roelj>davexunit: How far in the future is this? :)
<ArneBab>even without native compilation, it should be possible to just pack the modules with guile. But possible is not done
<ArneBab>A guile-binary which includes the Scheme-modules.
<ArneBab>and "possible" does not necessarily mean "easy".
<davexunit>ArneBab: right, native compilation isn't necessary for that.
<davexunit>but a nice bonus. ;)
<ArneBab>that yes :)
<davexunit>roelj: native compilation is on the roadmap. all of the maintainers are looking towards a day when we have that.
<davexunit>and design decisions are currently being made with native compilation in mind.
<davexunit>"is okay to port feature X from C to Scheme for a slow down now that will become a speed up when we have native compilation?"
<davexunit>stuff like that
<ArneBab>(though for me it would be even more important to have working lilypond again)
<ArneBab> (http://lilypond.1069038.n5.nabble.com/Current-status-of-Guile-2-for-lilypond-td189545.html lilypond.1069038.n5.nabble.com/guilev2-work-was-LilyPond-boolean-syntax-true-and-false-td185707.html )
<ArneBab>or rather, the original source: http://lists.gnu.org/archive/html/lilypond-devel/2016-04/msg00063.html )
<roelj>davexunit: Cool, I did not know that :)
<davexunit>"is it okay", rather.
<davexunit>having one of those days where you leave words out of sentences.
<peterbrett_work>Guile is getting harder to embed
<peterbrett_work>I still haven't got a good solution to the finaliser thread issue in gEDA/gaf
<davexunit>extending > embedding
<peterbrett_work>Yes, I'll just completely rewrite an entire suite of EDA tools because the extension language's maintainers have decided they don't want to be an extension language any more.
<davexunit>it is still an extension language
<peterbrett_work>I like Guile _a lot_ but it's becoming increasingly difficult to justify using it
<peterbrett_work>:-( :-(
<davexunit>anyway, this is a conversation to have with the maintainers.
<davexunit>from my perspective, guile is only getting better and better for writing extensible applications.
<peterbrett_work>Yes, the focus has been increasingly towards "write your application in Guile" rather than "use Guile to add extensibility to your pre-existing application"
<peterbrett_work>It's a completely reasonable decision but it leaves projects like LilyPond and gEDA out in the cold
<dsmith-work>day Greetings, Guilers
<peterbrett_work>I also realise that since we should be doing the work to keep Guile working for our purposes
<peterbrett_work>People work on the things they are interested in and which matter to them
<peterbrett_work>So, this is not so much a complaint as an observation & disappointment ;-)
<ArneBab>peterbrett_work: I agree that guile should keep working for embedding.
<ArneBab>peterbrett_work: not to forget that losing things like lilypond is essentially the worst PR I can think of
<ArneBab>peterbrett_work: can I somehow help with that by donating something else than time?
<peterbrett_work>ArneBab:
<ArneBab>(I have a bit of money left over each month at the moment)
<peterbrett_work>I don't know
<peterbrett_work>For gEDA, there are only minor issues that are causing problems, like the fact it is very difficult to build Guile for Windows and the finaliser thread (for which there is a sort-of workaround)
<peterbrett_work>But I think LilyPond has much larger issues
<davexunit>guile needs a contributor that can maintain windows support.
<davexunit>not many guilers want to use Windows due to the usual reasons.
<peterbrett_work>Yes. :) It's the usual problem of "people who want X" and "people who have the time/skills to provide X" not intersecting :)
<davexunit>yup
<davexunit>I would like guile to be well supported on windows so I could distribute my free software games to windows users
<random-nick>davexunit: the toplevel posix primitives are a problem
<davexunit>random-nick: not really.
<davexunit>plenty of POSIX applications run on windows
<peterbrett_work>random-nick: Most other languages that want people to write full apps in them have provided cross-platform primitives (Rust, Python, Go)
<peterbrett_work> https://doc.rust-lang.org/std/fs/ for example
<wleslie>related: http://midipix.org/
<random-nick>a good thing is
<random-nick>guile has no cxx code
<wleslie>indeed
<random-nick>because all cxx compilers are incompatible
<taylan>there's only one C++ compiler relevant to GNU/Guile ;-)
<random-nick>does gnulib have a w32 backend?
<janneke>ACTION maybe requesting a gc works... yay! node --expose-gc coroutine.js ... global.gc()
<random-nick>janneke: wrong channel?
<janneke>random-nick: sorry for being so off-topic
<janneke>i'm doing some javascript for work and am *so* happy i didn't get this sort of thing with guile
<random-nick>just thought you were in the wrong channel since it seemed out of context
<janneke>random-nick: yes, thanks
<paroneayea>hey davexunit, working on the 8sync site a bit, trying to figure out if I have a nice way to add some new things to the skribe reader
<paroneayea>davexunit: it looks like (make-skribe-reader) accepts a list of modules
<davexunit>paroneayea: yeah, that's how I add new things to it
<paroneayea>but I think that would mean that the best way that I do things is to make my whole website into an autoconf package or something, so those modules can be imported
<paroneayea>unless there's an easier way
<paroneayea>I'm feeling kinda lazy
<davexunit>haunt adds the current directory to the load path, IIRC
<paroneayea>davexunit: oh does it? well that makes things easier...
<davexunit>yeah just throw whatever you want in there
<paroneayea>cool
<paroneayea>ty davexunit
<davexunit>np
<davexunit>paroneayea: here's my WIP new blog's "skribe-utils" module https://git.dthompson.us/blog.git/blob/refs/heads/haunt-migration:/skribe-utils.scm
<paroneayea>davexunit: great! thx
<paroneayea>davexunit: okay for me to snarf that and put it under gplv3+?
<davexunit>yes
<paroneayea>great :)
<davexunit>no license header yet because this is "private" right now ;)
<davexunit>so I never got around to it
<paroneayea>ACTION nods
<ArneBab>davexunit: do you know legalese-mode?
<ArneBab>M-x legalese → done
<davexunit>ArneBab: didn't know about that one
<davexunit>not built-in it seems
<ArneBab>M-x package-list-packages :)
<ArneBab>(I really like the elpa — it makes Emacs usage much more painless)
<davexunit>I try not to use that anymore and instead use guix
<ArneBab>I use that, since I use emacs on several different devices and distros, and the packaging is much easier with elpa. It’s just clicking upload in a web interface to get a new package in.
<ArneBab>guix cannot be that simple, because it’s much more security relevant
<ArneBab>(and many packages are harder to check than a small emacs module)
<paroneayea>ArneBab: I'm not convinced guix couldn't be a great answer to this kind of thing
<paroneayea>though it's true that there's a lot more attention paid in sa system like guix than the "register a package willy-nilly and upload" approach many of these language package managers take
<paroneayea>supplementary repos for guix might help
<random-nick>is guildhall abandoned after guix?
<paroneayea>random-nick: it is in that nobody's working on it, it's not in that this has to be the case if someone steps up
<paroneayea>but I think it's true that many guix hackers have lost motivation post-guix
<random-nick>I don't like using guix for guile on non-guixsd distro because it tries to install guix guile
<davexunit>right, guix controls the full dependency graph.
<davexunit>so guildhall can do what you want
<davexunit>just needs people that want to maintain it
<random-nick>unless there is something in guix to shadow packages
<davexunit>what do you mean "shadow"?
<davexunit>if you mean substitute packages with things from a foreign system then the answer is no.
<davexunit>that would completely dismantle everything that guix is built upon.
<random-nick>yeah that's why I didn't even look in the manual if that is a thing
<ArneBab>davexunit: yes. I added basic paths-information for guildhall, but I did not yet get to create a web interface for adding packages.
<ArneBab>paroneayea: I started working on guildhall, though not all the time
<ArneBab>I’ll have to work on documentation, I think