<vijaymarupudi>daviid: Debian seems to think I'm pasting spam for some reason <vijaymarupudi>I know my code can be bad, but Debian gives me the honest truth <daviid>in a few hours debian will 'clear' your name from paste spamers ... :) <daviid>any one knows what i need to put in my .emacsso M-x run-python startspython3? <daviid>'no matter what' (i triedso far), it starts Python 2.7.18 <dsmith>manumanumanu: "dragon-infested" ? <clone>daviid: I think I found a bug in g-golf. My GtkTreeIters were randomly becoming invalid in my g-golf program, but not in an equivalent python program. <clone>i think the issue is in function.scm:1065, in the prepare-gi-args-out function. You do (bytevector->pointer (make-bytevector.. and I think the bytevector is getting garbage collected <clone>i'll try to make a simple program to reproduce but since it's related to garbage collection i'm not sure how to make sure it triggers <daviid>clone: tx, will look at your patch - could you please not use pastebin.com, tx <daviid>clone: invalid as in #f? or did this crashed g-golf? <daviid>clone: that seens a very nice catch, have to confirm, but tx! <clone>invalid as in (gtk-tree-store-iter-is-valid) returned #f. Parsing it as a struct showed random values <clone>thanks for looking at it, i'll try to remember to use a better pastebin next time <daviid>clone: yes, please prefer debian, gnome, sourcehut ... paste services, no js, no tracking ... tor-friendly ... tx <lloda>do we need a deprecation cycle to break (define a (make-shared-array (make-array 3 3 3) (lambda (j) (list 1 j)) 3)) (vector-copy a) <lloda>also stuff like (vector-ref a 0) etc already doesn't work <roelj>Are there RPMs for Guile >=2.2 for CentOS 8? <lloda>(vector-copy a) should be an error because a is not a vector <lloda>why not? a isn't a vector. Most vector functions won't work on it. And that's for a good reason. Having vector- functions support arrays makes vector depend on array depend on vector. It was a mess and we already got rid of most of it. <lloda>i just want to finish the job <leoprikler>If it makes stuff cleaner, then having a separate array->vector is all fine, but I don't really get what's wrong on the outside either <lloda>array-copy returns a vector if the result has rank 1 <lloda>well if the type is #t, also <lloda>it's a burden to support such things. We don't support (list-copy vec), even tho it's well defined <RhodiumToad>an array with rank 1 and lower bound 0 seems to be a vector for almost all purposes <lloda>and refer to a piece of some other vector, that is they don't own their storage <lloda>they are just different types. The vector- ops aren't polymorphic, they apply to the vector type. If you need a polymorphic api, the array- api does that. <lloda>it's not enough that something is 'functionally' equivalent to a vector. We don't support (vector-copy #f64(...)) either, for the same reason. I think i'm repeating examples. <lloda>it is a burden to the implementation for vector-copy to support 'some' non-vector arrays. <lloda>it isn't a burden to the user to use array-copy when the object they're dealing with isn't a vector. <lloda>actually i think it's a burden to the user for (vector? a) to return #f and (vector-ref a i) to return an error and yet (vector-copy a) to magically work <dsmith>roelj: Not built/distributed by the Guile project. Check your distro. <roelj>dsmith: Thanks, I thought at least one Guiler would've run into a RHEL 8 derivative with an outdated Guile and would have a pointer to an additional repository. :) <roptat>can I get something like number->string to complete with leading 0s? like 2 -> "002", 15 -> "015", 452 -> "452"? <lloda>format from (ice-9 format) does that <dsmith>roelj: I suspect most run Guix these days. I'm somewhat partial to Debian myself. <roelj>dsmith: Ahyes, I produced a Guix pack and untarred it on the RHEL8 machine, works beautifully ;) <roelj>It's unfortunate tho that it seems Guile is getting behind in the RHEL distributions. <apteryx_>having a handle to an object, how would I find the symbol its associated with? Is there some reflective procedure to do that? <apteryx_>seems I must manually search the exported variables with module-map? <apteryx_>but most introspection procedures appear to operated on variables made via `make-variable', which (define myvar "some-value") isn't, for example. <apteryx_>map-module is useful in that it allows a procedure passed to it to access both the symbol and the variable (as a boxed variable), but it does so only for public variables, not variables in the local scope. <civodul>apteryx_: in general, you can't rely on module-private variables existing at run time <civodul>that's why you may or may not see them when iterating on a module's set of variables <apteryx_>civodul: hi! :-) OK. In my case the variables are actually public (package variables). I think I've nearly found a Guix-specific way to get to it, but it feels convoluted (and doesn't work yet): https://paste.debian.net/1206360/ ***apteryx_ is now known as apteryx