IRC channel logs

2019-08-20.log

back to list of logs

***daviid is now known as Guest8066
***Guest8066 is now known as daviid
<daviid>I'm back :)
<daviid>lloda: yes, it is really great to have logs again, thanks again rekado_!
<daviid>though no luck this time wrt my guile-gnome g_hash_* function usage instead of scheme hash tables... hope andt will find a min or so to answer
<daviid>*andy
<daviid>davexunit: for info, the guile-gnome (C code), that performs the hashing, so to speak, is very short, and here: http://git.savannah.gnu.org/cgit/guile-gnome.git/tree/glib/gnome/gobject/gc.c
***jao is now known as Guest64353
***jao- is now known as jao
<daviid>davexunit: it seems using eq? won't work https://paste.debian.net/1096649/
<daviid>if i use pointers addresses, do i have to build my own hash function?
<daviid>davexunit: this sems the way to go (?) (eq? (pointer-address $11) (pointer-address $12)) -> #t
<daviid>*seems
<wingo>daviid: i think guile-gobject used glib hash tables because previously you couldn't call scm_gc_{protect,unprotect}_object within a finalizer
<wingo>and there were no foreign pointers obviously
<wingo>but now, finalizers run in a more-or-less normal environment, so you could change to use scm_gc_protect_object / scm_gc_unprotect_object, or some kind of hash table -- you need to be careful with synchronization though as finalizers run in threads
<daviid>wingo: thanks, I am working on a 'primitive' cache in sheme which will, indeed, have to be enhanced to be thread safe (as in glib thread safe), and then I also have to understand how 'all this' remains gc friensly ... a lot to learn about on my side ...
<wingo>:)
<daviid>wingo: guile-gnnome is such a master piece that I still feel, after all these years, 'ignorant', :) bahh we never stop to learn ...
<wingo>aw tx :)
<wingo>fwiw i am becoming more ignorant with time, i forget why things are they way they are :P
<daviid>yeah, I understand that, it is such a master piece that it is like a mozart composition, easy to read, impossible to compose again ...
<daviid>I need to understand what you did with these func-qdata* procedures, till now, these are still a bit of a mistery for me
<manumanumanu>Ahoy guilers!
<lloda>I get this trying to compile master from scratch https://paste.debian.net/1096687/
<lloda>I think the makefile is missing some header
<jonsger>lloda: can you give some more input about your build system (compiler version and stuff like that)
<lloda>g++ (Debian 8.3.0-6) 8.3.0
<lloda>I'm on buster
<lloda>pull & recompile on an old clone works just fine, so I think it's a file that's not being generated now
<lloda>sorry, should have said gcc not g++
<lloda>same thing regardless
<lloda>I compile off tree though
<lloda>yeah in tree gets over that so it's an in tree / offtree thing
<dsmith>lloda: Also on up-to-date Buster. gcc (Debian 8.3.0-6) 8.3.0.
<dsmith>lloda: Fresh pull and git clean -dxf is building fine. Got through all the C code no prob. Working on eval.go at the moment.
<dsmith>Ahh.
<dsmith>lloda: Hmm. Seems to be working for me.
<lloda>dsmith: off tree?
<chrislck>really st*p*d question, I cannot see INSTALL in guile/* where do I find build instructions?
<chrislck>ah found it
<dsmith>lloda: as in (mkdir buildtest; cd buildtest; ../configure; make) ?
<roelj>How do I specify a "\r" in Guile's format function?
<dsmith>lloda: If you haven't, might want to do a git clean and autogen
<nalkri>~newline?
<manumanumanu>Wow! The new #:declarative? and user-modules-declarative things in the git head is great!
<lloda>dsmith: yes. Actually (cd ..; mkdir buildtest; ...) starting from the source tree. Did it from scratch, new clone, everything empty.
<lloda>Anyway! the in-tree build finished and I still have the out-of-memory error
<apteryx>any builtin support for serializing objects in Guile?
<manumanumanu>I go to guile.git once in a while, and the last year it has been like christmas once a month
<apteryx>(or defining how a given object should be serialized?)
<chrislck>apteryx: object<->string? no
<lloda>roelj: I think you can just say \r inside a string, no?
<lloda>the char names are #\newline for 10 and #\cr for 13
<apteryx>chrislck: object->string! thanks for pointing me to it. Seems I have something to chew on.
<roelj>lloda: Thanks. So I can either use \r, or its character name equivalent.
<lloda>yw
<lloda>there's (integer->char nn) which prints the char name
<roelj>oh nice!
<lloda>it's annoying that (guile) and (srfi :1) have different versions of (iota)
<manumanumanu>even worse, they are both compatible.
<manumanumanu>or better. The change would be trivial :D
<manumanumanu>I am actually diving into guile to maybe be able to make trivial changes in the future.
<manumanumanu>That is one pet peeve
<manumanumanu>along with match not being user-extensible
<manumanumanu>and not allowing definitions in expression context :D
<manumanumanu>Which are all things I suspect I could take a jab at
<lloda>there are several instances of - need some function in boot.scm - don't want to pull in module x - define own simpler version. Those simpler versions shouldn't be public imo
<wingo>manumanumanu: the definitions in expression context thing could get fixed soon i think
<wingo>it should be doable to fix
<wingo>a bit gnarly but not a lot of code
<manumanumanu>Lucky me! I don't really do C, which I suspect is needed
<manumanumanu>It is trivial to do as a macro, but looking at the source in the guile expander I suddenly feel a bit dizzi.
<wingo>i don't think c is needed
<wingo>it's a psyntax thing
<manumanumanu>oh! I already have some macros that do it in my prelude. I can have a look.
<wingo>the macro should expand (begin x ... tail) to (letrec* ((id rhs) ...) tail)
<manumanumanu>meh. Not too gnarly! It is a rather trivial fix
<manumanumanu>in expand-expr
<wingo>where if x is a definition, you have the id and rhs right there
<wingo>and if x is an expr, lhs is a temporary and the rhs is (begin x #f)
<wingo>i think though the fix should be in expand-body tho
<wingo>probably you don't want to allow (+ 1 (define x 10))
<manumanumanu>Yes!
<manumanumanu>That looks worse :D
<manumanumanu>I have never been in those parts of the guile runtime. I'll have a poke around and see what I can do :D
<jonsger>wingo: I think I found another bug with guile and libgc 8.0
<wingo>yeep
<wingo>test cases are welcome :)
<jonsger> https://paste.opensuse.org/view/raw/94495646
<jonsger>I will check if it's really a problem of libgc8
<manumanumanu>By the way, how does goops deal with compartmentalisation between modules? If I define a method for <list> in a module, how is "contained" to the code that has has imported that module? I suspect there is some mutation going on
<wingo>jonsger: that may be a guile problem fwiw, master fails right now on that test
<manumanumanu>I just want to write some kind of library that allows me to keep things separated where some kind of shared state is mutated.
<jonsger>wingo: ah okay
<wingo>manumanumanu: mikael djurfeldt would always point to https://pdfs.semanticscholar.org/be63/cb65045c7396c61a63cdb64bfac2747646dd.pdf when this question was asked
<wingo>so from his POV each module needs to know where the methods added in define-method, which specific generic they're adding them to
<wingo>and then users compose those methods using the module duplicates handlers mechanism
<wingo>and though it seems like it could work i was never happy with it; i lost the feeling that i knew where my definitions were
<wingo>perhaps that's just subjective tho
<wingo>see https://lists.gnu.org/archive/html/guile-user/2006-05/msg00027.html also
<wingo>manumanumanu: also see https://docs.racket-lang.org/reference/syntax-model.html#%28part._intdef-body%29 regarding definitions and expressions
<manumanumanu>That would be the key to making match.scm user extensible. It would allow for adding a custom matcher, while also keeping it backwards-compatible
<manumanumanu>thanks wingo.
<wingo>honestly regarding matching, i think we should also be looking to just taking the one from racket. it's extensible.
<manumanumanu>I have found _where_ to make the changes, but I have to understand quite a bit more before hacking on it
<manumanumanu>the racket matcher looks nice. It also only uses syntax-case, which is comfortable for us.
<dsmith-work>Hey Hi Howdy, Guilers
<wingo>moo
<wingo>davexunit: do you use the 2-arg atan or the 1-arg atan
<davexunit>wingo: 2-arg
<davexunit>it's of lesser importance to sin/cos, fwiw
*wingo nod
<wingo>i just noticed that all of these are primitive-generics; joy...
<davexunit>wingo: I am picking up some sarcasm there
<wingo>:)
<daviid>manumanumanu: that kiczales article people point to to justify module protection for methods goes against the clos standard itself, like it suggest a complete opposite direction of what is at the heart of clos, a complete none sense imo
<daviid>fortunately, there are ways to circumvent this, and make things so that goops appears to work like clos, but it is not 'that easy', nor 'that complicated' either, but it needs bit of dedication to understand what th is all about, what guile/goops does and how to circumvent ...
<daviid>my personal position wrt this is that if you feel the need of module protection over your methds, then you have a design problem
<daviid>not a clos/goops problem
***jao is now known as Guest21804
<daviid> manumanumanu: i wrote what i think one should do when using goops here https://lists.gnu.org/archive/html/guile-user/2017-10/msg00027.html