AltME groups: search

$123.45678mg .... That is a drawback, Peter. Will format help?
And it may still be negotiable in R3:
http://www.rebol.net/r3blogs/0092.html

With 64-bit decimals, you have 15 digits precision, and it's faster. 
You can specify up to a million ton, and still have milligrams. Is 
that enough for your task?

Example: 123'456'789.123'465 is a valid decimal! with full precision.

The precision for 64-bit IEEE decimals is 15.95 decimal digits. You 
can have results up to 17 digits (it's a parameter to be able to 
change). It's default set to 15 to always give correct result. In 
5% of the cases, the 16th digit will be wrong. See e.g.: http://babbage.cs.qc.edu/courses/cs341/IEEE-754references.html

Work is done to get around problems like:
>> (0.2 - 0.1) = 0.1
== true
>> (1.2 - 1.1) = 0.1
== false
(This is also a the results in R2.)

Write that down somewhere (other than only here). When the DocBase 
go public, there could be a place there for new ideas and suggestions.

maybe, we can do 123#kg but i don't see a big improvement here.

or we just could state, that $ is simply a unit char. And rename 
datatype from money! to unit! :-)

syntax error means that we have a free spot in the parser there :-)

kg123 is a word for example.

yes, as i said, i think only # $ and % are "special" for the parser, 
so that you have to pick there. carl picked # for a lot of things 
because $ and % carry meaning.

#123 is an issue so kg#123 would mean that you always have to specify 
a unit... and a space by mistake becomes a subtle bug.

Petr; I use money! all the time with the contruction accounting scripts. 
 Bosses love it, until I have to pummel them for using commas in 
big money! and with construction projects it doesn't take long to 
get to a monkey.

Gabriele: Why not leave money! just as it is for compatibility for 
the people who want to use it and introduce a Fixed! type. (I didn't 
call it BCD because apparently it isn't). The following behaviour 
(modelled on IBM 360) would be ideal:

>>fixed-dec: 1.98F2
== 1.98
>>type? fixed-dec
== fixed!
>>print fixed-dec
== 1.98
>> probe fixed-dec
== 1.98F2
>>2F2 / 3F2
== 0.66
>>2F2 / 3F2 + 0.005F3
== 0.67

Could be a cat in the bag...

petr: because this the current money! format is faster and takes 
less space (you can't pack 26 bcd digits in a rebol value otherwise)

I read every VID related doc more than 5 times, and I am only slowly 
starting to get the idea behind it :-) So I wonder - is new VID conceptually 
so complicated, or there is still not enough docs to get the idea? 
:-) There are already things I like a lot, but there are also some 
worries, although those migh show as minor. Maybe some better explanation 
(more docs) will help the situation ...

So far the most precise docs in View area are Cyphre's draw docs. 
Well, those are mostly a reference. I also like make-gobs doc.

From my pov, I can already see some things, which are a bit disappointing. 
I represent userbase as any other potential user. And I can already 
imagine typical answer - "you can create your own GUI after all" 
:-)

having used VID3 for a bit now, I can tell you, it's SO EASY. it's 
amazingly simple, compared to the R2 VID. it's possible to do things 
in 10 lines of code that would require 500 lines of R2 VID code.

but it's not done yet, so we'll wait a bit longer with the comments

well, I expected that first comes some "basic" architecture design, 
then comes styles. Of course, when we think more complex styles, 
we just may find out, that we need to change a design, that is ok 
....

Currently reading docs (and I know they are supposed to change) is 
like reading a facts ... there is function xy, which does that. But 
the question of novice is - but why?

we are already internally talking about the shape of the documentation. 
right now, the important thing is that WE HAVE DOCS. that is opposed 
to some R2 docs that are NON-EXISTANT. fixing the flow to make it 
nicely readable comes later. this is just not a priority.

E.g. - let's look into some VID reference Introduction. Some may 
find it vague, and saying nothing:


By their nature, graphical user interfaces (GUI) are more descriptive 
than they are functional. In REBOL, the Visual Interface Dialect 
(VID) provides an efficient method of describing GUIs. VID is implemented 
as a layer that rides on top of the REBOL/View graphical compositing 
system. VID provides shortcut expressions that are automatically 
translated into View objects and functions. You can seamlessly combine 
VID and View code and data for great power and flexibility.


Whereas for me, it s real jewel, as it introduces me into concept 
of relation of View and VID.

I think the whole situation is cause by you commenting on things 
that are not done. Perhaps it's a good idea to close the docs even 
further down now, so you can't see them anymore, so we'll at least 
have the piece and quiet required to finish them.

Pekr, just calm down, how can someone write full docs, when VID3 
is not yet finished? Can't you wait a bit more? Where's the problem? 
Don't base your assumptions on some unfinished docs, I know you're 
eager to get R3, but, please, wait until it's done.

