AltME groups: search

is: func [
		[catch]
		{Current face inherits from a block!}
		spec [block!]
		/local locals old when init
	][
		either all [
			find spec set-word!	; locals founds
			not empty? exclude  ; new ones (not found in the current face)

    first locals: construct copy spec ; copy: because [construct] modifies 
    the block (R2 bug ?)
				first face
		][

   ; Would be simpler, faster and safer using R3 (objects can be expanded)
			; rebuild face with new locals 

   ; (make face spec : can't be used here because of the special bounding 
   rules)

   when: face/when					; prevent copy/deep of when and init blocks
			init: face/init
			face/when: face/init: none
			set locals none

   resolve* locals face			; initialize locals with current face (if 
   intersect)

   face: make old: face locals		; rebuild current face with new locals
			face/when: when
			face/init: init
			do-safe bind bind spec face self; run style constructor 

   bind bind init face self		; rebound current face constructor (which 
   is currently running)

   error? set old :bound-err		; prevent old object from being used anymore
			old: none
		][
			; no new locals

   do-safe bind bind spec face self		; just run style's constructor 
		]
		if error throw-exit
	]

Doc, will it be necessary or possible to have a debug version of 
Red with deep level of integration with debugging tools as well as 
a non-debug version with higher performance, or is this something 
that can be turned on/off in the same runtime?

From ~Links group: "Could Red eventually become a contender for #6? 
 How strong will support for parallel processing be, eventually, 
in Red?"


#6: yes, that is one of the goals I want to achieve with Red. For 
parallel processing, the model I have in mind is the "parallel collections" 
from Scala. This means that when you are looping over a series, Red 
should be able to parallelize the loop code over n (CPU and/or GPGPU) 
cores at the cost for the user of only a change of the loop function 
name (in Scala, they use a "par." prefix for such functions). This 
requires that the compiler do a deep static analysis of the loop 
body to determine if it can be parallelized (e.g. iterations not 
dependent on results from previous ones). Now, if you also add SIMD 
support in the equation to leverage intra-core parallelism, you get 
a good picture of what I want to achieve. ;-)


So, I think a semi-assisted parallelization/vectorization of loops 
in Red is doable. To what extent and which final efficiency, I'm 
not sure before we build some prototypes.

On the subject of hot-patching, I've thought for a long time that 
the ability to instrument apps--like DTrace--would be very helpful. 
I know DTrace is deep kernel voodoo, and not available on all OSs. 
If Red supported probe points for DTrace, that would be great for 
those who use it. My question is whether it would be better to use 
a DTrace model, where the analysis happens from outside the app, 
or if having an instrumentation/tracing/logging model internally 
is better. Or can you support both with the same set of probe points 
in an app?

I have found an issue with word! value casing in Red. The Red/System 
code generated for:
	print 'a = 'A
is:
          stack/mark-native ~print
          stack/mark-native ~strict-equal?
	word/push ~a
          word/push ~A
          natives/strict-equal?*
          stack/unwind
          natives/print*
          stack/unwind


The problem is that Red/System is case-insensitive, so ~a and ~A 
are the same variable. So, no way to make it work like that. I see 
two options for solving it:

1) Make Red/System case-sensitive.

2) Deep encode each Red generated symbol to distinguish lower and 
uppercases.


Solution 2) works, but it makes symbol decoration operation very 
costly (each symbol letter is prefixed with a sigil for lowercases 
and another one for uppercases). The example above becomes:

          stack/mark-native ~_p_r_i_n_t
          stack/mark-native ~_s_t_r_i_c_t_-_e_q_u_a_l_?
          word/push ~_a
          word/push ~-A
          natives/strict-equal?*
          stack/unwind
          natives/print*
          stack/unwind


So, it is not nice, it doubles every Red symbol size that is handled 
by Red/System and slows down Red compilation by 25%.

So, my questions are:
a) Does anyone see another cheaper solution to this problem?

b) In case of option 1), do you have anything against making Red/System 
identifiers case-sensitive?

COPY on any-block! series implemented, /part and /deep supported 
(/types has not been implemented yet).

Implementing that feature revealed a few deep bugs in the current 
Red runtime code, I hope to be able to finish fixing them by tonight.

