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 :)
Better abbreviate the names of the !REBOL 3 * channels to !R3 * so the names fit in the navigation panel
Android and iOS. How much of a bounty do I need to offer for R3 with GUI on Android?
That's a huge amount of work
Yes it is. And worth it.
I'm hoping to nudge someone who's already considering taking it on.
I'm not particularly interested in it, except maybe as an extension of a Red/System port
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 ...
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.
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 ....
Has anyone tried compiling R3 for ARM Linux? This affects RPi, Android, and misc. micro-servers.
Yes. TGD got it working on RPi.
I suppose that compiling for ARM depends on the particular ARM platform and instruction set.
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
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.
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?
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.
We did a short test some time ago to use OpenGL, works but is quite some work to implement it completely.
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.
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.
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.
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.
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.
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.
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 ;)
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?
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.
we are out of topic here probably
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.
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.
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
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.
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.
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.
The R3 I mentioned is R3-View. I'm going to publish it with the latest R3-GUI. Announcement will follow.
I wonder, if in today's web situation, it would make sense to reopent the browser plugin project?
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.
It would be interesting to port R2/R3 under Squeak/Pharo, http://squeak.org. Just an interesting thought.
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.
R3 is designed to be able to be thread safe. Whether it actually is that currently is a different matter
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.
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
Has anyone tried to compile in 64bit mode and dived into the problematic areas already?
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: to me it looks you are right, you can do "pull request" with the fix.
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.
Now digit the following commands in MinGW console: => Now type ??
Can rebol be built to include .r scripts for a portable rebol?
not sure I understand your question ':-/
to distribute applications?
Bundle scripts along with the rebol executable, for distribution, as a single file.
if you compile the host kit you have full control over this. Otherwise, Saphirion seem to have built an encap tool for R3.
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?
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 ...
Are you answering the question?
I'm just saying that with the hostkit, you can execute or setup evaluating whatever you want however you want.
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.
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
"for which he's made a pull request" -> "for which Andreas has made a pull request"
Thanks. Andreas helped set me up with VS2012 builds. I'll get to CB later, I'm sure with the help of your project.
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 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 ()
Trying to learn how to investigate the structures to identify where it's going wrong
Anyone else have any scripts they have had bugs with tcp that I could look through.
darn I wish I could put more time on R3 :-(
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?
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.
So you are trying to build the community version?
there doesnt' seem to be that many errors, a part for this qsort issue.
I thought that rename is not needed?
I'm currently looking into the qsort declaration within msvc... maybe I can use it directly instead.
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?
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
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)
don't change the original source if possible, please
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.
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 !
"Does anyone have already successfully done it?" - I did it
I did it, and at some point added a few notes, but they don't appear to be there any more.
with the console version it does not crash but gcc still gives error: CreateProcess: No such file or directory
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.
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?
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 !!
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.
Max, are you up and running on MSVC?
not quite... running around on three projects... a lot of analysis on stone in the last few days.
Any QT + R3 integration going on?
I would prefer VID + R3
Why then ask for QT? And, no not that I know about.
Did you try R3-GUI?
I was for a short time, I will look again...thanks Robert. and happy New Year!
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: *** [r3-view-host] Error 1 make: Leaving directory `/d/work/saphir-master/make' make: *** [all] Error 2 Any ideas what's wrong?
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! 188.8.131.52.1 build date! 28-Jun-2013/16:18:18 Is there a newer one available?
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)
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 ...
but I'm happy I can start playing with it anyway!
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.
Change done on r3-gui.r3: it works now :)
is the community version always up to date with saphirion changes wrt core stuff?
I should have said... is the community version **currently** up to date with latest changes from saphirion and atronix?
I doubt it. Carl does not accept PRs, there is 37 PRs in the queue, dunno who can eventually accept them?
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.
(didn't see 'wrt core stuff') Well, mostly up to date I guess. There are some bug fixes
Q: Which is the most appropiate R3 GitHub repo for 64b Redhat, Debian & derivatives these days?
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:
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)
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.
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?
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.
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.
> 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.
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 ?
SDL 2 would be a good backend to add
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.
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.
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.
GregP, make sure you check out your private chat
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.
-- 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?
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?
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.
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?
we are slowly working towards unifiying the commercial Rebol Branches .
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 :-)
other than that, sounds promissing ....
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.
That's very welcome news!
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.
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
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
TomBon: there's even 4 major branches at the moment:
No quick overview matrix, unfortunately. Probably worth doing. Or maybe wait for the Rebol Alliance stuff :)
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
Were those sources included?
The sources to the Android View port have not been released so far, as far as I'm aware.
Right, so the feature is not really there
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.
Will they be in the Alliance version?
(I can't answer that; don't know.)
(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.)
It seems correct to me
Atronix has a complete serial implementation as well.
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?
I extended Carl's posix work to Windows and Shixin added all the other features and changed it to asynchronous
Carl's implementation wasn't asynchronous?
@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.
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?
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 ....
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 :)
Cyphre - is there any estimate of when such abstraction code could be finished? Just curious ....
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.
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).
Watching for "blazing fast HW accelerated graphics" on Android.
Any update on the "unifiying" Rebol 3 project?
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.
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 ;-)
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.
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?
avast is blocking the dev version from downloading....says dRep infection. Production version downloads fine.
If Shixin doesn't see your note here, I'll make sure he knows.
There is no OSX version that supports a GUI yet. What can be done is rendering to images, but no visible GUI.
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 ?
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
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!