AltME: R3 Building and Porting

Messages

BrianH
For discussion and debugging of the process of building R3 (in the compiler sense, not the development sense). Also, the same for porting R3 to new platforms, since getting the core to build on the platform is the first step of that.
If you have a request that R3 be ported to another platform, here's the place for it. You might want to keep in mind that iOS and Android have their own groups, but if you just want to get it to compile on their respective SDKs then this is the place :)
Kaj
Better abbreviate the names of the !REBOL 3 * channels to !R3 * so the names fit in the navigation panel
Gregg
Done.
Kaj
Thanks

NickA
Android and iOS.  How much of a bounty do I need to offer for R3 with GUI on Android?
Kaj
That's a huge amount of work
NickA
Yes it is.  And worth it.
I'm hoping to nudge someone who's already considering taking it on.
Kaj
I'm not particularly interested in it, except maybe as an extension of a Red/System port
Pekr
NickA: during my private talks to Cyphre, he told me that if he would aproach the View engine nowadays, he would abstract it a bit, so that it could use various rendering backends - AGG, Cairo, so that where platform permits, it could be HW accelerated. But - such project would take some time, and Cyphre would have to be sponsored, in order to be able to do the work. I think, that it could be even written in a way, so that both R3 and Red benefit. But who knows ...
As for Red - no party is willing to port View engine, yet :-) Doc wants to aproach it other way - to use something like VID dialect, but final toolkit used would be the native platform one. Kaj did some example with Red/System + GTK, if I understand it correctly. I still think that even for Red, something like small View  engine would be benefical, e.g. for embedded work, where non traditional graphics is not a problem.
Dunno, how difficult would it be to get View sources adapted to Red/System. Red is missing on timers, events, etc., so maybe later, so that it can be naturally plugged in to its architecture ...
NickA
Thanks Pekr.  I spoke with Cyphre too - waiting to here if he's interested in being sponsored, and how much it would cost to make Android a priority.
here > hear
Pekr
sounds good :-)
Oldes
Btw.. with High Resolution Displays coming these days, the HW powered GUI is a must. The CPU rendering will be just for making high quality assets for GPU. http://www.tomshardware.com/news/Intel-Higher-Resolution-Displays-Coming,15329.html
Pekr
with higher resolution displays, comes higher performant CPUs/GPUs. Tegra 4 announced, 4core A15 1.5 GHz + 1 A8 Core, 72 GPU cores .... I still think, that we did not utilise full power of AGG yet. Gee, View 1.x ran on my Pentium 75 machine ....
BrianH
Has anyone tried compiling R3 for ARM Linux? This affects RPi, Android, and misc. micro-servers.
Bo
Yes.  TGD got it working on RPi.
BrianH
I suppose that compiling for ARM depends on the particular ARM platform and instruction set.
Bo
To download a tarball of an executable REBOL 3.0 program for the Raspberry PI (build with Raspbian “wheezy” ) take a look at:
http://www.TGD-Consulting.de/REBOL/r3-RPi.tar
---
pi(at)raspberrypi ~/dev/r $ uname -a Linux raspberrypi 3.2.27+ #250 PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l GNU/Linux
pi(at)raspberrypi ~/dev/r $ ./r3
>> system/version
== 2.101.0.4.10
>> system/build
== 16-Dec-2012/13:13:11
>> system/product
== core
Oldes
With HRD comes higher performant GPUs but I'm not sure how CPU scales. Look at Adobe, they are almost dropping support for classic display list (rendered on CPU) and forcing everybody to use their Stage3D which uses GPU. It's not easy move as there is almost no tooling yet, but it's a must. CPU is not able to process so many pixels with the new screens (with high frame rate). I don't say we should drop AGG support, just that there must come GPU support using OpenGL/DirectX and let the AGG to do high quality rendering of assets.

