[REBOL] Re: How to send big string to library and back?
From: petr:krenzelok:trz:cz at: 16-Apr-2001 19:43
----- Original Message -----
From: <[jeff--rebol--net]>
To: <[rebol-list--rebol--com]>
Sent: Monday, April 16, 2001 4:44 PM
Subject: [REBOL] Re: How to send big string to library and back?
> Howdy, Petr:
>
> > But my friend asked me a question I am not able to answer
> > him. According to him, in C language, string is ended by
> > "0" char. So if my image data will contain "0" char, it
> > could be regarded as an end of a tring by internal Rebol
> > library interface routines.
>
> First, let me clarify the terminology:
>
> In REBOL: In shared library:
> ------------------------------------------
> routine! "external library routine"
>
> In REBOL you may have string data that contains null
> characters. REBOL doesn't care. In C, operations that work
> on a string consider the null character as a terminator.
>
> If you are working with an external library routine that
> expects image data, then that routine most likely does not
> consider null characters as the end of data.
>
> So you can happily pass along string! to any external
> library routine that is expecting a pointer to any kind of
> data.
Jeff, thanks for the answer, I passed it to my Linux guru coleague :-)
I have to state that my knowledge of C is - well - I know the language
exists, that's all, so be patient with my questions, please :-)
Question to your above paragraph - Can I send "pointer" to rebol data into
library? I thought I will have to pass whole string to library = copying the
data in memory. If I can do following, it is cool:
1) having rebol word referring to string/binary data (rebol-string:
abcdefgh
)
2) defining routine which sends "pointer" to 'rebol-string into library ..
3) manipulating data referred by 'rebol-string in memory from library space
4) returning from routine, which means operation upon my image data is over
(from the library space perspective) and I can continue to work upon my
'rebol-string
in rebol environment ...
> The only hitch is having that memory come back. The way
> COMMAND works now is that if you have a return type of
COMMAND = View/Pro library interface? Does have View/Pro library interface
the same capabilities? (I hope so :-)
> string! (or char*) then REBOL/Command must find the null
> terminator-- otherwise you have some unbounded string
> hanging out (which can't happen).
>
> If you have a data buffer going off to a shared library from
> command that you would like to operate on both in REBOL and
> in the external routine, I recommend: 1. doing all your
> manipulations on that data from REBOL first.
All I need is to find optimal minimum and maximum in image data (rebol
minimum-of and maximum-of are not enough, as our image can contain "hot"
pixels, so range set could be inaccurete ... I would need some
maximum-of/exclude date [#{FFFF} #{FFFE}]), compute at least linear look-up
table (simply said to divide all values by some computed constant ... it's a
pity 'change/dup can't accept some simple math expression to be evaluated
upon each element of data array), and divide pixel values to get displayable
value (bitmap). Rebol iteration is slow for that ....
2. returning an
> integer! instead of a string! which allows you to hold the
> pointer to that memory but does not provide it. 3. Pass a
> reference (address of) to your buffer to an external routine
> which will modify it "in place".
Well, :-) I will have to stop wasting your time. My understanding of above
is just currently in theoretical level, I will have to ask my friend to
implement basic scenario and once I do some coding in C myself, I will be
able to discuss possibilities further ...
> > For example:
>
> // FOR UNIX --
> REBOL [
> Needs: [Command]
> ]
>
> write %zap-buff.c reform ["#include <string.h>" newline
> "void zap_buff(char ** buf, char what, int len) {memset(*buf, what,
len);}"
> ]
> call/wait "gcc -fPIC -shared zap-buff.c -o zap-buff.so"
> zbl: load/library %zap-buff.so
>
> zap-buff: make routine! [
> b-wrap [struct! [buf [string!]]] what [char] len [int]
> ] zbl "zap_buff"
>
> buff: {foo bar baz ^@ ^@ bing}
> b-wrap: make struct! [buf [string!]] reduce [buff]
> foreach c "REBOL^@" [
> zap-buff b-wrap c length? buff
> ?? buff
> ]
>
> The memory inside our BUFF in REBOL is actually manipulated by
> the external library. Scary cool stuff.. :-)
Sounds cool. And once I will understand it fully, it will sound even much
cooler :-)
Thanks anyway,
-pekr-
PS: is that only me or do you see global world Rebolution started by View
1.1 release? :-)
