• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[!R3 Building and Porting]

Arnold
21-Dec-2012
[46]
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
21-Dec-2012
[47]
we are out of topic here probably
Bo
21-Dec-2012
[48]
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
21-Dec-2012
[49x3]
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
Robert
21-Dec-2012
[52]
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
21-Dec-2012
[53x2]
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
21-Dec-2012
[55]
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
22-Dec-2012
[56]
The R3 I mentioned is R3-View. I'm going to publish it with the latest 
R3-GUI. Announcement will follow.
Pekr
23-Dec-2012
[57]
I wonder, if in today's web situation, it would make sense to reopent 
the browser plugin project?
AdrianS
23-Dec-2012
[58]
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
23-Dec-2012
[59]
It would be interesting to port R2/R3 under Squeak/Pharo, http://squeak.org.
Just an interesting thought.
Bo
23-Dec-2012
[60]
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
24-Dec-2012
[61]
R3 is designed to be able to be thread safe. Whether it actually 
is that currently is a different matter
Bo
24-Dec-2012
[62]
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
24-Dec-2012
[63]
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
25-Dec-2012
[64x2]
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
5-Jan-2013
[66]
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
5-Jan-2013
[67]
LiH: to me it looks you are right, you can do "pull request" with 
the fix.
VincentE
13-Jan-2013
[68]
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
16-Jan-2013
[69]
https://github.com/hostilefork/r3-hf/wiki/Building-from-source-on-windows-with-mingw

Now digit the following commands in MinGW console: => Now type ??
Florin
21-Jan-2013
[70]
Can rebol be built to include .r scripts for a portable rebol?
Maxim
21-Jan-2013
[71]
not sure I understand your question  ':-/
Arnold
21-Jan-2013
[72]
to distribute applications?
Florin
21-Jan-2013
[73]
Bundle scripts along with the rebol executable, for distribution, 
as a single file.
Maxim
21-Jan-2013
[74]
if you compile the host kit you have full control over this.  Otherwise, 
Saphirion seem to have built an encap tool for R3.
GrahamC
21-Jan-2013
[75x2]
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
21-Jan-2013
[77]
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.
Maxim
22-Jan-2013
[78x3]
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
22-Jan-2013
[81]
Are you answering the question?
Maxim
22-Jan-2013
[82]
I'm just saying that with the hostkit, you can execute or setup evaluating 
whatever you want however you want.
Andreas
22-Jan-2013
[83x2]
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
22-Jan-2013
[85]
thanks
GrahamC
22-Jan-2013
[86]
Florin, I wrote this about adding your own scheme https://github.com/hostilefork/r3-hf/wiki/How-to-add-your-own-scheme
Florin
22-Jan-2013
[87]
GrahamC: Wonderful, thanks.
GrahamC
22-Jan-2013
[88x2]
That's what I did for my vanity builds for integrating the time and 
smtp schemes
see the vanity group here
BrianH
4-Feb-2013
[90x2]
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
4-Feb-2013
[92x4]
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