Thanks Doc for sharing this information and Kaj for doing this GUI 
binding, paving the way for newcomers and sharing the source for 
deep study. When I will be going back to my former status (more free 
time) I plan to deeply study Red/System in parallel with the C language 
just to be able to write some small doc (or book) to help newcomers 
to start with Red/System after coming from the C environment. In 
fact it's a long time I planned to do it for myself first but never 
found the time to do so when I worked as a teacher in the past. Now 
I hope I will better drive my diary to cope with this new planniing 
!!!

I implemented compose/deep. With the latest Red fixes, it works now

Kaj: I've pushed a change in attributes handling for Red/System functions, 
you can now specify attributes or function's description doc-string 
in any order. I've replaced direct spec block access for attributes 
by a function call in deep compiler's code parts, so watch out for 
regressions especially in callbacks!

Doc - you still don't seem to understand. Are you so deep in an a 
language design, so that you can't understand lamers like myself? 
:-)

You know how it is with benchmarks: you can never specify it deep 
enough to prevent all caveats

It is intentional and has several purposes: 


a) avoiding the creation of an hidden context for each iterator instance 
and especially the costly deep BINDing of argument block on each 
call.


b) making the iterator word available outside of the loop, can be 
useful when early breaking from loop, avoiding the passing of the 
counter through a BREAK/RETURN. It can also be used to check if the 
loop counter has reached its limit or not.


c) it is IMHO counter-intuitive for users, after a few years you 
get used to it, but it is a wall that every new user will hit more 
than once. I think that the extra step of defining it as local word 
is really not a big deal in comparison. Also, FUNCTION constructor 
could be enhanced to take care of that for you.

Gregg: only set-words are localized. What you saw in _function/collect-words 
is the the conversion of spec block elements to words for the ignore 
list. The collection of words from body block happens in collect-deep.

BTW, even though I'm not ready to write deep .reds code, it's very 
enjoyable to have a reason to go through the code now. It's very 
nice.

Kaj: I think I've found a workaround for the semi-random compilation 
crash on Linux. It seems SELECT has some deep stability issues in 
R2.

Pekr: I think FB was a mistake, it's not the right place/tool where 
to have technical discussions (especially on deep topic like programming 
languages).

It sounded like deep voodoo required for your bridging needs.

I guess it is still deep voodoo, just a different kind. :-)

I imagine Doc will profile things if performance becomes his argument. 
I support what makes it easier to use PARSE to get the job done, 
though sometimes there may be confusion between those who understand 
parsing at a deep level and those who don't. I would rather have 
support for TO [a | b], and other rules, even at the cost of them 
having lower performance, versus people not being able to do the 
job at all. In docs, we can note the tradeoffs, and people can optimize 
if necessary.

For building an x86 system compatible apk, the following changes 
are required in the build script:


make-dir/deep bin-dir/lib/armeabi => make-dir/deep bin-dir/lib/x86
-t Android
 => "-t Android-x86"
/libRed
 => "Red"

In order to be able to generate x86 target, do the following:

- copy %build.r into %build-x86.r


- change make-dir/deep bin-dir/lib/armeabi => make-dir/deep bin-dir/lib/x86

- change "-t Android" => "-t Android-x86"


- change "rejoin [%../red/bridges/android/ bin-dir/lib/armeabi" => 
"rejoin [%../red/bridges/android/ bin-dir/lib/x86"


- run %build-x86.r - generates an apk and if you ran arm version 
previously, will pack both versions into one .apk

The above mentioned script also fails at it tries to make a directory. 
Maybe it needs make-dir/deep %runnable/arm-tests, or simply to remove 
%runnable ....

I'll add the /deep to %build-arm-tests.r Pekr (Runnable dir is required 
and built by quick-test.r)

I'll also suspend the function tests from the Arm build.

Oldes, I'm interested in the psychology of this. Why would you rather 
write a script for which you need deep Fossil knowledge, than download 
one Fossil executable file?

you can simply say that when an entry doesn't have a year, it is 
always larger,  so you have them at the end of the list.  you could 
then sort those without a date according to their name.


if you want just the list for "1991-1992" yes, that is a good approach... 


however usually, the fastest way to filter-out lists, is to copy 
the block (not deep, so its quick) and then use remove-each on the 
new block... like-so:

filtered-data: copy data

remove-each [hash mcapz] filtered-data [ not select mcapz "1991-1992"]

Yeah, R3's USE does a COPY/deep of the body, then make closure! uses 
the copy itself, then when executed (IIRC) the closure executes a 
BIND/copy of its body. So it copies its body more than once, but 
possibly less than twice.

