World: r3wp

Uhhh, parallel vector processing! If you get that working and can 
use the hardware to do the actual calculations, then you'll get lots 
of speed!

interesting discussion regarding modules starts, and some points 
are raised, mainly because of security.

Geomol, tuples are currently an immediate value like an integer, 
rather than a block-like value. This is why they are fast.

Yes, I realize that. It was just a crazy idea, that would make it 
easier to work with colour values. But we better keep tuples the 
way, they are. Fast!

Something to consider for REBOL 3: The current implementation strategy 
for symbols in REBOL has significant limits to the possible number 
of symbols available at one time. It might be a good idea to try 
a red-black tree for symbols instead - newLISP uses that strategy 
and can handle millions of unique symbols efficiently.

I'm just putting the idea out there - I'm not familiar enough with 
red-black trees to know whether they would be possible to use in 
this case, just that another language with similar implementation 
size uses them and it works for that language.

Any news on user datatypes ? I've just realised they would be very 
useful to me to implement an interpreter.

Just wondering if it would be possible for richtext command sequences 
to also fit into a word!, so symbols can have their own colour and 
font when molded into a richtext field. eg:
	word: to-word "/bPhrase"
Now when I mold word I see it rendered with bold text.

My concern is just to make sure that all the command sequences (like 
/b in the example) are allowed in a word!, and possibly also still 
allow  loading as a word! directly. eg:
	type? load "&bPhrase" ;== word!
(assuming the richtext escape character is & )

This could mean an editor could render symbols with their formatting, 
for instance. (I'm also thinking of implementing an interpreter within 
rebol).

for R3 View group. I just did my homework, trying to get PythonCard 
working. It seems to me Python plus PythonCard is not enough, so 
I needed wxPython - total install is 55MB :-)

but that is not the point. I just first could not follow, how they 
work with widgets, and then I found out - they have separated code 
and widget definitions. At first it looks strange .... it is like 
having 'feel(s) , event maintanance, app logic, without seeing what 
actually you are working with. But I do understand, why they keep 
widget defs outside in external file, which is kind of simple (as 
VID is), with static positioning - it is very easy to import to visual 
GUI builder ....

so just for the sake of inspiration, to think about - can you imagine 
having screen painter, taking your layout block, and enabling you 
to change the postions/size etc. params for our widgets, without 
actually being dependant upon running the app with live data?

btw - how do we refer to instantiated style - still a 'style? Or 
will we adapt widget name too?

you mean using the layout as kind of a "dead skeleton"?

yes ....

they have e.g.:
{'type':'TextField',
  'name':'Profile',
  'position':'170,110),
  'size':'(307,-1),
  'editable':True,
  'foregroundcolor':(0,0,255),
}

just dunno what they do, if the want some kind of comuted values? 
Maybe they import just what is defined, you change layout, and after 
the widget is drawn, they can adjust, dunno .... just an idea, we 
imo need visual screen editor in future ...

I believe this is how Cocoa works and have seen the technique referrd 
to as "freeze-dried widgets".

widgets and their functionality are defined in .nib files for a cocoa 
program. this is because much of the binding between the widgets 
and the code is created during runtime. this is also why Interface 
Builder is able to create much of the initial functionality for a 
Cocoa GUI, just by defining attributes to widgets and let you test 
the interface to a fairly high level without compiling any code.

BrianH, do you know what structure rebol currently uses for holding 
symbols ? Red/Black trees are complex, so it will take a fair effort 
to implement and debug.

red-black trees are 2-3 trees implemented as binary trees

or they were when I studied them

As far as I can tell, REBOL currently uses a hash table. I am not 
the one to ask though.

As for red-black trees, I'm not sure they had been invented yet the 
last time I was in school for computer science. My studies were more 
focused on programming language design than data structures, so again 
I am not the one to ask.

Well, you could always try seeing how hard it is to implement from 
the available souce snippets. I think by the time you've finished 
doing that you'd be an expert.

The difference between binary search trees and red-black trees is, 
that the latter only have O(h) if the height of the tree is small. 
Red-Black tries are balanced and hence can guarantee O(lg n) times. 
But there exists many other search-tree schemes that hold too.

will R3 use packed BCD?

Ups... just saw: latter=former

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/197938
-- looks like the Ruby approach to Unicode will be to use UTF-8/16 
as the internal string representation and convert from legacy encodings 
on read(/write?).

http://plib.sourceforge.net/

lgpl, uses in flightgear and torcs. Dont know about size, but all 
my  crashes where steering-related :)

I would like to know what status the REBOL v3 is in. When will we 
have the beta version? Thanks.

I'd like to know when the alpha version comes. :-) Thanks.

no release date set yet. just stay tuned... :)

Takiing into account the first made estimate (alpha in April IIRC?) 
and the time lag we now have, I think we won't see R3 final before 
September-2008. Other bets?

Xmas 2006.  Carl usually gives us a Xmas present.

for the first beta

remember also, when it's quiet, Carl's probably working like a madman.

Yes, I know, nevertheless doing it "mostly" alone limits the pace 
we can move... it's still the same problem. Within production optimization 
I would say: We have a capacity, lot size (the different tasks) and 
setup time problem to solve.

being away for more then week, I would expect more than one vague 
blog post?

You would? Really ???

I've given up on expecting anything.

I would not like to, but probably this is the way to ... nothing 
to expect ....

So far, RT is killing REBOL, definitely ...

well, there is a blog entry up now on garbage collection :-)

Now, that sounds fitting :-(

RT is not the only company around that has delays in shipping a product.


One of the reason, why it feels painful, is because of the tight 
community and the up-close-and-personal feeling with Carl.

Well, yes, he takes his ball and goes to france!!

I strongly doubt that RT would be wasting time. It's just that there 
is so much to do and R3 is one component in a large amount of software. 
Had this been some single-purpose program (like LIST-VIEW), we would 
see more rapid fire releases. :-)

it would also help if the community could do a little bit. GUI Design 
for example didn't have to stop, just because Carl goes to France.

or if people help testing Rebol/Services so that a set of ideas could 
be written down for design changes

rebservices needs patches and patches need mre readable source.