<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 <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>$35 = #<task task-list args: (#<task set-testy-result-prop-to args: ("...> #) desc: #f id: "3e07eca51b5141a91ce6902e4b3d24324052cedb32"> <mark_weaver>paroneayea: hmm, I don't seem to get syntax highlighting at the geiser REPL for some reason. <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. <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. <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 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 <paroneayea>is there no way to do #:optional in goops (define-method) ? <mark_weaver>one obvious hack would be to define separate methods with and without the optional argument <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>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>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 http://paste.lisp.org/+35BU <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>... <mark_weaver>an implementation of 'define-method*', supporting all of the things that 'define*' supports <mark_weaver>the main limitation is that only the required arguments can be specialized based on type ***cluck` is now known as cluck
<paroneayea>mark_weaver: maybe a nice patch for the next verison of guile? :) <mark_weaver>in the meantime you can just stick that definition directly in your code <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>(let ((how-many-equals 3)) (format #f (string-concatenate (list "~" (number->string how-many-equals) ",1,'=t>")))) <paroneayea>basically I just want to create n number of 1 concatenated into a string <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>on #guix we were saying that it would be cool to have a simple way to set up a REPL server over SSH <artyom-poptsov>Hmm... I think I haven't. But the idea seems to be worthy of investigation. <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>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 :-) <civodul>i think it would be nice to be able to do remote eval without having guile-ssh on the remote side <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. <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? <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 <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>I imagine there's a flag to specify the target system. <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 guile-user@gnu.org 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 :) *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? <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>I'm a bit baffled to hear that they have a guile-2.0.6 package <mark_weaver><hellekin> the beta version of Devuan will include Guile 2.0.6 (the version packaged in Debian). <mark_weaver>I confess I find this whole devuan thing a bit baffling. <mark_weaver>the number of packages in debian that won't work with sysvinit is surely miniscule <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_>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) <mark_weaver>please_help: I'll have to look at it later, must leave soon... *paroneayea subscribes to guile-devel & guile-user <zacts>oh should I update to 2.0.11? <zacts>what major changes are there between 2.0.9 and 2.0.11? ***koz__ is now known as koz_
<zacts>so is guile aiming to eventually support R7RS-small? <zacts>huh, looks like it would be good for me to update <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)