IRC channel logs


back to list of logs

<civodul>hey hey!
<civodul>it's Friday!
<civodul>how's everything wingo?
<wingo>good! been a bit busy at work, but fine :)
<wingo>how are you? :)
<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
<civodul>fine, likewise busy :-)
<civodul>that's cool!
<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
<civodul>oh, that's nice
<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
<wingo>which can be interesting :)
<civodul>indeed :-)
<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>there's also signal handlers
<civodul>well that's a kind of preemption
<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>civodul: indeed it could!
<civodul>fun stuff
<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>wingo, civodul: would like to push;a=shortlog;h=refs/heads/lloda-squash0, I sent the patches to the list a while ago...
<lloda>except the last two patches it's all housekeeping and a bugfix, could I push those at least? it's already rebased
<wingo>ACTION looks
<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 ?
<wingo>lloda: why remove the weak-vector guards in;a=commitdiff;h=4070bceddfb21771132cb3f5e1e01f5b665a5be6;hp=d0dd52756ca032eeebc458313f28e2c95e386d5f ? nack on that i think
<lloda>re scm_from_contiguous_array, it seems it was introduced in 73788ca8bedcb4dd9578a1a992223e51a7d99a0d. It wasn't documented though.
<wingo>re;a=commitdiff;h=1945cdf491c669ce54f94b90fd083f71642d1b2e;hp=5d4b2c9c7a213ef3b7b511c4840978cf587a488f is it possible to use static functions instead of the macro?
<wingo>it would seem so
<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>so NACK on that change
<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 (!)
<lloda>I can ask in #scheme
<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>ah, I see
<lloda>re: preposition
<lloda>civodul: there is some of that test...c&e where the array read syntax isn't used, so I can remove it there
<dsmith-work>Happy Friday, Guilers!!
<mvdw>Near done with work.
<OrangeShark>happy friday
<davexunit>happy friday indeed
<davexunit>got in very early to work, helped swap out a production database, just gotta make it a few more hours and then vacation
<iyzsong>I alrealy done, happy weekend :-)
<davexunit>iyzsong: guess I'm on the wrong hemisphere
<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>thx, I'm trying that
<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>ok I'm using SCM_INTERNAL
<lloda>ok, I've fixed the patchset in;a=shortlog;h=refs/heads/lloda-squash1
<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
<lloda>thx for the review btw
<stis>heya guilers!
<dsmith-work>stis: Greets
***holomorp1 is now known as holomorph
<wingo>good evening :)
<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?