I guess you could use ALSO for R2's USE blocks too, or you could 
explicitly COPY/deep the body the way R3's USE does internally.

I always  though  BIND/copy    was   equivalent to    BIND COPY/deep

Will this work?

    LPINT-def: [value [integer!]] none
    LPINT: make struct! LPINT-def none

    make-LPINT: does [make struct! LPINT-def none]

    get-dereferenced-data: func [

        {Given a pointer to memory, copy the target data into a REBOL struct.}
        pointer [struct!]   "LPINT structure"

        struct-def [block!] "Contains a sub-struct that is the real struct 
        you want."
        /local struct data orig-pointer result
    ] [

        struct: make struct! compose/deep/only [ ; make wrapper struct
            sub [struct! (struct-def)]
        ] none

        orig-pointer: third struct              ; store original inner pointer

        change third struct third pointer       ; change inner pointer to 
        ref'd data

        data: copy third struct/sub             ; copy data from the inner 
        struct
        ;print mold data

        change third struct orig-pointer        ; restore inner pointer

        result: make struct! struct-def none    ; make result struct

        change third result data                ; change data in result struct
        ;probe result
        struct: data: orig-pointer: none
        ;recycle
        result
    ]

It's from some old code, so no guarantees.

THat is a complicated issue, but the principle is easy. USE modifies 
it BODY and should be treated as modifying. However, you can easily 
define a non-modifying version:

    USE words copy/deep body

Here is a version with no locals, no temporary context, no shit and 
not tested ;-)

