IRC channel logs


back to list of logs

<paroneayea>maybe I should turn off syntax highlighting at the guile repl
<paroneayea>because output which prints a single quote seems to constantly break my highlighting
<paroneayea>and suddenly my prompt thinks it's in a string
<mark_weaver>paroneayea: what are you using to do syntax highlighting at the REPL?
<paroneayea>mark_weaver: it comes on by default in geiser I think?
<paroneayea>but this will break it
<paroneayea>$35 = #<task task-list args: (#<task set-testy-result-prop-to args: ("...> #) desc: #f id: "3e07eca51b5141a91ce6902e4b3d24324052cedb32">
<paroneayea>because it has an odd number of "
<mark_weaver>paroneayea: hmm, I don't seem to get syntax highlighting at the geiser REPL for some reason.
<mark_weaver>but I wonder what's printing that unmatched quote
<paroneayea>mark_weaver: anything that truncates output
<paroneayea> (format port
<paroneayea> "#<task ~a args: ~:@y desc: ~s id: ~s>"
<paroneayea>the ~:@y
<mark_weaver>ah, okay
<mark_weaver>and indeed, I do seem to have syntax highlighting at the REPL, but it's subtle enough that I didn't notice it
*mark_weaver looks at truncated-print
<mark_weaver>I thought truncated-print was smart enough to not leave unbalanced parens or quotes.
<paroneayea>mark_weaver: doesn't seem so here
<paroneayea>maybe it is in newer guiles
<mark_weaver>paroneayea: when I call 'truncated-print' directly, so far I've been unable to get it to print an unbalanced delimeter, although admittedly I've only tried a few things: a big string, a list containing a big string and some other items, etc
*mark_weaver tries with 'format'
<mark_weaver>I guess maybe it's related to the nested structure. maybe the inner structure is getting converted into a plain string, and then that string is later truncated by the outer printer.
<davexunit>hey guilers
<mark_weaver>hey davexunit!
<mark_weaver>apart from the license issue, there are technical issues with using GCC for code generation.
<mark_weaver>it's not designed to handle the more general control flow of scheme, e.g. procedures returning more than once
<mark_weaver>it's not designed to cooperate with a garbage collector
<mark_weaver>it's not designed to allow guaranteed tail calls
<mark_weaver>it's not designed to support closures that can be called after the parent procedure has returned
<mark_weaver>there may be solutions to these problems, but it would require someone deeply knowledgeable with both scheme and GCC internals to work them out
<mark_weaver>it also probably lacks the optimizations needed to make code run fast that makes heavy use of higher-order procedures
<mark_weaver>making scheme code run fast is a lot harder than making C run fast
<davexunit>mark_weaver: thanks for the detailed explanation
<davexunit>that makes sense
<paroneayea>is there no way to do #:optional in goops (define-method) ?
<mark_weaver>indeed, there's not
<paroneayea>hm, kind of a bummer
<mark_weaver>well, there's no easy out-of-the-box way
<mark_weaver>one obvious hack would be to define separate methods with and without the optional argument
<mark_weaver>and a macro could take care of doing that
<mark_weaver>but obviously this is not very nice
<daviid>paroneayea: there is a way, use let-keywords within a (define-method (initialize (self <yourclass>) initargs) ...)
<mark_weaver>another way is the way optional arguments have to be done in standard scheme: use a dotted tail argument
<mark_weaver>e.g. (define-method (foo (x <string>) . rest) ...)
<mark_weaver>and then 'rest' is bound to a list containing the remaining arguments
<mark_weaver>and you can use 'let-optional' and 'let-optional*' from (ice-9 optargs) module to make it nicer
<mark_weaver>e.g.: (define-method (foo (x <string>) . rest) (let-optional rest ((y 1) (z 2)) (list x y z)))
<mark_weaver>(foo "test") => ("test" 1 2)
<mark_weaver>(foo "test" 2) => ("test" 2 2)
<mark_weaver>(foo "test" 2 7) => ("test" 2 7)
<mark_weaver>paroneayea: ^^
<mark_weaver>so that's not so bad, I think
<mark_weaver>I suppose it wouldn't be too hard to implement 'define-method*' based on these
*mark_weaver tries implementing it
<daviid>i don't have time to build a small example right now, but here is a 'big' one i'm sure you will be able to understand and grab the idea to write yours
<daviid>note that in the above example, virtual slots are unknown to gobject, which clutter-actor inherits from, so, the same way they wuld be extra keywords in your case, i need to grab them and specially treat them ... see initialze <clus-grid>...
<paroneayea>mark_weaver: ah I see!
<paroneayea>thanks also daviid
<daviid>paroneayea: wc
<mark_weaver>actually, this might not be very hard
<mark_weaver>daviid might also be interested
<mark_weaver>an implementation of 'define-method*', supporting all of the things that 'define*' supports
<daviid>mark_weaver: looking, thanks
<mark_weaver>the main limitation is that only the required arguments can be specialized based on type
<nalaginrut>morning guilers~
***cluck` is now known as cluck
<paroneayea>mark_weaver: hey nice!
<paroneayea>mark_weaver: maybe a nice patch for the next verison of guile? :)
<mark_weaver>yes, perhaps
<mark_weaver>in the meantime you can just stick that definition directly in your code
<mark_weaver>but yes, I'll propose it
<paroneayea>btw, here's a dumber question
<paroneayea>the most concise way I can find to do this is (format), the only other thing I can think of is to use (map) but that seems dumb
<paroneayea>what's the simplest way to do
<paroneayea>(let ((how-many-equals 3)) (format #f (string-concatenate (list "~" (number->string how-many-equals) ",1,'=t>"))))
<paroneayea>which produces "===>"
<paroneayea>I'm sure there's a better way
<paroneayea>basically I just want to create n number of 1 concatenated into a string
<mark_weaver>also see 'make-string'
<paroneayea>(string-concatenate (make-list 3 "="))
<mark_weaver>paroneayea: (make-string 3 #\\=)
<paroneayea>mark_weaver: oooh, much better
<lloda>please_help: array-copy! is just slow for typed arrays (not #t). It seems easy to improve some cases at least (unit strides, same types). look at libguile/array-map.c:racp in the Guile source.
***michel_mno_afk is now known as michel_mno
<civodul>Hello Guilers!
<zacts>lo #guile
<civodul>howdy artyom-poptsov!
<artyom-poptsov>Hi civodul
<civodul>on #guix we were saying that it would be cool to have a simple way to set up a REPL server over SSH
<civodul>have you thought about it? :-)
<artyom-poptsov>Hmm... I think I haven't. But the idea seems to be worthy of investigation.
<civodul>something like channel-request-exec
<civodul>say, channel-request-eval
<artyom-poptsov>Yeah, I remember there was an idea that one could use Guile-SSH to make distributed computation procedures for Guile.
<civodul>yeah, with some restrictions, notably because there are objects that cannot be automatically serialized
<civodul>(and sometimes you wouldn't want to)
<artyom-poptsov>Oh wait, I did some experiments related to that idea on the branch 'wip-distributed-forms':
<artyom-poptsov>The code is quite clumsy though.
<artyom-poptsov>civodul: By the way, I remember you saying that you're faced with "Out of memory" error in 'userauth-public-key!'. I wasn't able to reproduce it. Does that problem persist in Guile-SSH 0.7.2?
<civodul>artyom-poptsov: i think i haven't checked, sorry
<civodul>i highly recommend using define-record-type instead of make-vtable
<civodul>higher-level, easier to read, and more future-proof :-)
<artyom-poptsov>Ah, thanks. I'll take it in account.
<civodul>i think it would be nice to be able to do remote eval without having guile-ssh on the remote side
<civodul>by just executing guile there
<davexunit>so would we spawn the guile process, call 'eval', serialize the result to the proper port, and quit?
<davexunit>do we already have a procedure in guile to serialize just plain objects?
<artyom-poptsov>civodul: Well, it makes sense. It should be enough to have an SSH server and Guile running on a node to run some Scheme code. Although I have distcc in mind which requires a client on each node.
<paroneayea>oooooooh that would be great.
<davexunit>I imagine there's a version of write such that reading its output with 'read' always succeeds?
<paroneayea>btw, (read) in guile, does it read reader macros?
<paroneayea>as in, I'm asking how "safe" it is :)
<davexunit>not sure :)
<civodul>davexunit: 'write'? :-)
<civodul>davexunit: there's no such 'write', no
<civodul>so one needs to sanitize the input before or something
<please_help>lloda: OK. That seems really weird, can't scm_array_copy (or whatever) simply use memcpy?
<davexunit>civodul: ah, okay. so that would be another bit of code that needs to be sent over the wire
<davexunit>since core guile can't do it
<please_help>that is, iff the array is contiguous of course
<please_help>For the generic case I don't see anything that can be improved in racp, or the generic vector ref/set, save for going with inline ASM. The benefits in that case would most likely be negligible anyway.
<please_help>so arrays are represented as a single 1D strip with constant stride between elements internally?
<lloda>you see the special case for SCM_ARRAY_ELEMENT_TYPE_SCM, the same can be done for the other types if there's no need to convert (can use = to copy). That saves the .vset & .vref which I guess is most of the slowness. Then if the strides are 1 for both arrays one can do a straight memcpy. The conversion cases and the non-unit-stride cases just take the old path.
<lloda>fact is, array-copy! does a lot more than just copying.
<lloda>but those changes require getting the type sizes & stuff and would make the function 3 times as big. It's probably worth it, if you copy big arrays a lot.
<lloda>it should be done, I think. I just haven't found myself in a situation where I personally needed it.
<mark_weaver>please_help: are you doing an array-copy! within some inner loop?
<mark_weaver>I vaguely recall that you iterators did far too much work within the inner loop. I'm not sure if you've improved that since I last looked
<lloda>then there're the nasty cases of bitvectors & strings, which aren't even actual arrays, but array-copy! has to support them :-/
<hellekin>the beta version of Devuan will include Guile 2.0.6 (the version packaged in Debian). If you want to package 2.0.11, please step up!
<davexunit>hellekin: I don't think there's anything to do sans bumping the version number.
<sneek>Welcome back davexunit, you have 1 message.
<sneek>davexunit, Sleep_Walker says: Guix defaults to (%current-system) when building the OS
<davexunit>thanks Sleep_Walker
<davexunit>I imagine there's a flag to specify the target system.
<davexunit>I'm thinking about it for 'guix ops
<davexunit>how to deploy systems to different architectures
<ArneBab_>hellekin: I don’t know of anything which breaks with 2.0.11 but runs with 2.0.6
<hellekin>davexunit, ArneBab_: I would feel more comfortable if someone who actually knows about Guile gets to maintain the Devuan package. It would ensure that Guile is always up-to-date, and thanks to the devuan-sdk, the maintenance work is pretty much a no-brainer.
<ArneBab_>hellekin: my problem is that I cannot promise any maintenance. In my free time I’m too project driven for that (I’d just fail)
<davexunit>I'd encourage someone to maintain it, but I cannot do it.
<davexunit>too many irons in the fire as it is as a guix maintainer.
<ArneBab_>Guile provides autotools-based releases, so it should be easy to maintain.
<davexunit>but thanks for advertising it here. hopefully someone will be interested.
<davexunit>hellekin: perhaps you could also send mail to about it
<hellekin>the next pre-release will be next week I think, and will ship Guile 2.0.6. I hope by the time we reach the 1.0 we have a 2.0.11 :)
<hellekin>davexunit: good idea
*wingo pushed "transients" for intmaps / intsets to master
*davexunit needs to check that out
<davexunit>Clojure: a pretty gross language with lots of neat ideas to steal. :)
***michel_mno is now known as michel_mno_afk
<mark_weaver>hellekin: why don't you just take the guile-2.0.11 that's in Debian jessie?
<ArneBab_>wingo: yay!
<ArneBab_>davexunit: ☺
<mark_weaver>why does devuan need a separate maintainer for guile when debian already has a fine guile package that doesn't have any systemd stuff?
<mark_weaver>presumably devuan can't take 99% of what's in debian as-is, right?
<mark_weaver>hellekin: ^^
<mark_weaver>I'm a bit baffled to hear that they have a guile-2.0.6 package
<mark_weaver>it's ancient and not even in debian
<mark_weaver><hellekin> the beta version of Devuan will include Guile 2.0.6 (the version packaged in Debian).
<mark_weaver>hellekin: according to, guile-2.0.6 is not in any version of Debian.
<davexunit>perhaps 9 was read upside down?
<mark_weaver>I confess I find this whole devuan thing a bit baffling.
<davexunit>2.0.9 would make sense
<mark_weaver>the number of packages in debian that won't work with sysvinit is surely miniscule
<mark_weaver>so why replace the entire distribution?
<mark_weaver>anyway, I have to go.
<ArneBab_>mark_weaver: I understand it - it’s to ensure that no dependencies creep in.
<ArneBab_>based on experience from people who saw that just a few packages with dependencies can lock-in the majority of the user.
<ArneBab_>I don’t understand why stuff which is OK at debian needs to be done again, though
<ArneBab_>hellekin: from it looks like debian has 2.0.11 — why can’t you use that?
<civodul>2.0.6 is unacceptably old
<ArneBab_>debian stable has 2.0.5
<ArneBab_>gentoo has 2.0.0 ☹ - 2.0.11 is available from the lisp-overlay, though.
<ArneBab_>I still didn’t succeed at making lilypond work with 2.0.11
<ArneBab_>(though I only spent an hour or so on that)
<nalaginrut>2.0.9 is unacceptably old too...
<please_help>mark_weaver: here's the current version of the array-ec:
<mark_weaver>please_help: I'll have to look at it later, must leave soon...
<dsmith-work>Morning Greetings, Guilers
<cmhobbs>hello guilers!
<ArneBab_>moin dsmith-work
*paroneayea subscribes to guile-devel & guile-user
<paroneayea>finally :)
<zacts>oh should I update to 2.0.11?
<zacts>I'm on 2.0.9
<zacts>what major changes are there between 2.0.9 and 2.0.11?
***koz__ is now known as koz_
<zacts>oh cool
<zacts>so is guile aiming to eventually support R7RS-small?
<zacts>huh, looks like it would be good for me to update
<zacts>I'll do this
<dsmith-work>zacts: I would think, in general, that it's always best to be on at least the latest stable release.
<dsmith-work>(sometimes you might want git stable to pick up a bug fix before a release has it)
<hellekin>ArneBab_: thanks for the heads up