AltME groups: search

I think you need to add OS sleep() function.

Well, we need to integrate an R3-like async port/event system with 
multithreading (both internal threads and OS threads), that's the 
real challenge. So port! might be implemented as a sub-class of actor! 
(basically a message-based object). This is still rought as I haven't 
worked on the details of ports and actors yet. I'm not sure that 
using an external library for that very sensitive part would be a 
good idea, because we probably only need a tiny subset of the features 
provided by those libs and we need a perfect integration with the 
rest of the runtime/language. You can count of me to implement the 
solution that will give us the best performances, as this is a critical 
feature for being able to implement state-of-the-art servers...and 
you know that we want a very fast Cheyenne v2. ;-)

Protothreads is an interesting minimalistic approach to cooperative 
concurrency, but probably too limited for implementing something 
like task! or actor! BTW, I'm not sure if task! will be required 
in Red, in R3, it starts a new OS thread IIRC, although, I might 
use it to spawn a new process instead, as threads management will 
be covered by actors.

However, Windows, OS X and Android are missing from the OS entries

OS APIs and systems don't need that feature. And C++ is not that 
low-level, as you need to use C if you want to use WinAPIs or kernel 
functions.
OOP is a high level feature and no use in low level APIs.

In case, you wonder why Red needs both UTF formats, well, it's simple, 
 Windows and UNIX worlds use different encodings, so we need to support 
both. Red will use by default UTF-8 for string values, but on Windows 
platform, it will convert the string to UTF-16 on first call to an 
OS API, and will keep that encoding later on (and avoid the overhead 
of converting it each time). 


We might want to make the UTF-16 related code platform-depend and 
not include it for other platforms, but I think that some text processing 
algorithms might benefit from a fixed-size encoding, so for now, 
I'm for including both encoding for all targets.


It will be also possible for users to check and change the encoding 
of a Red string! value at runtime.

Or for me on OS X :

Schulz:Red peter$ rebol -qs red-system/rsc.r red-system/tests/hello.reds

Cannot access source file: red-system/tests/hello.reds

Peter: the lib-test file is crashing here on my OS X 10.6.2 image 
with following error:

dyld: lazy symbol binding failed: Symbol not found: _strnlen

  Referenced from: /Users/dk/Desktop/Red/red-system/tests/runnable/lib-test
  Expected in: flat namespace


After researching a bit about it, it seems that strnlen() is (was?) 
not supported by OS X.

strnlen only available in last year's OS X? Oh man...

Nenad" "Peter: the lib-test file is crashing here on my OS X 10.6.2 
image with following error:"


Did you install Xcode including the Unix libs?  I wrote the tests 
under OS X 10.6 but am now running on 10.7.

I just checked on my old machine, I did re-wrtie the lib tests on 
OS X 10.6 but on OS X 10.7.

I meant that I re-wrote the lib tests on OS X 10.7 not 10.6.

The SQLite binding now works on OS X, thanks to Peter

(I wonder if it's not an OS compatibility issue)

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).

So far, my short-list of encodings to support are UTF-8 and UTF-16LE. 
UTF-32 might be needed at some point in the future, but for now, 
I'm not aware of any system that uses it?


The Unicode standard by itself is not the problem (having just one 
encoding would have helped, though). The issue lies in different 
OSes supporting different encodings, so it makes the choice for an 
internal x-platform encoding hard. It's a matter of Red internal 
trade-offs, so I need to study the possible internal resources usage 
for each one and decide which one is the more appropriate. So far, 
I was inclined to support both UTF-8 and UTF-16LE fully, but I'm 
not sure yet that's the best choice. To avoid surprizing users with 
inconsistent string operation performances, I thought to give users 
explicit control over string format, if they need such control (by 
default, Red would handle all automatically internally). For example, 
on Windows::

    s: "hello"		;-- UTF-8 literal string

    print s		;-- string converted to UCS2 for printing through win32 
    API
    write %file s	;-- string converted back to UTF-8

    set-modes s 'encoding 'UTF-16 ;-- user deciding on format
or
    s/encoding: 'UTF-16

    print length? s	;-- Length? then runs in O(1), no surprize.



Supporting ANSI as internal encoding seems useless, being able to 
just export/import it should suffice.

BTW, Brian, IIRC, OS X relies on UTF-8 internally not UTF-16.

