<schaeffer>does anyone here write guile in an editor that isn't emacs? <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 :^) <spk121>schaeffer: what is a non-emacs that does decent auto-indent for scheme/lisp <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>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>(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 ... <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 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>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. <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 <daviid>i'll get hose binded i 10min or so ... <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 <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>I was trying in the wrong places ***adriano is now known as Guest95484
***adriano is now known as Guest57378
<heisenberg-25>GC Warning: Repeated allocation of very large block (appr. size 66064384): <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>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 <wingo>weinholt: anything other than else and => ? <wingo>as far as aux keywords go i mean <wingo>maybe i should define _ as well <jcowan>You should bind all of (else => unquote unquote-splicing _ ...) <wingo>i think unquote and unquote-splicing are already done <jcowan>yes, I always thought _ was unschemely <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>the status of literals is a bit weird <wingo>and xgettext or whatever is happy to do G_ <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) <wingo>civodul: so -- r6rs and r7rs specify that _ is bound <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>_ is used in `match' as well as an aux kw <wingo>anyway the same arguments that apply to 'else' apply to '_' <wingo>and i'm sure like me you've been tripped up from time to time by (lambda (_) .... (match x (_ . ) ...)) <wingo>er, not quite syntactically correct, but you see the point (in the match _ is not recognized as a kw) <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>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>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