amacleod - there aparently is more things that are complete - you 
saw the mention docs are some 30% behind? And have you ever been 
in process of writing docs? I mean - in the team? Do you think that 
ppl only wait for the work to be 100% finished? Some concepts HAVE 
to be already in place. I prefer to rewrite/restylize docs instead 
of writing them in a hurry ...

yes, please do. there will be a requirement for much more help, once 
R3 goes beta.

indeed it kicks ass. a very small example:

view [progress slider attach]


slider is attached to progress and will adjust it's length automatically.

ok, let's fight a bit :-)

I am a new programmer - how it connects? I want to have some imagination 
about it. btw - that was the most difficult part of VID vs View. 
At least when I taught Bobik VID. Once you needed to go deeper, non 
skilled View guru would get lost ...

there's a lot more interconnection between words in VID now.

you see, i don't think anyone has problems with you getting r3, we 
only have problems with you complaining too much about it - considering 
how much you do by just having looked a bit at the docs ;)

been working on the vid docs for a few days already.

that's why i'm sure they'll improve a lot.

but i'm also sure he will need a lot of help.

Petr;  One word of caution.  In a support role; getting invited to 
the REBOL 3 kitchen, efforts have to be made to not bother the cooks. 
 It's hard, (really hard) but trust the chefs.  :)

Brian - I exactly understand what you mean. The bad thing is, that 
when you feel you have something to say to the design itself, you 
can't, or you don't want to, to not spoil the chefs. But - I will 
write docs only to desing I have 100% trust into. So far I have some 
worries. Those are more philosophical ones. E.g. worst part I read 
so far was 'tight command, which imo has bad influence on how VID 
code "feels". So - at first run, I will try to read most past discussions 
and try to understand new design philosophy. There surely are differences 
to VID2, mostly that styles seem to be organised in groups (columns). 
I can't e.g. see VID2 keywords like 'at, 'across, 'below, 'return, 
etc. - so, how I said - I first need to study the design. Then I 
will have some questions. 


I will ask those questions to Gabriele privately, to not flood the 
group, and because he is master designer. I think that guys managed 
to create strange atmosphere here. Since when is the design a closed 
effort to those who are interested in the design process? I don't 
remember it happening even with View 1.0 - ally mailing list. Everybody 
interested could reply at least on mailing list - no wait and see 
mode. That is exactly why I asked for the design docs first, althought 
I understand Gabriele's point of rather coding first. But the aproach 
of "watch, but don't spoil" excludes others from the design.


So once again - if I find new design unpleasant to use, difficult 
to use and explain in the docs, I may also departure from the effort.

Let's say I am very average rebol coder, and that I also had one 
person, which I taught REBOL, VID specifically. I saw various VID 
code in the past, some was pretty and self explanatory, some was 
more messy. I e.g. liked simplicity in most of IOS reblets. The ugliest 
design in VID2 is a list for me. Thru all those years, I catched 
several ppl, to not really get it. It is kind of "usage pattern", 
and if it repeats, then we should think, if the aproach is best for 
the user. E.g. list style assumed cnt word in its block, and it was 
really confusing.

When teaching VID, my basic understanding was, that Bobik generally 
liked it very much, unless he had to touch its internals. The last 
escape was 'with. Creating new style was mostly a show stopper. What 
I and even him really liked, were facets. It is like the last easy 
chance of how to move upon the surface (VID), without the need to 
go under (View).

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

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.

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?

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

it might take a while for r3 to be stable

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

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

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.

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.

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

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

Personally I feel that adding extra testers at this stage would probably 
be a mistake. This feeling is not based just on my own experience 
or the observation that those currently in the team keep asking for 
the space they need to get things done. It is also the advice on 
the seminal work on managing software product development - Fred 
Brooks's The Mythical Man-Month.

Saying that I share everybodies frustration .....but as the saying 
goes "patience is a virtue".

I am curious if they fixed a bug that exposes source code that I 
never put in RAMBO because of the sensitivity of it.

Graham, it needs a little context. The set-word in the word block 
points to the current position in the series. The behaviour has also 
been introduced with FOREACH. Before, there was no other way to grab 
the series itself (only its values) at it's current index inside 
the loop block.

Hi Pekr, I'd love to get my hands on an R3 alpha ... and I maybe 
would even have the time to play with it, but at the moment I don't 
feel like I'd have the resources to do some serieous testing. 

So, on the plus side, you don't have to expect a flood of error reports 
from my part ;-)

sorry I forgot to put an "a" into serieous ;-)

maybe time for a status update on Carl blog? 8-)