Pekr: "I wonder what the strategy for Red is going to be in regards 
to GC ..."


Currently Red is using a per-OS thread mark-sweep-compacting GC. 
I intend to make it concurrent (maybe parallel) and incremental when 
(and if) possible. The collector is not yet fully implemented. It 
is also possible to easily make it generational if we need it. When 
we'll have big Red apps, we'll profile them and determine the best 
tuning options for the GC.


There's no silver bullet for memory management & GC, you need to 
adapt it to the language specific needs (and they may vary depending 
on the type of application: client-side, server-side, realtime, ...).

Brian: I was wrong for OS X, it uses UTF-16 internally according 
to http://en.wikipedia.org/wiki/UTF-16

That was under OS X, it runs okay under Windows.

The output I'm seeing on both Linux and OS X is the same as on V0.3.0 
before you applied the patch.

All tests pass on Linux and OS X after latest master branch commit. 
Thanks.

Kaj: ok, I will have a deeper look in mmap syscall later, I'm currently 
debugging the OS X version.

Please remember we want to contribute but without a reasonable clue 
this is hard to do. (Besides the closed-source issue this is what 
Carl ran into when expecting others to contribute). Me and Github 
wil never become friends for example, I managed to get some source 
long ago but no clue how to update to the newest sources and github 
has informed me they do not wish to support their macosX tool for 
Leopard that I am running, nor remove the useless (?) check on OS 
number 10.5, and I am NOT updating my system and learning all the 
commandlines to upgrade etc is too much effort, (maybe someone can 
build a REBOL interface).

Kaj: I can reproduce a similar memory allocation error on OS X too, 
so I hope that fixing it there will fix it on Syllable too.

Ok, got Red working fine on OS X too.

Syscalls: given how much a programming language has to call OS services, 
I don't see why we shouldn't try to avoid an unnecessary layer. But 
I'm pragmatic, if we get more troubles than benefits, we'll adopt 
a more classical approach.

So far, the plan was to use Actor abstraction, but I might decide 
to use a more lightweight approach (something like goroutines). The 
basic idea for the low layer is to have cheap concurrent threads 
of execution that are dispatched over a limited number of OS threads. 
On the upper layer, they might appear as task! or actor! values, 
that you could create in various ways (do/task, read/write on I/O, 
...).

Well, when CPU I/O instruction will be added, you'll be already able 
to make kernel drivers for Windows or Linux....and an OS is typically 
90% made of hardware drivers.

cURL is included in almost all open source based operating systems, 
including OS X

There are OS- prefixes left in all platform files except Windows

I just got an idea - we will reimplement Amiga OS in a modern way 
:-)

OK, and also dispo in android I think and bbrerry os...

What is really exciting is the concept of creating an OS which is 
completely red/red/system - the control, power and speed of that 
woulod be phenomenal

Fixed the math library in the C library binding; should now also 
work on OS X and Android

There's something deeply wrong in the way most so-called "modern" 
OS/desktops are designed. My 133MHz Bebox with a poor PCI video card 
was able to provide a very responsive UI, even under heavy load.


The RPi feels like dying as soon as you launch the lightweight (no 
kidding!) web browser Midori...Of course, the browsing is very slow...I'm 
quite disappointed by that and it's not the hardware fault, the RPi 
is a great platform, but the software stack sucks a lot.

What we'll probably get first on Raspberry is RISC OS. I was using 
that in 1987, so looking forward to use it again with Red

At least in the official Raspbian you already have NetSurf, a completely 
custom browser ported from RISC OS

Interesting, that meshes with the idea that the extension interface 
should be able to function without an OS loader

It's helpful to make a conceptual distinction between the host interface 
and the extension interface, even though for R3 they are currently 
related to each other and share a lot of the same code.


