IRC channel logs

2019-09-09.log

back to list of logs

<schaeffer>so, here's a question
<schaeffer>does anyone here write guile in an editor that isn't emacs?
<schaeffer>like, say...acme?
<Tirifto>Acme's one letter away from being an anagram of Emacs!
<schaeffer>and acme's is an anagram of emacs', depending on your ideas of what makes an anagram or a plural of emacs :^)
<Tirifto>xP
<spk121>schaeffer: what is a non-emacs that does decent auto-indent for scheme/lisp
<schaeffer>that's the real question, isn't it
<daviid>str1ngs: gtk-text-iter is not a class, it is an opaque struct, whch tou may look at doing this: (gi-cache-ref 'boxed 'gtk-text-iter) and then describe ...
<daviid>now, there is a bug when i try to call make-c-struct upon it def and init vals
<daviid>kere is a trace http://paste.debian.net/1099598/
<daviid>any guilers familiar with make-c-struct could help?
<daviid>spk121: do you import the GtkTextIter in scheme, or refer and instantiate those from their C def 'only'?
<spk121>daviid: we pull its memory size from the BaseInfo and allocate it as bytevector space. There is a goops that wraps the bytevector pointer, and it is the goops class that labels it as a GtkTextIter. So far haven't tried to write the struct accessors
<spk121>GtkTextIter doesn't have a C instantiation procedure, otherwise we would have just wrapped that
<daviid>spk121: help much apriaciated, tx ... so far, i've never had a make-c-struct failure upon any imported GI struct (in g-golf, but this is for info, it irrelevant to the instatiation bug, which strictly use guile functionality, GI struct are imorted as <gi-struct> instances
<daviid>spk121: unlike you seem to do, g-golf grabs the struct field types, then in thiscase guile isn't happy
<spk121>daviid: still haven't got around to actually doing struct fields on our side
<daviid>i could try to grab the base info size to, but now i dead curious why this failed - is it because of the void fields?
<daviid>spk121: ok, however, this is a guile bug, imo
<daviid>i'm clling make-c-struct passing 'valid' field types defined by gule, and 0 as the init val ...
<daviid>you can try in guile
<daviid>(make-c-struct '(0 0 8 8 8 8 8 8 0 0 8 8 8 0) '(0 0 0 0 0 0 0 0 0 0 0 0 0 0))
<daviid>this works - (make-c-struct '(8 8 8 8 8 8 8 8 8) '(0 0 0 0 0 0 0 0 0))
<daviid>which is the same as the above, but i removed the void (0 type def) from the feid def, and their corresponding 0 it vals ...
<spk121>the GTK+3 Reference Manual suggests that the struct is opaque and is supposed to be initialized by gtk_text_buffer_get_iter_*. I don't recall how that looks in its terminfo/gir.
<daviid>spk121: we must instantite initializa a pointer to a GtkTextIter, no matter what ... all these are out args ...
<daviid>spk121: hence you mus call make-c-struct, no matter what
<daviid>in this case, the C struct def includes a few void fields, that causes a bug in guile ...
<spk121>Yeah, that's why this one case is tough. GTK wants this one to be an opaque struct that you instantiate via malloc.
<daviid>spk121: but gtk surelly s enable to deternine from which lang the memory comes from?
<daviid>or am i being a bit ignorant here?
<daviid>spk121: do yu have a way to tell me what size guile-gi retruns for a GtkTextIter? removing these void fields, guile tells me it is 36
<spk121>daviid: dunno. The C docs say this is an opaque struct, that you don't instantiate it yourself, but, it doesn't supply a constructor, so you have to use a static C GtkTextIter or malloc one for yourself.
<daviid>we should be able to use make-bytestructure, but i'm going to ask on #introspection
<daviid>(sizeof '(8 8 8 8 8 8 8 8 8)) -> 36
<daviid>spk121: 0 is the type associated to void in guile scheme
<daviid> (sizeof '(0)) raises an exception
<spk121>I just wrote a C prog that did sizeof(GtkTextIter) and I got 80 on amd64
<daviid>(sizeof '(8)) -> 4 and so on ...
<daviid>ah, terrible haha
<daviid>what a mess
<spk121>lemme see what guile-gi thinks its size is
<daviid>it surely will answer to same i guess - i can immediately write a constructor in C, for g-golf, but when i can avoid writig C code, i try to avoid ...
<spk121>guile-gi says that g_struct_info_get_size(info) for GtkTextIter returns 80
<spk121>so maybe you need to compare your make-c-struct size to the struct-info-get-size, and if the differ, go for the bigger one?
<daviid>spk121: of curiosity, '(0 0 8 8 8 8 8 8 0 0 8 8 8 0) gives me 5 void fields, and (- 80 36) -> 44 is not even divisible by 5 ???
<daviid>spk121: yes, that sounds a good remedy
<daviid>but i am a bit unhappy :):) so to speak
<daviid>spk121: by the way i can't compare because it raises an exception
<daviid>spk121: do you happen to know what this is supposed to tellus? g_struct_info_is_foreign
<daviid>it returns a boolen
<daviid>it that is opaque, then yes, i can use the struct-info size and use 0 as its iit val ...
<daviid>spk121: i didn't even bind g_struct_info_get_size yet, nor g_struct_info_is_foreign
<daviid>i'm going to do that right now
<daviid>there is the g_struct_info_get_alignment as well
<daviid>but so far i use guile's alignment (@@ (system foreign) align)
<spk121>OK. The 80 bytes should be chunked up as 8 8 4 4 4 4 4 4 8 8 4 4 *4* 8. the 4 are ints. the 8 are pointers, and the *4* is a padding that will be inserted on 64-bit systems to keep the last pointer aligned on an 8-byte.
<spk121>Or the last two might be 8 *4*.
<daviid>spk121: given the def i receive, is there any chance to write a robust algo to do this in scheme?
<daviid>i'm going to enhance <gi-struct> so it lists the size and the alignment as well, s we can check those on the fly ...
<daviid>spk121: thanks a lot for your help
<spk121>daviid: no prob. good luck
<daviid>i'll get hose binded i 10min or so ...
<daviid>be right back
<daviid>is gsize site_t in guile?
<daviid>spk121: here is what i get http://paste.debian.net/1099601/
<jcowan>I use emacs from the command line to justify Lispy code, even though I don't edit with it.
<daviid>have to leave, the place i'm is closing ... bbl tx again
<civodul>Hello Guilers!
<weinholt>good morning
<rain1>hi :)
<lloda>it seems you cannot have a docstring in a macro def, any ideas?
<civodul>lloda: you can have a docstring in syntax-rules and syntax-case
<civodul>like this: (define-syntax foo (syntax-rules () "docstring" ...))
<civodul>or: (define foo (lambda (x) "docstring" (syntax-case x () ...)))
<lloda>ooh thx civodul
<lloda>I was trying in the wrong places
***adriano is now known as Guest95484
***adriano is now known as Guest57378
<heisenberg-25>Anyone has this error?
<heisenberg-25>GC Warning: Repeated allocation of very large block (appr. size 66064384):
<heisenberg-25> May lead to memory leak and poor performance
<lloda>heisenberg-25: all the time
<lloda>I just ignore it
<heisenberg-25>lloda: so would it cause performance degradation like it says?
<lloda>heisenberg-25: it probably does... if you have a long running program that has this issue, there might be large gc pauses sometimes. You may want to change your program to allocate once and then reuse or something.
<lloda>I guess you'd need to profile
<lloda>when it happens to me it's because I really need to allocate 10 big arrays, so there's no way around it
<lloda>10 or however many
<lloda>if you search guile-user or guile-devel, there may be more info about this. I think it's come up a few times
<lloda>there are some environment variables that you can use to control the GC, should be in the manual
<dsmith-work>{appropriate time} Greetings, Guilers
<civodul>heya, dsmith-work!
<wingo>weinholt: anything other than else and => ?
<wingo>as far as aux keywords go i mean
<wingo>maybe i should define _ as well
<wingo>... also
<wingo>as the r6rs says
<jcowan>You should bind all of (else => unquote unquote-splicing _ ...)
<wingo>tx
<wingo>i think unquote and unquote-splicing are already done
<wingo>was just else => _ ...
<wingo>hum, _ versus gettext :P
<jcowan>yes, I always thought _ was unschemely
<wingo>hehe
<jcowan>spell out the syntax keyword, dammit.
<wingo>civodul: so some macros (e.g. syntax-case) will use _ as an aux keyword. currently in guile, _ is not bound so those macros succeed as long as _ is not defined in the module. do you run into this problem when you use gettext
<wingo>i like using _ but yeah a bit of a mess
<wingo>also i wonder what racket does
<civodul>wingo: we had problems when switching to 2.2 because we were using _ for gettext
<civodul>so we renamed _ to G_ :-)
<civodul>(in Guix)
<wingo>:)
<civodul>the status of literals is a bit weird
<wingo>and xgettext or whatever is happy to do G_
<wingo>ok.
<civodul>yeah, you can use whatever you want
<civodul>i don't think you need to bind _, though
<wingo>i was thinking, what if we did (define (_ . args) (error "bad usage of _")) ; and then programs wanting gettext would (set! _ gettext)
<civodul>_ is not like 'else', for instance
<wingo>civodul: so -- r6rs and r7rs specify that _ is bound
<civodul>oh
<wingo>yeah
<civodul>r6 even?
<wingo>yeah
<wingo>because syntax-case
<wingo>syntax-rules also
<civodul>but syntax-{rules,case} don't do anything special with _, do they?
<civodul>one could just as well write "foobar"
<wingo>of course they do! (define-syntax-rule (foo _ _) 42)
<wingo>that's different than (define-syntax-rule (foo a a) 42)
<wingo>latter is an error i think
<wingo>_ is used in `match' as well as an aux kw
<wingo>not r6rs tho
<civodul>ah true!
<wingo>anyway the same arguments that apply to 'else' apply to '_'
<civodul>i see now
<civodul>well, let it be bound
<wingo>and i'm sure like me you've been tripped up from time to time by (lambda (_) .... (match x (_ . ) ...))
<civodul>yep, but i wasn't surprised :-)
<wingo>er, not quite syntactically correct, but you see the point (in the match _ is not recognized as a kw)
<civodul>yeah
<wingo>still not sure whether to make _ a syntactic binding or a "normal" binding. the standards specify syntactic, though currently in guile there is little different from an aux kw perspective
<wingo>syntactic i guess would be the thing
<wingo>i bet the manual tells people to (define _ gettext) :P
<wingo>it does, hehe
<wingo>civodul: do you think we should switch _ to be bound then? i guess gettext-related issues are already shaken out by 2.2 ?
<wingo>the whole aux-keywords-are-bound thing is a little weird to me, but it's consistent and macro nerds seem to want it, so i guess we can do that
*wingo a nerd for many things but not a high-culture macrologist
<civodul>wingo: in 2.2 you already run into troubles if you (define _ gettext)
<civodul>so in that sense, it seems to be quite safe
<civodul>we should maybe double-check on a few packages
<wingo>hehe wow, that was a bit of past incompatibility that i hadn't accounted for
<wingo>friggin americans
<wingo>no concept of other languages ;)
<wingo>well, good. in that case i will update the manual and make _ bound, removing a gratuitous r6/r7 incompatibility
<enderby>hi, which is "best practice" - using rnrs versions of modules or the srfi version?
***karlosz_ is now known as karlosz