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

AltME groups: search

Help · search scripts · search articles · search mailing list

results summary

worldhits
r4wp235
r3wp2632
total:2867

results window for this page: [start: 2767 end: 2866]

world-name: r3wp

Group: Parse ... Discussion of PARSE dialect [web-public]
Geocaching:
15-Mar-2011
Yes... Ladislav reminds me some basic math! God, I felt so stupid 
about this associativity bug! 

The reason why I developped parse-expression.r is because I need 
it to build an companion app for one of the best math book: Calculus 
3d edition from Smith & Minton! For now, I have developped a rebol 
library to transform any vid face into a function plotter, and parse-expression.r 
allows me to use human readable expression in the gui instead of 
guru rebol code :)
Group: #Boron ... Open Source REBOL Clone [web-public]
JaimeVargas:
7-Feb-2006
No it doesn't because there are some extensions and some minor changes 
desired. Extensions include math for 3D, gui thru Qt, and others.
Group: !REBOL2 Releases ... Discuss 2.x releases [web-public]
Anton:
9-Oct-2008
http://anton.wildit.net.au/rebol/gui/self-hider-btn.r
BrianH:
24-Oct-2008
No, and work on it has barely started. We will have a public development 
release of the new R3 GUI first.
Pekr:
29-Dec-2009
BrianH: how can you write your own client to R3 Chat? Can you actually 
use its command set? I mean - create a gui, and "send" command like 
"n", "lm", etc. to console in the background?
BrianH:
2-Jan-2010
OK, now that we have 2.7.7 released (even though there is more work 
to do, i.e. platforms and the SDK), it is time to look ahead to 2.7.8 
- which is scheduled for release in one month on February 1. The 
primary goal of this release is to migrate to REBOL's new development 
infrastructure. This means:

- Migrating the RAMBO database to a new CureCode project and retiring 
RAMBO.

- Using Carl's generation code for the manual to regenerate the R2 
manual, so we can start to get to work updating it.

- Porting the chat client to R2 using the new functions and building 
a CHAT function into R2 similar to the R3 version.


The R2 chat client might be limited to the ASCII character set, though 
support for the Latin-1 character set might be possible. Still text 
mode for now, though if anyone wants to write a GUI client (Henrik?) 
we can put it on the official RT reb site accessible from the View 
desktop. The server is accessed through a simple RPC protocol and 
is designed to be easily scriptable.


It turns out that Carl already rewrote the installer for 2.7.something, 
but it was turned off because of a couple minor bugs that we were 
able to fix in 2.7.7. With any luck, only minor fixes to the registry 
usage will be needed and we'll be good to go.


As for the rest, it's up to you. Graham seems to have a good tweak 
to the http protocol, and others may want to contribute their fixes.
Graham:
5-Jan-2010
Steeve, how's the R2 chat gui going?
BrianH:
5-Jan-2010
Actually, the GUI can get started before the API is - the semantic 
model of DevBase is pretty well set already.
Steeve:
5-Jan-2010
Agree. The project can be separated in two task.
- Working on a gui

- Refine the current chat app to extract a bunch of usefull functions 
(app API).


Idealy it should be 2 separated apps, so that we could write different 
GUIs for the same app.
BrianH:
30-Jan-2010
The same will likely be the case for future releases too, at least 
in the areas where R2 and R3 are comparable (not GUI, database, ports, 
/Library, etc.). Well see though.
Steeve:
26-Mar-2010
it's used for commit/rollback objects in my GUI
Steeve:
26-Mar-2010
it's used for commit/rollback objects in my GUI
BrianH:
26-Mar-2010
The new. You've been in GUI doc hell, and not noticed it.
Graham:
9-Apr-2010
The gui is not important
ICarii:
25-May-2010
is there the possibility of getting R3 AGG Richtext dialect backported 
to R2 - it would make a huge difference for gui development and text 
rendering?
Andreas:
29-Jun-2010
What would you call a REBOL binary that comes with GUI capabilities 
on Windows?
Andreas:
29-Jun-2010
On Linux, there's two versions of REBOL immediately available: /Core 
and /View. /Core is a REBOL binary w/o GUI capabilities, /View is 
a REBOL binary with GUI capabilities (and beyond that, it comes bundled 
with a self-installer and the Viewtop app).
GrahamC:
11-Dec-2010
Since a stable GUI based release of R3 is far off still, I agree 
that R2 should be updated
nve:
31-Dec-2010
And hope the design of View will be refreshed as what has been bone 
by Carl in march !
Cool design !
http://www.rebol.com/r3/docs/gui/guide.html
nve:
31-Dec-2010
Just change design... there was button, after btn with different 
design.

