World: r3wp

But OSes often signal the program of such an error after they detect 
it. Do the REBOL internals react to such a signal?

IOS messenger used to happily write 0 byte length messages when it 
ran out of disk space, which crashed messenger when it tried to read 
them.

BrianH: Yes, I do not expect write to check for available disk space. 
But I expect an error, if an action is not successful. And this I 
do check and react according to the outcome.

Graham: That's similar to what happend to me.

The receiving process did not write data anymore, but informed some 
consecutive processes, that new data had arrived. And as he did not 
notice about the failures, he went on signalling, that he will accept 
new data.
These data were lost.(

For rambo viewing I have one killer model ;) named Flyspray it's 
the best visual I ever see :) It could be fun to adapt Rambo to clone 
this visual ;)

http://bugs.splitbrain.org/index.php?project=1

shadwolf. The bug tracker / "shared development tracker" plugin for 
Altme is pretty good.

Assuming you remember it from ealier betas, or have access to worlds 
where it is used.

I liked that bug tracker, why was it removed?

From what I can determine the bug where select/skip on a string locks 
up the interpreter is related to bug #3327  My guess is that because 
/skip isn't skipping properly then it sometimes finds itself in a 
forever loop trying skip at the same point repeatedly.  Shall I submit 
this as a new bug references the expected relationship between these 
two or do we want to extend the description of #3327 to include this 
information as well?

#3755 : not a bug - it's just a syntax problem: "file: read %//server/share/file" 
doesn't work but "file: read %/server/share/file" does. {to-local-file 
%/server/share} and {to-rebol-file "\\server\share"} gives the expected 
results.

Ammon: i'd say submit a new one, and write that it may be related 
to 3327.

Kewl, will do.

Allen no I don't see any thing like that in ALTME ..

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?