Today Carl stated that we are probably close to public beta release. 
What "close" does mean, noone but Carl knows, though :-) But please, 
expect, well, a beta version, hmm, maybe even alpha :-)

Pekr.. I hope its a public Beta..but i do think is an improved closed 
alpha release...

Seems a simple requirement .. needed for localisation etc

shouldn't be a problem

gabriele has a localization system that we might use

yes, multiple buttons in a panel e.g. - you want the probably of 
the same size, aligned, to look nice ...

view [btn "Button with a very long text"] works perfectly here. also 
notice that if you set-face the button with another text, the size 
is adjusted in real time.

I was expecting a fully functioning C3PO by now.

Just a note for those who might be curious. From Carl today:

Just a note of interest...
I've built the first version of R3 for Linux and OSX.
Console only, with file and dir I/O.
They pass most of the non-graphics tests.

John (Geomol) will be working on the OSX features in the days ahead.


.... just to let you know, that other platforms are not forgotten 
....

Back in the day, a key feature of R was it running on 40+ OS... 
Seems these days, that's down to 3.  

Hooray.

good times ahead, guys: "Carl: Now, I think we are at a stage when 
it would be a good idea to get more people involved." :-)

Great news! please send me a copy of R3 on osx!

Please send me a C3PO running on Linux

Ill drop Gabriele a note..

Q: are there any functional changes to the parse-dialect in R3 or 
is it purely the speed optimization that gets a thoroughly restructuring?

There is a new algorithm for empty parse to avoid the some end infinite 
loop...afaik, and I know little. :)

But what Im actualy missing in the global Blogs on R3 is a statement 
on the functional behaviors on R3 function? I assume they globaly 
stay the same and no big impact is to be expected, besides new functions...

If I misunderstood you and you were asking about the behavior of 
particular functions, you'll have to ask about them individually. 
Many are changing from mezzanine to native, others are changing from 
native to mezzanine or a hybrid of the two. Many are going to be 
able to do more.

Small R3 update:


We can do modal popup windows now and fully borderless windows. This 
should help in building a real popup menu that isn't limited to the 
size of the main window, like in R2.

I'm building VID3 tests so we can find bugs in the layout engine.

Alpha 81 was released yesterday.

332 bug reports in the tracker.

Soft font shadows are cool. :-)

Just curious if anyone has any info on tables in vid3. They were 
pretty poor in R2 but I think they are a key element for many apps. 
I took a quick look at "turbogrid" mentioned in the Tech News forum 
and its crap. it's Ajax based.  A list-view based app in a plug in 
would blow it away.

there is a simple text list for emergency testing right now, but 
a new one will be written. I hope it will feature many of the features 
from LIST-VIEW, without taking up too much code. LIST-VIEW for R2 
is almost as big as the entire of VID3.

About plug-in...I need to change my mindset about it. I always avoided 
thinking: "Nobody wants t have to download a plug in o use your site. 
But I find myself needing to do it all the time and some of these 
new technologies like silverlight, require a download of some sort. 
 Rebol plugin downloads so fast it really is a minor annoyance. WE 
just need it on more platforms and browsers.

My take on graphical tables;  R2 had a beautiful base for this with 
list and supply.  Downside was that the documentation was so limited 
and late comming that no one could comes to grips and we all mostly 
ignored it.  We lost out on the ability to build on the shoulders 
of giants as using list and supply pretty much meant learning by 
expermentation, coding from first principles and not from tool kits 
and cookbooks.  Hopefully the power gems of R3 and VID3 will not 
suffer the same fate.

btiffin, I agree. Clear and complete documentation is essential. 
Few people will take the time to study source code. No matter how 
great a language is, it is useless unless people can easily use it 
to do what they need to do.  An inferior language that is documented 
well is very likely going to attract more users than a great language 
that no one can figure out how to use.  Core is fairly well documented 
I think, but I have never been able to get past problems in View. 
 I'm really hoping that the docs for REBOL3 will fully explain View 
and give lots of examples, especially showing how to interface view 
with databases, etc.  But writing good docs is very difficult, because 
the creators of the language know it so well that it is difficult 
for them to put themselves into a beginners shoes.  It is easy for 
them to assume that the beginner already understands things that 
, in fact, he doesn't understand at all. Anyway, I have high hopes 
for R3.  And I can do more with R2 than I ever dreamed possible, 
so I really can't complain at all.  That doesn't lower my hopes for 
better view docs though. That is the way we humans are: the more 
we get the more we want.  :>)  They call that being spoiled.

Gabrielle, I beg you if you solve the problem of 307 redirection 
wtih R3. Can you send me a link to download it ? thanks.

do you have a little idea when we can download a version of R3bol 
?

Wasn't there some talk that r3 will have a new filesystem? Is this 
still going to happen?