World: r4wp

I don't know if it's complete, but it goes beyond REBOL

Doc, this page can be updated because of the support of DLL generation. 
http://www.red-lang.org/p/roadmap.html

Also, 4.8 in the documentation:

As c-string! and struct! are already implicit pointers, the only 
pointed datatypes allowed are integer! and byte! (logic! pointer 
is not needed).

Outdated since float support

4.8.2:

Pointer declaration is only required for local pointer variables 
in functions' specification block. In such case, the datatype declaration 
can be omitted and left to the inferencer to guess.

This seems to contradict itself

Blender: yes, API is huge and it's a lot of work, but I'm convinced 
that Red, with appropriate dialects, would do wonders there and it 
could be a great way to make Red known.

-dlib option: it's just set the flag to produce shared library instead 
of executable.


-t option: sets a target which is just a handy way to group several 
options together (most options don't have a specific command-line 
switch).

can I generate e.g. ARM executable/library from Windows Red/System?


You can cross-compile ARM/ELF code from Windows or MacOSX, just use 
the appropriate target (https://github.com/dockimbel/Red). Currently 
there's only two ARM targets: Linux-ARM and Android. You can cross-compile 
to these targets from any platform Red/System compiler works on.

When Windows for ARM will be out, I guess we'll need a few modifications 
to PE emitter to support it. Does anyone know if Windows8/ARM beta 
versions are available somewhere?

Jerry: roadmap updated.

Re 4.8 in docs: I agree it's messy...improving that right now.

Done.

I know I'm late to the game, but temp.dll works here (win7 x64). 
If needed, I can pull up an XP x64 box to test.

Gregg: thanks for taking the time to test it. I think it won't be 
needed for XP x64 as we know it works on XP 32-bit and W7 x64 already.

Doc, I can confirm that the DLL works now. Thanks!

Well that was too soon. If I compile your example (%shared-lib.reds), 
I cannot load it into R2 (R2 crashes). If I comment all the on-* 
actors, I can load the lib, but I cannot access any values from the 
lib (foo, bar, i has no value).

Rebolek: I can reproduce the crash, looking into it....

(I'm pretty sure it was working last time I've tested shared-lib.reds 
script)

And are you able to use the exported values (foo, bar, i)?

Ah, nevermind, I had an error in my test script, exported values 
work.

It seems there are some remaining bugs in on-* callbacks, probably 
registers saving issue...still investigating...

So I've got this working:

>> foo: make-native [a [integer!] return: [integer!]][a + 1]
>> equal? 124 foo 123
== true


Still needs some work before publishing, but it shouldn't take long.

Great! :-)

I'll push a fix for the on-* issue in a couple of minutes.

Fix pushed, let me know if you see regressions.

Is Rebols GUI code (view etc) going to be usable in Red? Or is it 
going to something completely different? A while back I think there 
was talk of an dedicated Red editor (Reditor?). Is this still included 
in the roadmap?

I think that guys had some kind of GUI in mind, or maybe more specifically 
- some GUI targets, as e.g. html5, etc., being native on target devices. 
Myself, I would support and sponsor bit a View plus VID3 transition 
towards the Red, but not sure if someone would pick up. So - in the 
end, some "GUI" might appear ....

... but GUI is not a priority right now I think ....

It's important to distinguish between View and VID, and I assume 
that any kind of graphics engine can be implemented. I would personally 
like a View/VID like clone without the design flaws, but there is 
probably no hindrance in using GTK+ or whatever.

I'm not sure it's useful to repeat this, because people seem to wipe 
their memory and start over the discussion, but:

- Red's roadmap includes binding to native GUIs. That means there's 
supposed to appear a binding for every platform Red is ported to. 
The intent is to try to create one dialect that would be able to 
drive all these native bindings. This would be a common denominator 
dialect.

- Some of those GUIs are actually cross-platform, such as GTK and 
Enlightenment. so those can figure as a cross-platform GUI. They 
could offer more functionality than the common denominator dialect 
but still be cross-platform.

I can't accept anything so bloated as GTK or Enlightenment, hence 
I will voter for View clone anyday .... but the "architecture" of 
the plan sounds reasonable ...

You don't have to accept anything: the roadmap calls for a binding 
to the platform you already work on

I'm not convinced with the native GUI bindings. A lot of framework 
have tried it too and it's a lot of work to bridget the gaps. Or 
if the least common denominator is becoming to small the native look 
& feel won't help since the app feels crippeled anyway: Why don't 
they use widget ABC here?

Porting / binding R3 GUI to Red shouldn't be hard to do. It's a lot 
of work but we would get a simple and fast to use GUI. One of the 
major USPs of Rebol. I don't know any other simple to use interpreter 
that gives you a GUI out of the box. And, in these app days, it's 
no longer so critical to support native look & feel in all aspects.

Robert - it is just that talking to Cyphre, he was eventually interested 
in a "port", which would be more of a new implementation, supporting 
more advanced stuff in the backend (as switching targets, hw acceleration, 
etc.), and doing it in his free time the initial guess was 12 months. 
Such product would be surely cool, but it seems to me, that it could 
be just the second stage. 


In first stage, I would prefer having windowing/events plus AGG ported 
(still fast enough for many things, I don't understand the obsession 
about the speec, well, apart from devices lacking float support, 
here, AGG would be really slow). Such step could be done in 2-3 months 
of work? Then ppl could start port R3 GUI to it ....

That's fine; it would be one of the supported cross-platform GUIs, 
next to Enlightenment and GTK. Of course, you'll have to make sure 
you have the rights to use the R3 GUI

I could afford. e.g. 50USD/month for that. I know, it does not make 
for a living, but maybe such an effort would be considered by more 
ppl?

Well, for Robert, anyway, if Carl does not decide to go open-sourced, 
that thing is mostly dead anyway. But who knows, who owns the licence 
of View engine? IIRC the work was done by Cyphre. But what's the 
licence of the sources coming with Host Kit? Or is Cyphre still the 
owner of the work/licence?

the more options, the better imo ....

We don't have to be limited in GUI backend options, as long as we 
can use the same dialect (or subset of it) to program them.

About the native GUI option (using only what the OS provides), I'm 
pretty confident that the minimum common should be enough to cover 
most needs for business apps, I will do a prototype for the Red IDE. 
Having a free drawing x-platform canvas, for games and non-native 
GUI would also be needed, SDL seems to be the best backend for that 
AFAIK (that gives us also OpenGL for free).

I guess then that some code from R2/R3 applications will be reusable 
in Red (as Red uses Rebol syntax), but not the GUI code.

R2/R3: probable, for the GUI code, it depends how close our VID version 
will be (R3 VID seems to be a good model that we could push further).

I have this code for Red/System DLL:

f-1423181: func [a [integer!] return: [integer!]] [a + 1]
f-10584225: func [a [integer!] return: [integer!]] [a - 1]
#export [f-1423181 f-10584225]

and this code in R2 to load it which throws error:

>> lib: load/library %builds/routines.dll

>> foo: make routine!  [a [integer!] return: [integer!]] lib "f-1423181"

>> bar: make routine!  [a [integer!] return: [integer!]] lib "f-10584225"
** Access Error: Cannot open f-10584225

Is it Red/System or R2 problem?

Let me test that...

Error reproduced, looking for the cause...

Rebolek: issue fixed.

(fix pushed)