r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

eFishAnt
14-Jan-2005
[213]
grant proposal (ah, was writing backwards in French)
shadwolf
14-Jan-2005
[214]
eFishAnt your right !!! in a C# ressource explorer motion (wich you 
can see in Shardevolp IDE for example ) could be an amazing thing 
and even more if the same code all you to do so on evry OS rebol 
stands in
[unknown: 5]
14-Jan-2005
[215]
Cyphre - you should let Carl know that you want callback handling. 
 I know several of us have wanted that.
eFishAnt
14-Jan-2005
[216]
Josh wrote a simple hello example .dll a while back, including how 
to write the .dll...I started to mention this to him, but we talk 
about lots of things...so not done yet...guess I can tell him to 
read this.
Cyphre
14-Jan-2005
[217]
I mentioned this to Carl few times but you know... ;-)
eFishAnt
14-Jan-2005
[218]
ah, you must have made him think then of REBOL Platform ... ;-)
shadwolf
14-Jan-2005
[219]
If I take Cal Dixon's libopengl.r software for example we clearly 
notice that it only use the multi float functions in opengl and not 
the vectorial float functions that leads me to think  glColor3fv( 
my_colors[ 0.3, 0.5, 0.0 ]) kind of function are un explotable as 
is in rebol and many are the external libray that deal with array 
of data for arguments instead of fractionnal multi datas
Cyphre
14-Jan-2005
[220]
I used succesfully such arrays of floats as argument in my interface 
to AGG...this is no problem IMO
[unknown: 5]
14-Jan-2005
[221]
Cyphre do you have documentation on AGG anywhere?
shadwolf
14-Jan-2005
[222x2]
cyphre how do you do it ?
it's curiosity not evilness ...
Cyphre
14-Jan-2005
[224]
Paul: the docs aren't still for public..due to alpha state. When 
we reach beta the information in the docs will be 'stable' enough 
so all people could write code which syntax don't change.
[unknown: 5]
14-Jan-2005
[225]
Excellent at least there exist some docs :)
Cyphre
14-Jan-2005
[226]
Shadwolf: let me show you some example...
shadwolf
14-Jan-2005
[227]
oki
Cyphre
14-Jan-2005
[228x5]
to-double-array: func [blk /no-header /local result][
	result: make binary! []
	if not no-header [

  insert tail result third make struct! [d [double]] reduce [length? 
  blk]
	]
	foreach dbl blk [
		insert tail result third make struct! [d [double]] reduce [dbl]
	]
	result
]


pass-doubles: make routine! [
	doubles [binary!]
	return: [int]
] some-lib "PassDoubles"

my-doubles: to-double-array [10.5 2.8 3.0 2.325]


pass-doubles my-doubles

---------------------------

on your C side:

extern "C"
MYDLL_API int GradientPen(unsigned char* doubles)
{
	<your code here>
	return 1;
}
this way you can pass a block of decimal!s to C side
note: the first value is the length of the array if you don't use 
the /no-header refinement
ups: the 'GradientPen' should be  'PassDoubles'
but I hope you got it
shadwolf
14-Jan-2005
[233]
yes I understand i think
Cyphre
14-Jan-2005
[234]
...then you can either work on the array directly using C code or 
copy it into new array etc.
shadwolf
14-Jan-2005
[235x2]
but how to handle in rebol a C function of this kind void  my_func 
( int my_arg[25] ) { code... }
without adapting the C function argument type
Cyphre
14-Jan-2005
[237]
let me check...
shadwolf
14-Jan-2005
[238x6]
If I'm the conseptor of the external C lib i can do ma best for preprepare 
the data to be use to be teh easier to deal for rebol but I want 
to use a yet existant lib I will have to work pretty hard to be allowed 
to inteerface rebol code and this library
in PassDoule on C side you have a char * double argument that's not 
the same as handling a pre defined PassDoubles( unsigne double [4])
in PassDoule on C side you have a char * double argument that's not 
the same as handling a pre defined PassDoubles( unsigne double doubles 
[4])
I'm agree with you char * can feet every thing but this will need 
you on C side to make the spliting of the char content user << and 
&& maks to be able to retrieve your initial data passthue by rebol 
;)
it's impossible on C side  code to do without a spliting statement 
the direct exploitation of the data you pass to the lib
using rebol
Cyphre
14-Jan-2005
[244x9]
here is teh example of your case:
test: make routine! [
	arg [binary!]
	return: [int]
] my-lib "SumIt"

probe test #{0100000002000000030000000400000005000000}
==15
the C side:
extern "C"
MYDLL_API int SumIt(int my_arg[5])
{
	int result = 0;
	for(int i = 0;i<5;i++){
		result+=my_arg[i];
	}
   return result;
}
you can build the binary! array using this function
int-to-bin-array: func [blk /local result][
	result: make binary! []
	foreach int blk [
		insert tail result third make struct! [d [int]] reduce [int]
	]
	result
]
>> int-to-bin-array [1 2 3 4 5]
== #{0100000002000000030000000400000005000000}
>>
hope this helps you
shadwolf
14-Jan-2005
[253]
yes it helps me a lot
Cyphre
14-Jan-2005
[254]
so you can see everything is possible to do (except the callbacks 
;))
shadwolf
14-Jan-2005
[255]
to figure out in simle example this looks easy .... (hum not a lot 
in fact beacaus all the science is done by int-to-array reebol function 
witch is not pretty accessible to common or mortals )
Cyphre
14-Jan-2005
[256x3]
maybe one improvemet would be great for us:
have some faster way how to construct those binary! data from Rebol
I hope this could solve the REBIN feature or else we need some another 
native functionality for that
Gabriele
14-Jan-2005
[259x2]
you could makje it faster by reusing the same struct instead of creating 
a new one on each iteration
that would avoid a reduce too
shadwolf
14-Jan-2005
[261x2]
and if y have twenty array sized and typed  different kind for my 
external lib I will need to wirte and handle as many function to 
play with binary content
Cyphre you comming to my main point ;) giving to carl a premaid function 
that allow us to deal easyly with array (int, float, char what ever 
type) but for struct based array that's a challenge too and an horrible 
task to do