World: r3wp

when we generate blocks on the fly, we sometimes need evaluation 
to occur at a later stage.  this allows to save on an uneeded additional 
copy.  (which can be taxing on the GC when blocks are large)

this allows to save on an uneeded additional copy.
 - if you are referring to the

    reduce/into b b


expression, Max, then your assumption is wrong, this cannot save 
an unneeded additonal copy

well IIRC Steeve had done tests and it was much faster... so something 
is being saved.

it was so that new memory didn't need to be allocated in this expression, 
and the old didn't need to be garbage collected:

b: reduce b

About the /into refinement.

I don't bother if internaly, a copy is done or not, while it's faster 
and memory safe (the block must be freed immediatly not by the GC) 

The GC used to have some memory leaks and was reacting too late to 
be useful (especialy in apps with a GUI).
I now it's better now (thanks to recycle/ballast).

* I know

about reduce/into b b

It allows to keep several references of the same block without the 
need to reassign them when the block is reconstructed.

But currently, we can't avoid the block expansion because the data 
are inserted instead of beeing replaced (which would be more useful 
to my mind).

Then, if internaly it's faster to do a copy, I don't care while it's 
not recycled by the GC (for the reasons I mentioned previously).

Sounds interesting. I know that CHANGE/part is the real fundamental 
operation, but that needs an additional parameter and would require 
renaming the option - /into isn't an appropriate name for that operation. 
But I don't think it would have been implemented in that case, and 
having it be a direct CHANGE would definitely not have been accepted 
because /into is mostly used to replace chained INSERT and APPEND 
operations.

The downside of the /into option is that you have to be careful when 
using it or your code won't be task-safe. Your multiple references 
to a block that can change scenario is an example that can quite 
easily lead to task-unsafe code, for instance. But /into is great 
for micro-optimization and local code simplification, as long as 
you are careful to not modify shared structures without coordinating 
tasks.

yeah indeed

Of course task-safety isn't a problem for most R2 code, but then 
neither does R2 have natives with /into. Some of the new mezzanines 
though.

for the record (for the other people reading, which might not be 
as fluent in the more low level aspects of the core)..


I just want to note that your comment about thread safety doesn't 
only apply specifically to the /into... 


It applies to *all* series usage in REBOL 3 since they are mutable 
and MANY functions modifiy series "in-place".


Other languages always copy on assign so its not as big an issue 
as in REBOL.

Agreed. Though not many other languages always copy on assign - that's 
a relatively new habit.

Or copy on any change, rather than on assign, as Java does with String

Does anyone have a well-tested mezz version of CASE handy for use 
with older REBOL cores?

Ladislav's PIF is my first stop.

how old is old?

1.2.47

I don't know where this came from:

	case: func [
		[throw catch]
		args [block!] /local res
	] [
		either unset? first res: do/next args [
			if not empty? args [
				; invalid guard
				throw make error! [script no-arg case condition]
			]
		] [
			either first res [
				either block? first res: do/next second res [
					do first res
				] [
					; not a block
					throw make error! [
						script expect-arg case block [block!]
					]
				]
			] [
				case second do/next second res
			]
		]
	]

Thanks Graham!

looks like PIF!

That's Ladislav's PIF, just renamed.

:-)

Yep ... !

All roads lead to Ladislav.

Does anyone else experience the inability to read the clipboard ?

I can paste from the browser to notepad, and other apps, and it's 
just text, but .... the clipboard shows empty.  The problem will 
go away if I reboot though.

If I write to clipboard://, nothing is there either ...

REBOL sometimes seems to get confused if there is data on the clipboard, 
possibly related to the format of the clipboard data. Writing can 
fail at times too IME. Clearing the clipboard before writing usually 
solves the problem for me.

I think this is also what messes up AltMe's clipboard behavior at 
times.

Correction, I can write to the clipboard:// and paste into other 
apps, but Rebol is seeing nonthing there.

I can paste this: test
from Rebol, but can not paste into a new instance of View

Do you have any kind of clipboard monitoring software installed?

No, I don't

What program are you writing data to the clipboard with?

if the clipboard were screwed .... then Altme wouldn't see it either??

I was just copying from Chrome's address bar .. and also writing 
to the clipboard using core.

AltMe is built against an older core.

ok, let me raise up an old core

What OS and what REBOL version?

Ahh...... !!

fails on 
>> rebol/version
== 2.7.7.3.1

works on 
>> rebol/version
== 2.7.6.3.1

Windows 7 prof

Interesting, and very good to know.

I wonder what happened to the clipboard handling...

Only RT can say, unless a changelog is posted somewhere.

Could be as simple as a change that tried to handle errors better 
and now fails for some reason.

started up view 2.7.6, pasted to clipboard and can't read in 2.7.7 
again.

I'd better log this to rambo