World: r3wp

To better understand my very general concern, not concrete complaint. 
Let's talk simply command usage, e.g. zip:

zip.exe what -a param1 -b param2 param3 -c param 4 
zip.exe/a/b/c what param1 param2 param3 param4


As you can see, in REBOL there is much more emphasis put onto user 
remembering the order of the paramteres, whereas in the first example, 
user simply takes desired parameter, and in THAT context, specifies 
the parameter value. It is shorter path, and user does not need to 
follow long patterns.


VID, in relation to above exple, might or might not be similar. We've 
got facets, which too, allow immediate context modification of particular 
parameter. For me facets are one of the strongest aspects of VID 
semantics and how it relates to lower layers.

Then we've got keywords for VID, which I like less. They are somewhere 
in your VID code, and mostly are as switches - 'at, 'pad, 'tab, 'across, 
'below, 'return. They are more difficult to follow, because they 
somehow "fly" in your code, and you have to look for them, to know 
actual state, when writing your code.


And now to styles - I don't like too much, if something outside my 
style, influences my style. So, how self-explanatory is "tight right 
off left 50% top 100%"? There are few possibilites, well, yes, based 
upon my assumptions:


1) the design, from my pov, is not right, and 'tight should be a 
facet to the style. We reach philosophical difference of object.show() 
or rebolish show object (or more objects).

2) 'tight does not affect real/internal margin of particular style, 
it stretches spacers used in group column model

3) the name is not self explanatory. Even first sentence description 
talks about margins. So why not 'margin or 'set-margin, which would 
be much more obvious at first sight ...

And you see, those issues might look as absolutly minor, for most 
of guys here. I am not language purist. I don't care much how you 
cook VID inside, but how will VID level code attract the eye of newcomers. 
We want to have millions of them, right?

Those aspects are nearly psychological, but judging upon my experience, 
when trying new stuff, I mostly follow following pattern - see screenshots, 
download product, install, try to run it with some examples, look 
at sources. Only if I am interested at first sight, I consult docs. 
I think that might be pattern of most newcomers .... if VID code 
will be obvious, they will stay and go eventually deeper. There is 
why I care so much for the "surface" of the things ....

petr: when i talk about "assumptions" you make - you make statements 
that sometimes have nothing to do with the current code or with what 
we plan in the future. you make them just by looking at some doc 
or something i or henrik said and then you "connect the dots" in 
your own way assuming that something is going to work in some way, 
or be limited and so on. most of the times, it's just the docs that 
are missing or the implementation that is not final.

Petr: let's assume that each person here did provide some input. 
there are 244 users here. reading all that would take a huge amount 
of time, and most of the feedback would make no sense unless you 
guys have actually used the system. you know, things are not going 
to be set in stone when beta is released, if we get valid input, 
we're going to listen to it. but, first, we solve the most obvious 
problems, and with a small group it's much easier to do so! you seem 
to underestimate the "management" work that is necessary whenever 
you have a bigger group. we don't have a person dedicated to support 
only - it's mostly me doing it, and i must handle three altme worlds 
at a time - if they were all big like this one, i wouldn't have any 
time for any coding.

use facets, not 'with

 - there is no 'with in vid3, actually, changing anything in the face 
 object is forbidden.

tight being a facet: Carl did not want that (it was my proposal). 
keep in mind though, that you normally don't use tight (you're going 
to see it a lot in current examples for another reason, but it'll 
go away very soon.)

anyway, i don't think it's a good idea to discuss it here, because 
most people here don't know what we're talking about. they'll just 
think vid3 is going to be broken because you continuosly complain 
about it... :)

There was a time, just when VID3 discussions had started last year 
that it was proposed to make VID3 way more scalable and powerful 
at a slight cost in ease of use. It certainly is way more powerful 
now. I can't see any dead ends or impossibilities where I'm sitting, 
like you can with R2 VID, but the ease of use never went away. It's 
a lot easier to use than R2 VID. I'm also betting that implementing 
new features will be a breeze compared to the wrestling you had to 
do for R2 VID.

Sounds really great!  Is there going to be a new file system with 
file locking for multi-user support?

*I* don't think VID3 is going to be broken. I know that Pekr complains 
and docs can be spotty. That is the nature of the universe.

Instead of using Mediawiki ... have a look at MindTouch's Deki-Hayes. 
 See http://wiki.mindtouch.com/Deki_wiki

Comes with a programmable API too

I don't think Mediawiki allows you to save multiple versions of the 
same file for versioning, but Deki Wiki does ...

Api docs: http://wiki.opengarden.org/Deki_Wiki_API

Any reason why the new vid dialect can't be back ported to r2?