For the host interface, the host is the OS (more or less) and provides 
an execution environment that the R3 runtime runs on like a program 
(this is all metaphorical, but I'm sure you get it). The OS in this 
case could be something like Windows, Linux, some microkernel, whatever, 
or it could be an application or application plugin like Eclipse, 
Visual Studio, Notepad++, Excel, Firefox, whatever.


For the extension interface, R3 is the OS, the extension-embedded 
module is the program that runs on the OS, and that program calls 
the extension's native code like a library. The program source is 
returned by the extension's RX_Init function, and that program then 
wraps the native library code. The module source is loaded like a 
normal script (slightly hacked after loading to make it a better 
wrapper), so the script could be embedded in binary data along with 
non-Rebol stuff just like with normal scripts. You could even have 
Red and Rebol scripts in the same file (if they use the same embedding 
method) so you the data the init function returns can be like a Red/Rebol 
fat binary, metaphorically.


Given this, Red could either be (or compile) a host for R3; or it 
could be (or compile) a runtime library that implements the same 
host interface as r3lib, making it a drop-in replacement for R3; 
or it could be (or compile) an extension that R3 is a client of, 
returning R3 code that calls calls the compiled Red code; or it could 
be an alternate extension container, for extensions that return both 
Red and R3 code from the same init function, which would call the 
Red code returned, which would in turn call the same native code. 
The two languages could be integrated at any point in the stack, 
along with other languages.

Another OS for running Windows console binaries (and possibly more): 
http://www.jbox.dk/sanos/

Brian: you don't have to like it, on Windows, it's the default target, 
so you'll never have to type it as long as you're not cross-compiling 
from another OS. ;-)

It breaks the "fit all in one binary" REBOL philosophy, requires 
to compile it for each platform and maintain OS-specific code...Not 
a problem per se, but IMHO a sub-optimal solution, that's why I was 
interested in a possibly purely "internal" solution, in case I would 
have missed it.

RISC OS runs best, though, but no Red

Possible to port Red to RISC OS too? Or a lot of work too %Y\ ?

I could contribute to the wiki (which one are we talking about here?) 

Now I have my 10x10 checkers game in Version 1.0.0 released I have 
some time to spend on the script Doc asked for. Can the specifications 
be reposted please?

Pekr: you don't get the right picture. When I mention "native widgets", 
I am mainly referring to the ones provided by each OS, which is what 
most users expect to find in an app for their OS, and what most developers 
wants, is to provide a consistent experience for users. So, actually, 
such approach will be lighter then /View, because the OS provides 
you with everything you need. In the case of Linux, GTK is the main 
standard and it is built-in many distros, so that is the one we will 
probably use for Linux target and you don't need to provide it with 
your app.

How many of us would ever need to do a real native Linux app?


We are talking about a cross-platform GUI framework, that means: 
write once, run everywhere. Using native widgets from the OS is an 
option, using custom ones (with non-standard look'n feel like /View) 
is another option. So, you write a Red GUI app on whatever system 
you like and your Linux users will be able to run it.

My understanding is that most people stick to one desktop OS, they 
are not switching OSes whole day (that is just a very small minority 
of computer users). Having close integration with OS can bring many 
advantages over a custom GUI like hardware acceleration or close 
integration with OS/desktop services. There are still cases where 
a custom cross-platform GUI could be good enough, so a View-like 
engine for Red is welcome. I just think that the default GUI option 
should be to provide an OS-integrated user experience.

Doc, would this Linux server you could provide be able to run VMs 
with OS X and Windows in order to do multi-platform automated builds? 
I'm thinking we could set things up like Unity does (see the link 
below). JetBrains provides TeamCity (the continuous integration server) 
for free to OS projects with an active community.


http://blogs.unity3d.com/2011/10/21/build-engineering-and-infrastructure-how-unity-does-it/

From the Unity link: "Most of these are virtual machines running 
Windows, Mac OS X, and Linux." 


I though Apple was explicitly forbidding to install Mac OS X on anything 
other than Apple hardware? Do they sell special licenses for VM?

Ok, I see what you mean. Like in C, you can already write "thread-safe" 
code in Red/System by using only variables on stack. If you need 
concurrent access to global variables, usually, the OS are already 
providing some API for that (locks, semaphores, mutex,...). I haven't 
chosen yet how it will be implemented at Red/System level, there 
are different options. For example, it could be handled by the language 
directly using a similar construct as in Java:

    synchronize [ x: x + 1 ]


In my early design notes, I have researched only how to handle concurrency 
at Red level, I've left the underlying Red/System part as an "implementation 
detail". I plan to start working on it after I/O will be implemented.

using the latest commit under OS X

If you're thinking about OS bindings, they should go in %platform/ 
folder. Can't you add CALL to natives? If you need help I can give 
you a check-list of things to add to support a new native, it's pretty 
simple.

Time is another fine thing. The OS should support one or another 
timestamp that can be picked up and molded into a preferred representation?