rfunc: func [spec body][
	func spec compose/deep [
		forever [
		   set [(spec)] catch/name [
			  return (func spec body) (spec)
		   ] 'recur
		]
	]
]
recur: func [args][throw/name reduce args 'recur]

OK, this is the long version:

tail-func: func [
    {

  Define a recursive user function with the supplied SPEC and BODY.
     	The function can use a special TAIL-CALL local function
     	to perform a tail-recursive function call.
    }
    [catch]


 spec [block!] {Help string (opt) followed by arg words (and opt type 
 and string)}
    body [block!] {The body block of the function}
    /local the-function tail-call context-word
] [
	; define a new 'tail-call local variable
	tail-call: use [tail-call] ['tail-call]
	
	; bind the given BODY to "know" the 'tail-call variable
	body: bind/copy body tail-call
	
	; find a local word in SPEC
	context-word: find spec word!
	if context-word [context-word: first context-word]
	
	; define the TAIL-CALL function
	set tail-call func spec compose [
		(
			either context-word [
				; set parameters to the new arguments
				compose [set parameters values? (context-word)]
			] [[]]
		)
		throw/name none 'tail-call
	]
	
	; define the function
	the-function: throw-on-error [
		func spec compose/deep [
			(either context-word [context-word] [[]])
			while [true] [
				catch/name [
					return do [(body)]
				] 'tail-call
			]
		]
	]
	
	if context-word [
		; get the function context
		context-word: bind? first second :the-function
		
		; replace the context word in the function body by NONE
		change second :the-function none

		; adjust the TAIL-CALL body
		; replace the 'parameters word

  change/only at second get tail-call 2 bind first context-word context-word
	]

    :the-function
]

values?: func ['word] [second bind? word]

I think I included all your modifications Ladislav but shortly :-)

rfunc: [spec body /local args][
	args: to-block form first (

  do second func spec compose [bind? (to-lit-word first find spec word!)]
	)
	funct spec compose/deep [
		recur: func spec [
				throw/name reduce [(args)] 'recur
		]
		forever [
		   set [(args)] catch/name [
			  return do [(body)]
		   ] 'recur
		]
	]
]

Should do the trick:

rfunc: [spec body /local args][
	args: to-block form first do second 
		func spec compose [bind? (to-lit-word first find spec word!)]
	funct spec compose/deep [

  recur: quote (func spec compose/deep [throw/name reduce [(args)] 
  'recur])
		forever [
		   set [(args)] catch/name [return do [(body)]] 'recur
		]
	]
]

Last version.

- Any spec accepted but needs at least one parameter (can be just 
a local)

rfunc: func [
    [catch]
    spec [block!] body [block!] /local arg obj recur
][
    throw-on-error [

        if error? try [arg: to-lit-word first find spec any-word!][
            make error! "rfunc needs at least one parameter."
        ]
        recur: func spec compose [throw/name bind? (:arg) 'recur]
        obj: catch/name [do second :recur] 'recur
        funct spec compose/deep [
            recur: quote (:recur)
            forever [

                set/any [(to-block form first obj)] second catch/name [
                    return do [(body)]
                ] 'recur
            ]
        ]
    ]
]

Completly changed my mind. It's lot leasier to manage /recur as a 
refinement! 
- eg. safe/recur instead of recur

- no words collision anymore (obviously /recur can't be used as a 
parameter).
Also really short code 

rfunc: func [[catch] spec [block!] body [block!] /local ctx fun][
    spec: append copy spec /recur

    ctx: bind? first second fun: throw-on-error [func spec [recur]]
    change second :fun compose/deep [
        if (in ctx 'recur) [throw/name second (ctx) 'recur]
        while [true][

            set/any [(bind to-block form first ctx ctx)] catch/name [
                return do [(bind/copy body ctx)]
            ] 'recur
        ]
    ]
    :fun
]

;Go back to recur as a function.
;Still recur can't be used as a parameter, local or a refinement.

;This implementation is much more clean (no shitty compose/deep) 
and still very short.

;The collision of words is avoided by the use of singleton functions 
#[function!]
;I'm confident with this one. It could be the last one -_-;


rfunc: func [[catch] spec [block!] body [block!] /local ctx args][
    ctx: bind? first second throw-on-error [
        ;* Temporary function created to retrieve parameters
        ;* and to get a new context for 'recur.
        ;* The context will remain alive (not GC'ed).
        func append copy spec /recur [recur]
    ]
    args: bind to-block form first ctx ctx
    ctx/recur: func spec reduce [

        quote #[function! ['word] [throw/name second bind? word 'recur]] 

        first args ;* may be 'recur if empty specs (still, it's ok)
    ]
    func spec reduce [
        quote #[function! [args body][

            while [true][set/any args catch/name [return do body] 'recur]
        ]] 
        head remove back tail args ;* remove 'recur
        bind/copy body ctx         ;* bound 'recur
    ]
]

;Go back to recur as a function.
;Still recur can't be used as a parameter, local or a refinement.

;This implementation is much more clean (no shitty compose/deep) 
and still very short.

;The collision of words is avoided by the use of singleton functions 
#[function!]
;I'm confident with this one. It could be the last one -_-;


rfunc: func [[catch] spec [block!] body [block!] /local ctx args][
    ctx: bind? first second throw-on-error [
        ;* Temporary function created to retrieve parameters
        ;* and to get a new context for 'recur.
        ;* The context will remain alive (not GC'ed).
        func append copy spec /recur [recur]
    ]
    args: bind to-block form first ctx ctx
    ctx/recur: func spec reduce [

        quote #[function! ['word] [throw/name second bind? word 'recur]] 

        first args ;* may be 'recur if empty specs (still, it's ok)
    ]
    func spec reduce [
        quote #[function! [args body][

            while [true][set/any args catch/name [return do body] 'recur]
        ]] 
        head remove back tail args ;* remove 'recur
        bind/copy body ctx         ;* bound 'recur
    ]
]

Rebol [
    Title: "Catch"
    File: %catch.r
    Date: 5-Oct-2012/17:49:58+2:00
    Author: "Ladislav Mecir"
    Purpose: {
    	Catches local throw'
    	Ignores non-local throws
    }
]

; Error definition
system/error: make system/error [
	throw': make object! [
		code: system/error/throw/code + 50
		type: "throw' error"
    	not-caught: ["throw' not caught"]
    ]
]

catch': func [
    {Catches a throw' from a block and returns the value.}
    [throw]
    block [block!] "Block to evaluate"
    /local err disarmed
] [
	use [throw'] copy/deep compose/only [
		; "localize" 'throw' in the block
		block: (block)

		throw': func [[catch] value [any-type!]] [
			disarmed: disarm err: make error! [throw' not-caught]
			set/any in disarmed 'arg1 get/any 'value
			disarmed/arg2: 'throw'
			throw err
		]

		get/any either all [
			error? set/any 'err try block
			(
				disarmed: disarm err
				disarmed/type = 'throw'
			)
			disarmed/id = 'not-caught
			disarmed/arg2 =? 'throw'
		] [
			in disarmed 'arg1
		] [
			'err
		]
	]
]

rfunc: func [[catch] spec [block!] body [block!] /local ctx fun][
    spec: append copy spec /recur

    ctx: bind? first second fun: throw-on-error [func spec [recur]]
    change second :fun compose/deep [
        if (in ctx 'recur) [throw' second (ctx)]
        while [true][
            set/any [(bind to-block form first ctx ctx)] catch' [
                return do [(bind/copy body ctx)]
            ]
        ]
    ]
    :fun
]

This time it's really really my final version T_T
- Both f/recur and recur allowed
- Catch/throw interferences ok.

NB: The code would be simpler in R3 since several workarounds are 
used to correct misbehaviors of object related natives of R2.

Also the lack of the reflexive capability for a function to read 
its own context in a easy way is definitivly a huge miss.

(On can't create anonymous functions without analysing their specs 
first. What a pain)

One would need a reserved word holding the context (like SELF for 
objects).

These shortcomings are making the code too much obfuscated and huge 
for my taste.
I hope it will be corrected in R3..

rfunc: func [
    [catch] spec [block!] body [block!] 
    /local ctx args call-tail
][
    ctx: bind? first second throw-on-error [
        func spec: append copy spec /recur [recur]
    ]
    args: bind head remove back tail to-block form first ctx ctx
    call-tail: func ['word] compose/deep [
        set/any [(args)] second bind? word 
        throw/name (ctx) 'recur
    ]
    ctx/recur: func spec reduce [:call-tail 'recur]
    func spec reduce [
        quote #[function! [
            [throw] 'recur 'call-tail ctx args body /local ret
        ][
            if get/any recur [call-tail :recur]
            set recur get in ctx 'recur
            while [true][
                set/any 'ret catch/name [return do body] 'recur
                unless all [value? 'ret same? :ret ctx][
                    throw/name get/any 'ret 'recur
                ]
                set/any args second ctx
            ]
        ]]
        'recur :call-tail ctx args body
    ]
]

