World: r3wp

interesting method

That's what 'lookup is used for is it not?

yep

R3 request: Please, please, please... .add a good paranthese balance 
problem report. I don't know how often I have searched for a missing 
[ or ] in either source-code or large data-files. Rebol doesn't give 
a good hint where the problem is.

Editors choke on this as well because these are to stupid to skip 
braces in strings. So the balance function is mostly not correctly 
working.

Robert I have this issue all the time ...

The easiest way for me to fix it is to use a pretty code tool to 
indent until I see where I'm no longer balanced

Well, but I really don't want to scroll through a 1MB data file getting 
pretty printed... this will be thousands of line long.

hehe ...

ftp://ftp.compkarori.com/pub/clean.exe

I just paste functions into the text area and run clean script on 
it ...

because I generally know which function I've been working on ...

Same question as I asked in the Core group. It would be nicer with 
a REBOL function, so we could build a REBOL based diagnostic tool 
around it. Very handy to build into programs, so they can examine 
damaged datafiles themselves.

If you've got a 1mb function .. you're in bigger trouble that this 
tool can help you with ....

clean.exe is just a text area that has clean-script running on  a 
button.

Usually this is not functions, but data files. Yesterday, we encountered 
a datafile with an illegal char in it. Took an hour to find the problem.

and it was a data file that had been MOLD/ALL/FLAT from REBOL and 
then attempted to LOAD/ALL again, which failed.

Be sure to report the problem, and which char in which type caused 
the problem. In theory, MOLD/all generating an illegal char or non-loadable 
syntax at any point is a bug, and should be reported.

Robert & Graham: JEdit does a good job of matching [, { & ( and even 
auotmatically indents and de-indents them for you.

I have found out that JEditX (a cocoa editor not related to Jedit) 
has a very good brace matcher as well. But anyway, an in build one 
would be nice.

The _Official Guide_ (huge paperback) had a bracket checker as a 
worked example of using REBOL  code as data.

If anyone has easy access to a copy, perhaps they could dig it out.

I have Rebol 1.0 manual. Do you mean this?

No, the official guide as listed on this page (the link by the book 
itself no loner works):
   http://www.rebol.com/books.htmlhttp://www.rebol.com/books.html

I have it here, and found what I think Sunanda is referring to. If 
someone is really interested I'll post it.

uedit has no brace matching issues.  it works very well with REBOL 
and its fast enough to match braces  on very large parts of code 
in real time.

notepad++ does bracket matching ...

So Carl, have you come back with some proposals on the network base 
context ?

Sunanda: with the new site, please tell us what to add.  We are very 
interested, and it is easy now, to keep things updated.

Graham: make it a module.

Carl, have you seen these new plug computers?  Running Marvel ARM 
processors ...

They're going to make great REBOL appliances !

Robert mentioned it.  Let's do it!

So, R2 first ... 2.7.7 to ARM, and then R3

Probably not.  R3 first... and if that works, then R2.  R3 is built 
for portability.  R2 can be problematic.

whatever works ..

though I do want to run Cheyenne on them !

Another entry for rebolweek ... RT is porting R3 to ARM

I have one R3 question...is this bug or was it changed intentionaly 
in R3 (don't remember right now):

>> a: [[1 + 2]]
== [[1 + 2]]

this is OK:
>> do a/1
== 3

but this doesn't evaluate in R3:
>> do to-path [a 1]
== a/1

>>

I would say: intentionaly
>> do get to-path [a 1]

to-path return a quoted path

seems...

that is possible...I'd like to know the reason why it was changed 
as it is not symetric word! now...

in R2:
>> a: [[1 + 2]]
== [[1 + 2]]
>> b: [a a/1]
== [a a/1]
>> do first b
== [1 + 2]
>> do second b
== [1 + 2]
>> b: ['a 'a/1]
== ['a 'a/1]
>> do first b
== 'a
>> do second b
== 'a/1
>>


but in R3:

>> a: [[1 + 2]]
== [[1 + 2]]
>> b: [a a/1]
== [a a/1]
>> do first b
== [[1 + 2]]
>> do second b
== a/1
>> b: ['a 'a/1]
== ['a 'a/1]
>> do first b
== a
>> do second b
== 'a/1
>>


I think the R2 behaviour is more cleaner but maybe I'm missing something?

Agree now, disturbing disturbing...

a: [[1 + 2]
b: [a/1]
>> do do do do do do b/1
== a/1

really disturbing...

Can't figure if it's good or bad.

i pass...

I think it's bad.

But i'm afraid there are some drawbacks to reverse it to the R2 behavior.

Notice there is bug involved:

>> do ['a]
== a

>> do do ['a]
>> a
** Script error: a has no value

One bug is, that
do do ['a]
doesn't raise an error, when a has no value.

Yes, there is definitely something wrong in this area with R3...so 
now it doesn't look like a intentional change.