World: r4wp

Saphirion is Robert Muench's company, who sell R2- and R3-based apps.

Afaik R3 GUI is workably stable. Saphirion has a non-trivial app 
running with it.

(http://development.saphirion.com/)

You have to circumvent fifty crash cases

Will take a look.  I am acquainted with Robert.I am a learning scientist 
(just finishing my PhD).

We write apps for classroom networks of handheld devices.  We used 
TI-83/84 calcs for years.  Just moved over to iOS.  Software bloat 
and complexity is killing us.

Bolek, Cyphre, Henrik, Ladislav, Robert (alphabetically) are working 
on it.

(Afaik)

That's a really good team.  I can see why they are on top of the 
OS release of R3.

There's quite a few more working with OS release :) New faces, even.

We often need to modify code within hours (between class sessions). 
 Not even close to happening on iOS so far.

I can imagine

Btw, it's 10 crashes in the testsuite. ~50 non-crashing test failures.

Would a bounty help get R3 on Android?

If we could encap R3 apps we might have a chance to continue this 
stream of research.

NickA: possibly. Should probably talk to Carl to get him spread it 
more widely.

Not sure if someone's around here on AltME with the time, skill and 
interest to work on that.

I'm basing myself on Robert's statement Sunday:

Than we will extend R3-GUI and the automatic test-framework. The 
latter is used to regression test all R3 builds over and over again. 
We currently have about 50 cases that crash R3. These need to get 
fixed.

Yeah, it's 10, not 50.

Let me see if I can get ahold of Robert and talk through some things.

Well, good news, I think I have the problem underlying the RESOLVE/extend/only 
crash (cc#1865) nailed down:
https://github.com/rebol/r3/pull/41

Would it make sense to use a group separate from !REBOL3 for discussing 
development _of_ R3. This would free !REBOL3 from this (at least 
currently) high volume of discussion.

Makes sense...  We have an Apple iOS group, but no one has responded.

Would it make sense to for a start, have a non-native GUI running 
on top of OpenGL? This is what you see from a bunch of different 
groups out there - e.g. using Lua (Corona, Gideros, Muai), Python 
(Kivy), Haxe, etc. This could maybe be done more quickly since I 
think there's already been some experimenting with OpenGL by Maxim, 
and others (Cyphre?). I guess taking this route would depend on how 
much work it would be to make Draw run over OpenGL, but it would 
open the door to a certain class of apps (games, graphics)..

The other frameworks I mentioned all have some extension mechanism 
to allow access to device sensors, camera, etc.

I suppose getting Rebol to compile, with Red/System, as some people 
have suggested would also be needed. Or would you just run interpreted 
Rebol on the device?

Scot, Saphirion's R3GUI is used in our Treemapper application: http://www.tree-mapper.com/


It's a bit ugly right now, because I haven't had time to work on 
the skin yet.

Yes, imo the first thing, whichou would REALLY help R3 GUI, would 
be to create a new skin - boxy, simplified, modern. No capsules and 
old OS9 Apple design hybrids ...

It crashes a lot, but Saphirion can start fixing it now

 - that is simply not true. We have build relatively complex R3GUI 
 based application (windows version at the moment) and there are no 
 crashes. Even our old "pre open source" R3 version works pretty stable 
 and can be used for production IMHO.

Also it should be mentioned when you compare the big test suite you'll 
realize R3 is even now more stable than R2.

Henrik, Pekr, yes R3GUI needs to get some nicer skin but otherwise 
in terms of functionality it's a proof the current R3 can be used 
for GUI apps even now.

Cyphre, I was under the impression that there were core bugs affecting 
R3GUI ?

AdrianS: re OpenGL. I see multiple ways here:

-try to HW accelerate the AGG graphics engine (currently used in 
R3) : I did some experiments which looks interesting. But the more 
you 'accelerate it' the more compatibility problems you get on different 
HW so it's about wighting the pros/cons.

-build completely OpenGL based engine (big task, brings lot of crossplatform/HW 
issues)


Otherwise it would be great if the current R3 graphics codebase is 
reviewed and some parts made more modular so different graphics engines/libraries 
are easier to plug-in. That should be not so hard work to do.

GrahamC, we get over all of them without the need to touch R3 dll 
code.

Ofcourse there are still critical crash bugs in the Core but they 
are not showstoppers (at least for our app the weren't). And now 
the crashes can be fixed which IMO should be the focus.

How to compile R3 in win 32bit using mingw32? I get always:
./r3-make -qs ../src/tools/make-headers.r
mingw32-make: *** [prep] Error 100

do you have the r3-make.exe in the make/ dir?

also make sure you are using the mingw32 makefile and not the Linux 
one

Yes yes, but there is some special option when I launch "mingw32-make 
prep" ??

r3-make must me r3-make or r3-make.exe?

(must be)

well, it depends what you have in the makefile, see the REBOL variable

r3-make -qs

so should it  be named just "r3-make"?

If you are under windows I'd prefer the .exe suffix ;)

I noticed another variable: TO_OS
what does it mean?

To me it looks you are using some Linux version of the makefile

because TO_OS= TO_LINUX

Is there another make file?

Where?