World: r4wp

If you want to offer multiple functions as a library, you can wrap 
their shared state in a CONTEXT

Then you can have random/seed, but it won't be a refinement :-)

And it will definitely stop looking like C :-)

It certainly would be nice to wrap all possibilities up in one package.

I think that's something different than what I meant

I think about a flexible solution to use the one random routine you 
want or need.

You can implement several algorithms with the same interface. CONTEXT 
is useful there. Then you can #include the one implementation you 
want

There are many such constructs in my bindings and Red itself

Hi Doc, I noticed that you published Android support yesterday. Will 
you publish also some example how to use it?

Note that it's preliminary, in the development branch

Is it a problem? :)

I consider all branches to be a development as all Red/S is still 
in alpha (or is it already beta?) version.

I think Red/System counts as beta, as far as v1 is concerned

I don't know if it's a problem. What I do know is that the Android 
port doesn't fully work yet. If you consider it developmental, then 
you can also expect Doc to add examples later. Anyway, I was just 
providing a preliminary answer for you because Doc is offline

Hi Oldes, I have pushed online only the low-level layers of the Android 
port. I will push the rest after some cleanups most probably tomorrow. 
It's working fine on pre-4.1 Android systems, but I'm still struggling 
with low-level bugs with 4.1+.

I will provide the full source code of the preview demo I've posted 
and will probably add another demo. It's still low-level manipulations 
of the Android Java framework, the final layers of abstractions are 
not yet there (dialects, schemes, ...).

I will need to go back to object! implementation in Red before implementing 
those layers.

Quick testing of the MT Red/S and C versions on my machine give a 
~4x difference in speed.

Odd. Is that on a Mac?

Linux

Which GCC version?

Red/System (current master, g0c9c1bf): 2.5s
GCC 4.8.1 -O0: 1.9s
Clang 3.3 -O0: 1.6s
Clang 3.3 -O2: 0.6s
GCC 4.8.1 -O2: 0.5s

So there's a much bigger difference between optimised and unoptimised 
versions than in previous tests

I was on an older GCC version then, 4.1.2 or 4.2.3

Xie is on Windows, and his compiler is apparently called cl. XieQ, 
is that CLang? Which version?

That's MSVC.

Perhaps GCC has gotten better at optimisation

Compared to 6-year old GCC 4.1.2, it certainly has improved a lot.

Just dug one of your Fibonacci results from back in Feb-2012, that 
used GCC 4.43.

dug up*

Oh, don't remember that

Ah, it must have been GoboLinux's GCC

You mentioned the benchmarks running on Syllable Server.

Yes, that's why I thought 4.2.3. But I would have tried them on Syllable 
Workstation on top of Syllable Server

That's an unreleased GoboLinux-on-Syllable-Server FrankenLinux

So it's a pretty big difference in optimisation, and MSVC doesn't 
show it

I use VS2012 and it's MSVC ver 17.

Thanks

We

 are a team! Yoho!! According to Frank Ruben on the Red mailinglist. 
 He has a question about interfacing a C app in Red/System.

Now in Red/System, we can't pass a function as parameter to Red/System 
FUNC,
but we can pass it to external C FUNC, right?


cmp-func!: alias function! [left [byte-ptr!] rihgt [byte-ptr!] return: 
[integer!]] 
quick-sort: func [
	base	 [byte-ptr!]
	n		 [integer!]
	size	 [integer!]
	cmp-func [cmp-func!]	
][
	; can't use cmp-func in this function
]

XieQ, that should work too.

You should try passing the function! pointer as integer! then type-cast 
it inside the function. IIRC, function! cannot be  yet used in a 
Red/System func spec block.

(But as you mentioned, function! is accepted for external functions)

I write a simple test  try to understand it, it's can be compiled, 
but the output is not expected

Red/System []


cmp-func!: alias function! [left [byte-ptr!] right [byte-ptr!] return: 
[integer!]]

cmp-int: func [
	left [byte-ptr!] right [byte-ptr!]
	return: [integer!]
	/local a b
][
	a: as int-ptr! left
	b: as int-ptr! right
	a/value - b/value
]

bar: func [
	cmp-func [cmp-func!]
][
	a: 1
	b: 2
	print cmp-func :a :b
]

bar :cmp-int

XieQ - that's what Doc stated, no? you use cmp-func! function type 
in func spec block, which is not allowed (except the external functions, 
whatever that means). Sorry if misunderstood on my side, just trying 
to point that out ...

it's print a memery address ( 00401A8F in my windows 7)

Pekr, I will try again

Yes, because the compiler is not yet able to process `cmp-func [cmp-func!]` 
correctly. Try to declare an integer! there and then type cast it 
to a cmp-func! inside the body.

Got the right result! Thanks Doc