MaxV
Bo
Actually, Oldes, that's a great idea!  R3's new GUI could be built to utilize OpenGL by default.  That way, the GPU would handle all the graphics calls, and R3 would have 3D capabilities built-in as a bonus!  This would probably even make porting to Android and other platforms a lot easier.  In fact, doesn't IOS (iPhone) use OpenGL?
Oldes
It is. OpenGL ES2.0. As well as Android. Actually I don't think there is a chance to do GUI on these platforms without OpenGL.
Robert
We did a short test some time ago to use OpenGL, works but is quite some work to implement it completely.
Cyphre
The problem of OpenGL is it is great for rendering bitmaps etc. that can be used in 'crossplatform' way and I'd like to make such frontend for R3.... But if you want to implement something like DRAW  in OpenGLyou are getting into troubles. To do it properly you would need to use GL shader fragments.
When it comes to shaders, that means my 8 years old notebook won't be able to render it :-)
Also note that on Android for example the Canvas class (which is comparable to DRAW) is still not HW accelerated AFAIK.
I guess same is on iOS....the "draw' api is also not using GPU
The HW acceleration is still currently mostly used only for moving textured bitmaps...kind of fast blitter in the 2d graphics area.
Ofcourse if you want to create classical 3d game from textured polygons, shaders etc. that's the area where OpenGL excells (and the developement was mainly focused)
But good news is some people are experimenting with shaders to created 2d oriented engines but until the main players on the market won't set some standard it can still take lot of time.
NickA
MaxV, I made a couple tiny edits to clarify https://github.com/hostilefork/r3-hf/wiki/Building-from-source-on-windows-with-mingw .  I hope that's ok.
Bo
Couldn't DRAW work the same way as it does now, but render to a bitmap?  Then that bitmap could be rendered by OpenGL like it does any other bitmaps.
Cyphre
Yes, that's actually the method I'd like to upgrade the View engine...but not only for DRAW. The code would be modular so you can render to textures using any other library if you want.
I believe the Android porting effort will show us what is the optimal solution. It is good to find a balance between highly optimized but not much compatible HW engine and smoething that is fast enough and can be ported without big pain.
Bo
Just think, though, if OpenGL was the default renderer for graphics in R3, you could create a flat surface for a 2D screen, but during the same session, you could create another flat surface for another 2D screen at a 90% Z-axis orientation to the first, and then rotate from the first 2D screen to the next 2D screen in a fluid 3D way.
I did quite a few tests with OpenGL on R2, but the killer for me was the inherent delay with R2 calling the methods (functions) in the OpenGL dll.  I was still able to rotate an object created with over 1000 coordinate points 30 times per second on a quad-core computer, but that's probably 1000 times slower than you could do it with straight C on the same computer.
Bo
I toyed with the idea of writing a C-based dll that could take all the information for rendering an entire data structure from R2 so R2 would only have to make one method call to a dll per frame instead of thousands, but couldn't get enough higher priority items off my list to get started on it.
Oldes
I don't say you should use OpenGL for DRAW. There is no drawing api in Stage3D as well. I was proposing to use AGG to draw to bitmap with the best possible quality and let the HW do what it's made for.. to move pixels around. Bo understands it. That's actually how are modern apps made to have 60fps. To make animations just in AGG will not work (and honestly never worked). But maybe I'm too involved in animations and for many people would be enough to have static content. But that is not for future.
But of course, it's not an easy task. One must be careful to make it right.. all the draw command batching, texture packing etc.
Cyphre
Oldes, I don't argue with you and Bo about that. I think we all know the state of this technology. I've already did several prototypes of such "engine" so I have some ideas how this could be done for R3 it's just matter of prioritizing&time&resources.
I wrote about the drawing apis just so other people know OpenGL is not any Messiah if you want to do hi-quality 2d vector graphics in realtime.
I'm not against HW acceleration at all. It's just not easy topic in this non-ideal programming world as you pointed out.
I see the solution with good high quality rasterizer + HW accelerated compositing engine. That should be flexible setup at least IMHO. Plus this way also we got the classic 3d api for free.
Bo, I even tried to HW accelerate the AGG renderer code so it is completely using OpenGL...works well and you can use draw directly inside the OpenGL context mixed with 2d surfaces or 3d objects...lot of fun. But still , lot of stuff is still computed on CPU that way. Nevertheless its still better that fully SW based renderer.
The best solution for nowadays gfx HW would be to rewrite most of the AGG code for GPU using shaders. That would be state-of-the-art 2d engine for future. But also pretty big task ;)
Bo
What do you think is the best roadmap for the graphics engine in R3 right now?  Simply port VID to R3 to start, and then in R3v2 change out the graphics engine with hardware-based code?
Arnold
There are plenty of possibilities here.
Either port VID and have to deal with it's flaws and the history with it
or go the path of the RebGUI
or redo VID
I have read somewhere that Carl expected someone to come up with something better than VID.
I like VID yet it has its oddities, like when positioning elements using 'at. It could be improved in some of its behaviours, if you import it you may be hindered by this aspect, and it may get harder than restarting with a restricted base set of widgets.
Oldes
we are out of topic here probably
Bo
I don't think we're really out of topic here as the graphics stuff pertains to porting to different platforms, but if you wish, we could move this to the View/VID group.
When Carl was developing VID, he clearly expected that VID would not become the de-facto standard for Rebol graphics.  The face engine was the de-facto standard, and VID was simply one of what he expected to be several dialects for the face engine.  There were a few others, like GLASS, that came about.
Cyphre
Bo, I think if we don't make drastic changes to the GOB mechanism we should be safe when building anything on top of the GOB datatype. The gob! is in fact abstraction layer between the "VIew engine" and any "GUI framework" written in REBOL.
So as take this example:
We have now R3GUI framework which runs quite well on the current View engine (although this engine was build in 2 weeks during the very early R3 alpha work so it's kind of Q&D prototype ;))
(BTW should I mention the R3GUI is much better than R2 VID?)
Anyway, the R3GUI works on current View engine. When I tried to change the engine so it uses OpenGL accelerated AGG the R3GUI still worked without any problem (except visual bugs caused by incomplete OpenGL code implementation of the new prototype).
SO from that example you can see the "View engine" and "GUI framework" are two independent things and can be developed or even exchanged separately.
From the "design architecture" POV we should focus on stabilizing the GOB abstraction mechanism and DRAW/TEXT/EFFECT dialects syntaxes. If these layers are fine-tuned you have great base that allows us make experiments at the low-level graphics and also as well at  the high-level GUI abstraction layer.
Cyphre
So to sum up my thoughts:
-anyone can even now start working on it's own great GUI dialect for R3, or contribute and enhance to already existing R3GUI (latest version will be published soon)
-anyone can create own great low-level graphic engine for XY platform or just one native binding for specific os
-work of these people won't be useless if they stuck to the current gob! datatype
Ofcourse we can do slight changes to the gob!s or draw dialect as well but these should be always easy to incorporate in already existing code that relies on them
Robert
We made it to compile R3 into a single EXE. Filesize:  855566  can be packed with UPX down to 368654   (43.09%) That's the base we use for encapping R3 apps into a single EXE.
Bo
Cyphre, thanks for that info.  So does the R3GUI framework work on all current R3 platforms?  I understand Android is a no, but everything else?
Robert, do you have instructions posted anywhere for how you encap R3 apps into an EXE?  I'd like to publish that somewhere.

Andreas
Bo: R3GUI depends on the R3 View engine, which is currently only publicly available for Win32 (and that only as part of the former host kit releases, not yet integrated with the open source R3).
An Amiga port of R3/View reportedly also exists, but I don't know about its state.
Robert
The R3 I mentioned is R3-View. I'm going to publish it with the latest R3-GUI. Announcement will follow.

Pekr
I wonder, if in today's web situation, it would make sense to reopent the browser plugin project?
AdrianS
Don't know what the effort to get something going would entail as a regular plugin, but maybe as a Chrome Native Client there could at least be something available for Chrome more easily. It seems less work, at first glance.
https://developers.google.com/native-client/
Evgeniy Philippov
It would be interesting to port R2/R3 under Squeak/Pharo, http://squeak.org. Just an interesting thought.

Bo
I believe in order to do the browser port properly, the R3 engine would have to be multi-threaded or it would only work in one browser window. That seems like it would require a lot of rewriting if it isn't already in the design.
Kaj
R3 is designed to be able to be thread safe. Whether it actually is that currently is a different matter
Bo
That's good to know.  I know that Carl was aware of the browser limitation if not multi-threaded.  I just didn't know if he worked that into R3.
Kaj
There's unfinished multitasking functionality in R3. It couldn't work if it would be impossible to use R3's internals in a thread-safe way. Indeed, the way functions work was redesigned to make it so

Robert
Has anyone tried to compile in 64bit mode and dived into the problematic areas already?
Robert
I think the first thing to look at is the structu sizes. Either press it back to fit 32bit size, or expand it into 64bit space. Not sure what kind of side-effect this will have.

LiH
Hi, I'm reading the REBOL3's source codes, and I don't know It's a typo or not: in this file https://github.com/rebol/r3/blob/master/src/include/reb-c.h at line 61, about defining the uint type, It seems #ifdef DEF_UINT  was not correct. Maybe #ifndef DEF_UINT ?
Cyphre
LiH: to me it looks you are right, you can do "pull request" with the fix.

VincentE
As I'm updating my old scripts on rebol.org, I'm trying to understand the problems with compress/gzip & decompress/gzip ,
and found at least one issue in u-zlib.c .
When compressing, as the checksum method is assumed to be adler32 for most of the code, stream->adler (the current checksum) is wrongly initialized to 1 in two places, giving an off-by-one checksum in the output and making it unusable for decompress/gzip.
Still no clue for what yields the
     ** Script error: value out of range: none
error and why calling
     compress ""
seems to fix this problem sometimes.It seems that something isn't correctly resetted between calls.

GrahamC
Now digit the following commands in MinGW console: => Now type ??

Florin
Can rebol be built to include .r scripts for a portable rebol?
Maxim
not sure I understand your question  ':-/
Arnold
to distribute applications?
Florin
Bundle scripts along with the rebol executable, for distribution, as a single file.
Maxim
if you compile the host kit you have full control over this.  Otherwise, Saphirion seem to have built an encap tool for R3.
GrahamC
Saphiron's encap tool was built before the sources were available
If you do what Florin wants, how would you get your code to execute instead of landing on the console?
Maxim
the console is just a loop in the main which gets a string and executes it.  what you'd do is execute a string of utf8 text directly.
I had the r3 hostkit running as a dll with full host support... in fact, I was able to execute R3 scripts from within R2   :-)
obviously there was no sharing of info, only exchange of string data
so I'd use load/mold on the string from/to R3  ...
GrahamC
Are you answering the question?
Maxim
I'm just saying that with the hostkit, you can execute or setup evaluating whatever you want however you want.
Andreas
florin: yes, it's possible to include embedded modules or embedded extensions with R3. but it's not documented how to do so, at the moment, so you'll have to dig through the sources yourself.
for embedded modules, it could be as simple as dropping your module in src/mezz/, including its filename in src/mezz/boot-files.r and doing a full rebuild (including `prep`) after that. didn't try yet, though.
Florin
thanks
GrahamC
Florin, I wrote this about adding your own scheme https://github.com/hostilefork/r3-hf/wiki/How-to-add-your-own-scheme
Florin
GrahamC: Wonderful, thanks.
GrahamC
That's what I did for my vanity builds for integrating the time and smtp schemes
see the vanity group here

