<dsmith-work>Just visually inspecting the code, all gets seem to have matching ungets. <rekado>rebasing guile-emacs on top of Emacs 25 now. It’s not exactly fun, but it’s a great way to get familiar with the changes. <RhodiumToad>I can't tell whether what I'm seeing is a debug artifact or is real <dsmith-work>RhodiumToad: Could be a wild pointer smashed it. But my reading of the code says it can ony ever be 0 1 (or 2 for arm,aarch64) <RhodiumToad>what gdb is telling me is that the _jit is pointing to the wrong place <RhodiumToad>ASSERT(!(im & 0xfbff8f00)); in torri() is where it dies. <RhodiumToad># define rotate_left(v, n) (v << n | v >> (32 - n)) /* spot the problem */ <rlb>Why does this print bar twice? (define-syntax foo (begin (display "bar\n") (identifier-syntax 1))) <justin_smith>rlb: could this be similar to the semantics that make eval-when neccessary? <justin_smith>eg. the define-syntax is executed twice when entered at the repl, maybe <rlb>Ahh, I suppose that might be it. <rlb>Thanks. I'll poke around a bit more. <justin_smith>I don't know your actual case, but it might help to consider using eg. a delay to make some side effect only evaluate once <rlb>In this case, I want to define a syntax (maybe an identifier syntax) that captures a binding. <rlb>Though I still need to think through whether or not that really makes sense here... <RhodiumToad>anyone want to bet on whether this compile succeeds? <RhodiumToad>(currently 36 minutes into the compile of psyntax-pp) <daviid>it make couple of hours on old machines ... <RhodiumToad>well that depends on whether my fix for the above bug is correct :-) <daviid>if your bug fix is a fix and not a bug :):) i bet it will compile *RhodiumToad will leave it compiling :-) <minerjoe>I'm hoping this is a channel to just shoot from the hip? <minerjoe>I'm new to guile and trying to add it to an existing program. I'm trying to call a function defined in the main program (not a shared library). The symbol is present via "readelf -sW" as GLOBAL DEFAULT, but it is not found via (dynamic-func "foo" (dynamic-link)). Maybe this is not the way to get at a function not dynamically linked into the program? <daviid>if i wanted to measure the impact of replacing map by a generic, what would be a good micro benchamrk? ***emacsoma1 is now known as emacsomancer
<dsmith>RhodiumToad: What problems do you see in that rotate macro? <dsmith>The args are unsigned. And single names. And it's for a 32bit arm. <dsmith>The one call site loops < 32, so no "overrotate". ***apteryx is now known as Guest68790
***apteryx_ is now known as apteryx
<RhodiumToad>dsmith: the rotate macro has an undefined result when n is 0 <wingo>we should have a way to build with ubsan :P <RhodiumToad>what I did was add if (v <= 0xFF) return v; and change the loop to start from 2 rather than 0 <RhodiumToad>other options would be to use v >> ((32 - n) & 31) or a compiler rotate intrinsic <RhodiumToad>did you see my other comment about nonportable use of `date` ? <mauritslamers>hey all, I have a question regarding style or best practices. I am writing something in guile within the context of Lilypond. It is not part of the project at all, but it uses the context it gives for additional output. My question is not how to use the Lilypond API, but more on what the best approach is datawise. Lilypond seems to be using mainly assoc lists to keep track of things. Now I am contemplating whether to use assoc-lists as a main <mauritslamers>vehicle for storing additional info, or to use object properties. <mauritslamers>My own background is mainly JS, so I am used to construct these kinds of systems from a semi-funcitional, semi-OO point of view. <RhodiumToad>wingo: I'm going to try a build with clang -fsanitize=undefined :-) <wingo>RhodiumToad: saw the comment, didn't look into it *wingo has v little time lately, for family reasons <mauritslamers>Basic task is to retrieve a list of events, parse these events in a certain way, so they create output. The exact output however depends on circumstances (such as previous events and future events). My current approach is to leave everything in a big list of assoc-lists, change values where necessary. But I am wondering whether I should use object properties instead to keep track of these extra settings, and what the advantages are of object <wingo>assoc lists are fine if there are few elements in them tho <janneke>RhodiumToad: there used to be a ... yeah "it depends", last time i looked it was ~100 elements <wingo>basically i would use either alists or hash tables. object properties use weak hash tables underneath, which is good if you know you don't want to keep the object alive <mauritslamers>The easiest for me would be to use object properties, it would lead to me writing something that essentially would be JS but with a Scheme syntax :) ***dozzie_ is now known as dozzie
<wingo>but hash tables can be iterated over <wingo>yeah, sorry, no concrete guidance here ;) <mauritslamers>In JS I have the certainty that when I change an object, I will always keep the pointer (reference) to that object. I gathered from the docs that this guarantee doesn't hold with assoc-set! <mauritslamers>as in: when assoc-set! is used on a list while setting a new key, you get a different reference (pointer) back. <mauritslamers>wingo: no worries, it is more curiosity about what would be the more scheme way of doing things instead of JS. <wingo>yeah, can be interesting experimenting with different ways of writing a program, whether you build up a mapping in a functional way, or whether you use a more place-oriented approach of stuffing new associations in a hash table or whatever <mauritslamers>The biggest issue is that I might have to reverse course somewhere in the program. This big list of events consists of multiple streams (musical staffs to be exact). In most of the situations everything of importance stays within a single staff, but there are situations where I suddenly need to access info on a different staff, ie different stream. <mauritslamers>So, technically i could split it up in as many lists as there are staffs and process each list individually <mauritslamers>It would cause issues though when it turns out I do need info from a different staff. <mauritslamers>The functional way would be to split it up, and return parsed lists for each staff <mauritslamers>The JS or OO way would be to leave it as a single list, filter it out per staff, and adjust settings, but that works on the assumption that the pointers / references to these list items would not change. *RhodiumToad not sure that there is a "the" functional way <chrislck>1. I'm a pythonista. I like my for loops. <chrislck>2. I'm scheme-curious. What's all this about cons car cdr? <chrislck>6. srfi-1 can kiss my ass, ice-9 match ftw <RhodiumToad>well, -fsanitize=undefined has made the compiler a hell of a lot slower <RhodiumToad>used to take 30 mins to compile eval.go, it's now on 49 minutes and not done yet <mauritslamers>chrislck: if you were talking to me: not really on that scale. I know about macros, I know what they do. So conceptually I sort of know the roots of the language but I simply do not have the experience of designing with it <mauritslamers>So for me the question above is mainly about how I can "prevent" myself to starting writing JS in scheme syntax :) <mauritslamers>What I have seen so far with Guile is that using assoc lists and writing functions to change things very much resembles the way C deals with objects: structs to hold the data, methods/functions/procedures to change things on that struct. <mauritslamers>C has structs to keep data, and uses externally defined functions / methods to change data inside structs of that type <mauritslamers>Thinking about this a bit longer I think my question is mainly how to deal with state and state changes in scheme <RhodiumToad>records in scheme are like C structs. goops objects are more... objecty <mauritslamers>important for me at this moment is also that what I write has to work with a very old version of guile (1.8.2), as it runs as part of Lilypond 2.14 <mauritslamers>and it is a bit complex for me to figure out what is supported there exactly. <chrislck>maybe you can be the driving force to move on to guile-2.2 :) <mauritslamers>I am working on music braille support for Lilypond, not as part of the Lilypond project. <mauritslamers>The music basis of it atm is the song bundle of the dutch protestant churches, of which a new version has been made using Lilypond 2.14 <chrislck>are you the mauritslamers who hangs in #gnucash too? <mauritslamers>because of many reasons, not in the least that I am the one and only dev on this project, it is not possible timewise to convert either Lilypond guile to something more recent, or to try to convert that song bundle to a more recent Lilypond version. <mauritslamers>anyway: I have already written something that does at least a partial braille conversion, but I am now redesigning and refactoring because of the limitations of the current implementation. <mauritslamers>So I am mostly trying to figure out how to design this in a way that it works as fluent as possible within guile, instead of trying to imprint the semantics and methods of different language on this. <mauritslamers>What I find perhaps the most complex is how to do list navigation: I am parsing a list and I need to walk backwards and forwards in that list in order <mauritslamers>to figure out the context of the item I am currently processing <mauritslamers>in JS I would use an array and indexes, and use properties on objects to keep the context data on, and create a method to render the required braille for that object <chrislck>scheme lists are not designed for random access <chrislck>yes, but as usual, it depends. how often you expect to access elements randomly? <mauritslamers>Hmm, I don't see how I can make this into a pasteable snippet: Lilypond creates events, and from these events I create a list (currently) of all events. In that list I expect to access elements randomly a lot, as well as filter them based on different properties or settings. <mauritslamers>what I have been doing now is using for-each, and then through a closure keep track of the previousNoteEvent or previousEvent <dsmith>RhodiumToad: "<< 0" Should be fine, So ">> (32-0)" is undefined behavior? <RhodiumToad>this shows up when doing jit on arm, it's in lightening/arm-cpu.c <dsmith>Right. Wondering if its the "random" segfaults I'm seeing. <RhodiumToad>for me the result was that it would work apparently fine up to language/cps/compile-bytecode.go and then abort on that <dsmith>So that's probably clang-specfic? <RhodiumToad>the specific way in which the undefined behavior manifests itself can vary, of course <RhodiumToad>anyway, you could try fixing it and testing again on arm, see what happens? <RhodiumToad>my sanitize=undefined build has ground its way through psyntax-pp successfully and is now working through the other files ***terpri__ is now known as terpri
***rekado_ is now known as rekado
<rekado>rebased 25 of 159 commits for guile-emacs <rekado>lots of them are really big commits <chrislck>mauritslamers: nothing beats looking at your code directly <RhodiumToad>fails how exactly, and what exact sequence of events? <dsmith-work>running the test-language in isolation repeatedly until segfault. <dsmith-work>while GUILE_JIT_THRESHOLD=0 make TESTS=test-language check-TESTS; do :;done <dsmith-work>#0 0x76f505cc in scm_is_string (x=0x0) at strings.h:293 <dsmith-work>#1 scm_string_to_symbol (string=0x0) at symbols.c:361 <dsmith-work>Backtrace stopped: previous frame identical to this frame (corrupt stack?) <dsmith-work>../../meta/uninstalled-env ../../libtool --mode=execute gdb ../../libguile/guile core <dsmith-work>jit_new_state takes an allocation and a free function. *RhodiumToad hasn't dug into the code much yet <rekado>I see no stable-3.0 branch. Is that role taken by the master branch? <civodul>dsmith-work: you're seeing that with master on ARMv7? <dsmith-work>Never happens without the jit. So something arm jit specific. <dsmith-work>So is there any advantage to calling scm_gc_free()? (I'm thinking yes) <RhodiumToad>gmake[2]: *** [Makefile:2279: ice-9/and-let-star.go] Segmentation fault (core dumped) <RhodiumToad>this one looks like it is not completely reproducible <dsmith-work>Does a disassm of the surrounding code look reasonable? <RhodiumToad>I wonder if this is some confusion over arm vs. thumb mode <RhodiumToad>how do I convince gdb to do that? I've not used it much on arm, yet *dsmith-work looks for his notes... <RhodiumToad>and it obviously is, because in arm mode it's garbage <RhodiumToad>cpsr bit 5 is 1, so I guess we are in fact in thumb mode. <dsmith-work>That bug monster arm-jit patch handled all the arm->thumb and thumb->arm jump. Including when jumping through a "veneer". (branch to a close by jump to far away code) <RhodiumToad>so. the fact that it loads a constant 0 into r12 and then immediately uses it as a pointer does suggest bad code generation. but it's not clear why it doesn't happen predictably <dsmith-work>Yeah. A quick search says it's for os calls or something. <dsmith-work>Also, thumb has limited registers. (they are all still there, you only get 3 bits in the opcode to specify them instead of 4 bits in arm mode) <dsmith-work>Alsom little endian, so the opcode is 0x5e00 0xf85c ? <dsmith-work>I need to get gnus working. The web interface for my old email is totally hozed. <RhodiumToad>I think the 0xf85c is the first halfword and 0x5e00 the second. <RhodiumToad>and the reference manual does say that decodes to ldrt r5,[r12] <dsmith-work>So right now, code like that *NEVER* takes the branch. <dsmith-work>Could that be the torri12() function generating that? <RhodiumToad>THUMB2_LDRI is 0xf8500c00 and THUMB2_U is 0x00000200, so OR those and get 0xf850 0e00 <RhodiumToad>then fill in register numbers 12 and 5 and immediate 0, and get 0xf85c 5e00 <dsmith-work>Hmm. Maybe it's just because ldi_i() called trying to deref 0, and the real problem is somewhere else. <RhodiumToad>ldi_i being called at all with a last parameter of 0 indicates a problem, I think <RhodiumToad>if it were reproducible I would be setting a breakpoint for that <dsmith-work>That brings me back to something is overwriting something somewhere. <dsmith-work>RhodiumToad: There are couple of <<32 in hash.c that causes warnings in my compiler. <RhodiumToad>yeah. but I think those are harmless because they're under conditionals that are false when the value being shifted is 32 bits. ***_ is now known as Guest57951
<dsmith-work> memset(pool->entries, 0, sizeof(pool->entries[0]) * pool->size); <RhodiumToad>question is whether anything cares about the content beyond pool->size <dsmith-work>On the other hand, it is within #ifdef JIT_NEEDS_LITERAL_POOL, which is only for arm and aarch64 <RhodiumToad>I don't see anything that accesses beyond pool->size so I think it's harmless <dsmith-work>Another thing I'm suspicious of is the constants in literal_pool_byte_size <dsmith-work>With threshold=0 got one standalone fail. FAIL: test-use-srfi <dsmith-work>And again the popen test fails. But that might be due to no threads. <dsmith-work>sneek: later ask wingo: So is there any advantage to calling scm_gc_free() in jit_free_fn() ? <mauritslamers>To me it feels like this could be done differently, but I don't know really how. Problem is mainly all the state variables that I need to keep around, and that define what needs to happen next. <RhodiumToad>dsmith-work: I'm running standalone text without threads, and no failure yet after 10 runs <roelj>Is there a convenient way to see what is using how much memory in a Guile program? <dsmith-work>RhodiumToad: I can eventually get a core dump from this: <dsmith-work>while GUILE_JIT_THRESHOLD=0 ./meta/guile < /dev/null; do : ; done <justin_smith>roelj: having done such profiling in other lisps, even when it's possible there's a gotcha that you can use "cons" in ways that lead to the same spine being used in many places, as the tail of multiple lists <justin_smith>so even when you have a global view of all allocated memory, making sense of it requires application analysis <RhodiumToad>dsmith-work: is this on a platform with ASLR? if so, have you tried disabling it? <roelj>justin_smith: Well, I'd like to see what it looks like.. :) <civodul>roelj: there's no heap profiler, unfortunately, but there's gcprof in (statprof) <civodul>that shows you which parts of your code spend the most time allocating memory <civodul>which is not exactly what you want, but can already be useful <roelj>civodul: Thanks! It's going to be interesting to read anyway <dsmith-work>RhodiumToad: Prob was enabled. Trying with it disabled. <dsmith-work>RhodiumToad: That seems to have allowed guile < /dev/null to no longer segfault. <dsmith-work>#1 0x76f556c0 in scm_i_string_ref (str=<optimized out>, x=478720) at strings.c:668 <dsmith-work>Of course, running that single test by hand has no failure. <dsmith-work>civodul: Wasn't there some problem with some arch that needed some extra stack space? <RhodiumToad>windows has a stack size set at link time and doesn't behave very nicely if you exceed it <dsmith-work>The thing I was thinking was like some reserved padding, before or after the stack. <RhodiumToad>this is weird, I turned on some address randomization options on freebsd and tried the </dev/null test <RhodiumToad>#0 0x21cd4048 in scm_i_is_narrow_string (str=<optimized out>) at strings.c:548 <RhodiumToad>valid backtrace up to scm_i_str2symbol, which seems to have been called from jitted code and the stack isn't readable from there <RhodiumToad>I think there's no way to get a valid backtrace through jitted code, because it's not conforming to the conventions that allow tracing <RhodiumToad>the option I turned on doesn't actually randomize the program load address, it only makes mmap() calls more random in the addresses they choose <RhodiumToad>freebsd 12-stable (not very recent, few months maybe), armv7 (compiled for cortex-A7), rpi2b <dsmith-work>Maybe the stack isn't being overwritten. Maybe some return code is popping the wrong values and loading a stack that's just something else entirely. <dsmith-work>wingo had a suggestion. There is a var that stops jitting after a count. Need to bisect the count.