IRC channel logs

2021-08-02.log

back to list of logs

<daviid>vijaymarupudi: the url you pasted privately were https://paste.gnome.org/pbceokaf6 and https://paste.gnome.org/p8b2lsbwm - i prefer if you (always) use paste.gnome or paste.debian ... but now i don't need any, tx
<vijaymarupudi>daviid: Debian seems to think I'm pasting spam for some reason
<vijaymarupudi>Oh well haha
<vijaymarupudi>I know my code can be bad, but Debian gives me the honest truth
<daviid>vijaymarupudi: it happens to 'all of us', when that happens, prefer https://paste.gnome.org/ scheme mode ...
<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
<daviid>ah, gotit, nevermind
<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 did this bandaid change to confirm and it stopped the iters in my program from becoming invalid: https://pastebin.com/raw/pB56NrzK
<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
<daviid>clone: ok
<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
<leoprikler>doesn't gnome have js tho?
<manumanumanu>i believe it works without scripts
<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>note that (vector? a) is #f
<lloda>also stuff like (vector-ref a 0) etc already doesn't work
<roelj>Are there RPMs for Guile >=2.2 for CentOS 8?
<RhodiumToad>lloda: what do you want to break exactly?
<lloda>(vector-copy a) should be an error because a is not a vector
<RhodiumToad>that doesn't seem useful
<lloda>what doesn't seem useful?
<RhodiumToad>having it be an error
<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>there is array-copy
<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>arrays can have a step != 1
<lloda>and refer to a piece of some other vector, that is they don't own their storage
<RhodiumToad>yes, so?
<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.
<leoprikler>yeah, and?
<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>let me put it this way
<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
<lloda>search for '0 in https://www.gnu.org/software/guile/manual/html_node/Formatted-Output.html
<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?
<b4283> https://en.wikipedia.org/wiki/Singularity_%28operating_system%29
<b4283>原來 MS 早就已經用 C# 寫過一個 kernel
<apteryx_>oh, seems there's module-reverse-lookup
<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>hi apteryx_!
<civodul>apteryx_: in general, you can't rely on module-private variables existing at run time
<civodul>they can be inlined
<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_>this works, but still feels convoluted :-) https://paste.debian.net/1206363/
<apteryx_>more correct version https://paste.debian.net/1206369/
***apteryx_ is now known as apteryx