World: r3wp

I think it was only with the View altme server

1.2.119 (on Win2k) still always connects and starts desktop - settings 
done in desktop/user aren't saved. And the option to don't install 
and start rebol still yields an "please reinstall" message.

Vincent's description same for me on XP - I'll add that I get a "Problem 
uninstalling..." message when I try to uninstall. The rebol directory 
in docs and settings gets deleted but the registry key remains.

there are wrong links in this document: http://www.rebol.net/notes/rv13-changes.html
(Core 1.2.118 -- 4-June-2005)

Will 'create-link be included in final 1.3? If yes, there's a number 
of issues:

- create-link %/c/foo.txt "d:\bar.lnk" will create a link to "current-path\c\foo.txt"
- create-link %/c/foo.txt %/d/bar.lnk don't work
and the big security hole:
    secure [file ask]

    create-link %anything.dat "c:\my-file-to-overwrite.exe" ; bypass 
    sandbox
RAMBO?

#3757 fixed in 1.2.122 but only first part, not the second one - 
"There's one more problem - after changing name in user preferences, 
it's not changed in main desktop window - it still shows old one."

#3768 - finally I've worked out how to uninstall and repeat the problem

Install but do not select .r association option, then uninstall - 
problems.

To fix this situation, rename currentuser/software/rebol/view key 
to viewold - this allows reinstall which you should do this time 
with .r association then uninstal works ok.

To whom it may concern, on ticket -304 (currently) I misunderstood 
the purpose of the Fix field and filled it with prose with no line 
breaks. Could somebody fix this, perhaps by moving the prose to the 
Description section? The Fix section doesn't wordwrap, my entry messes 
up the layout of the Rambo web site.

done (will need approval)

Thanks!

Hey Gabriele, the install bug I mentioned (now 3775) is one that 
I would consider major enough to need fixing before the final 1.3, 
seeing as it would affect production installations.

I mention this because I just noticed that 1.2.125 is considered 
a final beta, short of major bugs. This is one of those.

As the file handling has been fixed, someone can write an external 
installer that can do the trick if necessary, but at least moving 
the appropriate registry key would help a great deal.

Hi Brian, I saw your posting.

This is a complex request - because all earlier versions of REBOL 
were installed the same way, as well as many other apps.

If you use Core or Link, you will find entries in the same location 
in the registry.

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.