We need a refresh of the design of R2, to make it younger... The 
screenshoots of R3 GUI by Carl are cool.
Henrik:
31-Dec-2010
A good look will be possible for R3 to do. It's simply a waste of 
time for R2 and you can't produce anything that resembles Aqua anyway 
in R2. In R3 that is possible. But focusing on look alone is a big 
mistake, which too many developers using GUI systems are suffering 
under.
BrianH:
2-Jan-2011
Not yet, as R3 is a bit of a moving target. Most R2 code will run 
in R3 if it doesn't use any GUI or port code. Part of the migration 
strategy has been the R2/Forward stuff, which allows you to write 
code in a more R3-like way in R2. Plus, we are backporting some of 
the native enhancements that are additive rather than changing, like 
SELECT on objects.
Group: !REBOL3 Extensions ... REBOL 3 Extensions discussions [web-public]
Pekr:
26-Jan-2011
I would like to get back to Oldes' quesiton - is unloading extension/module/gui 
or other elements technically impossible?
Pekr:
26-Jan-2011
Once the program closes is not usefull at all. Think about R3 as 
an OS. It somehow should track resources. And/or stuff like GUI etc. 
should be isoloted in some context which you could easily scrape 
- unset, free, whatever ... or the memory consumption will rise endlesly?
Group: !REBOL3 GUI ... [web-public]
Pekr:
26-Sep-2011
Taken from RMAsset Twitter: "We plan to release a new R3-GUI version 
next Friday." Any significant changes about tobe expected, in comparison 
to latest release?
Pekr:
26-Sep-2011
ok, thanks ... Ithought that R3 GUI is suited for that task, but 
that would be probably a preliminary assumption :-)
Henrik:
26-Sep-2011
That time is better invested in allowing people to work on specific 
things, like the automated testing system for the R3 GUI, rather 
than specialize ourselves into a corner this early.
Robert:
2-Oct-2011
With our R3-GUI test-system available now, we could really need some 
help in creating test-cases. The more the better. We want to build-up 
a huge test-suite for GUI tests that we run on "every commit" to 
keep quality high and identify breaking changes.
Robert:
2-Oct-2011
The more help to build test-cases and submit them to us, the faster 
we will be in pushing R3-GUI forward.
Pekr:
2-Oct-2011
I can still get hard crasches of R3, in various phases:

do %r3-gui.r3
do %examples/run-layouts.r3


Two times I got a crash, when just closing the windows, and when 
at layout #15, clicking in the form. Once I got it with layout #20, 
and once at layout #27, clicking the big red button ...
Pekr:
3-Oct-2011
Cyphre - is there any chance Carl is going to be available to do 
some low-level fixes? It kind of crashes very often, but of course, 
with one specific use-case, so "normal GUI usage" (whatever that 
means) could be without any problems ...
Claude:
4-Oct-2011
great release ;-) thank you. perhaps ask carl to do somethink for 
gui on linux
Pekr:
7-Oct-2011
As for the possible "look & feel" of the GUI, I personally like HTC 
Sense, and Linux Mint - combination of light greay and green. IIRC 
Ashley created some more lightweight look for his GUI too later in 
the process ...


http://www.xda-developers.com/wp-content/uploads/2010/04/ScreenShots.png?139d23

http://smartphoneblogging.com/android-picture-galleries/htc-sense-screenshots/
http://www.linuxmint.com/screenshots.php

