World: r3wp

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.

:-) I don't know. I kept notes in a file, but don't feel it's developed 
enough to publish. I have a vague desire for a new function which 
handles this case (as well as other, more general, set operations).

I'm hitting something that causes "invalid datatype during recycle" 
sometimes. I don't know yet what it is, but I thought the recycle 
bug was gone?

this is on View 1.3.2

Not gone entirely, but happens far less frequenty.

Which makes it hard to debug. Very deeply nested blocks with many 
inserts and removes can trigger it.

I see. Unfortunately it seems I hit it close to every time I do a 
specific operation, but I have no time to debug it...

It's annoying!

Sometimes just moving code around can fix it. Try making some local 
words global, for example.

it's actually a showstopper for me and exactly this code needs to 
be working in front of a customer in about 5 hours....

I think it would be good to have an example with this bug for sending 
it to Carl

the thing is that its db synchronization code (I'll think out loud 
here) and it's used in 5-6 different places. only in one place does 
it crash.

it seems to be accumulative, since it does not happen in exactly 
the same spot every tine and is possibly related to Rugby's do-every 
function, because it seems to happen whenever the do-every is executed.

To tell the truth, I don't know what I did with previous versions 
that actually worked. But doing *something* that affected garbage 
colection seemd to move the bug around. eg
-- global words not local words
-- xx: make block! 1000 not  xx: copy []

http://rebol.hmkdesign.dk/db-sync.r<-- the db sync code is here.

sunanda, repeated clears of a block perhaps?

I had adopted the techinque of clearing a block before reusage instead 
of using a new make block! [] Maybe that's a bad idea.

Clear -- It's probably a good idea for this reason: the block will 
grow to its maximum size after repeated uses, and so saves time in 
memory allocation / block extension.
May be a bad idea if that max size is causing problems :-)

allocated 100000 to the first block in the code and it's still running...

Let's hope that gets you through the demo....Good luck!

it crashed again :-(

I think I'll panic and allocate 100000 elements to every single block 
in the database

i had such a problem with massive gui and async. Workarounded the 
following way: recycle is off permanently. there is a thread (do-every 
or such) which checks how much memory was allocated and when it is 
to much it recycled. crashing stopped.

you may try  recycle/off   and do it yourself

:)