World: r3wp

no, i have just added brian's info to the ticket. Debian has a command 
(a bash script I assume) that will launch the user defined browser.

yeah tried on Mandriva using the Debian tricks and no luck

eh?
>> replace "aa-aa" "aa" "P"
== "P-aa"

what's the problem?

replace/all ???

ahaa.. :) thanks Graham.

>> mold/all/flat []
Bus error

Core 2.6.2.2.4 on MacOSX

works fine in WinXP

>> mold []
== "[]"
>> mold/all []
== "[]"
>> mold/flat []
== "[]"
>> mold/all/flat []
Bus error

same happens under Linux

also exists under Core 2.7.5.2.4 for MacOSX

RAMBO'ed

Re: 4268 - Gregg, do you think it really should return %/a/ %/c/ 
etc?

when you do a read %dir/   and you get %subdir/   as a result, you 
know that the path to subdir is %dir/subdir/  so it seems consistent 
to me that a read %/ gives %a/ and the path is %/a/ .

eg if i make a function like:  func [dir /local block] [block: read 
dir forall block [block/1: join dir block/1] block]

i expect it to work with any input, %/ included. but it would break 
if read %/ returned %/a/ .

I've considered it a long-standing bug, because it didn't do that 
before, and I think Carl acknowledged it as a bug at one point. There 
are two ways to look at it, but the consistent-path model may be 
best in REBOL, meaning it's not a bug. Under Windows, where there 
is no concept of a root above the drive letters, it's more comfortable 
to think in terms of the drive spec being a top level entity. Not 
sure what's best for UNC usage.

i'll leave it in as a bug, but i personally prefer it to be consistent 
with other operating systems.

I think I'm OK either way, as long as it's doc'd, though consistency 
is probably better.

Gregg, I seem to remember arguing *for* the change, in order to achieve 
consistency, so I'm with Gabriele, here.

Serialised function! not loadable 

in Rebol/View 2.7.5.3.1 on WinXP

>> load {#[function! [][]]}
** Syntax Error: Invalid construct -- #[
** Near: (line 1) #[function! [][]]

>> load/all {#[function! [][]]}
** Syntax Error: Invalid construct -- #[
** Near: (line 1) #[function! [][]]

The above are loadable on View 1.3.2

Anyone reported something like this ?

Reproduced here.

oh.. that is a mean bug!
crashes in 2.7.2 also.

Thankyou.

known and on the list for next release.

Ok, very good.

Strange new-line bug/issue:

foreach [style obj] svv/vid-styles [print mold to-lit-path reduce 
[style in obj 'color]]

solution/workaround:

foreach [style obj] svv/vid-styles [print mold to-lit-path new-line/all 
reduce [style in obj 'color] off]

(The first one produces lit-paths starting with a newline - looks 
weird.)

foreach [style obj] new-line/all svv/vid-styles off [print mold to-lit-path 
reduce [style in obj 'color]]

and why you use [style in obj 'color]?  this will works as well: 
foreach [style obj] svv/vid-styles [print mold to-lit-path reduce 
[style 'color]]

foreach [style obj] svv/vid-styles [print mold to-lit-path reduce 
[style get in obj 'color]]

You are right.

This is the reduction:
>> to-lit-path first new-line/all [word] on
== '
word

I think it is an error, since I am molding a lit-path which can't 
be loaded back, because of the newline between the ' and the first 
word.

I agree Anton. I imagine it's because paths are a block type. So 
we want to make sure it doesn't mess up other block types when fixed.

I think it's amazing that FIRST returns the word with its hidden 
new-line attached. Very confusing trying to reproduce it again today. 
:)

Makes me wonder how new-lines are implemented.

I thought it was an attribute of a block, but maybe it's an attribute 
of a word ?

It looks like it is. I was wondering where those new-lines were kept 
! :)

TO-PATH is affected the same way.

TO-SET-PATH is also affected.

Submitted the above bug to RAMBO.

Interesting. I assumed new-line markers were liike pseudo-values 
in blocks. 

Thanks for doing the research Anton.

AFAICT line-markers are attributes of the "space in between" the 
content.  using new-line we have complete, per-space control.

new-lines are attributes of value slots. values do not exist without 
value slots. rebol is always copyiing the 16 bytes of a rebol slot 
around... so it copies the new-line marker too

Excellent -- attributes of a value slot; that's clear.