Take it just as a note :-)
Robert:
11-Oct-2011
So, I see no one is really interested in this R3 GUI stuff... I'm 
wondering a bit but anyway... I think doing public releases might 
not be worth the effort.
Pekr:
11-Oct-2011
Robert - I think that it is not accurate, that noone is interested 
in the R3 GUI. IMO we all are, it is just that each of us is busy 
elsewhere. If you look into the past of this group, or in the old 
GUI (Carl's one) old days, it was mostly me and 1-2 users to do some 
comments, studying code, etc. It is about the general lack of man-power. 
E.g. shadwolf claimed, he can do tree view in few hours, but is refusing 
to, and you better don't read the long blog chat. It is also about 
lost confidence of many rebollers into R3 in general. Or just maybe 
- ppl being in wait mode, untill Carl reappears?
Endo:
11-Oct-2011
Robert: you are wrong.  As Pekr said many of us are waiting and busy 
with something else. I downloaded all the RMA R3 stuff, tested all 
GUI examples (found some crash problems btw) I really would like 
to help/write a tree style, but I'm not a good Rebol coder I'm afraid.
So please keep up the work.
Sunanda:
11-Oct-2011
Robert -- an R3 GUI just isn't one of my priorities just now.


While  there is no likely target date for a beta release of R3, all 
my REBOL development is on R2.


I was happy to help debug R3 alphas while that project had some momentum, 
and I may be again in the future, But right now, I just do not have 
the time for what I have to consider to be speculative projects.

I hope you do get the help and feedback you need.
BrianH:
11-Oct-2011
I will be more actively interested when I start having to write code 
that requires any GUI at all, but what I'm working on right now doesn't 
even need a web interface. All batch and server stuff, and almost 
all the REBOL stuff is R3. This can't last forever, so I will eventually 
need a GUI. I am working on ODBC though.
Pekr:
12-Oct-2011
Well, that contradicts a bit expectation, that RMA's GUI is RT's 
officially endorsed GUI to be bundled with R3. OTOH there are no 
official R3 releases anyway, so ....
Pekr:
12-Oct-2011
I understand that you are focusing resources as much as possible, 
otoh it is a bit dangerous aproach - R3 GUI saw rather intense concept 
changes during last year. Anyone eventually willing to give it a 
try once time permits will think twice, as recent public release 
could be pretty much outdated in few weeks, API wise, etc. There 
should imo be a way, that upon some request or bunch of requests, 
public release is done e.g once in few months?
Ladislav:
12-Oct-2011
That are not the same excuses. For core, the excuses are, that Carl 
is not developing. For R3 GUI, the excuses are that we *are* developing.
Pekr:
12-Oct-2011
hmm, that makes R3 GUI a private, mostly a closed effort. The only 
question which remains now is - once R3 development is re-established, 
is R3 GUI becoming part of official distribution, or not? What's 
Carl's take on that? :-)
Henrik:
12-Oct-2011
That would depend if Carl approves it, and AFAIK he has not looked 
at any of the changes yet. However, it won't affect the development 
of the R3 GUI, whether he approves it or not. It will still be made.
Pekr:
12-Oct-2011
ah, so it might be just a separate package,like RebGUI is to VID 
... yes, that's possible too ... we just did not want to have many 
GUIs available. But R3 GUI is in limbo anyway, so ....
Pekr:
12-Oct-2011
So the GUI we can see in screenshots is modified RebGUI? Looks decent 
enough. Similar skin would be nice tohave for R3 too ....
Ladislav:
12-Oct-2011
So the GUI we can see in screenshots is modified RebGUI?
 - yes
Robert:
17-Dec-2011
jsut a short update: We build our first real-life R3-GUI based tool. 
It's a little thing but needed in a lot of companies. It's a tool 
you can interactively create things like heat-maps with. Heat-maps 
for how your IT system landscape looks like, organizational things 
etc. It's a nested layout created with color-mapping for visualization.
Pekr:
17-Dec-2011
Screenshot of the UI? Your last Twitter message towards the gui was 
related to creating new skin? I expect it was not high priority on 
your list though?
Group: !REBOL3 Host Kit ... [web-public]
Kaj:
12-Dec-2010
I'll get to that when I start porting View to the Syllable GUI, but 
that project is still a bit in the future
Oldes:
2-Jan-2011
If RM want more people to join the GUI development, they should sync 
the host-kit with Carl.
Robert:
2-Jan-2011
advanced WRT to the graphics & GUI stuff.
Cyphre:
4-Jan-2011
Rebol strings are stored either as ANSI (one byte) or wide char (double 
byte). Of course the rich-text module is currently doing the conversion 
for every rendered ANSI string in realtime. Any sophisticated rich-text 
caching is not yet implemented. (note: this has nothing to do with 
font glyph cache which works well) But even though the cache of large 
text block is missing the performance is still very usable for normal 
GUI cases so the priority to spend time on the line-cache is not 
too high at the moment.
Group: ReBorCon 2011 ... REBOL & Boron Conference [web-public]
Pekr:
26-Feb-2011
just an embeddable core into other environments, or will some GUI 
be possible later too? Also - will concepts like 'parse be available? 
networking (and other) ports?
Bas:
26-Feb-2011
@Pekr parse network ports, yes. GUI later
Dockimbel:
27-Feb-2011
Hi guys, I've spent a great time at the conference (and after also) 
with the people present. A big thank to Bas and Kaj for organizing 
this event, it was really nice meeting you all (pity that Robert 
couldn't been there to present RMA's GUI). The Boron's OpenGL demo 
was impressive (Star Trek's Enterprise ship), I'm looking forward 
to see the dialect used for that.


 I'm currently preparing the slides I've presented to put them online. 
 Should be done in the next hour.
Pekr:
27-Feb-2011
BrianH - from end user's perspective, you might not be right - missing 
pop, smtp, ftp, sqlite, mysql, postgress in official distro, just 
to name the few, GUI's not useable yet too, hence ppl keep tied to 
R2 ....
Kaj:
28-Feb-2011
I suppose we could have. There's an assumption in there that it is 
about REBOL development, so Carl must be there. But when Robert offered 
R3 GUI talks, it was about REBOL development
Group: Core ... Discuss core issues [web-public]
BrianH:
17-Mar-2011
Consistency between OS platforms. On platforms other than Windows, 
/Core doesn't need X or any other kind of GUI, and so doesn't require 
the libraries (good for headless servers). When there is no GUI, 
there is no clipboard. The Windows version of R2 just inherited this.
Henrik:
4-Jun-2011
SORT seems to sort anything that you throw at it and I think that 
makes sense, when making GUI lists. Right now I have a problem in 
that I can't control the input datatype and must sort anyway. The 
structure of the data is currently so that SORT/COMPARE is best to 
use, but LESSER? and GREATER? prevent this from being simple.
Ladislav:
6-Oct-2011
The former situation (the information about the "culprit file" is 
stored in the error) looks as follows, currently:

performing localization
** User Error: INCLUDE
** Near: do last-error: make error! spec


The trouble is, that the present error-forming code does not show 
all the attributes. If you examine the error on your own, you get:

print mold disarm last-error

make object! [
    code: 802
    type: 'user
    id: 'message
    arg1: 'syntax
    arg2: %gui/include.r
    arg3: [
        id: missing
        arg1: "end-of-block"
        arg2: "["
        arg3: none
        near: "(line 949) ]"
    ]
    near: [do last-error: make error! spec]
    where: none
]


, which shows all the data as "stored" in the error, which is referred 
(for convenience) by the LAST-ERROR variable
Group: !REBOL3 Proposals ... For discussion of feature proposals [web-public]
PatrickP61:
2-Jan-2011
The only thing that cannot be intercepted is when the OS itself closes 
rebol for any reason.  An example would be a user clicking on the 
[X] box to close the window.  Although it would be great to have 
a CLOSE? termination condition, I certainly understand that Rebol 
would not be able to intercept that.  Now that I think about it, 
the only way that Rebol could intercept a CLOSE? condition is if 
the window panel itself is under Rebol control through the GUI -- 
but even then, that may be a difficult proposal to implement.
Steeve:
27-Jan-2011
but not only GLASS, we have the same wory in any GUI engine
Steeve:
27-Jan-2011
several tens of megabytes to just display a simple GUI pisses me 
off
Ashley:
28-Jan-2011
re DEDUPLICATE ... it's not just GUI code that would benefit, DB 
code often needs to apply this on the result set. "buffer: unique 
buffer" is a common idiom, which can be problematic with very large 
datasets.
Ladislav:
29-Jan-2011
it's not just GUI code that would benefit, DB code often needs to 
apply this on the result set. 

buffer: unique buffer" is a common idiom, which can be problematic 
with very large datasets" - that is exactly where I was trying to 
explain it was just a superstition - buffer: unique buffer is as 
memory hungry as you can get any Deduplicate is just pretentding 
it does not happen, when, in fact, that is not true
Group: Red ... Red language group [web-public]
Dockimbel:
31-May-2011
If View sources are available under BSD, I will be glad to have it 
as one of the possible libraries for making GUI apps.
Kaj:
4-Sep-2011
The audience... sigh. They were friends, but there was only one programmer, 
formerly C++ and now Python. I asked him beforehand how long he thought 
his equivalent Python program would be. He didn't seem to be much 
into GUI programming, but he maintained it would be only ten lines...
Kaj:
9-Sep-2011
The GUI constructors are written to be flexible, so rather than crash, 
they work as best as they can while issuing warnings when they encounter 
errors
Kaj:
18-Oct-2011
The reason I chose GTK is that it's written in C, which makes it 
natural to bind to Red/System. Almost all other open source GUI toolkits, 
including Qt, are written in C++, which is much more problematic 
to bind
Kaj:
18-Oct-2011
So I chose GTK to support as the "native" GUI for Linux and BSD. 
It can also run on several other platforms until we have native support 
for those
Kaj:
22-Oct-2011
That's a pity, because Jaromil requested slider and file selector 
widgets from me. When he has those, he can start using Red for a 
GUI for his Tomb security tool
Dockimbel:
6-Nov-2011
Being able to make GUI apps on Android requires at least two more 
steps:
- have Red/System linker be able to generate shared libraries

- build a generic Java bridge to be able to instanciate java objects, 
invoke methods and receive events
Pekr:
6-Nov-2011
Are "native" Android GUI apps posible? I mean - e.g. GTK based ones. 
Or if View would be ported - it uses own methods to draw stuff, no? 
Although windowing is native, so probably some link to JAVA still 
required. Pity MeeGo did not become popular instead (pure Linux based 
IIRC)
Dockimbel:
6-Nov-2011
Does the NDK provide access to all the GUI framework?
Kaj:
7-Nov-2011
I do think that in practice, REBOL has usually been a Windows-only 
technology. Especially because its biggest draw is the easy GUI, 
and this is not (R3) or not well (R2) supported on anything but Windows. 
And because it still pretends to be cross-platform, there are even 
serious deployment problems on Windows
Dockimbel:
6-Dec-2011
The default target on Windows for Red/System apps is MSDOS (console 
mode). When Red will be there, I guess we'll switch the default target 
to Windows (GUI mode).
Kaj:
10-Dec-2011
People immediately came up with the standard question of "Why yet 
another language?", but when I showed the GUI dialect and compared 
it to conventional development, they recognised that something special 
was offered
Dockimbel:
23-Dec-2011
But it only runs in command-line mode for now, a Java bridge will 
be required to produce GUI apps on Android.
ArthurIngram:
24-Dec-2011
is it possible to get guide for new bees and info on the IDE.... 
from reading it looks like the GUI will be gtk+
Dockimbel:
24-Dec-2011
Sorry, no IDE available yet. For the GUI, gtk+ support is quite advanced, 
I might use it for the IDE if I run out of time to implement my own 
library.
GrahamC:
31-Jan-2012
And if there's a plan for a GUI
Henrik:
31-Jan-2012
I would hope Red adopts one of the existing GUI solutions.
Dockimbel:
31-Jan-2012
Newbies info: well, from all the presentations slides, you can see 
that Red is meant to be a "general purpose" programming language, 
so making any list of possible applications would be restrictive 
and probably also premature as Red is not yet implemented.


GUI is certainly a feature to have, but I wouldn't make it part of 
the "core" language, rather handle it as library. One remark about 
future Red GUI support, there will probably be several GUI frameworks 
available (we already have GTK+, I'll add a native one, and someone 
could contribute a View clone), I'll try to put a common VID-like 
dialect on top of them, so we can quickly switch from one to another 
with minimal changes needed.
Dockimbel:
31-Jan-2012
You can also add HTML5 to the list of future GUI frameworks. ;-)
Dockimbel:
31-Jan-2012
Also, there are several good high-level widget sets on top of HTML5 
that we could use as back-ends for client-side GUI, like Extjs and 
jQueryUI.
Dockimbel:
31-Jan-2012
REBOL-like languages are especially good at code generation, so we'll 
use that ability to abstract as many GUI API and frameworks as possible.
Evgeniy Philippov:
31-Jan-2012
Dockimbel: Re: native GUI - will this be X gui or you plan to write 
a native code for every card driver? ;)
Dockimbel:
31-Jan-2012
BTW, we could also make the View face/gobs hierarchy a common layer 
on top of all those GUI frameworks, if the overhead is not too high.
Dockimbel:
31-Jan-2012
Evgeniy: you're sounding like you're volunteering for writing the 
X back-end, thanks, that would be nice! ;-))