BrianH
Has anyone tried building R3 on Windows with CodeBlocks? I want to run R3 in debug mode, to track down native bugs.
I can also use VS2012 Pro, but it's less likely that someone has tried building on that. One can hope, of course.

AdrianS
Just so happens that I have a CB project file for the official source layout, if you want it. There's also a little change to make-make.r that you'll need t make for which he's made a pull request.
https://github.com/rebol/r3/pull/77
Sent you the file
btw, there's currently no difference between the release and debug targets - CB just builds the all target with whatever flags were there. We could change this to create distinct builds, obviously.
put the project file in the root of the project - sibling to the .git
AdrianS
"for which he's made a pull request" -> "for which Andreas has made a pull request"
BrianH
Thanks. Andreas helped set me up with VS2012 builds. I'll get to CB later, I'm sure with the help of your project.

Josh
I'm trying to learn a little more about debugging to figure out what is happening with the TCP bug
(On Windows), I've built a rebol with symbols included and I have reached segmentation faults with rebol several times
using GDB
Using backtrace, I can see the following:
Program received signal SIGSEGV, Segmentation fault.
0x76f0579c in ?? ()
(gdb) bt
#0  0x76f0579c in ?? ()
#1  0x76f055c5 in ?? ()
#2  0x76f8cc48 in ?? ()
#3  0x76f385ff in ?? ()
#4  0x76f055c5 in ?? ()
#5  0x75199b9c in msvcrt!malloc () from C:\Windows\SysWOW64\msvcrt.dll
#6  0x00421363 in Make_Mem ()
#7  0x00421814 in Make_Series ()
#8  0x0042d5fb in Make_Binary ()
#9  0x0042bc16 in TCP_Actor ()
#10 0x00409a10 in Do_Port_Action ()
#11 0x0040922a in Do_Act ()
#12 0x00409364 in Do_Action ()
#13 0x00404457 in Do_Next ()
#14 0x00404d45 in Do_Blk ()
#15 0x004235c3 in N_switch ()
#16 0x0040914f in Do_Native ()
#17 0x00404457 in Do_Next ()
#18 0x00404d45 in Do_Blk ()
#19 0x004093ae in Do_Function ()
#20 0x00403bbf in Apply_Function ()
#21 0x00403c66 in Apply_Func ()
#22 0x00425122 in N_wake_up ()
#23 0x0040914f in Do_Native ()
#24 0x00404457 in Do_Next ()
#25 0x00405a5f in Do_Args ()
Josh
Trying to learn how to investigate the structures to identify where it's going wrong
Josh
Anyone else have any scripts they have had bugs with tcp that I could look through.

