IRC channel logs

<daviid>lloda: (or any bytevector 'pro') any idea why i don't ge twice the same value? https://paste.debian.net/1122187/

<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?

<daviid>*friends

<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>right

<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>hello

<ahungry>hi

<nly>hi ahungry

<nly>is there any good resource for writing portable scheme?

<chrislck>sneek: tell faLUCE https://github.com/Gnucash/gnucash/blob/maint/libgnucash/scm/utilities.scm#L175

<sneek>faLUCE, chrislck says: https://github.com/Gnucash/gnucash/blob/maint/libgnucash/scm/utilities.scm#L175

<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 http://paste.debian.net/1122356

<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 http://paste.debian.net/1122360

<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

<lloda>imo!

<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 http://paste.debian.net/1122368/

<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: http://paste.debian.net/1122371/

<daviid>np, tke your time

<dsmith-work>Monday Greetings, Guilers

<daviid>hello dsmith-work! could you tll our bot to remember about this http://sph.mn/foreign/guile-software.html

<dsmith-work>sneek: guile-software is http://sph.mn/foreign/guile-software.html

<sneek>So noted.

<dsmith-work>sneek: guile-software?

<sneek>Its been said that guile-software is http://sph.mn/foreign/guile-software.html

<dsmith-work>sneek: botsnack

<sneek>:)

<daviid>cool

<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 http://paste.debian.net/1122394. 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 http://paste.debian.net/1122396/

<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 http://deb.debian.org/debian/ 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>yes

<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 http://paste.debian.net/1122406/

<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>sorry

<daviid>i pasted to quick ...

<str1ngs>which is the error I get when import Gtk

<str1ngs>okay no error with require

<daviid>so?

<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

<str1ngs>understandable