The native GUI I have in mind for Red is a SWT-like one, but as light 
as possible (SWT has some really heavy widgets). So, yes back-ends 
for Win32, X, Cocoa and Android are planned. The Cocoa and Android 
back-ends would need obj-c and java bridges.
Robert:
31-Jan-2012
Since we either do a Lua GUI or perhaps can adopt Red ;-) and do 
the GUI there, I think there will be some choices.
Dockimbel:
31-Jan-2012
Oh, I forgot to mention Flash also as a possible back-end for GUI, 
if Oldes makes the AVM2 port for Red/System some day. ;-)
Henrik:
31-Jan-2012
I would personally want a View clone with a GUI dialect on top. The 
R3 GUI could be appropriate.
GrahamC:
31-Jan-2012
Makes sense to re-use as much of the R3 GUi work as possible
GrahamC:
31-Jan-2012
So, Red/GUI is complete and awaiting RED
GrahamC:
31-Jan-2012
( though I have this nagging suspicion a dialected GUI trades ease 
of use for sophistication and flexibility )
Dockimbel:
31-Jan-2012
That will be the real challenge, define a GUI dialect good enough 
to cover the common parts and backend-specific extensions for been 
able to fully use backend-specific features.
GrahamC:
7-Feb-2012
Ok, though I can't think of anything I need to write in R/S at present. 
 I need GUI based apps though
