<chrislck>mauritslamers: your function is fine. you can used named let for the state variables. <rekado>gah, the rebase is really tricky <rekado>Emacs 25 changed the way symbols are represented internally ***wxie1 is now known as wxie
***wxie1 is now known as wxie
*terpri_ way behind on guile-emacs rebasing ***catonano_ is now known as catonano
***wxie1 is now known as wxie
***terpri__ is now known as terpri
<daviid>I pushed an important patch, to the G-Golf repo, devel branch: "Methods - Both long and short name generic functions" // this is an important milestone, for G-Golf, because till now, GObject methods were actually imported as procedures. They are now imported as goops methods. In addition, G-Golf also provides short name generic functions and method, 'just' like guile-gnome. <daviid>sneek: later tell tohoyn I pushed an important patch, to the G-Golf repo, devel branch: "Methods - Both long and short name generic functions" - please pull, make ... and see if everything is ok <conjunctive>Hi, I was wondering, how would you limit read-line to 512 characters in the context of the Fibers ping-server example? <leoprikler>daviid so I can do stuff like (destroy window) now just like in Guile-GI? <RhodiumToad>gmake[2]: *** [Makefile:2279: ice-9/iconv.go] Segmentation fault (core dumped) <RhodiumToad>this is with alsr on, so it may of course only happen with particular choices of memory addresses <RhodiumToad>the last mov/ldrt error was with alsr off but threading on <civodul>bytevector-u32-native-set! is mis-cross-compiled on master and not in 3.0.2 <civodul>generated CPS is the same as if the "target" fluid was ignored <civodul>but i can't find where that expansion happens <RhodiumToad>random guess, is this related to the change on Jun 1 that makes -O1 also do resolve-primitives? <civodul>the starting point of all this is that .go files under prebuilt/ for 32-bit platforms are miscompiled <RhodiumToad>miscompiled only for endian-mismatched platforms or for all? because presumably an issue with bytevector-u32-native-set! would only be a problem in the event of endian mismatch <civodul>RhodiumToad: AFAICS it's really just the word size that's problematic <apteryx>what's happen when a guard close is missing an "else" for unknown condition types? The doc suggests it get rethrown but I'm not sure. <apteryx>nevermind, it seems to be related to the kind of exception that `canonicalize-path' throws <apteryx>consider this: (guard (c ((message-condition? c) (format #t "error: ~a: ~a~%" "fixed-arg" (condition-message c)))) (canonicalize-path "/doesntexist")) --> error: fixed-arg: ~A: ~S <apteryx>why doesn't the formatted string get produced right? <guix-vits>dsmith-work: Thanks. Is sneek doesn't accept "later tell" from inside of '/query' any more? <civodul>dsmith-work: how's your debugging journey going? <civodul>i just fixed that cross-compiled .go bug <civodul>i'm testing it, but if everything goes well, all the lights are green for me <dsmith-work>single threaded seems to make it happen less often, but does not eliminate. <dsmith-work>I tried to do a bisect on make check. GUILE_JIT_STOP_AFTER=1384 fails. 1383 works <civodul>yeah, turning ASLR off is a good way to make bugs reproducible <civodul>meanwhile i'll test on the machines i have access to <civodul>is it OK if we release 3.0.3 ASAP and leave the bug fix you're working on for 3.0.4? <civodul>except for a statically-linked Guile variant <civodul>so perhaps it's just that the issue had become rare enough <dsmith-work>With the jit threshold at default, it happens rarely. But it can. <civodul>if you have more details to describe how to reproduce it, what backtrace you get, etc., feel free to email them to that bug <dsmith-work>And gdb doesn't even let me disassemeble at the failed address. *dsmith-work shakes fist at gdb <wingo>you can disassemble 0x75106c26+100 <sneek>Welcome back wingo, you have 1 message! <sneek>wingo, dsmith-work says: So is there any advantage to calling scm_gc_free() in jit_free_fn() ? <wingo>like disassembly a byte range *RhodiumToad returns from power failure <RhodiumToad>yeah. I'm trying an assert in ldi_i to see if it gets hit <dsmith-work>wingo: Can you explain or point me to some docs/code on how stacks happen with jited code? How they grow and are cleaned up and how they are swithched? <wingo>dsmith: basically the scheme stack is entirely separate from c <wingo>it is a data structure that can grow either by remapping or copying. any time the scheme stack might expand (generally at function entry) it might relocate <wingo>the interpreter operates on the stack as a data structure and doesn't recurse on the C stack, unless it needs to call out to C <wingo>if a function has JIT code, the interpreter will call the JIT code, which does the same operations on the scheme stack as the interpreter would <wingo>and when it reaches a function that has no JIT code, either in a call or in a return, it returns back to the interpreter, which reloads the state of the data structure and continues operating <wingo>all the bits in jit.c and vm-engine.c that reload e.g. SP from the thread are sometimes about register spilling, but often about this need to account for invalidated SP because the stack expanded <wingo>SP in the logical sense of scheme <wingo>because remember, two stacks <wingo>the c stack and the scheme stack. <RhodiumToad>I think the question behind the question is "why don't backtraces work in gdb when a call came from jitted code" <RhodiumToad>and I think the answer to that is that the jitted code lacks the debug info needed for gdb to figure that out. *civodul pushes cross-compilation bug fix <RhodiumToad>I think it's moot anyway. generating mov #0 followed by a load/store using that register indicates something wrong in code generation, not at runtime <civodul>wingo: you're also OK with releasing as is? <dsmith-work>The segfaults are often: set r12 to zero, load some reg with [r12] <wingo>civodul: yes, fixes can always come in a followup <wingo>sounds like RhodiumToad has a nice ARMv7 fix tho that might make sense to land <RhodiumToad>using (v << n | v >> ((32 - n) & 31)) would be another fix <RhodiumToad>basically, when v is 32 bits as it is here, (v >> 32) is undefined <wingo>RhodiumToad: what name and/or email should i use to thank you? :) <dsmith-work>wingo: While you are here, what's with #define jit_ldrt_strt_p() 0 <dsmith-work>So effectivly always disabling that branch of the if <wingo>dsmith-work: it comes from lightning. either i need to detect a feature and use that, or i need to constant-fold it to 1 or 0 <RhodiumToad>we were wondering why it generates ldrt / strt insns despite there being no obvious reason to do that <civodul>wingo: ah cool, let's include the fix by RhodiumToad <dsmith-work>wingo: And another thing. ;^} memset in reset_literal_pool() seems to be a noop. <wingo>will merge when the test succeeds <wingo>dsmith-work: why is it a noop? <dsmith-work>pool->size = 0; memset(pool->entries, 0, sizeof(pool->entries[0]) * pool->size); <dsmith-work>The rest of the code doesn't touch entries unless the have been initialzed first. <wingo>yeah i think i was being paranoid about struct holes and related things <wingo>a lot of invariant-asserting code there anyway <dsmith-work>So the errors are trying to dreference NULL. Why? Is the code being generated incorectly? Or is something funky going on at a higher level, passing a zero. <RhodiumToad>this is why I'm trying it with an assertion in ldi_i <RhodiumToad>if something tries to generate a load from address 0, it should fail. but this problem doesn't reproduce reliably for whatever reason <RhodiumToad>it hasn't failed for me yet. though the power failure I had earlier was in the middle of a run <RhodiumToad>dsmith-work: do you get it repeatably with aslr and threads off? <dsmith-work>It always fails a certain test with make check, but NOT when running that individual test <RhodiumToad>dsmith-work: can you put ASSERTs into ldi_i and sti_i to assert that i0 is not 0? <civodul>wingo: i'll run some more tests, update GUILE-VERSION, and go ahead <dsmith-work>RhodiumToad: Added the asserts, but I still don't get a backtrace. Looks like they were not asserted. <RhodiumToad>what's the surrounding code to your crash at runtime? <dsmith-work>#1 0x76f556c0 in scm_i_string_ref (str=<optimized out>, x=478720) at strings.c:668 <dsmith-work>Dump of assembler code from 0x75106c22 to 0x75106c2c: ***jonsger1 is now known as jonsger
<RhodiumToad>ok, I have to stare at the manual a while to figure this out ***apteryx_ is now known as apteryx
<civodul>now to debug a deadlock with open-input-output-pipe <civodul>regtur: if you're around, it's tests/inferior.scm in Guix that triggers it :-) <RhodiumToad>civodul / wingo, if you're planning a release or anything, stop now <RhodiumToad>I think I found it, one of the paths through encode_thumb_immediate is _completely_ bogus <dsmith-work>Oh, that's a beauty of a function. Lots of hex everywhere <RhodiumToad>the case for abcdefgh 00000000 abcdefgh 00000000 will always generate 0, regardless of the input value <RhodiumToad>the return should be return (((v & 0x0000ff00) >> 8) | (2 << 12)); <RhodiumToad>(it is obvious that (v & 0xff) is 0 because it literally just checked that) <RhodiumToad>this is why it fails randomly with aslr, because that makes the top bits of the value variable; the success/fail based on whether or not it's run from make might be dependent on the environment size or similar <RhodiumToad>this thumb instruction encoding stuff is pretty crazy <RhodiumToad>yup. but only when the valid address was in the form xx00xx00 where both xx were the same. <RhodiumToad>so you can see that with aslr, it'd be highly unpredictable <dsmith-work>And with threshold=0 more opportunities for that to happen <dsmith-work>ERROR: 00-repl-server.test: repl-server: simple expression - arguments: ((misc-error #f "~A" ("Unable to create directory in /tmp for 00-repl-server.test") #f)) <dsmith-work>That's just crazy that XX00XX00 or 00XX00XX would have a sepecial encoding. <RhodiumToad>well you can sort of see it, in that there's only 12 bits available to use, and they want to represent as many as possible of the actual constants people might want <RhodiumToad>so e.g. there are ways to encode 0xaaaaaaaa or 0x00010001 <dsmith-work>"Ooo look. Lot's of people use 0xDEADBEEF, let's make a special code for that..." <RhodiumToad>think about the sorts of values that get used as bitmasks, for instance <RhodiumToad>(there actually _isn't_ a good way to encode 0xdeadbeef in this scheme) <dsmith-work>So if bit x is set, then bits yz select one of these 4 constants. 0xDEADBEEF ... <dsmith-work>Hmm. There ought to be some test in the lightening repo that validates all that. <RhodiumToad>clearly there should be, but equally clearly there is not <janneke>i heard somenoe prefers 0xCABBA9E nowadays <civodul>RhodiumToad: could you email what you have to 40737@debbugs.gnu.org? <RhodiumToad>why do you allow trailing whitespace in your files, btw? it really messes up my diffs *civodul not sure what that statement implies :-) <dsmith-work>civodul: I'm guessing guile inherited the whitespace from lightening which inerited it from lightning. Just a guess. <dsmith-work>$ grep JIT_NEEDS_LITERAL_POOL lightening.c | sort| uniq -c <RhodiumToad>oh, there's a small bug in the configure script somewhere <RhodiumToad>I _think_ it gets here: if test $gl_cv_func_working_mktime = no; then without gl_cv_func_working_mktime being set at all <dsmith-work>RhodiumToad: Check out tests/ldr_i.c in the lightening repo. Looks could be easily extended for the failure case (and others). <apteryx>refining my minimal repro: (guard (c ((message-condition? c) (format #t "error: ~a~%" (condition-message c)))) (throw 'system-error "canonicalize-path" "~A" '("No such file or directory baba"))) -> error: ~A <apteryx>shouldn't condition-message be able to extract the message from such a throw? <apteryx>perhaps I need to read the source of make-exception-from-throw <apteryx>OK, so the error happens in (ice-9 exceptions): (guile-system-error-converter 'system-error '("canonicalize-path" "~A" '("No such file or directory") '(2))) -> $4 = #<&compound-exception components: (#<&external-error> #<&origin origin: "canonicalize-path"> #<&message message: "~A"> #<&irritants irritants: (quote ("No such file or directory"))>)> <apteryx>we can see that already at that point the message is lost <apteryx>is this by design? Is it left to the users to correctly format the message doing something like (apply format `(#f ,msg ,@msg-args)) ? <apteryx>or should the exception object message slot already be populated with a correctly formatted message? *apteryx has too many questions <mwette>aperytx: haha - yeah, i don't like the return of "error"; I usually use something like (catch 'ctx (lambda () (throw 'ctx "error ~S ~S ~S" 1 2 3)) (lambda (key fmt . args) (apply simple-format #t fmt args)) if that helps <apteryx>mwette: the glue in (ice-9 exceptions) seem to provide an opportunity to rectify this if we want <apteryx>it bridges legacy throw exceptions with srfi-34 style ones <apteryx>it it typical for a system-error to contain "~A" as the message, and the actual message as a message-argument? <apteryx>if it's always true, we can format the actual error message at the level of guile-system-error-converter <apteryx>the node 7.2.1 POSIX Interface Conventions hints that this is the case, with a handler example binding the variables "fmt fmtargs data". <apteryx>and formatting a human readable message with: (apply format #t fmt fmtargs) <dsmith-work>Not sure how the api works. But that fails without your fix, and passes with it. <apteryx>the docstring at SCM_DEFINE (scm_error_scm, "scm-error", 5, 0, 0, (error.c, line 70) gives me confidence that we should format the message before raising the exception. <mwette>apteryx: you mean via (format #f ...) ? <mwette>I would prefer to have error accept format string and args. <apteryx>try this for example: (guard (c ((message-condition? c) (format #t "message: ~a~%" (condition-message c)))) (canonicalize-path "/doesntexist")) <apteryx>I'm not sure where that ~S came from <apteryx>They describe what msg and irritants should be: msg must be a string and should describe the exceptional situation. The irritants may be any Scheme objects and should include values that may have caused or been materially involved in the exceptional situation. <apteryx>describe the exceptional situation: I don't think "~A" fits the bill ;-). <civodul>i don't feel confident with merging the lightening patches so i would prefer to let wingo take a look <RhodiumToad>that test would presumably go in the tests/ subdir of wingo's lightening repo <dsmith-work>Really should test more cases. But I havn't figured out how yet. <dsmith-work>And it's more of an example for someone with paperwork to write a real test. <civodul>i don't know how much has diverged but perhaps there are applicable bug fixes in lightning.git <dsmith-work>apteryx: There were some recent changes to exceptions and conditions. Looks like more to come too. See NEWS <dsmith-work>Would be nicer if those ASSERTs printed out something instead of just calling abort() <dsmith-work>Probably some very unexplained things going on there too. <RhodiumToad>I was looking for the origin of the code and whether it had been fixed elsewhere ***Guest59015 is now known as nalkri
***drakonis1 is now known as drakonis
<dsmith-work>Hmm. The assert *does* print stuff. Just not the actual return value. <mwette>lightening @ gitlab.com/wingo/lightening; lightning @ www.gnu.org/s/lightning <rekado>apteryx: you’ll find the ~A here: (catch #t (lambda () (canonicalize-path "/doesntexist")) (lambda args args)) <rekado>that gives you (system-error "canonicalize-path" "~A" ("No such file or directory") (2)) <RhodiumToad>#0 0x21f97030 in compare_u32_strings_ci (s1=0xbcd2b6d0, s2=<optimized out>, locale=<optimized out>, func_name=<optimized out>) <dsmith-work>RhodiumToad: That is supposed to save all those registers at *r3++ right? <RhodiumToad>it's doing a memory to memory copy using the vector regs <RhodiumToad>I think this is the for loop in SCM_STRING_TO_U32_BUF <RhodiumToad>c_str = c_str_malloc_p ? malloc (bytes) : alloca (bytes); <dsmith-work>I've heard that "malloc can't fail on Linux" too many times. <dsmith-work>I've been learning Rust lately, and I've been appreciating it more and more. <dsmith-work>I guess the safest thing to do there is conditionalze the loop on c_str, and then check it at the call sites. <dsmith-work>I was really amazed the other day how rust optimized match foo {'Y'|'N'|'y'|'n' => true, _ => false } <dsmith-work>After adjusting an offset, loaded a bitmap into a regiser and probed that. <dsmith-work>RhodiumToad: was it a specfic test that failed or another "random" one. *RhodiumToad runs it again to see <RhodiumToad>I'd just done a make check at top level, nothing special <rekado>davexunit: the r/guile community on Guile is restricted so I can’t post there. Is this on purpose? <dsmith-work>Maybe if you swapped the true/false it would be closer <terpri_>slightly shorter, but not as concise as the rust asm <dsmith-work>I was just amazed at the bitmap in a register. Not used to regs with that many bits. <dsmith-work>A friend of mine challenged me to write that with no branches. (Because of course, you need to respond in sub-nanoseconds after waiting for a keypress) <dsmith-work>RhodiumToad: alloca or malloc? (why would it need malloc?) <terpri_>RhodiumToad, i don't think so. guile does have a fallback malloc implementation from gnulib though, it seems <RhodiumToad>but the code in question seems to be calling the bare libc malloc <dsmith-work>That code allocs and frees right after. No need to get the GC involved. (I assume) <RhodiumToad>so the question is why did it fail to allocate a mere 4 megs <dsmith-work>RhodiumToad: I meant, wny need malloc from gnulib? (not libgc) Is't the c lib malloc good enough? <terpri_>dsmith-work, i don't know under which circumstances it would *use* gnulib malloc, just that it exists in the repo (lib/malloc.c) <RhodiumToad>FAIL: r6rs-ports.test: 8.2.7 Input Ports: custom binary input port position, long offset - arguments: (expected-value 4398046511104 <terpri_>i wonder where malloc isn't posix-compliant. maybe ancient *nix systems or windows or something <terpri_>here's the rub, i think: https://pubs.opengroup.org/onlinepubs/9699919799/ "If the size of the space requested is 0, the behavior is implementation-defined: either a null pointer shall be returned, or the behavior shall be as if the size were some non-zero value, except that the behavior is undefined if the returned pointer is used to access an object." <terpri_>"If size is 0, malloc allocates a zero-length item in the heap and returns a valid pointer to that item." is the windows behavior i meant to quote <terpri_>hence its presence in gnulib, i guess <dsmith-work>RhodiumToad: So on your system, is that malloc really returning 0? Is there a limit to the amount you can request? <RhodiumToad>as far as I can tell it returned 0. I don't know why. <terpri_>your system does have more than 4 megs of memory, right? :D <RhodiumToad>something's assuming that (port-position) should truncate to 32 bits <dsmith-work>Modern malloc typically uses mmap for largish allocations. <dsmith-work>r6rs and str ports check for base > SCM_T_OFF_MAX, which could be INT64_MAX, INT_MAX, or LONG_MAX. <RhodiumToad>#if defined GUILE_USE_64_CALLS && defined HAVE_STAT64 <RhodiumToad>no comprehension that platforms exist that don't have idiot largefile breakage <RhodiumToad>on freebsd, as with all *BSDs since around the 4.4BSD period, off_t is 64-bits and there are no silly *64 system calls <RhodiumToad>lack of largefile breakage is one of my favourite freebsd features :-) <dsmith-work>It's been about 19 years since I used fbsd. Really enjoyed how the drivers and man pages and stuff was all in sync. Nice clean code too.