World: r3wp

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.

So there must be at least one bit devoted to a new-line marker.

I tested by extracting a word, then inserting into another block.

>> word: first new-line/all reduce ['word] on
== word
>> head insert [] word
== [
    word
]

and you can move the word into other series datatypes like path, 
then back to a block and see the new-line has followed it.

As Gabriele said, it's not just words, it's any value, because it's 
part of the value slot.

>> val: first new-line/all [1 2 3] on
== 1
>> head insert [] val
== [
    1
]

Yes, that makes the most sense.

Interesting problem: Why do I need BIND/COPY ?


The aim is to copy the values of the facets in face F2 to face F1.

f1: make face []
f2: make face [text: "hello"]

facets: [text]

set bind      facets f1 reduce bind      facets f2
f1/text ;== none   ; <-- why ???

f1/text: none
set bind/copy facets f1 reduce bind      facets f2
f1/text ;== "hello"

f1/text: none
set bind      facets f1 reduce bind/copy facets f2
f1/text ;== "hello"

f1/text: none
set bind/copy facets f1 reduce bind/copy facets f2
f1/text ;== "hello"

Aha! I know why. I seem to remember doing this once before. :)

The SET gets its two arguments first, which binds the block twice, 
leaving the block bound to f2 before the setting takes place.

That was my first thought.

It's interesting I stumbled the same way twice. Will I do it again 
in a year or so ?

It would be a good guru tech-note to post somewhere, The Singularity 
of Bindings.