World: r3wp

Henrik - you should, it is a big helper, although one has to lear 
how to interpret the result. But by parsing output, I cam imagine 
visual tool being done :-) More here - http://www.rebol.com/r3/docs/functions/trace.html

Here's the fontize:

fontize: funct [
	"Define text styles (from dialect)."
	spec [block!]
][
	assert-gui parse spec [
		some [
			spot:
			set name set-word!
			set parent opt word!
			set spec block!
			(make-text-style to-word name parent spec)
		]
	]["Invalid font syntax:" spot]
]

I wonder why trace shows 3 errors instead of 1?

Dunno. The errors don't correspond to what seems to be a reason why 
script crashes. It imo crashes, because the header of make-text-style, 
actually font-parent, expects word! or none! types, whereas it seems 
to get block! (at least that is what the error message says ...)

make-text-style: funct [
	"Define a new font style (used for text face styles)."
	font-name [word!]
	font-parent [word! none!]
	spec [block! none!]
][

so fontize gets spec block, which does not parse as needed anymore.

it would seem that PARENT is a block, but I can't duplicate this 
in the test parser, I'm building here.

how can I replace inbuilt fontize by my own? Will it be rewritten(redefined) 
by the demo call?

I think I know what it is.

For BASE font style there is no parent, and we have a new rule that 
says that SET does not set a new value, if the  value shouldn't be 
set.

This could be solved with

parent: none

prior to the parse.

Previously, this would be done automatically by PARSE. It would set 
PARENT to none if there was no parent.

ah, so what is 'parent set to, then?

so 'parent is not set at all? That is bad then. So you have to preset 
your parse level words to some defaults, if you can't be sure, if 
they will be set?

Maybe it's not entirely that. Because parent is a block, and it's 
set to the next value, so it borrows the next value after opt, where 
it shouldn't. That could be a parse bug.

Henrik - I think that you should post your finding, along with fontize 
short source to the CC, in order for Carl to identify the problem 
more easily ...

So the bug would be that SET uses the next value instead of doing 
nothing.

already posted in #1253, but now to formulate the cause.

>> parse [base: [specs]] [set-word! set c opt word! block!]
== true

>> c
== [specs]

That would be a bug :-)

description changed accordingly.

good catch, Henrik! :-)

Thanks. Still doesn't explain 3 errors shown in the stack trace, 
though.

>> secure [debug]
** Script error: datatype assertion failed for: pol
** Where: assert foreach secure

** Near: assert/type [target [word! file! url!] pol [block! word! 
int...

Hmm?

I did secure none, in order to be able to debug. This seems like 
a bug too.

Ah, it's just an unclear explanation. I needed secure [debug allow].

submitted as bug#1255.

Pekr, if I say secure [debug none], I get a security violation?

oops, not that but: invalid security policy

it throws invalid security policy here. I think none is not allowed 
secure dialect keyword, or is it? I know setting all security to 
none, but not particular section ...

but does it still allow you to debug with [debug none]? If that's 
the case, there is another bug.

ah, none simply doesn't change the secure status for debug. I guess 
that's not a bug.

Bug #1254 is a direct result of the A85 changes to the INSERT, CHANGE 
and APPEND functions, so we should probably test all functions that 
use those.

Does function! and closure! work backwards when dealing with indirect 
values (block!, string!, ...)?

>> f: func [/local b s] [b: [] s: "" insert b 1 insert s 1]
>> f
== ""
>> f
== "1"
>> source f

f: make function! [[/local b s][b: [1 1] s: "11" insert b 1 insert 
s 1]]

>> g: closure [/local b s] [b: [] s: "" insert b 1 insert s 1]
>> g
== ""
>> g
== ""
>> source g

g: make closure! [[/local b s][b: [] s: "" insert b 1 insert s 1]]

Souldn't the functionality be the other way around?

looks correct to me

I got the feeling, closures should work as R2 functions, that would 
remember local variables, after the function returned. And functions 
in R3 are implemented using stack-frames.

ok, I'm under the impression that closures are supposed to do the 
opposite thing.

well it's because inside a closure, all series are copied before 
each new run.
it's like having done:

g: make closure! [[/local b s][b: copy [ ] s: copy "" insert b 1 
insert s 1]]

Perhaps we should ask Carl not to copy deep the series when a new 
calling context is created.
Don't know...

What a closure seems to do (sort of):
func [][
	compose context [
	 (copy/deep body)
	]
]


It's not a correct simulation of R2 functions, which should be something 
like:

context [
	func spec body
]


You see, the context created should be outside, so that it would 
be build only one time and not each time the function is called.

(don't focus on the examples i gave, which are not functional, but 
about the topic)

Actually, it's what i do to create local persistant variable in a 
function. I wrap the function in a context and declare the persistant 
variable in the object instead.

More i think about that, more i think the closure! type is useles, 
at least less than the above case.

My bad, FUNCT is doing that (wrap the function in a context).
So the true alternative is to use FUNC not closures.

* FUNCT i meant

k so lets say that network protocols are not the hardest part so 
far it can wait the last minute ?

Geomol, closures need to do a bind/copy at each call. maybe that 
should not copy strings, though, however, this way it is more consistent 
i guess.

Hehe, what is this? I did not know such func exists :-) I just realised 
it as Carl adressed the stack size:

evoke: make native! [[
    "Special guru meditations. (Not for beginners.)"

    chant [word! block! integer!] "Single or block of words ('? to list)"
]]

example:

secure none
evoke [stack-size 1000000]

2.100.87 out ...

http://www.rebol.net/r3blogs/0262.html

BREAK for PARSE.

btw - what does Carl mean, that BREAK is not yet defined for parse? 
It exists even in R2, no?

Ah, I had the same reaction Pekr.