My personal usecase for wanting a single string is more basic, though. In the callback, I log the display to a gui console. The console adds a new entry everytime it is called. When receiving that data, there is no indication of when the string stream ended. So, to log the string as 1 entry starts involving buffering the data and checking and logging it later. To me, seems backwards of how it should be: if someone wants to loop over the data, they can do it using the pointer and the length when the receive the callback. I understand it's there for historical reasons, but still -- the requirement of a client application leaked into the api of the runtime. I'm raising my hand to add a normal version of that function.
On Sun, Nov 20, 2022 at 6:03 AM vladimir florentino <[email protected]> wrote: > > Sounds good. But, please, do consider providing a way to receive that > string as a single value. The functionality is already present, it > just needs a little extra to be exposed. > > I don't know if I consider this a minor optimization. If the Scheme > side deals with long strings, say by receiving large xml payload from > an RPC call, invoking a function once for each character, just to > reassemble the data again, is an unnecessary use of cpu cycles. > > Thanks > > On Sun, Nov 20, 2022 at 5:49 AM <[email protected]> wrote: > > > > Thanks for the suggested code, but that is not how > > I want to do it, if I do it at all. This is a minor > > optimization, so it should not introduce compile-time > > switches that split s7 into two incompatible versions; > > I'd have to add stuff to ffitest.c and the documentation > > and so on. I'll look at it later. > > _______________________________________________ Cmdist mailing list [email protected] https://cm-mail.stanford.edu/mailman/listinfo/cmdist