Maxim
darn I wish I could put more time on R3   :-(
Arnold
Agreed, but now I try to compile and it is looking for gcc, but that is already somewhere in my $PATH so anybody has a precompiled R3 for Mac 10.6.8?
Kaj
Arnold
Thank you Kaj!!

Maxim
running through compilation in msvc, I'm getting a few errors...   I've already fixed a few little details wrt VC vs GCC
one snag I currently have is that I'll have to rename the qsort function, cause msvc already seems to have one in its linkeage.
Ladislav
So you are trying to build the community version?
Maxim
yep.
there doesnt' seem to be that many errors, a part for this qsort issue.
Ladislav
I thought that rename is not needed?
Maxim
I'm currently looking into the qsort declaration within msvc... maybe I can use it directly instead.
Ladislav
What is the error you are getting?
And no, you certainly should not use the Microsoft-provided version, unless you want to keep the bugs it has
So, can you cite the error you are getting?
Maxim
ok then... it seems like its part of the stdlib tree, so not much I can do to not include it..  we should just give it a new name within our codebase then. I checked and its only used  4 times in the complete code base... not a big issue to fix.
bug is 'qsort' : inconsistent dll linkage
basically a redecleration
re-declaration
Maxim
I guess I'd just set    I_AM_QSORT_R   so that the ifdef in the code triggers and use qsort_r in the string! and block! code.
I guess  "qsort_r"   stands for qsort redefinition
ah no... its a different func spec... ignore that... I'll just change the qsort name to uc_qsort   (uc for university of california)
Ladislav
don't change the original source if possible, please
Maxim
well, this is part of porting code to different compilers and toolchains.  for example, the   static inline   hints are different in msvc  nothing I can do there.  I added an #ifdef  setup for that with comments explaining why.
I'm not playing inside the algorithm.  but if the name of the function causes errors in the compiler, I can't just wish it to go away.

Marco
I am trying to build R3 with MinGW on Win 7 without luck. Does anyone have already successfully done it?
I tried this:
https://github.com/hostilefork/r3-hf/wiki/Building-from-source-on-windows-with-mingw
but (apart from the fact that Rebol links are outdated) When doing make prep R3 crashes with error #1405.
If I use r3bazaar It can not find gcc, then if I copy MinGW/bin/gcc to MinGW/msys/bin the process stops with error: CreateProcess: not such file or directory AND THEN I GAVE UP !
Ladislav
"Does anyone have already successfully done it?" - I did it
(but I did not use HostileFork's instructions)
Marco
Could you please give me the instructions?
Ladislav
which R3 did you use as r3-make?
Ladislav
could you try again using an interpreter from http://www.rebolsource.net/
Marco
Idem for the interpreter found on rebolsource.net
NickA
I did it, and at some point added a few notes, but they don't appear to be there any more.
Marco
with the console version it does not crash but gcc still gives error: CreateProcess: No such file or directory
Maxim
I've had troubles too.   a few notes:
-the rebol scripts in the current community distro do not work properly with saphirion'ts latest build... something to do with the use of 'FUNCTION vs 'FUNC .   I've had to edit at least one script.
-the CreateProcess error is due to local dir handling which is pretty screwed up, if you launch the make from a windows prompt. either create a batch file which does a CD first or use the -C option in make to tell make to change directory internally before interpreting the make file.
if you haven't done so, you might also want to add the msys package and make sure you've got a folder in your PATH environment which points to a folder with a proper  make.exe  (not the mingw_make) function.
Marco
yes, something wrong with paths. If I use : make TOOLS=c:/minGW/bin/ it starts but complains about not finding a .dll so now how I can I tell it to search for it in that dir? or How can I make a folder in my PATH environment which points to a folder with a proper make.exe?
Marco
I surrender so I tried to copy ALL  lib*.dll in c:/minGW/bin to c:/minGW/bin/msys/1.0/bin and it worked !!
Marco
So to summerize it if you have Win7:
Follow hostilefork instructions but:
- download R3-*-console.exe from http://www.rebolsource.net/  and use it as r3-make.exe
- copy ALL lib*.dll from c:/minGW/bin to c:/minGW/bin/msys/1.0/bin
- as the last command use $ make TOOLS=c:/minGW/bin/
good luck! Tell me if you find a shorter/simpler way.

Josh
Max, are you up and running on MSVC?
Maxim
not quite... running around on three projects... a lot of analysis on stone in the last few days.

eFishAnt
Any QT + R3 integration going on?
I would prefer VID + R3
Robert
Why then ask for QT? And, no not that I know about.
Did you try R3-GUI?
eFishAnt
I was for a short time, I will look again...thanks Robert.  and happy New Year!
NickA
eFishAnt, have you tried Marco's http://www.rebol.org/view-script.r?script=vid1r3.r3 ?  It lets you run many R2 VID layouts directly in R3.  You need http://www.rebol.net/builds/#section-2 to use it.

eFishAnt
Thanks I wll do some other experiments.

Arie
Hi, I try to make R3 in Windows 8.1 and get this error:
c:/mingw/bin/../lib/gcc/mingw32/4.7.2/../../../../mingw32/bin/ld.exe: objs/agg_g
raphics.o: bad reloc address 0xc in section `.rdata$_ZTVN3agg33gradient_polymorp
hic_wrapper_baseE[__ZTVN3agg33gradient_polymorphic_wrapper_baseE]'
collect2.exe: error: ld returned 1 exit status
make[1]: *** [r3-view-host] Error 1
make[1]: Leaving directory `/d/work/saphir-master/make'
make: *** [all] Error 2
Any ideas what's wrong?

Arie
Never mind.
I thought the Github sources are the bleeding edge of R3 sources, but that does not seem the case.
Just wanted to get the latest build of R3.
The build on Saphirion website is:
   version         tuple!    2.101.0.3.1
   build           date!     28-Jun-2013/16:18:18
Is there a newer one available?
Cyphre
Arie: the latest public builds of R3/Saphir are always here: http://development.saphirion.com/experimental/builds/
Cyphre
( latest public builds =  'official' builds made by Saphirion)

GregP
I've downloaded the zip archive today from Saphirion/Saphir and tried to build with MSYS.
I get r3.dll and r3-core-host.exe built OK. But didn't compiled r3-view-host.exe OK, here is the error I get:
gcc -o r3-view-host.exe objs/host-main.o objs/host-core.o objs/host-args.o objs/host-device.o objs/host-stdio.o objs/dev-net.o objs/dev-dns.o objs/host-lib.o objs/dev-stdio.o objs/dev-file.o objs/dev-event.o objs/dev-clipboard.o objs/lodepng.o objs/rc4.o objs/aes.o objs/bigint.o objs/rsa.o objs/dh.o
objs/host-view.o objs/host-window.o objs/host-graphics.o objs/host-draw.o objs/host-draw-api.o objs/host-text.o objs/host-text-api.o objs/host-compositor.o objs/host-event.o r3.dll -L. -static-libgcc -lm -lwsock32 -lcomdlg32 -lgdi32 -lmsimg32 -lstdc++ -liphlpapi -Wl,--stack=4194300 -mwindows objs/a
gg_arc.o objs/agg_arrowhead.o objs/agg_bezier_arc.o objs/agg_bspline.o objs/agg_curves.o objs/agg_image_filters.o objs/agg_line_aa_basics.o objs/agg_path_storage.o objs/agg_rasterizer_scanline_aa.o objs/agg_rounded_rect.o objs/agg_sqrt_tables.o objs/agg_trans_affine.o objs/agg_trans_single_path.o ob
js/agg_vcgen_bspline.o objs/agg_vcgen_contour.o objs/agg_vcgen_dash.o objs/agg_vcgen_markers_term.o objs/agg_vcgen_smooth_poly1.o objs/agg_vcgen_stroke.o objs/agg_vpgen_segmentator.o objs/agg_graphics.o objs/agg_font_win32_tt.o objs/agg_truetype_text.o
objs/agg_graphics.o:agg_graphics.cpp:(.text+0x3610): undefined reference to `std::terminate()'
objs/agg_graphics.o:agg_graphics.cpp:(.rdata$_ZTIN3agg33gradient_polymorphic_wrapper_baseE[__ZTIN3agg33gradient_polymorphic_wrapper_baseE]+0x0): undefined reference to `vtable for __cxxabiv1::__class_type_info'
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: objs/agg_graphics.o: bad reloc address 0x0 in section `.rdata$_ZTIN3agg33gradient_polymorphic_wrapper_baseE[__ZTIN3agg33gradient_polymorphic_wrapper_baseE]'
collect2.exe: error: ld returned 1 exit status
make[1]: *** [r3-view-host] Error 1
make[1]: Leaving directory `/c/persokeyfull/rebol3/saphir-master/saphir-master/make'
make: *** [all] Error 2
Any help appreciated!

Arie
@Cyphre thx!

Cyphre
GregP: try to compile all the cpp files and do the final linking with g++ instead of gcc (the next update on github will have the makefile improved)
GregP
Thanks a lot Cyphre, I only changed gcc into g++ to link the r3-view-host and r3-view and all compile!
My only issue now is this:
>> demo
Fetching demo...
Script: "Untitled" Version: none Date: none
Fetching GUI...
** Script error: / does not allow none! for its value2 argument
** Where: do resize-panel actor all foreach do-actor either -apply- apply case v
iew catch either either -apply- do try demo
** Near: do bind bind/copy [
    size: viewport-box/bottom-right
    ...
GregP
but I'm happy I can start playing with it anyway!

Cyphre
GregP: the error is fired because your compiled r3-view.exe contains more recent changes which are not reflected by the current public r3-gui build on our servers. We need to have the r3-gui build to be compatible with our current experimental binary builds. (ie. if you download our latest binary release it should always work with the latest r3-gui release)
So you are in a bit odd state now. To quickly fix that you can download the r3-gui from http://development.saphirion.com/resources/r3-gui.r3 (same link is used in the DEMO or LOAD-GUI commands) and replace all "unit-size" string occurences to "log-size". Then you can use the r3-gui with your custom saphir build.
Otherwise we'll be soon updating our build/releases/repositories with new versions (quite a lot things happened from the last public updates) so the multiple codebases will get in sync very soon.
GregP
Change done on r3-gui.r3: it works now :)

Maxim
is the community version always up to date with saphirion changes wrt core stuff?
Maxim
I should have said... is the community version  **currently**  up to date with latest changes from saphirion and atronix?
Pekr
I doubt it. Carl does not accept PRs, there is 37 PRs in the queue, dunno who can eventually accept them?
Josh
No, it's not up to date.  There are some diffferences in structure between the rebol repo and the other two in some places with the addition of the GUI code.
Josh
(didn't see 'wrt core stuff')  Well, mostly up to date I guess.  There are some bug fixes

Tomc
Q: Which is the most appropiate R3 GitHub repo for 64b Redhat, Debian & derivatives these days?

Andreas
Depends on if you need GUI.
If you don't need GUI support, I'd suggest going with the "community" repository. Which at the moment is basically mainline (i.e. the official codebase) + 64-bit support:
https://github.com/rebolsource/r3
A pre-built 64-bit Linux binary is also available under the "experimental" section on rebolsource:
http://www.rebolsource.net/
If you need GUI support as well, go with Atronix' version:
http://atronixengineering.com/downloads.html
Tomc
core is fine for now.
Goal is to have an established automated process to build an arbitrary version of rebolin a Docker container.
(which only suppotrs recent 64b kernels)
A fixed link to the current 64b linux binary at www.rebolsource.net  would help
something like a symlink from  r3-g25033f8  to r3-latest  
(asuming the -g25033f8 part changes and becomes unavailable after a while)

GrahamC
I think it would be nice to have a link that is easy to type as usually you have to use wget to download rebol.

GregP
I had about the same question as Maxim regarding keeping R3 source in sync between repositories. Carl open sourced R3, Saphirion brought the UI and other improvements, Atronix works on Linux. and I just wish we could consolidate all those contributions. Anyone has an insight on this?
Andreas
Needs one or more people dedicated to doing the consolidation.
At least most of the stuff is now out in the open, so anyone technically able and willing to do it, _can_ do it. But I know that doesn't help those who can't do it on their own and are (rightly) frustrated by the perceived fragmentation.
However, note that there is quite a bit of consolidation going on. Many contributions are pending as pull requests against the "mainline" repostiroy. And both Atronix and Saphirion have integrated most of the contributions into their repositories.
GregP
It is great it is now open sourced and I think it also takes time for a community to build and organize around. For example when Blender went open source it took times to get some/enough people involved. My concern about fragmentation is mostly about getting the same behavior on all plateforms.
I agree things are on a good track though.
Andreas
> My concern about fragmentation is mostly about
> getting the same behavior on all plateforms.
A concern I can very much understand and sympathise with. Ultimately, I think this needs one or more "champions" for each platform who are willing to actively involve themselves.

GregP
Is there any existing documentation around R3 implementation that would help any beginner to jump in?
Also, what's your opinion on using SDL2.0 as a R3 host ?

Kaj
SDL 2 would be a good backend to add

GregP
It would be a good backend but at the same time I wonder if it is not too much. SDL2 handles video, events, files, timer, keybaord, mouse, simple drawing, ... and R3 does many of this already. Mostly the compositor is what we miss.
Cyphre
IIRC Robert had some interest to use SDL2 as replacement of some of the host parts. But I think this is not small project. GregP, you have good point about the SDL based compositor. That could be interesting to try, but IMO it wouldn't improve the 2d vector graphics cpu performance it that's what you are after. Also I haven't researched if the SDL is modular enough so you can use only specific parts of the framework to have small footprint.
GregP
I agree it is not a small project and I would not be alone on this. The main motivation to use SDL would be to port the host to some other OSes like Mac. Also, SDL is pretty well supported since version 2.0, that's another plus.
Maxim
GregP, make sure you check out your private chat
Cyphre
Since we have R3 "view" on Win and Linux I'd personally like to find some time to finisih porting R3 "view" to Mac...there is only relatively small part missing so it should be much easier than doing the full SDL port.
TomBon
-- Since we have R3 "view" on Win and Linux I'd personally like to find some time to finisih porting R3 "view" to Mac --
sounds much better than opening another SDL bottle, what do you need to find this time or increases your motivation,.money?

GregP
TomBon, what do you mean by another SDL bottle, can you clarify?
Cyphre, if you think we could collaborate on this, maybe you could guide us?
TomBon
as stated above R3 is quite fragmented and adding another loosing end (SDL) doesn't help much. from my pov R3 is well positioned but needs a 'best of branch' unification.
as cyphre said, adding the missing parts for mac could be done much quicker, therefore my question what is needed to do so.
moreover, iirc R3 is already designed to switch backends (renderer?) later, e.g. agg -> cairo but since i am not deep into rebol atm i not sure at which state this whole thing is.
TomBon
another thing, is it right that there are 3 major branches atm?
original, attronix, saphirion?
is there a matrix avail. to see the diffs (e.g. +/- FFI / encap / call / patches etc.) without checking the sources?
Maxim
we are slowly working towards unifiying the commercial Rebol Branches .
The idea being that this one:  https://github.com/Rebol-Alliance  should eventually become a junction point for the members of the alliance.
There will be phases to this unification and there will be several people from various groups, able to accept contributions.   Note that we encourage the community at large to contribute, and when acceptible, these will be rolled in the next version.
Pull Requests  will be reviewed by different people from different companies which have large code bases.  The idea being that R3 needs to get stable at this point.  there needs to be more collaboration and this is the first step.
We are moving ahead steadily,  taking many steps to make it work.  we are already 6-7 companies depending on how you count things and will be building up the project for all of november.  I am aiming Dec 1st  as a release date for public launch.  
I wasn't going to go public too much for at least one or two more weeks, but there is so much going on with people talking about R3 forks and (rightly) saying something should be done...  I feel like people should know that a few Rebol champions are doing their best to become team players  :-)
Pekr
Who's "we"?
other than that, sounds promissing ....
Maxim
all that will be revealed in due time but consider the current major players like atronix involved.  Not all members want their names to be public.
amacleod
That's very welcome news!
GregP
On AGG, I think it is a great piece of code and I'm not sure Cairo is able to do all AGG can do. I don't see a need for a change to Cairo for now.
Maxim
AGG seems much faster than Cairo to me.  though Cairo has been maintained for longer, so it may have new features not available in AGG

Kaj
It was. Cairo became a lot faster lately, so I don't know how they compare now
I always "love" how people get angry over their project called slow, and then ten years later they gloat over making it much faster
Andreas
TomBon: there's even 4 major branches at the moment:
- reboltech (aka mainline, rebol/rebol)
- rebolsource (aka community, rebolsource/r3)
- saphirion (saphirion/saphir)
- atronix (zsx/r3)
No quick overview matrix, unfortunately. Probably worth doing. Or maybe wait for the Rebol Alliance stuff :)
Andreas
The gist of it, feature-wise:
- reboltech/mainline: baseline
- rebolsource/community: mainline + 64-bit
- saphirion: community + https + win32 view + bugfixes
- atronix: saphirion + linux view + udp + linux CALL + ffi + encap + more bugfixes
Another factor is immediate platform support:
- mainline and community come with a relatively large set of build target platforms
- saphirion currently has immediate build scripts for the big three (linux, osx, win32) and android
- atronix currently has immediate build scripts for linux and win32
Ah yes, of course: in the features above, add "android view" to saphirion:
append saphirion android-view
Kaj
Were those sources included?
Andreas
The sources to the Android View port have not been released so far, as far as I'm aware.
(not publicly)
Kaj
Right, so the feature is not really there
Andreas
There's a working APK you can download.
If that's sufficient or not for one to consider the feature to be there, is a personal decision.
Kaj
Will they be in the Alliance version?
Andreas
(I can't answer that; don't know.)
Andreas
(Also: any omissions in the above list are purely due to me being forgetful or unaware. "rebolsource" is the only thing I can speak of with authority; the rest is purely my personal perspective. No misrepresentation of any of the above branches and their associated parties intended.)
Kaj
It seems correct to me
Josh
Atronix has a complete serial implementation as well.
Andreas
Thanks Josh; a big part of it due to your diligent work or integrating Carl's work. Shixin/Atronix extended it to Win32 and Linux support, if I'm not mistaken, right?
Josh
I extended Carl's posix work to Windows and Shixin added all the other features and changed it to asynchronous
and bugfixed
Kaj
Carl's implementation wasn't asynchronous?
TomBon
@andreas - very good overview, thx!
@maxim - yes, cairo seems a little bit slower but as kaj said, they improved speed and cairo offers also some additional backends like pdf and also hardware accelaration if available.
i just mentioned cairo as an example and perhaps usable backend later but AGG serves very well for 2D GUI so far.
Henrik
I remember talking about using Cairo back when R3 alpha was just out and how it was rather big and did a lot of things that we don't need. Is that still the case?
Pekr
Would you expect cairo be any smaller? I think not. The thing is, that it might be part of many systems, so you don't necessarily care ....

Cyphre
The good thing is one can switch agg to cairo(or any other 2d vector api) with relatively small effort even in the current R3 (I don't consider the abstraction code fully finished yet and plan to do some cool changes that give us blazing fast HW accelerated graphics).
In fact, it should be enough to implement   equivalent of host-draw-api-agg.cpp interface that wraps all the current DRAW commands. Could be quite some fun to do that :)
Pekr
Cyphre - is there any estimate of when such abstraction code could be finished? Just curious ....
Cyphre
AFAIK Currently R3 developement is not at the top of priority list for Saphirion so I can't tell you any estimate. Sadly, I have no spare time to do it as an hobby project at the moment but I hope things will change over time.
PeterWood
All I hope is that the Rebol Alliance will not only consolidate the code base but also the different versions issue tracking data including the R3 CureCode issues).

yoffset
Watching for "blazing fast HW accelerated graphics" on Android.

amacleod
Any update on the "unifiying" Rebol 3 project?
Maxim
still progressing, though not much to report as I was pretty much offline for 2 weeks.
note that the alliance is not just about the R3 repository, but that is one big part of it.
I have started to work on the web aspect of it again. so it should start having some presence next week.
Maxim
begining next week, I should be pulling the changes from atronix into the rebol-alliance repo.   so I get that's a sign that its starting ;-)

amacleod
I'm considering a project that i wanted to do in R3 instead of R2 but when ever I looked into R3 it just seemed a little fragmented with the different forks and missing pieces. Its exciting to see that its coming together. Thanks Maxim and to all that are involved.

amacleod
Probably asked a bunch of times but if were to start a gui r3 project which version would be best to use that would be most compatible with the upcoming unified version and where would I find it?
Gregg
amacleod
Thanks Gregg
Gregg
And Saphirion's docs are at https://github.com/saphirion/documentation. Shixin has integrated their gui work into the Atronix version.
amacleod
So only the one version and it includes gui?
dev release or production?
Gregg
Correct.
Dev has some new features in it, like FFI and greatly improvec CALL.
And encap.
amacleod
great
No mac binary?
Gregg
Saphirion has an internal one I think, but Atronix does not at this time.
Mainline R3 binaries are available at http://www.rebolsource.net/, and there is an OSX build there.
amacleod
avast is blocking the dev version from downloading....says dRep infection. Production version downloads fine.

Gregg
If Shixin doesn't see your note here, I'll make sure he knows.
Robert
There is no OSX version that supports a GUI yet. What can be done is rendering to images, but no visible GUI.

GregP
Not directly related to R3, but I started to play with SDL 2.0 and tried some examples, compiled with MinGW on windows 7, and I'm rather badly surprised about stability: I can easily get a crash with a few interactions (click, minimize, focus, ...). Not a good start! I post this here because I thought about possibly use SDL 2.0 for a Mac port for example. Anyone with experience to share on SDL 2.0 ?

Kaj
It's new, but it's been in the works for many, many years, so I expected it to be better
It uses hardware acceleration, so crashes could be due to an unreliable video driver
GregP
I'm going to try on another laptop, also I'm going to use MinGW-64 instead. SDL forum is quite active, I'll check there if needed. I think R3 or Red can benefits from SDL so we don't rewrite everything.. I know you did a SDL1.3 lib for Red!

eFishAnt
eFishAnt
should   $ar -q blah.o lib.a
be the proper way to add an object file to an existing static library lib.a?

eFishAnt

Last message posted 269 weeks ago.