IRC channel logs

2017-04-02.log

back to list of logs

<MoronicAcid>Does use-module prevent loading already loaded modules?
<kyamashita>MoronicAcid: That doesn't seem to be the case. I can run `(use-modules (srfi srfi-1))` twice in a row on Guile 2.2.0 without a problem.
<MoronicAcid>kyamashita: Of course you can call it again, but is it actually modifying the environment?
<kyamashita>MoronicAcid: use-modules doesn't modify the environment, but using the REPL command reload does the trick.
<kyamashita>MoronicAcid: Got it! Use `(reload-module (resolve-module (list (quote [name-of-module]))))`.
<kyamashita>Found it here: https://www.gnu.org/software/guile/docs/master/guile.html/Module-System-Reflection.html
<paroneayea>hmmmm
<paroneayea>ACTION debating whether or not to implement this program in a functional or imperative style
<paroneayea>maybe making it imperative is a premature optimization
<paroneayea>it would be nice to be able to snapshot execution at a particular moment in time
<paroneayea>guess I'll need fash.scm once again though
<amz3`>OrangeShark: regarding libgit2 bindings, do you have an idea why some C objects are wrapped with define-libgit2-type and others have a record type in structs.scm
<amz3`>it's seems like define-libgit2-type is useful for opaque pointers
<amz3`>whereas the record types are for public struct
<amz3`>I am trying to bind strarray which is a 'char **'
<amz3`>char * in bytestructures is represented as (bs:pointer uint8), I am wondering how to deal with the other *
<taylan>amz3`: (bs:pointer (bs:pointer uint8)) is possible
<taylan>amz3`: though char* often implies a null-terminated string. if that's the case, something else would need to be done
<amz3`>typedef struct git_strarray {
<amz3`> char **strings;
<amz3`> size_t count;
<amz3`>} git_strarray;
<amz3`>then this struct, is used in another struct.
<taylan>one discrepancy between what can easily be done in C and in Scheme with bytestructures, is that in C one can simply reference any offset from a given pointer, whereas in Scheme the length of bytevectors is fixed at the time the bytevector is created, so you have to declare in advance how many bytes starting from a given pointer really "belong"
<taylan>amz3`: the way I understand that struct, it's an array of null-terminated strings, and how many strings there are is written in size_t count, correct?
<amz3`>yes
<taylan>hmm, difficult
<amz3`>and how the C compiler can embed a struct which size is unknown in another struct
<taylan>that can be done with `delay' actually
<amz3`>git_strarray is used as paths field in http://dpaste.com/16DG63Q
<amz3`>I don't understand how it works in C already
<taylan>well the size of the git_strarray struct is known: one pointer and one size_t
<amz3`>sorry! yes, right.
<taylan>hm, goes guile have something that takes a memory address and returns the null-terminated string starting from that address?
<taylan>maybe the C function scm_from_locale_string can be called through the FFI :)
<amz3`>there is pointer->string
<taylan>oh neat. I missed it because its documentation says "nul-terminated" not "null-terminated" :P
<wingo>nul-terminated is correct
<wingo>NUL is ascii zero
<wingo>NULL is a pointer
<taylan>amz3`: I'm currently adding a descriptor called cstring-pointer to bytestructures, which can be used for 'char*', and when it's referenced it will return the nul-terminated string. this would be step #1 to be able to represent git_strarray most conveniently in bytestructures; step #2 would be to handle the size_t count automatically somehow...
<taylan>wingo: surprisingly, Wikipedia calls it "null-terminated". (info "(guile) Conversion to/from C") also uses "null-terminated". I think the manual should be consistent. should we go for nul or null? (I'll write a doc patch later)
<taylan>amz3`: cstring-pointer added.
<taylan>amz3`: for the 'size_t count' issue, I've been thinking of a magical dynamic-struct descriptor that can have a procedure as part of its definition, which is executed whenever a reference is made to get the correct sub-descriptor. e.g. in this case, it would read the value in the 'count' field and return (bs:vector <COUNT> cstring-pointer)
<taylan>amz3`: otherwise one could always do it manually at run-time: http://sprunge.us/dCcj
<amz3`>tx!
<paroneayea> https://emacs.stackexchange.com/questions/598/how-do-i-prevent-extremely-long-lines-making-emacs-slow TIL why emacs grinds to a halt when I print out really, really long lines (as seems to happen in the guile repl to me now and then)
<davexunit>paroneayea: thanks for sharing that
<davexunit>always wondered that
<paroneayea>davexunit: :)
<janneke>paroneayea: oh, this has caused sooo much pain over here
<janneke>paroneayea: do i misread the URL to say that there's really no solution?
<janneke>`you can try cache-long-scans and read the docstring of...' however `the best option is to add newlines'
<paroneayea>janneke: yeah I don't see a solution presented there, other than disabling the bidirectional text and etc
<paroneayea>but that's not guaranteed to make it super fast
<paroneayea>it looks like it's a datastructure decision in emacs which has caused the tradeoff
<janneke>i'm just wondering if this broke /after/ RMS stopped hacking on Emacs
<janneke>or how RMS managed to debug elisp with emacs hanging on long line display...
<paroneayea>maybe rms never used emacs with really long lines :)
<janneke>i'm probably stupid, but mes will try to display circular lists now and then
<janneke>yeah, maybe i should add line-width to my primitive display
<paroneayea>janneke: oooh
<paroneayea>davexunit: janneke: look at this: https://www.emacswiki.org/emacs?action=browse;oldid=OverLongLineMode;id=SoLong
<paroneayea>looks like it succeeds by disabling the "offending" minor modes.
<janneke>paroneayea: i'll try that!
<janneke>i have tried disabling font-lock in shell buffers and compilation buffers ...but only when i *expect* a problem...
<janneke>sometimes that's too late :)
<paroneayea>janneke: I hear you
<paroneayea>I wish I could turn on so-long-just-in-time-mode ;)
<paroneayea>since I like font lock and etc... until they cause problems :)
<janneke>yeah! ... and thanks, that's so nice of you to say that!
<paroneayea>m
<paroneayea>hm
<janneke>mhm
<daviid>sos: scheme object system
<daviid>hello guilers!
<paroneayea>hi!
<paroneayea>currently debating a couple of things:
<paroneayea>1) I just imported define-method* and clone stuff *again* into a GOOPS-using project, maybe it's time to submit patches to guile?
<paroneayea>2) is a 10x slowdown in this genetic programming environment worth it if it means no mutation
<paroneayea>ha ha, no mutation
<paroneayea>pun not intended
<paroneayea>the advantage for 2) maybe is being able to restart or save programs at any point
<daviid>paroneayea: in my opinio, this should remain a separate module, not part of guile
<paroneayea>daviid: really? even define-method* ??
<paroneayea>I can't believe people manage to make nice use of goops without it
<paroneayea>it's so useful to have keywords and optional arguments
<paroneayea>I mean, CLOS has them
<daviid>paroneayea: I was mostly talking about the clone stuff, define-method* could land in guile-lib
<paroneayea>daviid: I guess it could go in guile-lib, though I don't see why we wouldn't want it alongside GOOPS itself
<paroneayea>clone I can see being separate
<daviid>paroneayea: sounds good to me
<daviid>define-method* in guile-lib, clone a separate module of yours (not in guile-lib)
<daviid>then with time it makes to guile core, or not... but once it's in guile-lib everyone can start to use it, test it...
<daviid>paroneayea: it's just my opinion, if maintainers wants define-methods i guile core straight away, ok with me too :)
<daviid>define-method* I meant
<paroneayea>daviid: well mark_weaver wrote define-method*, so it's code by a maintainer at least :)
<daviid>yes I know :)
<janneke>paroneayea: mark_weaver ah, great
<janneke>ACTION would really like a curried-definition-method
<daviid>I have a copy here ...
<daviid>guile-lib should also have a define-class 'wrapper' that removes accessors and defines methods ... http://lists.gnu.org/archive/html/guile-devel/2017-03/msg00099.html (long email, look for 'second solution', towards the end ...)
<daviid>paroneayea: actually we could have your slot-fset and janneke's clone (or was it yours as well?) in guile-lib too
<daviid>it would be nice to make guile-lib 'alive' again, have more maintainers... more modules ...
<daviid>paroneayea: how about a egoops module (extended goops)
<paroneayea>daviid: clone was my code, but written with help/advice of janneke
<daviid>anyway, I'm not the guile-lib project admin, it all comes to wingo to decide ...
<daviid>egoops extending goops rather then extended
<daviid>or maybe another name
<daviid>?
<janneke>daviid: yes, i'm using #:getter only
<daviid>janneke: I understand, but I'm against 'making' immutable a dogme :) like scheme have set!, goops has slot-set!, guile-cv (although the core is pure functional programming (it never mutate an input image)) provides im-set! ...
<paroneayea>daviid: immutable won't become a dogma as in terms of the only option in scheme
<paroneayea>that's no risk
<paroneayea>you can't roll back set! ;)
<amz3`>who is the maitainer of guile-lib?
<amz3`>I thought it was abandonned
<paroneayea>amz3`: daviid is the maintainer, but I think wingo might call final shots
<paroneayea>amz3`: it works on guile 2.2 and I use it for some things
<amz3`>I only use htmlprag so far
<wingo>i should just give it away
<wingo>i think i valued stability over change, kinda hoped someone else would just make a different project
<wingo>but since then i just copy whatever i need from guile-lib into whatever proj i use
<amz3`>night!
<daviid>wingo: I'd be happy to take on a guile-lib admin priveledge, if you're happy with the idea, not having this 'position' has refrained me a lot, hence I wrote grip, I don't even feel like I can answer emails guilers sent with proposed modules ... and guile-lib could really accept more stuff and be a mini 'potluck' :)
<wingo>daviid: c'est fait
<wingo>you are admin!
<wingo>all hail the new guile-lib maintainer
<civodul>woohoo! :-)
<civodul>thanks for taking care of it daviid!
<daviid>oh, wingo, civodul, thanks!
<wingo>:)
<paroneayea>:)
<janneke>:)
<random-nick>:)
<daviid>my intention is to follow the way I see we (guile, guix...) do things: everybody can contribute, suggestions, request for improvment and patches sent to guile-user[devel], to be reviewed by all interested guilers, then when it feels like a consensus was reached, we can commit ...
<daviid>I don't see v0.2.5 tag, though I have one locally, did I forgot to push it maybe? is there a git command to compare local and remote tag list?
<daviid>right, pushed, the tag is there now
<dsmith-work>daviid: Yey!
<dsmith-work>Morning Greetings, Guilers
<daviid>dsmith-work: greetings and tx!