How are you supposed to implement an array, I can figure out some 
things about using a pointer, but I cannot believe it will work with 
the example value of 40000000h

What are you missing from using pointers?


I do not have a clue if this is a realistic value as a memory-address, 
that is why a simple array could come in handy.


The example is just showing how to do a dereferencing. It will probably 
crash on most systems if you use it with that value (reading should 
be safe on Windows, but writing not, as it is the default read-only 
memory starting page for PE executables). If you have a better alternative 
example that can work for real on all OS, feel free to submit a pull 
request. For example, retrieving the pointer value from an OS or 
C lib call would maybe be better (but much longer). My intention 
in this example was just to show how to dereference a pointer, how 
the pointer is initialized is a lesser concern.

What I am missing, is the background about the memory-management 
in certain OS'es, so where is it safe to place/store the data in 
memory. That is why I expect the example value to fail in a general 
situation. When array is supported, this will be taken care of by 
the compiler is my simple thought.

I know that François Jouen is already using Red/System to make image 
capturing from multiple cameras on OS X. Also as a rule of thumb, 
everything that is doable in C can be also achieved in Red/System.

Doc, in Red/System, I am currently forced to use the names READ and 
WRITE-string, because WRITE is taken for the syscall. Would you consider 
renaming that, to sys-write or os-write for example? I would really 
like to use READ and WRITE in Red/System like in Red

Well - IDE is IDE, I mean - the runtime stuff. Simply put (and most 
probably worrying unnecessarily and sounding like a broken machine), 
let's make R3/Red another Amiga like OS :)

I've added executables for all six current Red target platforms: 
Syllable, Linux, Linux-ARM, Android, Darwin (OS X) and MSDOS (Windows)

Let me announce first achievement of bringing R3 to Android OS based 
devices. I know many of you were waiting for this so long so here 
is the first test version to download:

http://development.saphirion.com/experimental/R3droid.apk


Note this is just first raw port showing the interpreter is working. 
The console input is missing at the moment, but will be probably 
among first things to add so you can have your beloved /Core on your 
mobile/tablet.


If you would like to speed up this developement, donate, sponsor 
or make a bounty for features please crosscheck with Robert/Saphition(he'll 
write more info here as well)

I've tested the versions for Syllable and Linux. ReadLine is probably 
available for OS X, but it probably needs to be installed through 
one of the extra packaging projects. I don't know if ReadLine is 
available for Android, but it would most likely also need to be installed 
as extra

We have made an other big achievement of bringing R3 to Android OS 
based devices. In the last couple of days Cyphre added console support. 
So you now can input stuff on your Android. Further .r extension 
is now associated with the interpreter. So you can run downloaded 
scripts. We have uploaded a script, so you try it out.


Android R3 installation package: http://development.saphirion.com/experimental/R3droid.apk


Test script, for direct access from Android device: http://development.saphirion.com/experimental/oneline-prime-numbers.r


Thanks again to all who made a donation to drive this stream. We 
still can spend 10-15 days on this project at the moment. If you 
would like to help push this developement forward, feel free to donate, 
sponsor or make a bounty for features.

The Red console-pro supports OS X now:


http://red.esperconsultancy.nl/Red-common/dir?ci=tip&name=examples

Thanks to Oldes for testing.

I made an OS-Mesa backend on SDL for my Red/System OpenGL binding:

http://red.esperconsultancy.nl/Red-OpenGL/dir?ci=tip


This does off-screen rendering in a memory buffer using the Mesa3D 
engine and then displays the result using SDL. Somehow I can't get 
it to work on Linux, but it's the first time I can use Red/System 
for OpenGL on Syllable. It circumvents two problems: the PicoGL library 
expects application functions that Red doesn't export, and Syllable's 
SDL port doesn't support the official OpenGL backend, so those routes 
both don't work. For most other targets than Syllable, the official 
SDL backend can be used.


It's also the first time that I have used my Mesa3D port to Syllable. 
I couldn't display the output before, because there is no display 
driver for the current Mesa3D versions for Syllable, just the standard 
off-screen rendering. It works great, even though it does only software 
rendering. PicoGL is a bit faster, but Mesa3D is a much more modern 
and complete OpenGL implementation.

I'm happy to announce that we made good progress regarding the Android 
R3 encapper.


A major breakthru in the multiple-app generation has been made (thanks 
to Andreas for ELF format hints). Now it is possible to create encapped 
apps with unique app-id. Such apps can be recognized properly by 
the Android OS and also accepted on the Google Play market.