Also interested in usage example for TAKE/DEEP where the /deep can 
be a pair!

:)
Is TAKE intended one day to work on image bitmaps?
Or is there another use for:
     TAKE/DEEP word 10x10

My confusion is due to the help for TAKE saying the /DEEP arg can 
take a pair! -- So I was looking for a usage case.

With REBOL, it's almost always something simple. Until you drop into 
the deep water. :-)

>> help copy
USAGE:
    COPY value /part range /deep


So, copy/part takes two parameters:  (1) the start index, and (2) 
the range


If you rewrite the copy/part like I did below, it is much easier 
to see how it is split up:

copy/part
	tail form idx	;parameter 1
	-1		;parameter 2

I saw code last year, but it's probably still in deep development

Before delving deep into R3 code, does anyone have any knowledge 
or idea of why this is happening?  Could it be a problem with buffer 
allocation around the 32K boundary?

bug?

v: 5
a: compose/deep [(v) q]
reduce a

Knock your socks off?  No, perhaps just get rid of a lot of deep 
bugs completely, and enable us to move on to the next stage (applets, 
and applets written by people other than us).

There's something deep-down that is wider than View.

Run enough CGIs under Core and you'll get what seems to be the same 
sort of error.

Which is weird as each CGI is a separate incarnation (when not using 
fastCGI, anyway).

Agreed.  


But if I did not engage Graham, I would be ignoring an important 
part of our relationship, which is "aside" from the point you describe. 
 


You know guys……………its OK to disagree about stuff, have deep discussions 
about them, and even walk away disagreeing to the end.  Perhaps it 
is a cultural difference that causes people to worry about "upsetting" 
people.

like
  b: copy [] append/only b b copy/deep b

make object makes deep copies of all blocks. sure that crashes. crash 
should should be a softer?

base: [text (c) 40x20 effect [draw [text 20x0 (c)]]]

lay: [origin 0 space 1 across]
for i 16 31 1 [
	for j 0 7 1 [
		c: copy to-string to-char 8 * i + j
		append lay compose/deep base
	]
	append lay 'return
]
view layout lay

that's funny.  I've always used compose/deep [[()]]

'compose evaluates any parens in the block passed to it.  If you 
are passing 'compose a block containing blocks that contain values 
you would like composed then you need to use the /deep refinement 
of compose

