IRC channel logs


back to list of logs

***apteryx is now known as Guest4530
***apteryx_ is now known as apteryx
***catonano_ is now known as catonano
***jonsger1 is now known as jonsger
<tohoyn>daviid: is it so that GValues should not be used by ordinary users of G-Golf?
<daviid>tohoyn: they souldn't have to - if you find (another) case where it seems to be the cae, probably the function or method should b overriden, let me know, and we can think about it ...
<tohoyn>daviid: gtk-container-child-get/set-property
<daviid>but in that case, you could use the property accessor on the child itself - i never used, never had to, what would be a use case that yu couldn't do that?
<tohoyn>daviid: child properties are different from ordinary properties. they are related to both parent and the child. the get/set functions take both the parent as a child as a parameter. are there accessors for these?
<tohoyn>daviid: see
<tohoyn>^parent and the child
<tohoyn>daviid: there seems to be an accessor for child property "expand" but it takes only one argument.
<tohoyn>daviid: that accessor is probably for ordinary "expand" properties
<tohoyn>daviid: there is a similar situation with propery/child property "position"
<daviid>tohoyn: I wrote a child-property.scm example when you first brought the subject, with an hpane and a vpane ... do you still have it? but i don't like it :), because the g-value must be initializd, then retreived ... it should dbe possible to override those i think
<daviid>also, we're in scheme, calling gtk-container-child-get-property and not receiving the value is 'damn wrong'
<daviid>i'll think about this - i never used those, of course i attach child, pass the pack-strt expand fill values, but never had to ask what thy are after that ...
<tohoyn>daviid: I still have the example
<tohoyn>daviid: probably the scheme version of child-get-property should return the value of the property instead of using a GValue.
<daviid>yes, but then it must be overriden, i didn't do that yet - i wonder what guile-gnome did
<tohoyn>daviid: guile-gnome version seems to take a GValue argument
<daviid>so it was not ovveriden then?
<daviid>anyway, will look into this - let's see ...
<janneke>hmm, in what module is sort defined?
*janneke tries to #:select ((sort . list-sort)) and find sort is not in srfi-1
<janneke>haha, it's in (guile) ... but so is sort-list
***catonano_ is now known as catonano
***gagbo__ is now known as gagbo
<dsmith-work>Happy Friday, Guilers!!
***jao is now known as Guest97871
<mwette>charsets don't use bitfields so for small sets memq is probably faster?
<mwette>memq w/ literal list, that is
*mwette is rewriting C99 preprocessor and ended up rewriting the number reader (num = integers, octal ints, hex ints, binary ints, floats, fixed-point and decimal floats); lot's of suffix combos to deal with
<RhodiumToad>I wouldn't expect memq to beat charsets
<RhodiumToad>not on any length of set
<justin_smith>for hash based lookup, it's usually only faster than linear search after ~16 items
<RhodiumToad>charsets don't actually use hashes
<justin_smith>oh cool, what do they use?
<RhodiumToad>looks like a linear search of ranges
<RhodiumToad>so I'd expect a hash to beat them for large sparse sets
<RhodiumToad>but simply on cache locality they'll beat out memq for any size
***rekado_ is now known as rekado
***hugh_marera_ is now known as hugh_marera
***jonsger1 is now known as jonsger