Dependencies on R3-specific features such as Rich Text, GOB's, Percent, 
Draw enhancements, etc

backport those too!

Graham - then R2 would become nearly an R3, what would be the point, 
with limited resources?

error compiling committee.c: too many arguments to function

it might take a while for r3 to be stable

That would be an even bigger problem for backports

graham, there are way too many dependencies on R3 to backport R3 
VID to R2. It would probably also take as long time to port it as 
it has taken to write it.

I think also with what it does, graphics performance will be poor 
under R2 View. There are things being done that would make a port 
for R2 run at a snail's pace. :-)

Latest report: Nothing big has happened in a couple of days. Carl 
is buried in some work and bugfixing. I'm building the new requester 
system with the new way to parse dialects. 267 bug reports listed. 
Cyphre has talked about speed optimizations that will be made to 
the graphics system. Pekr is talking. A lot. :-) Gabriele is also 
busy coding.


There are many requests on ports for OSX and Linux as this Windows-only 
thing is getting rather old. Geomol has shown interest in the OSX 
port. Brian Tiffin has shown interest in the Linux port. Both, I'm 
sure, could use some help at some point, if anyone is interested. 
:-)

Why isn't Kaj clamouring to help with the Syllable port ?? :)

Maybe I'm more patient than the rest of you? :-)

I'll just wait for the Linux port, and then R3/Core will probably 
compile right away on Syllable, thank you very much :-)

Well, it will likely be a bit more work than that. Multi-threading 
may be a problem, depending on what features it will use

Building two operating systems also tends to take a fair amount of 
time, so I'm not clamouring for more work

How about porting it to a plugin that actually works?

There's a logical problem with what you say. According to you there 
apparently is not working plugin, so there's nothing to port to

plugin will eventually come, I'm sure. right now it's not very productive 
to have a linux/OSX version, due to the fact that most of the developers 
don't run Windows on their primary development box.

it's not very productive _not_ to have a linux/OSX version :-)

Henrik, does this mean that it is going to _much_ harder to port 
R3 than previous versions?  I realize it will be harder as there 
is likely more system dependant code than in the past?  I also realize 
there is going to more dependence on the community to kick-in for 
various platform ports.  I agree however that the linux and OSX versions 
should come after the windows, but the plugin needs to be within 
this calendar year.  [Unless R3 is going to be so good without it 
that the X-internet that was invisioned years ago will be more possible]

I thought one of the reasons behind the R3 re-write was to make it 
much easier to port Rebol to different platforms. I believe there 
is a complete segregation of 'core' and 'platform dependent code'.

Given that the Python team is planning on a 12 month beta for Python 
3.0, personally I think that it would be wise to expect something 
similiar for Rebol 3.

On the other hand we can be confident that Rebol 3 won't take as 
logn as Perl 6 :-)

Brock; To add to what Peter said, it might be hard to say whether 
a port will be much harder, but there will be a far greater potential 
for getting more people involved.  So we are faced with the unknown 
of whether random masses can produce more than a select few; in term 
of better, stronger, faster.  Will opening the OS specific side free 
RT to focus on the core technology or saddle them with testing,  
filtering the various ports and spending all day answering developer 
questions?  Soon to be seen.  I'd hedge on the former and look forward 
to a tide of momentum.

Brock, it's mostly a time issue right now. Still a lot of loose ends. 
I have no idea of the porting process as it's not documented yet, 
and I don't expect to be doing the porting. I do expect that as soon 
the process is properly documented, anyone with experience in C-programming, 
will be able to do a port.

harder to port: no, it's the opposite, it's much easier than R2.

I think that would only be true if R3 can also be ported without 
implementing the multi-threading. Can it run single-threaded, like 
R2?

Kaj, Syllable does not support threading? I am curious, what REBOL 
threading strategy is, or how is IO solved in general. We know we've 
got devices. Do thouse run as threads? Or how does typical async 
network communication happen for e.g.?

Syllable has extra-special threading, like BeOS. Threaded applications 
need to be ported. We do have a PThreads implementation for portable 
threading, but it's incomplete

Syllable/BeOS threading is much more like Amiga threading than like 
Unix threading

Amiga had threading? I thought it has only tasks?

The terminology that exists today wasn't used at the time. It's vague 
whether you should call Amiga a microkernel, or it's tasking multi-threading, 
but it basically was

Unix has a rather big separation between heavy-weight processes and 
light-weight threads. Threads may only be implemented in userspace. 
On Amiga/BeOS/Syllable, threads are light-weight and are based on 
kernel tasks

kaj, i think it's still easier to port R3 even with threads.