World: r4wp

How hard would it be to have Red generate .SYS Windows drivers?

Gerard, it's most probably a faulty apk, we'll see with the next 
demo.

SYS: It seems that not much is required to add to the PE file itself, 
I see no additional sections needed. However, it requires a proper 
checksum in the header. That checksum is either calculated using 
Windows API or the algorithm could be implemented directly in Rebol. 
In the first case, it shouldn't take more than an hour to add support 
to it, in second case a day or two. The main issue would be to find 
a simple way to test it once generated? Any idea?

Andreas: was your Nexus4 running 4.2.2?

Nenad, I only had the window title as well, on the Galaxy Nexus with 
4.2.2 - thought that was all that was expected.

I just tested the hello.apk (downloading from the Red site) on an 
emulated 4.2.2 and it works fine. So, it looks like the Android emulator 
is not as reliable as it seems.

Gerard, found the native crash dump info in your log file, thanks! 
We'll give it another try with the new bridge version once ready 
(this week).

Thanks Doc.

I have an example Windows driver that would be interesting to port 
to Red/System, so that could be a test case

I guess a 32 bit driver wouldn't work on 64 bit Windows?

Hmm, I'm not sure.

It would be great if it would; then I could surely use the Red route

I wonder how do you make the testing process simple and straighforward 
for a Windows driver.

The driver I inherited is a simple file filter driver, so it fits 
in the existing Windows infrastructure and it could potentially be 
almost empty

I'm not sure that you can just change a driver file "in place" after 
each recompilation. I'm wondering if you need to deinstall the old 
one and install the new one each time...

I suppose you need to reboot Windows. It's not Syllable ;-)

Haha, maybe not to that extent (well, I'm half-joking, for some kind 
of drivers, I would be surprised that is a requirement).

would = wouldn't

According to the documentation, this driver can be deleted and rebuilt 
without rebooting

Is there garbage collection/reuse of series slots? Not series content, 
but their slots in the series pool?

Yes, they use a stack-based allocation system, so each time a slot 
is popped, it becomes available for a new series. But, as series 
are not freed yet, slots are not popped.

Just got my HTC Sensation backk from repair. Droid 4.0.1, hello app 
works nicely ...

Any news around? :-)

No news, I'm still working on the new Android bridge, I've been busy 
most of the week with offline tasks, so I couldn't advance much. 
I finally can focus only on that since this morning, so expect some 
new apk to test by tomorrow.

The random program in Red/System now has the same output as the original 
C version by Donald Knuth.

Next step cleaning up the code and maybe add it to the Red repository.

Nice! How fast does it perform compared to the C version?

ehm both very fast.. timer needed. (cooking now, so will try that 
later.)

Now how to time the script? Red/System and C, the executables have 
a start time in seconds in the terminal logs but that is imprecise 
and there is no endtime just a logout message.

On OS X, there should be a time command in the terminal

Did in a shell the following: 
time C-script
real	0m0.073s
user	0m0.028s
sys	0m0.004s
time Red/System script
real	0m0.059s
user	0m0.039s
sys	0m0.004s

Thank Kaj, found it by myself 
:)

this time ;)

The user value is what matters most

It includes a bunch of display's but both the same.

Feared so much, It is still impressive.

How do you mean?

Red/System seems to be only a third slower. Did you compile the C 
version with optimisation?

I will clear both scripts from the extra display's I built in during 
debugging.

Optimisation? Just hit build in XCode, happy it does something. You 
want the sources when I am ready cleaning them up? 

I thought about looping it a 1000 times each and see how it performs, 
but that is maybe only for more digits beyond the decimal point..

I mean optimisation by the compiler. You should make sure an -O2 
option is passed to the compiler

Looping is a good idea to get better timing accuracy

Having debugging code in there distorts the result, and a lot compared 
to the real code, since it takes so little time

But even loading the executable takes more time than the calculation, 
so the above timing is meaningless

I can specify Release or Debug. I used the Debug up till now.
loop 1000 times Red/System script 
real	0m18.446s
user	0m18.385s
sys	0m0.023s
Then I have 
real	0m2.424s
user	0m2.405s
sys	0m0.006s

My C is not what is used to be. No doubechecked should do same loop. 
Well if this is the case there is some improvement ahead.

One difference I found during debugging is that Red seems to initialize 
its array before using it. In the C version there was data in an 
previously unused part of one of the arrays.

If you like  I can share the sources I used.

I don't think Red/System does. ALLOCATE should just use malloc()

To get zeroed memory, you can use MAKE in my C library binding

Is the second time for 1000 x C? Then Red/System comes out almost 
8 times as slow as C. I wouldn't expect that, either

(I am trying to avoid as much C as possible) I am happy with the 
result being the same now, could not judge where the memory was allocated 
but it was consistent during all my testruns, as was the C array 
with it's unexplainable filled fields.