Kaj:
7-Feb-2012
Ok, though I can't think of anything I need to write in R/S at present. 
 I need GUI based apps though
Pekr:
11-Feb-2012
But some functions  work although defined the same way. There might 
be some more functionality happenening under the hood, and who knows, 
that the code tries to return. OTOH the specs are clear enough - 
if it is supposed to return integer, then integer is simply an integer. 
And dialog windows work - I e.g. got dialoc saying "LED screen not 
found", so the GUI is inside the dlls ...
Group: World ... For discussion of World language [web-public]
Geomol:
2-Dec-2011
Q: We already know that your physics background influenced the new 
complex numbers datatype. Should we expect further progress of this 
kind (physics/science)?

A: After pointing this language out to a couple of friends from university, 
I was quickly asked to give scientific examples, like making a Lorentz 
attractor. There will come examples like that. Also I have some contacts 
at the Niels Bohr Institute (Copenhagen University), that I would 
like to show the language to and see, if we can create some projects.


Q: How long has this been in the making in general & how much time 
have you spent programming it?

A: I started R&D late March 2009. In March 2010, I had >7'000 lines 
of C. Then I took almost a year break from World and started up again 
Spring 2011. I have used much time on it this year (2011). So I've 
used 1-2 years effectively, I guess.


Q: Is there a way loading and interfacing pure object files, how 
about callbacks?

