IRC channel 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!

IRC channel logs

2017-04-02.log