IRC channel logs

2020-06-21.log

back to list of logs

<dsmith>RhodiumToad: How goes the battle?
***terpri_ is now known as terpri
<RhodiumToad>the problem goes away at -O0
<RhodiumToad>which suggests either undefined behavior somewhere or a clang bug
<RhodiumToad>but it means more recompiles before I can make progress, so...
<dsmith>You got a rarely used os, a rarely used compiler, and rarely used hardware.
<dsmith>Lots of places for problems to show up.
<dsmith>(rarely used for Guile)
<apteryx>rekado: about the ~A, right I saw that too, and tried to fix it in http://issues.guix.gnu.org/41956, but failed so far
<RhodiumToad>ARGH
<RhodiumToad>(yes, that's an "I found the bug and it's stupid" kind of ARGH)
<RhodiumToad>ok. so too sleepy now to figure out what the code should actually be doing, but at least I've pinpointed why it breaks
<RhodiumToad>seems to be some disagreement over whether a uint8_t passed on the stack (rather than in a register) actually needs to be extended to 32 bits
<RhodiumToad>(caller thinks not, callee thinks yes, result is a value that was supposed to be 0 is ... not 0)
<daviid>leoprikler: would you have a more specific example, not sure I understand the scope of your warning :) - in g-golf, functions are never 'turned' into methods, so that exclude GLib potential name 'clashes' as a all
<RhodiumToad>sneek, later tell civodul I've identified the bug, fixing it shouldn't be too hard but I need sleep first
<sneek>Will do.
<RhodiumToad>looks like gcc and clang might be disagreeing over how the calling convention works, which would explain why it doesn't fail on gcc
<RhodiumToad>reading the arm specs, it looks like clang is assuming the caller is following the spec whereas gcc is a bit more conservative, and the JIT code generation is violating the spec
<tohoyn>sneek, botsnack
<sneek>:)
<tohoyn>daviid: there is a bug in g-golf. see https://paste.gnome.org/pubonddxl and https://paste.gnome.org/pe0kavzhs
<tohoyn>daviid: to reproduce the bug run command "guile -s koe6.scm"
<tohoyn>daviid: it reports that "raise" is undefined
<daviid>tohoyn: you might as well import the all Gtk namespece ... but you shouyld _never_ import anything from GObject - things from GLib, GObject are manually binded, for boostrap purposes ...
<daviid>wjay os this supposed to do? what is raise? how could you call vector on it ...
<tohoyn>daviid: "raise" raises an exception. In Theme-D it is set as a component of a vector.
<tohoyn>daviid: because Theme-D implements objects as vectors at the low level
<tohoyn>daviid: the error remains even though I remove the two GObject entries in koe5.
<daviid>tohoyn: yes, I was telling not to ever gi-import from GLib or GObject
<daviid>after you import one of the namespace name, raise becomes a generic functin
<daviid>*function
<daviid>tohoyn: I was working, yesterday, on a mechanism not to generate generic function and methods short names - that will fix your problem I guess - I didn't push yet because I am hesitating on the name of the uer varible ...
<apteryx>is there a way to run a locally built guile?
<apteryx>something like Guix's pre-inst-env script would be neat
<daviid>apteryx: yes, look in the ./meta subdir, there is uninstalled-env, read the comment in this file, it exlains what it does and how to run it ...
<tohoyn>daviid: FYI, Theme-D-Golf uses Theme-D generic functions for the short method names.
<daviid>tohoyn: I don't know what you do, but raise becomes a generic function after importing koe5
<tohoyn>daviid: but it should be visible in koe6?
<daviid>tohoyn: do you know which namespace name has a long name method that becomes 'raise'?
<apteryx>daviid: thanks! now I need to figure out why guile-readline doesn't seem to be built
<daviid>once 'shorten'
<tohoyn>daviid: raise is not a GOOPS method
<tohoyn>daviid: AFAIK
<daviid>i know
<daviid>it is a procedure, it becomes a generic function after you import ... i'd like to figure out what namespace name
<daviid>'provoques' it to become a generic functin ...
<tohoyn>daviid: If it is a G-Golf method you probably know it better
<daviid>it's not
<daviid>ah it is a gdk method
<daviid>gdk_window_raise
<daviid>tohoyn: so, there is no g-golf bug here
<tohoyn>daviid: we have a duplicate method name here
<daviid>tohoyn: I am hapy to help, but it is not a g-golf bug
<tohoyn>daviid: because raise is defined by the guile exception system
<daviid>tohoyn: I think, to make it simple for you, that you are among those users that will prefer not to generate short named generic functions
<tohoyn>daviid: yes
<daviid>okj, give me a few minutes, I ll push
<tohoyn>ok
<daviid>tohoyn: pushed - so now you may call (set! %gi-method-short-names-skip 'all) after you imported g-golf, to skip all method (gf) short name generation
<daviid>the default value is to generate all generic function short names
<tohoyn>daviid: it works. tx.
<daviid>perfect, wc
<leoprikler>daviid: IIUC "short name" generation does actually generate methods, does it not?
***apteryx is now known as Guest64543
***apteryx_ is now known as apteryx
<leoprikler>And a method being named "begin" or "raise" can cause issues with Guile internals.
<tohoyn>FYI: Theme-D-Golf version 0.8.3 has been released. See http://www.iki.fi/tohoyn/theme-d-golf/ .
<tohoyn>Changes: Updated for changes in G-Golf
<leoprikler>In Guile-GI, there is a similar potential for overriding core functionality with bogus. It's usually not that bad, because the correct method can be dynamically resolved in GOOPS, but that does not work for syntax.
<leoprikler>e.g. you won't have an issue with "connect" due to different arguments, but you will have one with "lambda" (good thing that there's no GLib lambda)
<daviid>leoprikler: GLib will never lead to a problem, there is no mthod in GLib, afaict - procedures should not (never) be a problem, raise is not a problem, it was a miss use by the user. syntax won't work, if you can point to a GObect long nam method that would short named to a guile core syntax, I'll use tht to come with a solution
<leoprikler>Gtk.SourceGutterRenderer.begin
<leoprikler>Gcr.SecretExchange.begin
<leoprikler>Gda.XaTransaction.begin
<leoprikler>Pango.Renderer.begin
<leoprikler>Gtk.Gesture.begin
<leoprikler>Tracker.DataProvider.begin
<leoprikler>I think you'll find more methods named "begin", but those were some of the top ones suggested by valadoc.
<daviid>Gtk.Gesture.begin is a signal, not a method
<daviid>but i'll look into this potential problem, tx
<daviid>i think all you posted are signals, not methods
<leoprikler>DataProvider is an abstract method according to Vala.
<leoprikler>SecretExchange is not even abstract
<leoprikler> https://developer.gnome.org/gcr/unstable/GcrSecretExchange.html#gcr-secret-exchange-begin
<dsmith>RhodiumToad: Wow.
*RhodiumToad yawns
<RhodiumToad>bleh. fixing this might not be simple.
<RhodiumToad>might need to talk to wingo about it
***roptat_ is now known as roptat
<dsmith>Hah. Here is that windows stack thing I was vaguely remembering: https://gitlab.com/wingo/lightening/-/commit/a96c0188f196acb46fdee3bd0c20575db6c945a9
<RhodiumToad>so, opened an issue for the arm thing
<dsmith>RhodiumToad: So is the problem clang is pushing a byte with garbage 32bits, or is it jit code doing that?
<RhodiumToad>when passing a value smaller than a word, the jit is writing only part of a word to the stack, leaving the other bytes undefined
<RhodiumToad>e.g. passing a byte by doing mov.w r0, #xx str.b r0, [sp]
<dsmith>Ok.
<RhodiumToad>however, the function being called is allowed to assume that the word at [sp] is all valid, containing the parameter value widened to 32 bits
<RhodiumToad>and clang indeed makes this assumption, so for example it will test for a zero by loading the whole word and seeing if it's zero
<RhodiumToad>so the error I get occurs because the jit code stored 0 but the called function thought the value was not 0
<dsmith>Looks like the x86-cpu code is doing sign extension, so maybe it's DTRT. Arm might need to do that
<RhodiumToad>no, this looks like a fundamental defect in the lightening code; consider for example abi_mem_to_mem
<RhodiumToad>if you have a parameter value which is in memory and smaller than 32 bits, then the load of the value and the following store have to be different sizes.
<RhodiumToad>e.g. ldr.b r0, [r1] str r0, [sp]
<dsmith>Hmm.
<RhodiumToad>though, hmm, that could still be fixed in abi_gpr_to_mem
<civodul>woow, great debugging session, RhodiumToad
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, RhodiumToad says: I've identified the bug, fixing it shouldn't be too hard but I need sleep first
<civodul>so it really happens with Clang specifically, right?
<RhodiumToad>but abi_gpr_to_mem doesn't seem to have any scope for cpu-specific behaviors as written
<RhodiumToad>gcc seems to generate ldr.b rather than ldr when reading the parameter value, which is why it doesn't obviously fail
<dsmith>Calls jit_stxi_c (really stxi_c in the *-cpu.c)
<RhodiumToad>however, it seems to me that it would be completely wrong in the big-endian case? does anyone run arm in big-endian mode?
<civodul>RhodiumToad: could you add a reproducer in https://gitlab.com/wingo/lightening/-/issues/15 ?
<civodul>is ARM in big-endian a thing?
<dsmith>Can be
<slyfox>ARM can be BE, yes
<civodul>i mean, the widespread CPUs don't support it, do they?
<slyfox>AFAIU most of them don't (maybe it's a firmware issue?)
<dsmith>I don't think so. No longer acive in Debian. (was for a time)
<civodul>ok
<RhodiumToad>details added to the issue
<civodul>awesome, thanks
<RhodiumToad>one can imagine that one reason why the ABI specifies things the way is does is that a function might want to load multiple args from the stack using one ldr instruction
<RhodiumToad>I don't know if any compilers actually do that, but it's clearly allowed
<RhodiumToad>er, ldm I mean
***sneek_ is now known as sneek
<civodul>so i'll tag 3.0.3 with what we have now, because there are already important fixes and improvements that have accumulated
<RhodiumToad>ok.
<civodul>thumbs up for all the fixes already committed!
<RhodiumToad>that should at least get it working with gcc
<civodul>(no pun :-))
<civodul>yeah
<mwette>RhodiumToad: Where does the optimization fit in?
<RhodiumToad>what optimization?
<RhodiumToad>oh, you mean why it goes away with -O0?
<RhodiumToad>my guess is that that makes it more likely that the stack slots happen to contain 0s in the unassigned bytes
<RhodiumToad>nope
<RhodiumToad>what actually happens at -O0 is that bind_kwargs copies the values of the parameters into local stack slots, as uint8_t
<RhodiumToad>so the undefined bytes get masked off again.
<mwette>thanks
<tohoyn>FYI: Theme-D version 3.0.4-1 and Theme-D-Gnome version 0.9.4-2 have been released. See http://www.iki.fi/tohoyn/theme-d/ and http://www.iki.fi/tohoyn/theme-d-gnome/ .
<chrislck>any match experts here? why would 2nd version be erroring out
<chrislck> https://paste.debian.net/1153188/
<chrislck> (define y (make-string-database-2 ))
<chrislck> (y 'store 'b "beta)
<chrislck><unnamed port>:11:2: Wrong number of arguments to #<procedure 55a3d865e860 at <unknown port>:11:2 (expr)>
<chrislck>is this a match.scm bug/wart?
<RhodiumToad>that's not quite correct usage of match-lambda
<RhodiumToad>(define (x) ...) already implicitly does (lambda () ...)
<wklew>I think that was the goal, the first version does the same
<RhodiumToad>to use match-lambda, you'd use (define make-string-database-2 (let ((string-hash (make-hash-table))) (match-lambda ...))
<wklew>I can't find anything wrong with it
<RhodiumToad>oh
<RhodiumToad>my mistake, the problem seems to be simply that you wanted match-lambda*
<RhodiumToad>match-lambda creates a function of 1 arg
<chrislck>oh that's right
<chrislck>still no
<chrislck>ah works yes
<chrislck>ty :)
<dsmith>RhodiumToad: Was just looking at the arm opcodes. strb (immediate) does zero extension, while strb (register) does not.
<RhodiumToad>uh?
<RhodiumToad>the immediate in strb is part of the address, not the data
<dsmith>Maybe I'm misreading. AHh, zero extends the address.
<RhodiumToad>strb as the name suggests is storing a byte into memory. just one byte.
<dsmith>I guess it's meant for storing individual bytes in a string..
<mwelt>Hi all. Short question on POSIX File System procedures. Refering to the documentation there's scm_mknod ( path, type, perms, dev ) for creating, inter alia, symlinks.
<mwelt>My question would be, how to define the source of the link, if there's only a single path input oportunity?
<RhodiumToad>mknod is not how you create symlinks...
<RhodiumToad>(you want the symlink function for that)
<mwelt>RhodiumToad: theres the keyword 'symlink for scm_mknod, that's why I was under the impression this might indicate the correct procedure.
<RhodiumToad>mknod used to do a lot more than it does now (and when I say "used to", I mean in the 1980s or so)
<mwelt>RhodiumToad: and what would this 'symlink function' be? The search in the documentation only returned this scm_mknod procedure.
<RhodiumToad>-- Scheme Procedure: symlink oldpath newpath
<mwelt>Thanks a lot. Are these procedures also part of the main documentation? If so, why is it so hard to find :)
<dsmith>Looks like a bug in the docs to use mknod for creating a symlink.
<RhodiumToad>that's under Guile Modules > POSIX > POSIX System Calls and Networking > File System
<RhodiumToad>mknod is kind of a raw low-level interface, way back in the day it was used for stuff like making directories
<mwelt>Ah it's actually the same document I was looking into ^^ sorry
<RhodiumToad>so in theory it can make any kind of inode, but in practice these days it's obsolete
<RhodiumToad>maybe linux still uses it for device nodes, I don't know (I don't use linux)
<RhodiumToad>the fact that you can specify any type of file is just to allow you to specify any value for the file type bits for the mknod() system call, it doesn't actually mean that they do anything useful
<dsmith>Yes, pretty sure you use mknod for that. Though that's often done to udev or something now. Not usually done "by hand"
<RhodiumToad>on freebsd, you can use mknod to make device nodes on a normal filesystem, but such nodes have been inert since freebsd 6
<RhodiumToad>actual device access is done via the devfs file system
<mwelt>ok I understand. Thanks for clarifying things up!
<RhodiumToad>and devfs creates and removes entries itself as directed by the underlying drivers
<mwelt>I am fairly new to guile. Did some chez scheme years ago came back to it now I fiddle around with guix. Thought it would be some kind of 'idiomatic' to write some scripts in guile.
<dsmith>RELEASE!!
<civodul>YES!
<civodul>3.0.3 is out!
<civodul> https://www.gnu.org/software/guile/news/gnu-guile-303-released.html
<civodul>well the page is on its way
***ChanServ sets mode: +o civodul
***civodul changes topic to 'Welcome to #guile. See https://gnu.org/s/guile for more information. Guile 3.0.3 is out! <https://gnu.org/s/guile/news/gnu-guile-303-released.html>. This channel is logged, see <http://logs.guix.gnu.org/guile/>. Bug database at <https://bugs.gnu.org/guile>.'
<civodul>big thanks everyone!
<slyfox>yaaaaaaaay! \o/
<janneke>civodul: \o/
<daviid>congrat! all, wow, 170 commits, 17 contributors ... amazing, well done all!
<daviid>I was looking at tje libraries page (out website) and spoted a few tipo/mistake - I don't have guix so I'll write about those here, just a few
<daviid>guile-studio says it is guile, including the url
<daviid>guile-lib says it works with 3.0, 2.0, but it works with 2.2 as well
<jcowan>Where is the 3.0.3 `pipeline` procedure documented, if anywhere?
<civodul>there's a link in the announcement on the web site
*civodul -> zZz
<jcowan>ta
<civodul>happy celebration, Guilers! :-)
<dsmith> https://www.gnu.org/software/guile/manual/html_node/Pipes.html#index-pipeline
<jcowan>okay, was hopimng for more details than that someplace, but thanks