A: I don't have much experience in this area. Two of the closed alpha 
testers have looked at interfacing with sqlite3, which uses callbacks 
for some stuff. I would say, it doesn't work 100% yet, but it's being 
worked on. I need to see examples of loading and interfacing with 
pure object files to judge, how much of such functionality should 
be in World.


Q: Wouldn't it be useful to treat the kwatz! type same way as binary! 
so you don't need to always convert it? I mean, all functions that 
are able to take binary! arg should be able to use the kwatz! as 
well...or do you think are there any problems regarding that?

A: I've thought of that and came to the decision, that KWATZ! should 
be treated with some care. Are we always sure, we want to treat that 
data as binary? I need more experience using KWATZ! to judge that. 
Conversion could be fast, if the AS function was introduced, which 
should just change the type without copying.


Q: Is there a call-in interface available, meaning I can embed World 
in other programs?

A: Not yet. Internally I do call World functions from C (to parse 
URLs) by pushing arguments on the VM stack and call the execute_vm() 
C function. I imagine an interface much like in Lua (lua_call), but 
a little more work is needed, before we're there. This is an alpha 
release, so things will change/be added, before we move to beta release.


Q: Regarding your thesis I guess you have something like an integrated 
db or a special datatype for permanent storage too.. ?
A: Too early! :)

Q: What subset of REBOL2 will run without change in World?

A: Uh, ah, hard to tell at this point. When I need new functionality 
in World (because I want to run some of my R2 scripts), I consider, 
if it should be part of World/Cortex or if the new functions should 
go into the REBOL expansion/dialect (%rebol.w). I want World/Cortex 
to be small and compact. The idea with %rebol.w is, that much of 
R2 code could run, after this script has run.


Q: Are there datatype and function comparisons between World and 
REBOL2?

A: No, I haven't documented that ... yet. Maybe someone else wanna 
document that!? But there are differences, like the REBOL decimal!, 
which in World is called real!. And then %rebol.w just include the 
line:
decimal!: :real!
, so REBOL scripts using that will run.


Q: How many people were working on this World? :) Is it just a single 
man project?
A: Yes, just me.

Q: Will there be a GUI?

A: I would really need a GUI for my own work at some point. I have 
ideas, but nothing set in stone yet. And I want World to be open, 
so different GUIs should be possible, also the native GUIs in the 
different OS.


Q: Are you rich enough to buy Rebol Technologies and employ Carl? 
:-)
A: [KWATZ!]
2701 / 286712345...252627[28] 29