World: r4wp

That solved it! Thnx, now putting the questionmark back in.

(As fast as yesterday) The base-1 versus base-0 would be accountable 
for a minute delay (less than 1% of the addressed numbers in the 
array, the 0-th and the last). The use of variables in the register 
looks more likely imho. Good point for the wishlist.

I was going to add register variables to the Red/System V2 wish list.


This is not required as one of the first change I have in mind for 
Red/System 2.0 is adding a good registers allocation method to backend 
code emitters.

That change alone should make a significant difference in speed (I 
expected it close to twice faster) and code size compared to the 
current approach.

Put it on for the world to know :)

The mersenne twister has a lot of examples in other languages. finding 
out the closest 1 to red/system.

Arnold as I understand, If the compiler to fully uses the registers 
then they wouldn't be available for application programmers.

to fully -> fully

I'm making good progress on the new Android bridge and demo, I should 
be able to release it tonight with all the new changes in source 
code (so Pekr will not need to reverse-engineer the apk ;-)).

most probbly I will do so anyway ;-) Will the demo be hello world 
example, or more usefull one, e.g. getting a contact list item? :-)

I'm not sure you're much interested in learning how to do it using 
Java objects, do you? It can be done already, but in order to implement 
proper abstraction for Red, we need at least objects support. Also, 
getting the GUI layer done is higher priority.

Arnold, sorry about forgetting the parentheses. They will really 
be gone in Red/System v2 :-)

The register storage class in C is just an advice from the programmer 
to the compiler. The compiler always needs to make the best use of 
the available registers. Your variables may or may not be stored 
in them, and if you request them, you may or may not get them

@Kaj, no problem, and Peter came to the rescue. Amazing even with 
a community this small, these things get solved in such a small timeframe.

I cut out all register directives from the C source, replaced with 
ordinary declarations. Program is yet as fast as previously. Most 
likely to me is the XCode compiler fills in some optimisations regarding 
this.

Yes

When Knuth wrote it long ago, it probably still made some difference 
in some compilers then

It even has #defines for K&R declarations...

About the pointer, I got the example of pointer/value: value somewhere, 
not saying from the fossil repository but might very well be so. 
The pointer: :value suggested confuses me. I tend to stick to what 
I had figured out. I prefer to avoid pointers almost always at all 
costs because of the trouble they can be. A good description is needed 
of how they are best used in  Red(/System).

Arnold, if you have specific questions about pointers in Red/System, 
maybe you could ask them on SO and make the first SO entries for 
Red?

Red on Android teaser: http://static.red-lang.org/droid-eval.png

Notice that this runs on the x86 emulator, there's still a few bugs 
to fix for the ARM version.

Nice :-)

Also, it's possible to use a ICS skin...I just need to figure out 
how/where to define it.

The whole UI is built in Red, calling the Android API through JNI.

Though, there's no UI dialect yet, but it can be built pretty quickly 
as Kaj demonstrated in the GTK binding.

ah, looks nice anyway. So - was the bridge rewriten, wrt your mentioned 
jni object limit?

What I mean is - would like to post something to FB channel, but 
not necessarily if the screenshot is an interim teaser. I can wait 
for some "more official" release, but surely I don't know your intentions, 
e.g. yesterday you mentioned objects, but those might be few weeks 
away?

Rewrite bridge: that was my intention, but I gave up after hitting 
a few walls in Java reflective abilities. So, I just optimized the 
memory usage of the current one and improved it.

Objects are required to build a cross-platform mobile API for Red. 
That way, you would use the same API for accessing universal mobile 
services and hardware from Red, like contacts, phone calls, SMS, 
GPS, Bluetooth,...

ok, now I understand. So objects are next it seems?

I mean - needed for parse, networking etc. anyway?

In the meantime, you will only have a platform-specific API, but 
as soon as objects are done, we could add some nice abstraction layers 
on top of it.

Yes, objects are becoming uber-urgent. :-)

OK, so will ask in a different way (wrt Android) - will there be 
any official release, an example published, or even a blog article? 
If not, I will post as we go. If so, I might wait, so that we can 
refer ppl to download it and try to do their own small steps ...

Parse: not necessarily, it was just a requirement from Gab.

Networking needs I/O, I/O needs ports, ports needs objects. :-)

If you mean by "official release" a 1.0, we're still far from that.

I might mention it briefly in the next blog entry. I would like to 
make merge the dyn-lib-emitter branch and make a new release. As 
the Java and Android bridges will be included, I will mention them.

ok, any timing? I mean - since thursday I will be out for 4 days 
....

(there is no need to rush those things, I can wait)

New release: Tuesday or Wednesday.

OK, good to know to plan ahead ....

Depends on how stable the ARM version of the bridge will be (and 
how much time I will take to fix it if required).

So I post a teaser, and later on will mention full new release, once 
the merge is in place and/or eventually blog article appears ...

btw - is ELF emitter finished? Noticed Cyphre used some of Adrian's 
work for R3 droid port too ...

I also plan to add a quick support for compiling kernel drivers for 
Windows. It shouldn't take long and some users need it, so I will 
give it a quick try.

Post a teaser: go on with spreading the teaser! :)

ELF: no it's not, Andreas hasn't found time for it yet, but I can't 
wait anymore, so I'll merge it in master this week.

Arnold, all sorts of constructs with pointers are valid, but the 
correction I gave is the correct translation of the C source

pointer/value: value