; (i.e. 
test-case-test: make test-case compose/deep [
    ...
    test-result-formating: func [/local ed][
        ed: make (test-result)
        ...
    ]
]

I can see, it must be hard to support these features on all platforms. 
It's rather deep down in the OS.

A way to go may be to make a deep analyse of, what a document is 
- what it consist of. There are basic elements like letters, dividers 
(<br/>), ... Then there are bigger elements (containers) like notes, 
tables, ... And we can talk about change of state like bold-on, bold-off, 
italic-on, italic-off, font change, etc. The containers should be 
strictly hierarchical. The basic elements and the containers will 
be represented in a sequence. The inside of a container is maybe 
also a sequence. Decisions should be made, if change of state can 
happen anywhere, or if going to one state and back is a container 
too. (I'm thinking loud here, you may notice.)

I'm interested in that, too. :-) What I know is that Arno is making 
deep changes to the video driver framework to add backbuffering in 
the memory of the video cards. We think about AGG as a crossplatform 
rendering library, but Arno is considering the few simple drawing 
functions in Syllable. Things like line drawing are passed directly 
to the video drivers, and if a driver supports 2D acceleration, the 
draw is done in hardware by the video card. In our new framework, 
these drawing operations need to be able to work directly in the 
memory of the video card when necessary. It makes sense that crossplatform 
libraries are not suitable for this deep integration

The driver framework is going to be revamped with better use of the 
video card: backbuffering and integrated 2D drawing functions. The 
current discussion will also lead to deep integration of 3D. Both 
software rendering and hardware rendering are being worked on. This 
takes the kind of fundamental changes throughout the system that 
take many years on for example Linux, because no project has control 
over all the parts that need to be changed to coordinate everything 
in the best way possible

We have just a few rendering functions, but they're deeply integrated 
with the video driver framework, now with backbuffering. When we 
add more functions they may need the same deep integration for the 
best result, and then we can't use an existing library directly. 
Of course, you can still use existing libraries on top of our framework, 
but that's not the most efficient solution

Volker is suggesting this:

escape-metachars: func["escape metachars" s][
 replace/all s "'" "''"
 rejoin ["'" s "'"]
]

browse: func[url]compose/deep[

call rejoin ["screen -X screen -- " (view-root/bin/browser.sh) " 
" escape-metachars url]
]

I had the same problems with the last /view release 1.3 on my old 
Slackware machine.. the dependency libs where knowwhere to find... 
else then hidden deep inside gcc somewhere..

Cool stuff…


I don't find either QuickTime or Flash to be quite as pervasive as 
everyone would like to think.  We have found bugs amongst about 50% 
of the Mac users trying to display Flash media, and about 20% of 
PCs have some sort of trouble with QuickTime (not the least being 
they have not downloaded it yet).


The fact that Apple only supports Flash 4 is a pain.  I wish they 
could simple confirm their was no security holes, and that installation 
from all browns (like all four) was truly just a confirmation box. 
 Some times I will go to upgrade someone, and I will even be forced 
to reboot.  Deep shame.

Phil if you need an IMAP account on a server to test with, we can 
give you access to the one we set up to test Qtask's new Webmail 
interface.  The account contains lots of examples like large attachments, 
deep folders.  As we learn more, we fill it with ore examples.  Just 
shoot me a private message, and I will get you name and password.

agree, COPY not needed - just an habit when I modify blocks, but 
here I did it two times wrong:
- the 'draw sub-block is modified, so it should be copy/deep 
- no 'copy needed with 'make, who does copy/deep

Volker: ( ) for actions - it will be a pain to use with compose/deep 
(needed because 'display evaluation is kept to minimal).

node-prototype: reduce [
    'type      0
    'namespace none
    'tag       none
    'children  []
    'value     none
    'parent    none
]

foobar: copy/deep node-prototype
foobar/type: 1
foobar/tag: "foobar"

bar: copy/deep node-prototype
bar/type: 1
bar/namespace "foo"
bar/tag: "bar"
bar/parent: :foobar

append foobar/children bar

text: copy/deep node-prototype
text/type: 3
text/value: "Some Text"
text/parent: :bar

append bar/children text

document: context [
    get-elements-by-tag-name: func [tag-name][
        remove-each element copy nodes [
            not equal? tag-name element/tag
        ]
    ]
    nodes: reduce [foobar bar text]
]

together with a bit unix for copy/deep test-directories and a diff 
later.

I'm having to create nested objects 7 levels deep ...

Let me understand this .. if I have an object that needs other objects 
more than 1 deep .. I can't use that to clone other objects without 
creating references instead of copies.

but note that your object's structure has to remain pretty static 
for any type of deep copy like this to be usefull.

deep copy

Ashley yes  !!! You noticed right I found them deep hided in the 
SVG format documentation on W3C dedicated pages to SVG format ....

Enjoy...REBOL, being light, is pretty deep wide and somewhat 'hidden' 
 :)

Gabriele, you might want to change the compose/deep call in the rewrite 
rules generated by rebcode-define to compose. The current version 
might trip up makers of rewrite rules, like it does in your first 
example rule above in the (either paren? ...) clause. Let any further 
composition be up to the rule makers, just in case they actually 
need to use parens themselves.

about the compose/deep, i think that's what most people will want. 
note that my either paren? has nothing to do with it (it is to handle 
parens in the expressions, not to workaround compose/deep)

how would compose without /deep help there?

Compose would just compose the parens directly in the production; 
compose/deep composes all of the inner parens inside the code as 
well.

>> compose/deep [([something (something)])]
== [something (something)]

if you have either or if or while or something like that in your 
production, you'll need /deep, and you'll be screaming if you don't 
have it ;)

OK then, I thought /deep meant /deep, my mistake :)

I thought you needed the extra compose since it was to be applied 
later, at rewrite time.

That makes compose/deep more useful than I thought.

Well finding an example is simple: Just convert to stack code and 
figure out when the stack would be used more than one deep between 
ops. That means more than one temp var. What we get for going to 
a register machine in a stack language :)