The cool thing with this approach is one really don't need anything 
more than the Android encapper to produce the apk file. No need for 
android NDK, SDK or even JAVA to be installed ;-)


There are some glitches we are going to fix and than the encapper 
is ready for production.

But if I understand your question well, Brian, I was trying to turn 
off this waking up events in power settings as once I noticed my 
pc restarted itself after some stupid urgent os update in the middle 
of the night. I'm quite used to not shutdown completely so it's pretty 
annoying behaviour. I have not lost any data, but state of several 
consoles with history of commands which are not easy to write from 
scratch.

the collection of the above (DO, FUNC, ...) is not a library, the 
r3lib.dll is


Restricting "library" to only encompass "OS libraries" is certainly 
a debatable opinion, but it's not the stance the FSF takes. Perl 
modules and Java classes are not OS libraries, but still libraries 
in the FSF's opinion.

OS libraries and R3 libraries are both libraries. However, with GPL2 
they make an exception for linking to OS libraries even if they're 
closed source. With GPL3 they extended that exception to libraries 
that come with a runtime or VM, like Java, .NET, or closed-source 
REBOL. The exception doesn't go the other way though: It's not allowed 
to link to GPL'd libraries with closed code.


Ladislav, the runtime library is used to implement the interpreters, 
and includes the interpreters for that matter, but it's still a library. 
The DO interpreter really doesn't do a lot; it resolves the op and 
path syntax and dereferences words, but everything else is done by 
the functions of the runtime library, which your code is bound to 
at runtime. But for the good news, it's at runtime, so afaict the 
GPL doesn't require you to release your source because of that binding, 
as long as you load the source at runtime, which you pretty much 
have to do at the moment for scripts.


Encapping is a trick, but you can handle that with some limitations. 
Extensions will need to be GPL 2, and that means that they can't 
be used to wrap closed-source libraries unless they were included 
with the operating system you're running on. Encapping regular scripts 
and modules is semantically iffy, but you could handle that with 
a FAQ entry that explicitly says that loading a R3 script doesn't 
count as linking, even if you bind the words to GPL'd values. The 
same FAQ entry would apply to scripts in files, databases, whatever.

'Restricting "library" to only encompass "OS libraries" is certainly 
a debatable opinion, but it's not the stance the FSF takes.' - My 
reservation is:


- everything mentioned here is just an opinion of the respective 
person, certainly not a qualified opinion of the lawyer

- the DO is not implemented in REBOL at all, is it a functionality 
implemented in C, and the DO variable is just a variable the interpreter 
"knows", certainly not some code your REBOL program is "linked to".

- also, the user of the interpreter obtains r3.exe and r3.dll, not 
some other "hypothetic library" which is just a construct you are 
creating

It is common to use this FAQ entry as a way to make GPL extensions 
that wrap proprietary components: http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL


Developers commonly put links on their web site to the vendor's web 
site to download the DLL. However, it's iffy with GPL2 because the 
actual exception is worded like this:

However, as a special exception, the source code distributed need 
not include anything that is normally distributed (in either source 
or binary form) with the major components (compiler, kernel, and 
so on) of the operating system on which the executable runs, unless 
that component itself accompanies the executable.


Read literally, it would exclude runtime libraries that aren't bundled 
with the OS. It's more unambiguously OK with GPL3.

Again, the FSF's "library" interpretation is much more relaxed than 
yours, and does not only encompass OS libraries.

No OS linking.

So programming language announcements (not related to an OS project) 
are not off-topic on OSNews? Good to know for Red v1.0. ;-)

Do you have OS X 10.5 yet?

It seems Carl is still not much OK with the os-ing REBOL, but understands, 
it is a needed move?

He doesn't like the development model. OS projects have generated 
a lot of crap. Half of good design is saying no, and removing stuff. 
OS projects often do design by committee, and that design style doesn't 
say no enough.

The key is the app, not the language.  Regular old REBOL is all that 
needs to be underneath.  Apps can have dialects that control them 
AKA AREXX.  AppleScript is really a dialect for the Apple OS.

When I use rename function to rename a file, the file date on my 
Mac OS X changes too. When I change a name using finder, carefully 
clicking the file and renaming it, the date does not change. Doe 
sthis happen on other platforms too? How to steer this behaviour?

