World: r3wp

We considered making the change, but unfortunately, the report came 
too late.

Installation code (and especially the self-installing kind like in 
REBOL) require a lot of testing -- not only by us in the dev team, 
but by all the beta users.

So, that does not allow us to make last minute changes, unless we 
really understand the solution and what impact it will have on everyone.

w

We know this is an important issue -- we want REBOL to be as easy 
to install as possible -- so we will look at it again soon.  If you 
have detailed know-how in this area, we should talk more about it. 
 Thanks.

I've written installers before, and you have my email address, so 
feel free. As it is, the new sandbox directory would make it relatively 
easy to make an external multiuser installer that would fake the 
current behavior well enough to fool View. I'll test the View no-install 
behavior to see if it works well enough to prevent View from undoing 
the work of an external installer.

The current installer works well enough for single-user situations.

bug or not : when image! was removed from any-string! (1.2.111) , 
"to-binary an-image" behaviour changed .
Instead of returning BGRA binary data 
(as stated in http://www.rebol.com/docs/image.html)
it returns the same that  "to-binary mold an-image"

sounds like a bug to me.

ok, I'm writing a report.

regarding #3808

it's just the common double slash, that Rebol does not like.
>> list-dir %//remotemachine/remoteshare   
should be written as
>> list-dir %/remotemachine/remoteshare

maybe that double-slash should be allowed then? would ibreak something, 
like splitting a path?

>> clean-path %//
== %/C/
>> clean-path %///
== %/C/REBOL/
>> clean-path %////
== %/C/REBOL/View/

so,

>> clean-path %//something
== %/C/something

i guess it's intended. not sure if anyone's ever used that.

I've used it, especially for shared scripts where I want to be able 
to move them to other drives and not break.

I just tested some scripts with rebcmd2512531.exe. 

Now they use the machine upto 100% and the machine reacts very  sluggish 
to user input, where before it was still usable..

Can you provide any details about what they do, or how they work?

They work in pairs.

One reads data from files, does some parsing, does some odbc and 
sends data via tcp.

the other reads data from tcp, writes some files and sends back an 
acknowledgement. 


one reads data from files, does some parsing and sends data via tcp.

The other reads data from tcp, does some parsing, does more odbc 
and sends the more data back as a reply.

In 1.3, 'forall does not react to 'return like in old version : just 
break the loop!

Try this in 1.3 and 1.2 or beta:

f: does [
	b: [1 2 3] 
	forall b [probe first b return] 
	print "après"
]

f

Due to change in 'forall, yes, but some people (on French forum) 
are in trouble with that.
Does it worth a RAMBO ticket ???

You are right.

I think yes.

Ok, go for it...

Hi Dide, you revealed two bugs at once, I think, that the Throw-on-error 
improvement is in Rambo already

I think the new SPLIT-PATH was done by Romano ?  I found this:

file: %/volume/directory/file.r
path: find/match file %/volume/  ;== %directory/file.r
split-path path  ;== [%directory/file.r %file.r]  ; <--- wrong !!
split-path copy path  ;== [%directory/ %file.r]

(split-path mucks up when its target argument is at a series offset.)

Anton: please sumbit it to rambo.

Ok.

Submitted.

Did Dide submit his bug above ? It sounded like he wanted me to do 
it. :)

he did.

It looks like split-path was done by Romano. Maybe we should alert 
him.

ok good.

yes, i'll tell him.

thanks

my secure query looks as follows: [net allow library ask shell ask 
file ask %/c/program files/rebol/view [allow read ask write

 ask execute] %/c/documents and settings/ladislav/data aplikací/rebol 
 allow %/c/program%
20files/rebol/view allow]

Is that intended?

What do you mean ? No final slash on those paths ? Or the what's 
allowed ?

Oh yes, I see, view-root is set to ALLOW (the last path) for me too.

actually I see two sandboxes there and I don't think it is in agreement 
with what Gabriele said

About the ticket for 'forall. Cocinelle said it's just a missing 
[catch throw] args to the 'forall function!

Gabriele: I let you check that as I'm not "confortable" with this 
sort of things and maybe add the proposal  correction code to the 
ticket.

yes, it's a missing [throw] both in forall and in throw-on-error

lad: is that from the console? try secure quero from a launcyhed 
script (i.e. a script launched by the desktop)

*query

*launched

yes, it is from console, but is that intended?