World: r4wp

Sorry, it's probably missing from my build recipe

Has anyone tried APPEND/DUP?

red>> s: copy ""
== ""
red>>
red>> append/dup s #" " 10
== 10
red>> s
== " "
red>> head s
== " "

red>> s: copy ""
== ""
red>> append/dup s #"1" 10
== "1111111111"
red>> length? s 
== 10
red>> s
== "1111111111"

There aren't any tests of refinements to append yet. I'll start an 
append-tests.red file for them inlcuding your 10 spaces test Gregg.

It appears that the problem is only appending spaces to a null string. 
it seems okay appending 10 spaces to a space.

red>> length? append/dup " " #" " 10
== 11

The issue seems to be with the console as the tests work in both 
the compiler and the interpreter.

The issue seems to be with the console as the tests work in both 
the compiler and the interpreter.

Sorry for the double posting.

Actually, Gregg's test works under OS X:

Schulz:Red peter$ ./console

-=== Red Console alpha version ===-
(only Latin-1 input supported)

red>> s: copy ""
== ""
red>> append/dup s #" " 10
== "          "
red>> length? s
== 10

works under WinXP too
red>> append/dup s: copy "" #" " 10
== "          "
red>> length? s
== 10
red>>

Works here from Win7 too.

'For MOLD/ALL, are you calling it "serialized" format in Red? And 
I assume that's a TBD at this point.' Gregg, suggested reading:

http://en.wikibooks.org/wiki/REBOL_Programming/mold

'No: without /ALL: "source" format, /ALL: "loadable" format?' - /ALL 
has a totally different meaning for LOAD than for MOLD, BTW

See also http://issue.cc/r3/1955

Your "construction syntax" is a bit long but accurate and meaningful 
naming.

Not exactly mine (to not take credits for something I did not invent), 
but I am promoting it is meaningful.

err: "as meaningful"

copying:

http://issue.cc/r3/2006

Saw it in R3 group. It's a nice trick, but don't you think that the 
setword used in such place might confuse readers? (at first look, 
I read [i: 100]...)

We shall se what the preferences are...

(At least I hope so)

Using [i:] instead of i: would remove the possible confusion, but 
it looks a bit inelegant.

Wouldn't it look confusing, if one would like (not sure anyone would 
to :-) to use something like:

 repeat i: j: 10 [print [i j]]

confusing? hmm, you can use parentheses to make it more readable:

repeat i: (j: 10) [...]

if you prefer

that's right ... I would understand the code even without parentheses, 
I think ....

Append/dup, thanks all for testing. Not sure how I could have broken 
anything by just adding doc strings to boot.red, but it's not just 
spaces for me here (Win7):

red>> s: copy ""
== ""
red>> append/dup s #"1" 10
== 10
red>> s
== "1"
red>> length? s
== 1

I will have to test more. If I just paste the original append source 
into the console (i.e. all doc strings removed), calling append then 
crashes.

If I rebuild the console with the version of append that has no doc 
strings, it works fine. Interesting.

It's having the doc string on the /dup refinement itself that causes 
it.

Take that out and it works fine.

It looks like that 's the case for all refinements that take an arg. 
If you have a doc string before the arg, it causes the arg to be 
ignored.

Can someone please confirm?

Testing with a string! between a refinement and its argument, I get 
odd results (but no crashes so far). Definitely a bug.

Do you want a bug report, or have you logged it yourself?

We need a bugtracker entry for this one, if you're on it, please 
add it.

red>> get 'x
red>> type? get 'x
==
red>> print type? get 'x
unset

The second result is the one in question.

Odd...please add it to the bugtracker.

Hmm, I get correct result here:

red>> get 'x
red>> type? get 'x
== unset!

Probably an interference from doc-strings like for APPEND.

Could be.

After pulling your doc-strings locally and recompiling the console 
I get the same output as you.

I need to fix that issue asap, before getting flooded with new tickets. 
:)

:-)

But I need to go to dinner now, so it will have to wait a bit.

How to create a routine which would accept any-type?

I was trying:  r: routine [value [any-type!]][] but got error like:

*** Compilation Error: invalid definition for function exec/r: [value 
[red-any-value!]]

sorry... 

*** Compilation Error: invalid definition for function exec/r: [value 
[red-any-type!]]

The commit to introduce the doc-strings seems to have caused a number 
of tests to fail, a few in the compiler tests but a much bigger number 
in the interpreter tests. For example:

	ok - serialization....................275 / 275
	** - interpreter-serialization*********11 / 275 **

Wow. Even my docs have bugs. I will run test here. Should have done 
that before.

My tests don't test the doc-strings so its definitely not you Gregg 
:-)

I wonder how I can test your doc-strings ?