<wingo>good! been a bit busy at work, but fine :) <wingo>guile-wise i finished all the thread stuff i needed to do -- there are still improvements to be made, but i'm ok with its maintenance state anyway <wingo>i added something yesterday whereby VM ops no longer check for interrupts <civodul>i haven't taken the time to look into it yet <wingo>instead there's a handle-interrupts opcode inserted by the compiler <wingo>slight perf regression there because of the additional instruction, <wingo>that way interrupts (asyncs) can run without leaving the vm <wingo>meaning users can make libraries that do pre-emptive threading <civodul>is there a risk that the compiler won't emit that instruction in the right place, leading to asyncs not being executed in a timely fashion? <wingo>there is a risk. but i think it should be correct by construction pretty much <wingo>the compiler currently inserts handle-interrupts before every call, tail-call, return, or loop back-edge <wingo>which is what the vm was doing before <wingo>if the only priority is "ensure the vm can be interrupted" you could relax that <wingo>for example only on calls and loop-back-edges, you could move the interrupt to the function prologue, etc <wingo>elide the interrupts from loop-back-edges where the loop definitely contains a call <wingo>interrupts have three purposes: C-c, profiling, and pre-emption <wingo>and for profiling the current positioning of interrupts makes sure that cost is correctly attributed <wingo>i.e. before calls and before returns <civodul>and i guess there are still interrupts in libguile, right? <wingo>i guess signal handlers are a mechanism that triggers interrupts, but the purposes of the interrupts is still one of the three above <civodul>oh and call-with-blocked-asyncs could somehow tell the compiler to not emit those interrupt insns in its lexical scope, no? <wingo>civodul: yes, whereever C could take a long time. which means that we should add something whereby the user can know if "abort-to-prompt" would result in the creation of a continuation that can't be resumed <wingo>some day i would like to replace the mutex implementation with something that looks more like futexes. it's good enough for now tho <lloda>except the last two patches it's all housekeeping and a bugfix, could I push those at least? it's already rebased <wingo>lloda: when was scm_from_contiguous_array introduced? <wingo>given that it was api and can be reimplemented trivially, does it makes sense to add an implementation to deprecated.c ? <lloda>re scm_from_contiguous_array, it seems it was introduced in 73788ca8bedcb4dd9578a1a992223e51a7d99a0d. It wasn't documented though. <wingo>lloda: then lgtm to remove scm_from_contiguous_array i think unless civodul carps about it <lloda>re: macro. I admit it's ugly, but all the array stuff needs to be moved to Scheme eventually, so I just did something that worked. But: sure, I can replace the macros. <wingo>yeah, just trying to reduce maintenance cost. i dunno <wingo>maybe that is not the shortest path there <wingo>for me the patch set is fine i think. we have neglected it too long and should just get it in i think. i would like to hear a civodul thought on it tho :) <civodul>removing a public interface is always touchy :-) <civodul>IWBN to deprecate it instead, but i haven't looked at the feasibility <lloda>the weak guards: I removed them b/c those functions used to work with generalized-vectors, but now they work only on scm_tc7_vector which weak vectors are not. This is the same change that was done to all the 'vector' functions back in the array shuffle <wingo>lloda: it is unsafe to access the memory of a weak vector <wingo>unless it's impossible that they be called with a weak vector as an argument <lloda>I don't understand why SCM_I_VECTOR_WELTS is used in scm_vector_copy <lloda>is the patch ok if I just keep the guards? <lloda>all that generalized_vector, inclusion of arrays.h in vectors.c etc needs to be gone, but it probably needs more care <lloda>wow, it's WRITABLE, it's been a while <wingo>lloda: patch is ok if you keep the guards yes <wingo>lloda: if you can make a small scm_from_contiguous_array patch that moves it to deprecated.[ch] instead of removing it then for me, all good <wingo>civodul: you ok with the new array-from etc interfaces from the last couple patches? <wingo>i only looked at things briefly but i mostly trust lloda's judgement about what should go in <lloda>ok, so 1. keep the guards, 2. replace the macros, 3. deprecate scm_from_contiguous_patch. <lloda>there's doc for those functions in the patch. <lloda>How I want all this to be in Scheme, I really do <civodul>wingo, lloda: 'array-slice' instead of 'array-from' maybe? <civodul>also maybe pass the C code through "indent --gnu" :-) <civodul>but yeah, it looks like a useful interface <civodul>i think 'with-test-prefix' instead of 'with-test-prefix/c&e' is enough, since there's no compiler magic involved AFAICS <lloda>array-from returns a scalar when the result is rank 0 <lloda>array-from* returns an array always (so #0(x) if the result is rank 0) <lloda>array-from is meant to work like J or numpy, where the normal array subscript a[i] is rank-polymorphic. <lloda>tbh I'd prefer to keep the names array-from and array-amend!, which are from J. <wingo>i think we should prioritize names that fit in well with guile <lloda>re c&e, the compiler is involved in reading #2() etc. where I found bugs in the past <wingo>we can mention J names of course <lloda>there's no -slice in Guile though <wingo>but historically guile tends to outlive everything that it takes names from :P <lloda>there's iota which is an APL name <wingo>no strong opinion here tho, things can change names in the future also <civodul>lloda: i think it's a Scheme name taken from CL, which borrowed it from APL :-) <lloda>ofc, if you both prefer array-slice, then I won't fight <lloda>but, learn from the masters, not the students (!) <wingo>we just don't tend to have trailing prepositions in our names <wingo>the array functions are a little weird and perhaps some of it is essential weirdness tho <lloda>civodul: there is some of that test...c&e where the array read syntax isn't used, so I can remove it there <davexunit>got in very early to work, helped swap out a production database, just gotta make it a few more hours and then vacation <lloda>HACKING is outdated re: the deprecation procedure <lloda>if a function to be deprecated needs includes, where do I put those includes after I move the function to deprecated.c? <wingo>what do you mean? perhaps look at any recent commit that touched deprecated.c <lloda>the deprecandum uses static stuff from arrays.c, how do you deal with that? either repeat the function in deprecated.c, or make it nonstatic. Don't like either :-/ <lloda>I'll ask the list for opinions on the names of the new functions <lloda>or if you all go for from/slice and the others are ok, just let me know ***holomorp1 is now known as holomorph
<daviid>ACTION renamed Guile-Vigra -> Guile-CV, a functional programming computer vision library for the Guile scheme language <daviid>I'm looking for a solution to my display image 'problem', im-show procedure: in mem, the image is a list, like this <daviid>(width height n-chan idata), with idata a list of channels, a channel is a f32vector <daviid>looking for ideas on writting, in memory, a struct that a lib can use to display the image ... any one has an idea? <daviid>davexunit: I've installed sdl2, load "hello.scm" works fine: do you know if the above is feasable using guile-sdl2?