IRC channel logs


back to list of logs

<daviid>lloda: (or any bytevector 'pro') any idea why i don't ge twice the same value?
<RhodiumToad>the index in bytevector-uint-ref looks like it's in bytes, not units of the specified integer size?
<daviid>RhodiumToad: the index, becaue tha's what i thought it should be, is the index :), just like vector-ref ...
<daviid>and i thought bytevector-uint-ref were going to compute the exact locaion i mem bsd on the index, e-ness and u-size, precisely
<jcowan>The entire (rnrs bytevectors) library uses byte indexes
<daviid>the manual shoud call these acrgument byte-index
<daviid>not to confuse users with what the index is, like in list-ref, vector-ref ...
<jcowan>Well, it is a bytevector library. It's not meant to do what SRFI 4 does
<daviid>and what is a byte index?
<jcowan>(Although there is an implementation on top of SRFI 4)
<daviid>jcowan: it shuld not use names that are commonly used in other context as for what they are, then change they siginificat ...
<daviid>but anyway
<jcowan>sorry, I meant there is an implementation of SRFI 4 on top of rnrs bytevectors
<daviid>not talking about that
<daviid>talkg about bytevector-uint-ref
<daviid>and frends
*jcowan nods
<RhodiumToad>if the index were in units of the size, it would be impossible to do unaligned fetches?
<jcowan>The elements of a bytevector are bytes
<jcowan>so you'd expect a bytevector library to index bytes, just as a list/vector library indexes list/vector elements.
<daviid>i'm sorry, i didn't
<daviid>an index, ever since i whent to the fac, is a postion, not a size/position
<daviid>anyway, no worry
<daviid>but i still don' tknow what my 'i' should be
<daviid>could you patch y example
<daviid>pleae, so i can learn wha the hell is a byte index :)
<daviid>ok i got it
<daviid>(bytevector-uint-ref bv (* i u-size) e-ness u-size)
<daviid>i thought, you got that, but for others ... that bytevector-uint-ref was doing this 'for us', using i as an index, then u-size and e-ness ... i wa wrong
<daviid>RhodiumToad: why did you think it couldn't fetch, if we pass a 'normal index', since it has the data to compute the byte index?
<RhodiumToad>suppose you have 6 bytes of which the first 2 are a uint2 and the next 4 a uint4
<RhodiumToad>how do you propose to access the uint4, if not by a byte index?
<daviid>this would break bytevector->uint-list, which is the context I was refering to, obviously ...
<RhodiumToad>it wouldn't work with bytevector->uint-list, correct
<RhodiumToad>but then who said it should?
<daviid>but anyway, lets hack, i still think 'index' is a wrong name for any bytevector proc
<daviid>unfortunately, the manual only shows an example of 4 bytes addressed on a per byte, so the index is a 'real index' ...
<RhodiumToad>the docs could be clearer, yes
<daviid>i think we could patch the doc with your example
<nly>hi ahungry
<nly>is there any good resource for writing portable scheme?
<chrislck>sneek: tell faLUCE
<sneek>faLUCE, chrislck says:
<jcowan>nly: The R5RS, R6RS, and R7RS standards.
<faLUCE>hello. Which is there right syntax for redefining a function of a module? (module-define! mod 'function-name ... ?
<rgherdt>from the REPL you can either switch to the module with ,m and define the function, or you can use the ,in syntax
<rgherdt>,help module
<lloda>daviid: you can do stuff like (s32vector-ref BYTEVECTOR i) in Guile and i is according to type (every 4 bytes in this case)
<lloda>you can also cast a bytevector to srfi-4 type with (bytevector->pointer ...) and (pointer->bytevector ...)
<lloda>these are in (system foreign)
<lloda>I think it's ill advised to use bytevector-type-ref at all unless you're really dealing with a blob and picking items out of the soup
<lloda>if you know something is a typed array, just use the srfi-4 functions :-/
<lloda>I remember someone in the mailing list who also insisted in counting bytes in a floating number array and I really didn't understand why
<lloda>it seems they were copying code from somewhere else and following a recipe
<lloda>in/on, I'll never get that right
<daviid>lloda: right, tx. but I wanted to understand my mistake while using bytevector-type-ref ... and because the context of this (for me) is GLib/GObject, where none of these byte vectors ever store different size values, it neve occured to me we could :), and hence, did not even think I had to cimpute the 'exact byte offset' myself ... but obviously, after jcowan and RhodiumToad explaination, I realize how 'brown bag' that was :)
<daviid>if only the manual had such an example, I would have spoted m istake myself ... maybe I'll submit a manual patch/enhancement
<daviid>now, I think bytevector->uint-list and friends are substantially faster then srfi-4 (?) but didn't benchmark
<str1ngs>hello daviid. I'm still trying to resolve this g-golf issue on guix. see
<lloda>,time (s32vector->list (make-s32vector #e5e6))
<lloda>;; 0.128391s real time, 0.128391s run time. 0.000000s spent in GC.
<lloda>,time (bytevector->uint-list (make-s32vector #e5e6) 'little 4)
<lloda>;; 0.569555s real time, 0.568521s run time. 0.000000s spent in GC.
<str1ngs>daviid: #:debut does not give more details other then can't constants that are not imported
<str1ngs>err #:debug
<daviid>lloda: ah, interesting! that's a surprise to me
<lloda>if it was the other way it would be a bug. I repeat myself but I don't see why people use bytevector functions for these things
<lloda>if the type is always X, use Xvector
<str1ngs>daviid: backtrace if it helps
<daviid>lloda: right, as I said, I wanted to understand ... but that srfi-4 is faster then (the C code) bytevector->uint-list is a bit of a surprise to me, I'll change that i my code then, thanks
<lloda>yw! still if it was slower, we should fix it instead of being forced to write needlessly low level code
<daviid>lloda: yes, agreed, but I'm glad I plaid a bit with all this ... I learned a few things while at it ... but i'll use srfi-4
<daviid>str1ngs: hello!
<daviid>str1ngs: can you locally modify a g-golf module on guix?
<str1ngs>daviid: yes not a problem. I'm using ./pre-inst-env
<daviid>ok, could you replace temp this def
<daviid>and try again
<daviid>str1ngs: in the (g-golf hl-api object) module
<str1ngs>i can, will need a few minutes
<daviid>str1ngs: actually this version instead, sorry:
<daviid>np, tke your time
<dsmith-work>Monday Greetings, Guilers
<daviid>hello dsmith-work! could you tll our bot to remember about this
<dsmith-work>sneek: guile-software is
<sneek>So noted.
<dsmith-work>sneek: guile-software?
<sneek>Its been said that guile-software is
<dsmith-work>sneek: botsnack
<dsmith-work>daviid: Unfortunately, there is currently no way to list remembered topics.
<daviid>dsmith-work: ok, it would be nice to have, but ...
<str1ngs>daviid: with (gi-import "Clutter") I get I truncated successful debug lines
<str1ngs>daviid: same error as well. ERROR: In procedure string-split:
<str1ngs>In procedure string-split: Wrong type argument in position 1 (expecting string): #f
<daviid>str1ngs: so, it should be
<str1ngs>daviid: ha I found the difference seems this does not happen with gobject-introspection 1.58.3. debian uses 1.53.3 guix is 1.60.2
<daviid>str1ngs: on debian buster, which i use, it is 1.62.0-2
<str1ngs>hmm don't get that on my debian buster 10
<str1ngs>apt show libgirepository-1.0-1
<str1ngs>Package: libgirepository-1.0-1
<str1ngs>Version: 1.58.3-2
<str1ngs>sorry for multiline paste, I was being lazy :(
<str1ngs>lsb_release -a is Description: Debian GNU/Linux 10 (buster)
<str1ngs>but this helps either way. if 1.60.2 works for you could be an issue with 1.62.0 . but also there is a patch in guix that does not apply to 1.58 so potentially that could be suspect.
<daviid>str1ngs: you're definitely not sing buster, becaue on buster, gi is 1.62.0-2
<str1ngs>deb buster main
<str1ngs>not sure how this could not be buster
<daviid>str1ngs: i am on buster
<daviid>and the version is 1.62.0-2
<daviid>but anyway, the problem is on guix you said
<str1ngs>okay so the main thing is 1.62 works for you to. I just need to figure out what the issue is with guix 1.60.2
<daviid>str1ngs: what is the clutter gir lib versio o guix
<daviid>i don't beleive it is a GI problem
<daviid>I beleive it is a gir problem
<daviid>on guix
<str1ngs>clutter is 1.26.2 note. guix does not split package the typelib. and I'm maybe a week behind master
<daviid>the function that returns #f is g-type-name, which is part of GObject Type-info, it probably works fine in any version ever, even the 0.1 decades ago
<daviid>i think, for some reason, the clutter gi repository is malformed
<daviid>on guix
<str1ngs>I can put a GJS test case together.
<daviid>on guix?
<str1ngs>the gjs GI is probably the best reference language
<daviid>yes, try
<str1ngs>okay will take some time to test this properly. this gives me a better idea as to where the issues is.
<daviid>try this
<daviid>in a guix repl
<daviid>after ,use (g-golf) and (g-irepository-require "Clutter")
<str1ngs>(g-irepository-find-by-name "Clutter" "PaintNode") gives me ** (process:576): CRITICAL **: 09:01:10.118: g_irepository_find_by_name: assertion 'typelib != NULL' failed
<daviid>yes, you need (g-irepository-require "Clutter")
<daviid>i pasted to quick ...
<str1ngs>which is the error I get when import Gtk
<str1ngs>okay no error with require
<str1ngs>(g-type-name $6) though returns #f
<daviid>right, and this is incorrect
<str1ngs>(g-type-name 196) simplifies the code
<daviid>but you don't know it will always be 196 :):)
<daviid>yu need the steps
<daviid>you may try using gjs
<daviid>'similar' steps
<str1ngs>with 1.58.3 I get "ClutterPaintNode"
<str1ngs>maybe C would be less abstraction
<daviid>if yu can try gjs, it would be better
<str1ngs>this helps though thanks.
<str1ngs>I will try with gjs, just can't do it right now. will probably later in the day.
<daviid>but using the exct same GLib, GObject, GI and Clutter/Cluuter gir lib of course ...
<daviid>which i am not sure it is possible on guix
<daviid>because gjs may have its own depenencies, that differs fro g-golf ..
<str1ngs>sneek later tell daviid will do. thanks again
<zig>hello guile!
<zig>there was an spam attack? again? I was quieted for a while.
<RhodiumToad>don't think so?
<zig>sneek: botsnack