AltME groups: search

; JS-like MAP. The order of args to the function is a bit odd, but 
is set

; up that way because we always want at least the value (if your 
func takes

; only one arg), the next most useful arg is the index, as you may 
display

; progress, and the series is there to give you complete control 
and match

; how JS does it. Now, should the series value be passed as the head 
of the
; series, or the current index, using AT?
map-js: func [

 "Evaluates a function for each value(s) in a series and returns the 
 results."
	series [series!]

 fn [function!] "Function to perform on each value; called with value, 
 index, and series args"
	/only "Insert block types as single values"
	/skip "Treat the series as fixed size records"
		size [integer!]
][
	collect [

  repeat i length? series [   ; use FORSKIP if we want to support /SKIP.
			keep/only fn series/:i :i :series ; :size ?
		]
	]
]
;res: map-js [1 2 3 a b c #d #e #f] :form
;res: map-js [1 2 3 a b c #d #e #f] func [v i] [reduce [i v]]
;res: map-js [1 2 3 a b c #d #e #f] func [v i s] [reduce [i v s]]
;res: map-js "Hello World!" func [v i s] [pick s i]

However, it is questionable whether a user unable to replace
    to [a | b]
by an idiom like recursive
    rule: [a | b | skip rule]
can be actually able to use Parse...

I feel, you need to explain this. If I replace a with "abc" and b 
with "str", and I want to parse ["abc"] :

(From R3 prompt:)

>> parse ["abc"] [to ["abc" | "str"]]
== false

>> rule: ["abc" | "str" | skip rule]
== ["abc" | "str" | skip rule]

>> parse ["abc"] rule
== true

Or did you mean

rule: [to a | to b | skip rule]

?

Geomol, I certainly did not mean the idiom you suggested. I just 
used an idiom for THRU, which can be adapted as follows::

    a: [here: "abc" :here]
    b: [here: "str" :here]
    rule: [a | b | skip rule]

Idiom I long time wanted - to [a | b] might be more expensive imo, 
as it will do incremental searches, evaluate the lower index and 
apply the rule. Whereas recursive [a | b | skip rule] will skip one 
positition at a time, trying to match rules .... or that is how I 
imagine the difference :-)

I remember now, how I solved my TO [a | b] situations in R2. It's 
what I call 'positive' parsing, where I all the time look for a positive 
all the way to either a or b is reached. It's easier to just let 
it skip to either a or b, whatever comes first, yes, but I was able 
to parse about everything the other way.


I need to look through all the R3 extensions to parse some day, when 
parse needs an overhaul in World. I guess, having parse as a mezzanine 
is a good thing to port it to also Red or other languages?

auto-crop-bitmap-text: func ["Returns a cropped image, or none if 
the input image was blank"
	image [image!] 
	/local region
][
	if region: find-bitmap-text-crop-region image [ 

  copy/part skip image region/1 region/2  ; return a cropped image
	]
]

Thanks......I can see now how SKIP can work on an image bitmap
    img: to-image #{....plausible hex stream....}
    skip img 2x2


However, TAKE does not work on image bitmaps.....Are there other 
types of bitmap?

try ? 

clear skip tail series -3

Similarly,

		either idx < 99 [clear back back tail ruler1]
			[clear back back back tail ruler1]
		append ruler1 to-string idx

can be written as

		change skip either idx < 99 [-2] [-3] to-string idx

err, I lost a part of the expression:


    change skip tail ruler1 either idx < 99 [-2] [-3] to-string idx

Patrick, rather than building up the strings bit by bit, consider 
how you might do it if you think of them as a buffer you're modifying. 
e.g., start with something like this:

ruler1: copy ""
insert/dup ruler1 "_" 110
forskip ruler1 5 [change skip ruler1 -1 "+"]

or this

ruler1: head insert/dup copy "" "____+" 22

Thanks to all that helped. Learning all the time.  I think I have 
the code pretty tight now!  A lot better than my first attempt.  
Final solution:

ruler-len: 80

ruler-1: head insert/dup (copy "") "----+----."	to-integer (ruler-len 
+ 9 / 10)
ruler-1: head clear (skip ruler-1 ruler-len)		; trim excess
r1: skip head ruler-1 9				; adv to pos 10
forskip r1 10 [	adj: ((length? idx: to-string (index? r1)) - 1)
				change skip r1 (-1 * adj) idx		]
ruler-1: head r1					; r1 is at tail

ruler-2: head insert/dup (copy "") "123456789." to-integer (ruler-len 
+ 9 / 10)
ruler-2: head clear (skip ruler-2 ruler-len)	; trim excess
print-ruler:	does [print ruler-1 print ruler-2]

My notes:


* it is absolutely unnecessary to set RULER-1 three times to the 
same value thus, I normally do:

    ruler-1: copy ""

    insert/dup ruler-1 "----+----." to-integer (ruler-len + 9 / 10)
    clear (skip ruler-1 ruler-len)		; trim excess
    ....
    ; for the same reason it is unnecessary to do:
    ; ruler-1: head r1

... and for the same reason I would do

    r1: skip ruler-1 9 ; HEAD unnecessary

parse-int-values: func [

    "Parses and returns integer values, each <n> chars long in a string."
    input [any-string!]

    spec [block!] "Dialected block of commands: <n>, skip <n>, done, 
    char, or string"
    /local
        gen'd-rules ; generated rules
        result      ; what we return to the caller

        emit emit-data-rule emit-skip-rule emit-literal-rule emit-data
        digit= n= literal=
        int-rule= skip-rule= literal-rule= done= build-rule=
        data-rule skip-rule
][

    ; This is where we put the rules we build; our gernated parse rules.
    gen'd-rules: copy []
    ; This is where we put the integer results
    result: copy []

    ; helper functions

    emit: func [rule n] [append gen'd-rules replace copy rule 'n n]
    emit-data-rule: func [n] [emit data-rule n]
    emit-skip-rule: func [n] [emit skip-rule n]
    emit-literal-rule: func [value] [append gen'd-rules value]
    emit-data: does [append result to integer! =chars]

    ; Rule templates; used to generate rules

    ;data-rule: [copy =chars n digit= (append result to integer! =chars)]
    data-rule: [copy =chars n digit= (emit-data)]
    skip-rule: [n skip]

    ; helper parse rules
	digit=: charset [#"0" - #"9"]
    n=: [set n integer!]
    literal=: [set lit-val [char! | any-string!]]

    ; Rule generation helper parse rules
    int-rule=: [n= (emit-data-rule n)]
    skip-rule=: ['skip n= (emit-skip-rule n)]
    literal-rule=: [literal= (emit-literal-rule lit-val)]
    done=: ['done (append gen'd-rules [to end])]

    ; This generates the parse rules used against the input

    build-rule=: [some [skip-rule= | int-rule= | literal-rule=] opt done=]


    ; We parse the spec they give us, and use that to generate the

    ; parse rules used against the actual input. If the spec parse

    ; fails, we return none (maybe we should throw an error though);

    ; if the data parse fails, we return false; otherwise they get
    ; back a block of integers. Have to decide what to do if they
    ; give us negative numbers as well.
    either parse spec build-rule= [
        either parse input gen'd-rules [result] [false]
    ] [none]
]

digit: charset [ #"0" - #"9" ]
alpha: charset [ #"a" - #"z" #"A" - #"Z" ]
idate-to-date: func [ date [string!] /local day month year zone]
[

 either parse date [ 5 skip copy day 2 digit space copy month 3 alpha 
 space copy year 4 digit space copy time to space space copy zone 
 to end ][
		if zone = "GMT" [ zone: copy "+0" ]
		to date! rejoin [ day "-" month "-" year "/" time zone ]
	][ none ]
]


if headers/last-modified [info/date: attempt [ idate-to-date headers/last-modified] 
]
		
seems to work

Chris, the easiest way to do what you are trying to do is to use 
sys/load-header, which returns a block of the decoded header object, 
the position of the script after the header (after decompressing 
it if need be), and the position after the whole script (useful for 
embedded scripts. If the script is embedded in a block it will decode 
the whole script and return the decoded block at the position after 
the header, but that can't be helped. R3 scripts are binary, not 
text, so the returned script position is binary.

>> sys/load-header "#!/some/path 1foo^/REBOL []^/script here"
== [make object! [
        title: "Untitled"
        name: none
        type: none
        version: none
        date: none
        file: none
        author: none
        needs: none
        options: none
        checksum: none
    ] #{7363726970742068657265} #{}]


>> to-string second sys/load-header "#!/some/path 1foo^/REBOL []^/script 
here"
== "script here"


Note that it will skip past one trailing newline after the header, 
if one exists.

Private

 modules were a side effect of the module name being optional. If 
 a module doesn't have a name, you can't check for whether it is already 
 loaded, so you have to load it again every time it is requested. 
 The module itself can't even tell if it was loaded before, so it 
 can't know whether it needs to resolve conflicts between itself and 
 other instances of itself. That makes it basically unsafe to have 
 an unnamed module export to lib. So instead, we skip the lib middleman 
 and import those exports directly into the target module or user 
 context, which makes the unnamed module effectively owned by that 
 target, a "private" module.


We found this facility useful enough that we added an explicit option 
to make it private (options: [private]). That makes it possible to 
have a named private module, which has some interesting abilities 
just from having a name. Having a name means that you can have the 
module load only once, and being private means that if you want to 
use its exports you have to import the module explicitly, so combined 
it means an explicitly accessed module that can share resources with 
other targets that also explicitly import the same module.

Rebolek, unfortunatly, you are mis-using TO.   TO is a search.   
 what you are doing is supposed to be done with SKIP

Is there a skip operation in PARSE?

Maxim: SKIP does relative positioning, TO/THRU do absolute positioning.

Wait, that's right, 2 skip, not skip 2.

well, I can imagine more scenarios, and it needs some thought to 
stay consistent between the cases. So my first thoughts, starting 
with the latest example:

for i 2 1 1 [prin "x"]


If above scenario means returning #none (and I agree with that), 
then I think that the for i 1 2 0 [print "x"] could be just the same. 
But - it might be related to the thoughts of the indexing. In REBOL 
series (if I am right), the position is in between the elements (not 
on the first element). So in that regards, skip 0 moves nowhere. 
But - it might also mean (as "first series" returns first element), 
that it should perform the loop just once. 


The last option for me is to cause an infinite loop, although from 
some point of view, it might make some sense too - you simply want 
to traverse the range, from 1 to 2, but you skip 0. If you would 
use just 'skip, you would cause an infinite loop. So - I really don't 
know ....

Let's say that I have two series that are the same length, and the 
values at each position of each series are related to each other. 
 What if I want to use a 'for loop to increment through the first 
series, but in some cases, depending on the value of the first series, 
I want to skip x values ahead, and on other values, I want to access 
that same position in the second series and perform an action on 
it.  Why couldn't I use a 'for loop to do this if I wanted?

Well, FOR isn't a general loop like in C, it's just an iterator. 
If we need a general loop we should add one, even though general 
loops are more expensive to use in interpreted languages than specific 
loops (which is why we have specific loops rather than one general 
loop). However, "I want to skip x values ahead" does sound like an 
argument for allowing index changes to affect the looping process, 
as a power-user feature.

Bo: you could rely on FORALL and series positions instead of carrying 
numerical indexes around:

forall b [
    offset: either b/1 = pick s1 index? b [
        do something
        1
    ][
        do something2
        5
    ]
    b: skip b offset
]

'However, "I want to skip x values ahead" does sound like an argument 
for allowing index changes to affect the looping process, as a power-user 
feature.' - agreed, it may be convenient when the user needs such 
a feature

Nice work, Gregg - thanks for doing all that.


I am having trouble getting LOOP to do what  FOR can do with a series:
    ser: [1 2 3 4 5 6 7]
    for v ser skip ser 5 2 [print v]
        1 2 3 4 5 6 7
        3 4 5 6 7
        5 6 7

Neither of these work for me:
    loop [v ser skip ser 6 2] [print v]
    loop compose [v ser (skip ser 6) 2] [print v]

Good catch. I just added series support, and since it's a simple 
dialect, it won't like that. In the current version, you would have 
to use an interim var for 'end. e.g.:

>> b: (skip ser 6)
== [7]
>> loop compose [v ser b 2] [print v]

e.g., in order to support Sunanda's example:

    loop [i ser skip ser 5 2] [print mold i]

Can I do this in my func:

    spec: repend reduce [spec/1] next spec

The generic problem to solve is this: You somehow have to specify 
what should happen for different actions. 


Let's start with the "somehow have to specify what should happen". 
For this you have some options:

1. Write the application logic code in the GUI spec block. For sort 
stuff OK, for long not.

2. Just call a function from the GUI spec block and write the rest 
somewhere elese. That's IMO the best way. I used FSM and just send 
"application logic events".

The next part is the "for different actions". Same here:

1. Name them explicitly on-* and specify the code with one of the 
options above.BTW: IIRC R3-GUI has click and right-click blocks for 
convinience.

2. Define an implicit mappging from block order to event type. 1st 
block = click, 2nd = right click, 3rd = double left, 4th double right, 
etc. IMO that's not a good style.


Overall what I never liked about VID was that is was not explicit 
enough. For big projects that's a must. For small you might skip 
this but if those projects get bigger, you are hit again.

Something like:

out: clear ""
script: {

 for /*(set)*/ myvar /*starting from*/ 1 /*reach*/ 10 /*use the stepping*/ 
 2 /* and execute*/ [
		print myvar
	]
}

parse script [some [
	copy s to "/*" (append out s) thru "*/"
	| copy s to end (append out s) 1 skip
]]
do out

1. Improved scrolling so that clicking on scroll arrows does not 
skip past text as now.

INMOLD: func [

 format [block!] "internal formatting to apply eg. [newline all skip 
 3]"
	value [block!] "block you would like formatted"
	/local path code
][
	; wrap NEW-LINE
	code: reduce [path: to-path 'new-line 'value true]
	parse format [
		any [
			'remove (poke tail code -1 false)
			| 'newline () ; redundant
			| 'all  (append path 'all)
			| ['skip set n integer!] (append path 'skip append code n)
		]
	]
	do code
]

blk: [a b c d e f g]

inmold [newline all skip 2] blk  ; -> new-line/all/skip blk true 
2
;== [
;    a b
;    c d
;    e f
;    g
;]

inmold [remove newline all skip 3] blk   ; --> new-line/all/skip 
blk false 3
;== [a
;    b
;    c d
;    e
;    f g
;]
inmold [remove newline all] blk  ; --> new-line/all blk false
;== [a b c d e f g]

Cal found a fun little bug with Select/Skip when using it on a string. 
 Here's the shortest code snippet that we've come up with to reproduce 
the problem.  Only copy and paste this into a console session that 
you don't mind killing cause it is going to lock up...  Tested on 
Win2K with the latest stable release, Command and recent betas...

select/skip {"<a><mm></mmmmf>"} "foo" 2

hangs here. first guess is, /skip steps behing the array, and that 
is not checkt. the it starts looking through hole memory. length 
of string is odd, step 2. maybe rebol tests "index = length" instead 
of "index <=  length".

I think it is related to a bug in FIND:
find/skip "abcdefghij" "azzzz" 5 ; locks up
find/skip "abcdefghij" "abczz" 5 ; locks up
find/skip "abcdefghij" "abcde" 5 ; == "abcdefghij"  OK
find/skip "abcdefghijkl" "zzzzz" 5 ; == none  OK

There are a couple of /skip bugs in RAMBO already... Search for "find/skip".

also, please add the find/skip bug to rambo as critical. thanks.

From what I can determine the bug where select/skip on a string locks 
up the interpreter is related to bug #3327  My guess is that because 
/skip isn't skipping properly then it sometimes finds itself in a 
forever loop trying skip at the same point repeatedly.  Shall I submit 
this as a new bug references the expected relationship between these 
two or do we want to extend the description of #3327 to include this 
information as well?

blk: head reverse [ A14 A2 B300]
out: copy[]
foreach w blk[repend out [to-integer next form w  w]]
probe extract next sort/skip out 2 2

sort/compare/all/skip  -- will crash earlier versions of REBOL...One 
reason not to use blocks.
It should work with recent versions.  Is that your problem, Petr?

Anton -- I had to debug the problems with Sort/all/skip/compare  
-- code that worked on one platform, but failed on another. It got 
burned into the brain.

Didec, i should do: parse b [any [h: set x skip (h: change/part h 
x 1) :h]]

Romano. Why not parse, because of skip not working?

Isn't skip working now in the new alphas ?

Comments could be italic. We're used to, that we can skip italics 
in text, I think.

Can't load ? Just skip it with with a warning message :) You still 
get your 99% solution.

Wolfie: Its strange because I often agree with the "essense" of what 
you are saying, but the way you stuff and the anger in your tone, 
always means I just skip all the posts.

>> help new-line
USAGE:
    NEW-LINE block value /all /skip size

DESCRIPTION:
     Sets or clears the new-line marker within a block.
     NEW-LINE is a native value.

ARGUMENTS:
     block -- Position in block to change marker (Type: block)
     value -- Set TRUE for newline. (Type: any)

REFINEMENTS:
     /all -- Set/clear marker to end of block

     /skip -- Set/clear marker periodically to the end of the block
         size -- (Type: integer)
>> a: [1 2 3 4 5 6 7 8 9 10]
== [1 2 3 4 5 6 7 8 9 10]
>> new-line a true
== [
    1 2 3 4 5 6 7 8 9 10
]
>> new-line a false
== [1 2 3 4 5 6 7 8 9 10]
>> new-line/skip a true 2
== [
    1 2
    3 4
    5 6
    7 8
    9 10
]

page: read http://www.rebol.com

images: copy []

use [whsp ws non-end-tag strd p1 p2 delim non-delim][

	whsp: charset " ^-^/" ; whitespace
	ws: [any whsp] ; a rule for any number of whitespace characters
	non-end-tag: complement charset ">" ; all characters except ">"
	strd: charset {"'} ; string delimiters, double and single quote
	parse/all page [
		any [
			thru "<img" [
				ws "src" ws "=" ws 

    p1: [strd (delim: form p1/1) | (delim: ">")] (non-delim: complement 
    union whsp charset delim)

    p1: any non-delim p2: (append images copy/part p1 p2) ; keep the 
    url
				| non-end-tag
			] | skip
		]
	]

]


new-line/all images on ; add hidden newlines to the images block 
so it molds nicely
print mold images

Ok, here is a version that should skip other attributes.

page: read http://www.rebol.com
images: copy []

use [whsp ws non-end-tag strd p1 p2 delim non-delim][

	whsp: charset " ^-^/" ; whitespace
	ws: [any whsp] ; a rule for any number of whitespace characters
	non-end-tag: complement charset ">" ; all characters except ">"
	strd: charset {"'} ; string delimiters, double and single quote
	parse/all page [
		any [
			thru "<img" whsp [
				any [
					ws "src" ws "=" ws 

     p1: [strd (delim: form p1/1) | (delim: ">")] (non-delim: complement 
     union whsp charset delim)

     p1: any non-delim p2: (append images copy/part p1 p2) ; keep the 
     url
					| non-end-tag 
				]
			] | skip
		]
	]

]


new-line/all images on ; add hidden newlines to the images block 
so it molds nicely
print mold images

page: read http://www.rebol.com
; special test cases from Alek_K
;page: {<img src="one two.jpg">} ; OK
;page: {<img alt="picture" src=one.jpg />} ; OK
images: copy []


use [whsp ws non-end-tag strd wh- non-str-delim p1 p2 delim non-delim][

	whsp: charset " ^-^/" ; whitespace
	ws: [any whsp] ; a rule for any number of whitespace characters
	non-end-tag: complement charset ">" ; all characters except ">"
	strd: charset {"'} ; string delimiters, double and single quote


 wh-: charset "^-^/" ; whitespace minus the space character (space 
 is allowed inside a quoted string)
	non-str-delim: complement union whsp charset ">"	

	parse/all page [
		any [
			thru "<img" whsp [
				any [
					ws "src" ws "=" ws 

     ;p1: [strd (delim: form p1/1) | (delim: ">")] (non-delim: complement 
     union whsp charset delim)

     p1: [strd (non-delim: complement union wh- charset form p1/1) | (non-delim: 
     non-str-delim)]

     p1: any non-delim p2: (append images copy/part p1 p2) ; keep the 
     url
					| non-end-tag 
				]
			] | skip
		]
	]

]


new-line/all images on ; add hidden newlines to the images block 
so it molds nicely
print mold images

so once you have done some header-lines  and got the ones you are 
interested in you skip the rest with thru "^/^/"

s: "Hello cè World" 
es: charset[#"e" #"è"#"è"#"ê"#"i"#"î" #"y"]

parse/all s [ to "c" p: skip es p2: ( p: change/part p "s" p2 ) :p 
]
? s

lines: copy []
rule: [ copy txt to "^/^/" (append lines txt) skip 2 ]
parse mytext [ some rule ]

untested ...

I get lost trying to find a good way to describe my rule. Here's 
the bad code that states my intent, but doesn't work ('parse doesn't 
seem to like having that 'until in there)

chunks: parse/all text [
	until [
		chunk: copy ""
		copy chunk to "^/^/"
		skip
		if chunk [
			append chunks chunk
		]
	] 
]

Hm. Still having issues:

>> rule: [ copy chunk to "^/^/" (append lines chunk) skip 2 ]
== [copy chunk to "^/^/" (append lines chunk) skip 2]
>> text: "Dude.^/^/Sweet!^/"
== "Dude.^/^/Sweet!^/"
>> lines: copy []
== []
>> parse/all text rule
** Script Error: Invalid argument:
** Near: parse/all text rule
>>

oops .. should be "2 skip" and not "skip 2"

parse/all data [any [to "*" a: skip b: to "*" c: skip d: :a (change/part 
a rejoin ["<strong>" copy/part b c "</strong>"] d)] to end]

;;; make the word set more restrictive if no space etc
;;; but this is most permissive for your example
word: complement charset "*"
rule: [
	skip to "*" 
	[copy item some word "*"(append output join[<tag> item </tag>])]
	| skip

markup-chars: charset "*~"
non-markup: complement markup-chars
tag1: ["*" "<strong>" "~" "<i>"]
tag2: ["*" "</strong>" "~" "</i>"]
parse/all data [
    any non-markup
    any [

        ["*" a: skip b: to "*" c: skip d: | "~" a: skip b: to "~" c: skip 
        d: ] :a (
            change/part a rejoin [
                select tag1 copy/part a b
                copy/part b c
                select tag2 copy/part c d
            ] d
        ) any non-markup
    ]
    to end
]

Whoops, an error. Change:

        ["*" a: skip b: to "*" c: skip d: | "~" a: skip b: to "~" c: skip 
        d: ] :a (
to:

        [a: "*" b: to "*" c: skip d: | a: "~" b: to "~" c: skip d: ] :a (

Silly me :(

yes, shortening the string you are parsing would pull the rug out 
from under the interperter,
(and I was aware that the string was being lengthened) 

note: setting the parse pointer back to :here will position you before 
the "*"  

you may be better off  with :here skip to gaurentee progress in the 
case the change fails

that a 16 skip

and then the other 12 for salt. copy salt2 12 skip

I added read-byte (charset), read-int (server-status), 13 skip (not-used), 
read-string (the rest of seed)

read-field: [
		(null-flag: false)
		read-length s: (either null-flag 
[field: none]
			[field:	sys-copy/part s len s: skip s len]) :s
	]

I managed to skip past the grub notes the first time, so I had to 
reinstall. :) Looks like I have to do it again.

do we have skip on files now?

there is a tailor.r in my folder on developer. it polls the tail 
of a file and calls a callback which each new line. uses /skip on 
file. may be a base for a daemon

Looks like there's no way to install lilo if you skip it in setup. 
Unclear and misleading comments in the setup notes.

I have reinstalled successfully from scratch. It seems to me I made 
two errors the first time around: I had skipped installing both the 
linux kernel and lilo bootmanager.

Max, why don't you use LOAD in PARSE, if you want to? Example:

rule: [
	(result: make block! 0)
	any [
		[
			; trying to load
			pos: skip (
				next-rule: either error? try [
					set [value pos] load/next pos
				] [[end skip]] [[:pos]]
			) next-rule |
			; load didn't succeed, using something else
			copy value skip
		]
		(insert/only tail result get/any 'value)
	]
]

>> parse "1 2 a, 3" rule
== true
>> result
== [1 2 "a" "," 3]

twist of redefining a rule...

 - that is just to "tell PARSE" whether the paren operation succeeded 
 or not - [end skip] is failure

file-modes doesn't seem to have anything

>> print mold new-line/all/skip get-modes %Desktop get-modes %Desktop/ 
'file-modes on 2
[
    status-change-date: 26-Mar-2008/12:29:33+11:00
    modification-date: 26-Mar-2008/12:29:33+11:00
    access-date: 27-Mar-2008/13:29:25+11:00
    owner-name: "anton"
    group-name: "anton"
    owner-id: 1000
    group-id: 1000
    owner-read: true
    owner-write: true
    owner-execute: true
    group-read: true
    group-write: false
    group-execute: true
    world-read: true
    world-write: false
    world-execute: true
    set-user-id: false
    set-group-id: false

    full-path: %/home/anton/.wine/dosdevices/c:/windows/profiles/anton/Desktop
]

From Didier

	; decode ISO-8859-1 / ASCII-US encoded text

 decode-iso8859: func [str /local ascii non-ascii char text emit quoted-printable 
 encoded-word res b e] [
		emit: func [v][append res v]
		ascii: charset [#" " - #"^(7f)"]
		non-ascii: complement ascii
		text: exclude union ascii non-ascii charset ["="]
		char: exclude ascii charset ["?_=^-"]
		encoded-word: [
			"=?" ["ISO-8859-1" | "us-ascii"] [
				"?q?" some quoted-printable |
				"?b?" b: to "?" e: (emit to-string debase copy/part b e)
			] "?="
		]
		quoted-printable: [
			"_" (emit #" ") |
			b: some char e: (emit copy/part b e) |

   b: "=" (emit do rejoin [ {#"^^(} second b third b {)"} ]) 2 skip
		]

		res: make string! length? str

  parse/all str [any [encoded-word | "=" (emit #"=") | "^/ " | b: some 
  text e: (emit copy/part b e)] to end]
		res
	]

construct: func [
    block [block!] /with object [object!]
/local nb spec values name value
][
    if not with [object: object!]
    spec: copy []
    values: copy []
    parse/all :block [
        any [
            to set-word! (nb: 0) some [
                set name set-word! (nb: nb + 1 append spec :name)
            ]
            set value skip (

                insert tail values nb insert/only tail values :value
            )
        ]
    ]
    append spec none
    object: make object spec
    foreach [nb value] values [
        loop nb [
            set in object (to-word first spec) 

                either find [true false none on off] :value [do value][:value]
            spec: next spec
        ]
    ]
    object
]

the datatypes are unique. Each on only shows up once. I don't see 
any optional parameters. The parameters can either be of type A or 
B, ok. But that can be handled in the action block of the matching 
switch. And there we can reposition the spec block to skip those 
handled cases.

shadwolf: Adding a hide flag requires me to alter all my data. Just 
wrap it around, if the grid doesn't know about it, just skip it.

Open/skip will be very helpful to allow file resume in Cheyenne.

Noticed you found some conversion numbers (where from?? ;) ), so 
here's a simple func to make use of them:

to-unit: func [s [string!]] [
	switch/default skip tail s -2 [
		"pt"	[1.25 * to decimal! copy/part s -2 + length? s]
		"pc"	[15 * to decimal! copy/part s -2 + length? s]
		"mm"	[3.543307 * to decimal! copy/part s -2 + length? s]
		"cm"	[35.43307 * to decimal! copy/part s -2 + length? s]
		"in"	[90 * to decimal! copy/part s -2 + length? s]
		"px"	[to decimal! copy/part s -2 + length? s]
	][
		to decimal! s
	]
]

blk: [
* 
+ 
- 
<> 
= 
all 
all 
append 
as-pair 
as-pair 
....
]
blk: sort blk
ublk: unique blk
hist: copy []
foreach word ublk [
	count: 0 forall blk [if blk/1 = word [count: count + 1]]
	repend hist [count word]
]
new-line/all/skip hist on 2
sort/reverse/skip hist 2
write clipboard:// mold hist

After testing and some guesses I figured out that the rebcode dialect 
is statement-based, although it can be converted from expression-based 
by the aforementioned rewrite rules. Also, the | in the declaration 
of opcode syntax refers to alternate data types, so that:
    skip: [word! integer! | word!]

means that skip takes a word! as its first argument and an integer! 
or a word! in its second argument.

(Thinking out loud) It occurs to me that computed branches would 
be a lot easier if you could reference the target values in your 
code, so that you have something to compute with. If the offsets 
were absolute you could just assign them to the label words (something 
that could be done in the first pass of the assembler rewrite of 
the branch statements). Relative offsets could be calculated pretty 
easily if you had something like a HERE opcode that would assign 
the current position to a variable that could be used soon afterwards 
to calculate the relative offset. For that matter, the HERE opcode 
could perform the assignment of the original label as well, and even 
be accomplished by a rewrite rule in the branch fixup pass of the 
assembler.


Here's my proposal for a HERE assembler directive. No native opcodes 
would need to be added - this would be another directive like label. 
This directive could be used to set the target values to words for 
later computation. Assuming BRAW stays relative and no absolute computed 
branch is added, it could also be used in computations to convert 
from absolute to relative offsets. This would be sufficient to make 
computed branches practical.


- A new directive HERE, taking two arguments, a word and a literal 
integer.

It would set the word to the position of the HERE directive, plus 
an offset specified in the second parameter. The offset would need 
to be a literal because the calculation would be performed ahead 
of time by the assembler - 0 would mean no offset. If you don't want 
to reset the position every time you branch to the word use an offset 
of 3. Resetting the word after every branch would allow its use as 
a temporary in absolute-to-relative calculations, but that would 
only be an advantage until the JIT or optimizer is implemented - 
the choice would be up to the developer. Having a mandatory second 
argument is necessary for reasons that will become clear later.


- The HERE directive would be rewritten away in the fix-bl function 
of the assembler like this:

REBOL []  ; So I could use SciTE to write this message

fix-bl: func [block /local labels here label] [
    labels: make block! 16
    block-action: :fix-bl
    if debug? [print "=== Fixing binding and labels... ==="]
    parse block [
        some [
            here:
            subblock-rule (here/1: bind here/1 words)
            |

            'label word! (here/1: bind here/1 words insert insert tail labels 
            here/2 index? here)
            |  ; Beginning of the added code
            'here word! integer! (

                here/1: bind 'set words  ; This is why HERE needs two arguments

                here/3: here/3 + index? here  ; Offset from position of this directive
                if (here/3 < 1) or (here/3 > 1 + length? block) [
                    error/with here "Offset out of bounds:"
                ]
            )  ; End of the added code
            |
            opcode-rule (here/1: bind here/1 words)
            |
            skip (error here)
        ]
    ]
    parse block [
        some [
            here:
            ['bra word! | 'brat word! | 'braf word!] (

                if not label: select labels here/2 [error/with here "Missing label:"]
                here/2: label - index? here
            )
            |
            opcode-rule
            |
            skip (error here)
        ]
    ]
]

Well Volker, what do you think of your alternate syntax? Note that 
opcodes that take any-type! instead of word! in their first parameter 
don't get their parameter abstracted out, and how easy it is to add 
exceptions. The direct branches might be a good idea to skip rather 
than abstracting the word and skipping the integer, but you can decide 
for yourself.

skip str 2

I guess it's really just because most people (me included) didn't 
know about it until recently. :-) And it's so nice, because (as Reichart 
said) it's for some things the way it should have been done in the 
first place. (it's nice for me, because in a small project I'm doing 
right now, I can skip almost all PHP coding, because I can do most 
stuff in Javascript and just let the PHP do the database handling)

the problems is reported in rambo ticket, will find it for you - 
it can report two zones +1 or + 2 here, and it is a problem - it 
depends if you skip the time the time is switched on, or if you go 
thru it ...

Then break it down into discrete queries and wrap it in some loops:

blk: copy []

foreach [company-id order-id date amount total] sql [

 select [company-id order-id date amount total] from orders where 
 [amount > 2000]
][
	company-name: second sql compose [lookup companies (company-id)]

 foreach [item-id item-price goods-name] sql compose [select * from 
 order-items where (order-id)] [

  insert tail blk reduce [order-id date amount total item-id item-price 
  goods-name company-name]
	]
]

sort/skip/compare blk 8 [8 1 5]

>> pickno: 7
== 7
>> db-select/where * prospectDB [rowid = :pickno]
** Script Error: Cannot use subtract on get-word! value
** Where: switch
** Near: insert tail buffer copy/part skip
>> :pickno
== 7
>> db-select/where * prospectDB [rowid = 7]
== [

    7 "7-02-2006" "Nom-7" "Prénom-7" "Québec" "Cie-7" "Référence: US" 
    "Conjoint-7" "Enfant-7" "Bur: 418-845-7" "Rés: 418-845-7...
>>

Graham, yes to all the above except timestamp/date fields. SQLite 
only supports 5 datatypes: Integer, Decimal, Binary, Null and Text. 
The driver (unless using the /direct refinement to connect) MOLDs 
and LOADs other REBOL types such as date!, pair!, etc into SQLite 
TEXT fields so date is certainly supported at the REBOL level (although 
an "order by date" clause will not give the expected results ... 
I tend to use 'sort/skip SQL "select id,date from t" 2' type constructs 
to achieve the desired result).


Given how common this later operation is (order by date) I'm looking 
at changing the way date is bound. Instead of just MOLDing it, if 
it is transformed to YYYY-MM-DD format then not only can LOAD recognize 
it but it can be sorted (as TEXT) directly by SQLite.

The change to handle date properly is pretty simple in fact (starting 
at line#375):

					unless direct [
						val: either date? val [
							p: reform [val/year val/month val/day]
							all [val/month < 10 insert skip p 5 "0"]
							all [val/day < 10 insert skip p 8 "0"]
							poke p 5 #"/"
							poke p 8 #"/"
							p
						] [mold/all val]
					]

Agreed. It's just that almost every datatype apart from date (pair! 
is also problematic) happens to sort correctly under SQLite as is; 
and changing date's TEXT representation so that it sorts correctly 
within SQLite is fairly easy. I'd rather write:

	result: SQL "select id,date from t order by date"


than:

	result: sort/skip SQL "select id,date from t"  2

as it's both easier to maintain and more efficient.

hmm, not sure I easily follow how dbs are opened in 'connect, so 
I skip the change to set path for dbs thru some variable ....

I agree with Maxim as well, there needs to be UI somewhere to stop 
automatic downloads.


With that said, is it possible to clean this whole thing up and reduce 
it to one place where you either have what you need or you don't.


Using Adobe Acrobat as an example, they have one plug-in interface.

When you download stuff, it asks you if you want any of the other 
modules Adobe has for you.  In fact a close friend of mine created 
one of those modules (Atmosphere), which is funny that Adobe's interface 
even asks if you want this, since almost no one know what Atmosphere 
is.


So a single consistent dialogue should pop up with something like 
this:

You have:

Rebol command 1.3 for OSX
Rebol view 3.0 for OSX

New modules that are available:    

[_] Rebol view 3.0 for OSX
[_] VID2 interface Alpha for OSX


[X] Always ask before downloading

[Skip] [Download all now]

another thing that people do not often realize is that our eyes are 
also not linear...  you can see each 8 bit step in the dark areas 
of an image, but can skip 5 steps within the brighter areas of an 
image without noticing it.  which is why we always notice image compression 
in very dark parts of DVDs and not in the bright parts of it... 


its very surprising to me that many compression algorythms get this 
wrong straight out of the bat.