This would all be solved by a built-in USE directive with literal 
blocks that acts like USE in REBOL except only binding at rebcode 
creation time. It could be implemented as a built-in rewrite rule, 
changing the temporary variables to local variables, renaming if 
necessary. This rewrite would be done after the user-defined rewrites 
were done, but before the binding to the opcodes.


Let me think about how this could be implemented - I am late for 
a class.

Im following this project now for some years (because its java im 
not very deep into it) but just nice to see what it does -> http://www.processing.org/

Also note that many join operations can be rewritten as sub-selects, 
as in:

	sql compose/deep [
		select * from a where [
			col < (
				sql [select max [col] from b]
			)
		]
	]

or:

	sql compose/deep/only [
		select * from a where [
			find (sql [select [col] from b]) col
		]
	]

Thanks guys, I've had a good look at both implementations and I've 
got ideas from both for a future full JOIN implementation; but at 
the moment my master/detail code has come along nicely. I've now 
enhanced the db-select function to accept statements in these additional 
forms:


 select * from master joins [select * from details where &id] on id

 select * from master joins [select * from details where [all [master-id 
 = &id master-date = &date]] on [id date]


which works exactly like a normal join with the following differences:

	a) It can only join one table to another

 b) Detail columns are always joined to the right of master columns

 c) Table.column prefixes are not supported so all columns in the 
 join must be uniquely named


Apart from that you get all the benefits of db-select (can replace 
* with specific column combinations, order and group by on the final 
result set, etc) *and* it's significantly faster than even the raw 
REBOL code example I gave before (as the SQL is parsed once within 
db-select and all loop sub-selects are done in-line).

I've also implemented “lookups” with the following form:

	select * from table replaces id with name
	select * from table replaces [id-1 id-2] with [table-1 table-2]


which performs a highly optimized db-lookup for each replaced value, 
but has the following restrictions:


 a) The lookup expects lookup tables in the form [id label other-column(s)]
	b) Only single-key lookups are supported
	c) A lookup that fails will replace the column value with none!


I'm now in the process of benchmarking these changes against sqlite 
to see where the bottlenecks (if any) are. Feedback on the design 
decisions is welcome.


While I was doing this, I was once again reminded how cumbersome 
it is to construct SQL statements (not just for RebDB, same goes 
for the other SQL protocols), as the heavy use of 'compose, 'rejoin, 
etc adds noise that reduces legibility. The design goal is to provide 
alternatives to:


 sql compose/deep [select * from table where [all [col1 = (val1) col2 
 = (val2)]]]


so for a start the 'sql function should probably accept a string, 
to allow:

	sql join “select * from “ table


