<davexunit>if/when you release it, post to jdev@jabber.org about it. there admins of that curate a list of XMPP libraries and clients somewhere. <rekado>well, it's still *very* primitive because I got distracted playing with guix... <rekado>but if one fine day it should be released I'll make it known. <davexunit>I did quite a lot of work with XMPP at my last job. writing a server in guile would be neat. <davexunit>all the existing servers are clunky in one way or another. ejabberd uses erlang, openfire uses java, and prosody uses lua. <rekado>I still plan to build a general purpose pubsub server component, but there's little support for that in languages I'm interested in. <rekado>does anyone here work with the lilypond folks to help them to move beyond guile 1.8? <mark_weaver>it's been a long work in progress. unfortunately, they became heavily dependent on details of our old implementation. <rekado>I'd love to help, but I don't know nearly enough about either projects' internals to know where even to begin. <rekado>(I have a scheme engraver patch waiting to be submitted upstream, but beyond that I'm just a user.) <mark_weaver>I don't think it makes sense for anyone to try to help with that who isn't already familiar with the internals of at least one of the two projects. <mark_weaver>really, it's a job for someone who is familiar with the internals of both projects, but it seems that no such person exists at present. ***please_help is now known as moshe
***moshe is now known as please_help
<please_help>turns out the I just made a mistake, the distribution of random is approximately correct. ***yrdz` is now known as yrdz
<davexunit>linas: are there some benchmarks available or is this just anecdotal? <linas>nah. I'm measuring something very specific, <linas>on the guile side I have smobs, on the python side, I have cython code <linas>and the bottleneck is probably in the C++ code that both access <linas>but my guile wrappers are faster than the cython ones :-) <linas>but enough to start the carping I put up with :-) <linas>well, actually, about 50% of time is spent in the C code and 50% in guile ***dje is now known as dje42
***32NAA62KE is now known as Cork
***heroux_ is now known as heroux
***petercom1and is now known as petercommand
***Fuuzetsu is now known as Guest15264
<b4283>nalaginrut_: hey man, congrats on the Artanis release ***Guest15264 is now known as Fuuzetsu
<please_help>also, is there a quick way to convert typed-arrays of one type to another type without reallocating, manually converting according to IEEE-754 (for instance) and then copying that on the new array? <please_help>or well, I suppose, something more performant than (list->typed-array 'type2 1 (typed-array->list old)) (I don't know if the overhead on that is significant yet) <mark_weaver>please_help: it's not hard, but you can't use the dynamic FFI for it. you have to do it in the older way, by making a wrapper of your own, written in C++ <mark_weaver>the functions callable from Scheme would have to use the C ABI, so I guess that means writing "extern C" iirc. (I haven't used C++ in almost 20 years, so I've forgotten those details) <mark_weaver>we use libffi, which is the only reasonably portable free dynamic FFI available. we are subject to its limitations. <mark_weaver>but I guess that supporting C++ would drastically increase the complexity of libffi and its API <mark_weaver>please_help: regarding your question about arrays: you are looking for a way to do the equivalent of casting one type of pointer to another type of pointer? e.g. char* to double* ? <please_help>not quite, I want to convert the data pointed to, not the type of pointing I'm doing. <please_help>I was wondering e.g. if there was a block-wise method somewhere but what I suggested was going element-wise <please_help>also, avoid two list/typed-array conversions would be good <mark_weaver>lloda` and wingo are the resident expert on guile arrays. I've never really used them. <mark_weaver>but you can certainly avoid a conversion to a list by just allocating the new array and then iterating over the old and new arrays in parallel, converting one element at a time. <mark_weaver>if it turns out you need more performance, writing a C extension is the way to go for now. <mark_weaver>also, guile vectors tend to be quite a bit faster than arrays, at least for now. <please_help>how come? typed arrays should be able to use type-hints for optimization. <mark_weaver>yes, there's no inherent reason why arrays can't be as fast are vectors, but at present our VM doesn't handle arrays as efficiently <mark_weaver>however, depending on your application, that may not be a problem <mark_weaver>remember what knuth said about premature optimization :) *mark_weaver goes afk for a while <mark_weaver>(we have dedicated VM instructions for accessing vectors, but not for arrays) <please_help>The point of the application I'm working on is high-performance with a high-level API <please_help>performance being literally (almost) the whole point, it's not really premature optimization <mark_weaver>we also have dedicated VM instructions for accessing bytevectors and SRFI-4 uniform numeric vectors <please_help>but of course for now it's a mix of checking out options while implementing core things <mark_weaver>you could use C extensions to add primitives (from the point of S <mark_weaver>we are working toward having a native compiler, at which point things will get a lot faster. <mark_weaver>for now, Guile arrays can be handled quite efficiently from C, and somewhat less efficiently from Scheme. <mark_weaver>anyway, ask lloda` or wingo. (lloda` is here now, but maybe afk) <please_help>Can a multidimensional typed array (such as #2f64((1.1 1.2) (2.1 2.2)) ) be temporarily interpreted as a flat array (i.e. #f64(1.1 1.2 2.1 2.2)) for the sake of obtaining a pointer to it suitable to pass to C functions? <mark_weaver>but whether that can be done depends on how the array was created. some arrays created by 'make-shared-array' are basically views on another array, where the elements are not stored contiguously. <mark_weaver>also see the section of the manual "6.7.5.4. Accessing Arrays from C" <please_help>In my case, all the arrays are created by make-typed-array <please_help>is array data retrieved with array-contents applies to a typed array defined with make-typed-array guaranteed to be contiguous in memory? <mark_weaver>please_help: you'd have to ask lloda` or wingo for a definitive answer, but I believe so.