Arnold: I believe that Rebol/View uses Windows Codepages under Windows, 
MacRoman on OS X and ISO-8859-1 on  Linux. Sadly this means it only 
really supports true ASCII characterrs cross platform unless you 
manage encoding your self.

The android version doesn't have thesee calls implemented yet (AFAIK 
android doesn't have any "default OS" requesters for that so we need 
to do it ourself or reuse custom code)

(check the OS_Request_Dir() function in src\os\win32\host-lib.c as 
a base for the feature)

I assume rebol doesn't have "Labeled Timezon => current offset" capability 
so I am wondering if anybody had to do this and what (s)he found 
the best solution was? I see two ways, using external service in 
a lang that has such database/library (like php's ) or using the 
OS below (from bash) "TZ=":Pacific/Auckland" ; date +%z" ... also 
is there anything still I can do inside rebol, like getting some 
prefilled sqlite db using some lib I don't know of..

Yup. You should see what they have in store for SQL Server 2012. 
It can be run on a fully command line OS, managed remotely entirely 
through PowerShell scripting. And you can do PowerShell scripting 
of MS servers from Linux clients too, reportedly.

but my OS is windows 7

Hi, I managed to install Syllable OS 0.6.7 on my old-old laptop. 
http://www.arnoldvanhofwegen.com/gedeeld/syllable_1.jpgHad some 
trouble with the installation because I viewed some installation 
instructions and by doing so skipped the part where GrUB should be 
installed. Now I understood Syllable has native/built in REBOL3 support, 
but I am still looking for that.

I got the browser to be unresponsive again and tried to kill the 
process using the System Information Processes tab, but that didn't 
work and the info applicaton became unresponsive as well. At that 
point the mouse didnt work either and when I tried to send the OS 
a ctrl-alt-del, that didn't do anything.

I did choose that option when installing, but I can re-create the 
VM to try to fix a little hassle with the startup menu. What happens 
now is that on the default first option, 'Start Syllable', you get 
an error saying that the selected disk does not exist. Choosing the 
second option, 'Start Syllable (automatic boot drive search), finds 
the OS and boots. I'm not sure what went wron there - I tried to 
install grub to the MBR - basically, I pretty much accepted the defaults 
or suggestions when installing. I'll go through it again just to 
make sure that I didn't mess something up, though, since it doesn't 
take very long.

during VM setup, I chose "Other" and 32 bit for the OS choices - 
not sure if that was what I should have chosen

I wonder how most people come to it - if you search for compact/small 
Linux distributions, does it come up in the results? I would think 
most people looking to get something lightweight would look at linux, 
not some completely different OS

That's a really good team.  I can see why they are on top of the 
OS release of R3.

There's quite a few more working with OS release :) New faces, even.

I noticed another variable: TO_OS
what does it mean?

because TO_OS= TO_LINUX

If you have TO_OS=TO_LINUX, then you need to generate a Win32 makefile 
first.

make make OS_ID=0.3.1

make make OS... is ok
make prep gives that error

Getting a implicit declaration warning while compiling (Ubuntu64) 
for strdup() line 86 and free() line 88 in src/os/posix/dev-stdio.c
Adding includes (stdlib.h and string.h) clears this.

Andreas:  Sorry. I wasn't really commenting as much on Make-Doc-Pro 
as the impending realization that we are going to see a ton of forks 
branching off.  Make-Doc and Make-Doc-Pro have been associated in 
my mind with the "official" RT over the years. 


Hopefully the R3 team will be able to keep this thing focused.  Still 
not sure who those people are.  As long as Mark Down is pure Rebol, 
I suppose I don't have much preference.  Rebol has always taken the 
high road, so if MDP is better, I think we should stick with it. 
 Widespread adoption has never been as important as top quality better 
design.


If we continue to adopt whatever is widespread we'll end up losing 
everything that is better.  Amiga OS, Be OS, QNX Nutrino, etc.  All 
far better OS designs than Unix and Windows NT.  What do we end up 
with?  Unix and NT and of course the dreaded DOM (don't try to convince 
me that a flavor of Linux is anything more than a Unix OS).


So better is better.  If MDP is better, then we should adopt it, 
not because it is widespread, but because it is better.

OK, but I really want to reserve the term "MSDOS" for programs that 
actually run on MSDOS, a still-common embedded systems OS.

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