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

World: r4wp

[#Red] Red language group

Pekr
27-Aug-2012
[1469]
... but GUI is not a priority right now I think ....
Henrik
27-Aug-2012
[1470]
It's important to distinguish between View and VID, and I assume 
that any kind of graphics engine can be implemented. I would personally 
like a View/VID like clone without the design flaws, but there is 
probably no hindrance in using GTK+ or whatever.
Kaj
27-Aug-2012
[1471]
I'm not sure it's useful to repeat this, because people seem to wipe 
their memory and start over the discussion, but:

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

- Some of those GUIs are actually cross-platform, such as GTK and 
Enlightenment. so those can figure as a cross-platform GUI. They 
could offer more functionality than the common denominator dialect 
but still be cross-platform.
Pekr
27-Aug-2012
[1472]
I can't accept anything so bloated as GTK or Enlightenment, hence 
I will voter for View clone anyday .... but the "architecture" of 
the plan sounds reasonable ...
Kaj
27-Aug-2012
[1473]
You don't have to accept anything: the roadmap calls for a binding 
to the platform you already work on
Robert
27-Aug-2012
[1474x2]
I'm not convinced with the native GUI bindings. A lot of framework 
have tried it too and it's a lot of work to bridget the gaps. Or 
if the least common denominator is becoming to small the native look 
& feel won't help since the app feels crippeled anyway: Why don't 
they use widget ABC here?
Porting / binding R3 GUI to Red shouldn't be hard to do. It's a lot 
of work but we would get a simple and fast to use GUI. One of the 
major USPs of Rebol. I don't know any other simple to use interpreter 
that gives you a GUI out of the box. And, in these app days, it's 
no longer so critical to support native look & feel in all aspects.
Pekr
27-Aug-2012
[1476]
Robert - it is just that talking to Cyphre, he was eventually interested 
in a "port", which would be more of a new implementation, supporting 
more advanced stuff in the backend (as switching targets, hw acceleration, 
etc.), and doing it in his free time the initial guess was 12 months. 
Such product would be surely cool, but it seems to me, that it could 
be just the second stage. 


In first stage, I would prefer having windowing/events plus AGG ported 
(still fast enough for many things, I don't understand the obsession 
about the speec, well, apart from devices lacking float support, 
here, AGG would be really slow). Such step could be done in 2-3 months 
of work? Then ppl could start port R3 GUI to it ....
Kaj
27-Aug-2012
[1477]
That's fine; it would be one of the supported cross-platform GUIs, 
next to Enlightenment and GTK. Of course, you'll have to make sure 
you have the rights to use the R3 GUI
Pekr
27-Aug-2012
[1478x3]
I could afford. e.g. 50USD/month for that. I know, it does not make 
for a living, but maybe such an effort would be considered by more 
ppl?
Well, for Robert, anyway, if Carl does not decide to go open-sourced, 
that thing is mostly dead anyway. But who knows, who owns the licence 
of View engine? IIRC the work was done by Cyphre. But what's the 
licence of the sources coming with Host Kit? Or is Cyphre still the 
owner of the work/licence?
the more options, the better imo ....
DocKimbel
27-Aug-2012
[1481x2]
We don't have to be limited in GUI backend options, as long as we 
can use the same dialect (or subset of it) to program them.
About the native GUI option (using only what the OS provides), I'm 
pretty confident that the minimum common should be enough to cover 
most needs for business apps, I will do a prototype for the Red IDE. 
Having a free drawing x-platform canvas, for games and non-native 
GUI would also be needed, SDL seems to be the best backend for that 
AFAIK (that gives us also OpenGL for free).
MagnussonC
27-Aug-2012
[1483]
I guess then that some code from R2/R3 applications will be reusable 
in Red (as Red uses Rebol syntax), but not the GUI code.
DocKimbel
27-Aug-2012
[1484]
R2/R3: probable, for the GUI code, it depends how close our VID version 
will be (R3 VID seems to be a good model that we could push further).
Rebolek
27-Aug-2012
[1485]
I have this code for Red/System DLL:

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

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

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

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

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

Is it Red/System or R2 problem?
DocKimbel
27-Aug-2012
[1486x4]
Let me test that...
Error reproduced, looking for the cause...
Rebolek: issue fixed.
(fix pushed)
Rebolek
27-Aug-2012
[1490]
Yes, works now. Thanks!
Kaj
27-Aug-2012
[1491x2]
How am I supposed to cross-compile a Windows DLL from Linux? I'm 
getting an internal compiler error with any combination of -dlib, 
-t WinDLL and -t Windows
Oddly, -dlib does produce an .so
DocKimbel
27-Aug-2012
[1493x2]
-dlib just activates the flag for generating a shared lib for the 
systems the compiler runs on.
From a non-Windows system, you have to use -t WinDLL target (and 
just that).
Kaj
27-Aug-2012
[1495x2]
That's what I thought. It looks like the crash happens when there 
are no exports
May I suggest that -shared is a more common switch, usually on systems 
using GCC?
DocKimbel
27-Aug-2012
[1497]
I guess we need an error message in such case.
Kaj
27-Aug-2012
[1498]
It also crashes when there's executable code outside functions. I 
guess that's disallowed
DocKimbel
27-Aug-2012
[1499x3]
There are short and long switches, -dlib is already a bit too long, 
so it might be reduced further in the future, the long version is: 
--dynamic-lib.
I prefer the dynamic/static naming scheme for libraries than shared/static.
Code outside: it shouldn't affect the library as it will never be 
run. I'm testing that...
Kaj
27-Aug-2012
[1502]
The compiler seems to crash on it
DocKimbel
27-Aug-2012
[1503]
Can't make it crash that way...what global code are you using?
Kaj
27-Aug-2012
[1504]
A lot of stuff. Just my way of claying a new binding out of an old 
one. We'll see when I encounter some specific situation
DocKimbel
27-Aug-2012
[1505x2]
Have you tried loading a Red/System DLL with Wine?
I've pushed a fix for the compiler crashing on missing #export.
Kaj
27-Aug-2012
[1507x5]
Thanks. No, I don't have a meaningful DLL yet
Don't really have WINE, either. I'd have to dig out the laptop
I'm confused by
https://github.com/dockimbel/Red/commit/0443c4c4fe9bd7a2a86f9b62b566b80f310539e4
I thought the callback attribute was replaced?
DocKimbel
28-Aug-2012
[1512x2]
The callback attribute is added automatically to a function when 
passed as get-word. But there are some cases where  it needs to be 
manually set, like for the ***-dll-entry-point function from the 
runtime.
The callback was never replaced, just inferred.
Jerry
1-Sep-2012
[1514]
Doc, will you extract all the information string of Red source code 
into a file, so I can translate them into Chinese without modifying 
the source code.
DocKimbel
1-Sep-2012
[1515]
You mean the docstring for functions (which we don't have yet), or 
all the code comments?
Jerry
1-Sep-2012
[1516]
Doc, I mean the docstring, error messages ...
Pekr
4-Sep-2012
[1517x2]
New Twitter message from Doc: "Making good progress on Red language 
layer, got a stable core compiler now and minimal datatypes set"
Go Doc, Go! :-)