type constructs; but this doesn't make the first example easier. 
So how about the 'sql function accept a block containing a string 
statement followed by a number of substitution variables, as in:


 sql reduce [“select * from table where [all [col1 = &1 col2 = &2]]” 
 val1 val2]


which makes things a bit more readable (and shortens the expression 
if longer word names are used multiple times). So the two questions 
here are:

	a) Is this a good idea?

 b) If so, what substitution character (& % $ @ other) will cause 
 the least conflict with REBOL and/or SQL?

wrt simplyfing the use of "noise"  ... why not just call compose/deep 
by default within the 'execute call of the client on ALL sql calls? 
 it could be a global option and IMHO the use of parens within the 
code is quite obvious and is used in many dialects. and its less 
cumbersome than to add the reduce word in your code, a string and 
then variables out of context of the sql statement.

Deliberate design that. The last line of 'sql is simply:

	buffer

not:

	copy/deep buffer


This is important when dealing with a large number of values as you 
want to pass a reference not double the amount of memory used with 
a redundant copy/deep! I'll add this "gotcha" to the documentation 
I'm writing.

Actually, there is no need to copy/deep buffer.
Just change 
	clear buffer
to
	buffer: copy []

there is no problem with integer, decimal, and none values regarding 
sharing.
Blob data is debased, which implicitly creates a new string.

Strings are normally loaded, which creates a new string. only when 
you use /raw, you are dependend on the sqlite.dll having a sane interface 
and not reusing the returned string data. You could add this as a 
possible gotcha.

clear buffer

 is also an optimization as it defaults to 32K values (make block! 
 1032 * 32) and I don't won't to reallocate it each SQL call. The 
 following benchmarks (Transactions Per Second) give some backround 
 to the design decisions I made:

	buffer				1744718
	copy buffer			282
	copy/deep buffer		76

	clear buffer			1144733
	buffer: copy []			824352
	buffer: make block! 32768	387


So the approach I took optimizes for large result sets by allocating 
a large buffer once up-front and then just referencing it thereafter.

depth is how deep links should be gathered for downloading. Values 
above 3 or 4 can be dangerous. :-)

I think, PS is good for printing too. I haven't looked deep into 
it, so I can't say, if PDF is enough. Does printers understand PDF 
directly, as they do PS? If not, PS is the way.

Yes, i mean that cauto-onfig-script. IIRC  it was not accessible. 
But digged not very deep.

Thanks. Affected tickets modified accordingly. Here's the new criteria 
for applying the "not a bug" severity:

- If the ticket is a Bug or Issue and the behavior is by design and 
intention, it gets marked as "not a bug" and dismissed.

- If there is some question, comments are added saying so and the 
ticket is marked as "waiting" or "problem", depending on whether 
the question is more of a group thing or a Carl thing, with some 
leeway either way.

- If the ticket isn't deep enough it will be rewritten to reflect 
the real problem, or maybe a new ticket will be made.

- If the ticket is too broad or general, it will be marked "problem" 
and split into multiple narrower tickets.

I've started working on the "POST data lost when session times out" 
issue, but that requires some deep changes in the RSP engine, so 
this enhancement is currently postponed.

There's a lot to that.  I was kind of using the DevCon '05 as a model 
(my fav so far) where all the info is knee deep on the front page 
with more detail on sub pages.

rebol [
	title: "explore.r"
	version 1.0
	date: 2009-03-19
	author: "Maxim Olivier-Adlhoch"
	copyright: "2009(c)Maxim Olivier-Adlhoch"
	tested: "win xp"

 notes: "Add any dir to the dirs block.  options are self explanatory"
]

dirs: [
	%/C/ []
	%"/C/program files/" [expand]
	"%tmp%" [label "temp dir"]
	"" [ label "my documents"]
]

blk: []

explore-dir: func [path expand? /local cmd][

 call/shell rejoin [" explorer " either expand? ["/n,/e,"]["/n,"] 
 path ]
]

ctr: 1
foreach [item opts] dirs [
	ctr: ctr + 1
	expand?: found? find opts 'expand
	label: any [select opts 'label to-local-file item]
	append blk compose/deep [ 
		pad 20 
		(to-set-word setw: rejoin ["dir" ctr]) check (expand?) 
		pad 20 

  btn 200 left (label) [ explore-dir to-local-file item get in (to-word 
  setw) 'data ]
	]
	append blk 'return
]


view layout compose [across vtext right "expand?" vtext "folder" 
 return (blk)]