AltME groups: search

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 ?

I hope this is useful for someone

REBOL []

rest: func [s [series!]][skip s 1]

define-object: func [
	spec [block!] 
	/local 

  arg-spec ctx-spec object-name constructor-name predicate-name attributes
		spec-rule type-spec continue? w
][
	arg-names: copy []

	continue?: [none] ;used to stop parsing
	name-rule: [set w word! (insert tail arg-names w)]

 type-rule: [set w word! (unless datatype? attempt [get w] [continue?: 
 [end skip]])]

 spec-rule: [name-rule some [name-rule opt [into [some [type-rule 
 continue?]]]]]

	if any [
		not parse spec spec-rule
		arg-names <> unique arg-names
	][
		make error! "invalid spec"
	]

    object-name: to-string first arg-names
	constructor-name: to-word join 'make- object-name
	predicate-name: to-word join first arg-names '?
	attributes: rest arg-names

	arg-spec: copy []
	foreach itm attributes [
		insert tail arg-spec reduce [
			to-word join itm '-value
			either block? w: select spec itm [w][[any-type!]]
		]
	]

	ctx-spec: copy []
	arg-names: extract arg-spec 2 1
	repeat i length? attributes [

  insert tail ctx-spec reduce [to-set-word attributes/:i to-get-word 
  arg-names/:i]
	]

	;create constructor function
	set constructor-name make function! 

  compose [(reform ["Makes a new" uppercase object-name "object with 
  attributes" mold attributes]) (arg-spec)]
		compose/only [make object! (ctx-spec)] ;body

	;create predicate function
	set predicate-name make function! 

  compose [(reform ["Determines if value is a" uppercase object-name 
  "object"]) value [object!] /local types]
		compose/deep/only [
			either (attributes) = rest first value [
				foreach itm (attributes) [
					unless any [

      [any-type!] = types: select (arg-spec) to-word join itm '-value
						find types type?/word value/:itm
					][return false]
				]
				true
			][
				false
			]
		] 
]

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

Tomc: "you may be better off  with :here skip to gaurentee progress"


Put the skip after the paren and I may agree with you there. Of course 
you would skip the number of chars in the replacement text then.

Here's what I have right now:

		markup-chars: charset "*_@"
		non-markup: complement markup-chars
		inline-tags: [
			"*" "strong"
			"_" "em"
			"@" "code"
		]

		markup-rule: [
			any non-markup
			any [
				[ a: "*" b: to "*" c: skip d: |
				  a: "_" b: to "_" c: skip d: | 
				  a: "@" b: to "@" c: skip d: ] :a (
					change/part a rejoin [ 
						"<" select inline-tags copy/part a b ">"
						copy/part b c 
						"</" select inline-tags copy/part a b ">"
					] d
				) any non-markup
			]
			to end
		]
		parse text markup-rule

If you want to guarantee progress with my and your examples (and 
better support multichar markup tags) change the last
  any non-markup
to
  any non-markup | skip
and that would do it.

okay, here's a slightly tweaked version that uses a multichar markup 
tag:

        markup-chars: charset "[*_-:---]"
        non-markup: complement markup-chars
        inline-tags: [
            "*" "strong"
            "_" "em"
            "@" "code"
            "--" "small"
        ]

        markup-rule: [
            any non-markup
            any [
                [ a: "*" b: to "*" c: skip d: |
                  a: "_" b: to "_" c: skip d: | 
                  a: "@" b: to "@" c: skip d: |
                  a: "--" b: to "--" c: skip skip d: ] :a (
                    change/part a rejoin [ 
                        "<" select inline-tags copy/part a b ">"
                        copy/part b c 
                        "</" select inline-tags copy/part a b ">"
                    ] d
                ) any non-markup | skip
            ]
            to end
        ]
        parse/all text markup-rule

split-text: func [ txt n 
	/local frag result bl
][
    bl: copy []
    result: copy ""

    frag-rule: compose/deep [ copy frag (n) skip (print frag append result 
    frag) copy frag to #" " (if not none? frag [ print frag append result 
    frag ]
append bl copy result clear result) ]
    parse/all txt [ some frag-rule ]
    bl
]

compose/deep [ copy frag (n) skip (print frag append result frag) 
copy frag to #" " (if not none? frag [ print frag append result frag 
]
append bl copy result clear result) ]


looks suspicious to me - don't forget that your parens are there 
for two different purposes. My guess is, that you don't need compose?

copy frag n skip should be perfectly OK

[ copy frag n skip | copy frag to end ]

or copy frag [n skip | to end]

split-text: func [txt [string!] n [integer!]
    /local frag fraglet bl frag-rule bs ws
][  ws: charset [#" " #"^-" #"^/"]
    bs: complement ws
    bl: copy []
    frag-rule: [
        any ws
        copy frag [n skip] (print frag)
        opt[copy fraglet some bs  (print fraglet)]
        (insert tail bl join frag fraglet)
    ]
    parse/all txt [some frag-rule]
    bl
]

how about this one?: copy frag [n skip | to end] (frag: any [frag 
""])

split-text: func [txt [string!] n [integer!]
    /local frag fraglet bl frag-rule bs ws
][  ws: charset [#" " #"^-" #"^/"]
    bs: complement ws
    bl: copy []
    frag-rule: [
        any ws
        [copy frag [n skip]
         [opt[copy fraglet some bs  (insert tail frag fraglet)]
        ]
       |[copy frag to end]
       (insert tail bl frag)
    ]
    parse/all txt [some frag-rule]
    bl
]

>> n: 5 parse "" [copy frag [n skip | to end] (frag: any [frag ""])]
== true
>> frag
== ""

split-text: func [
	txt n 
	/local frag result bl stop-rule
][
    bl: copy []
    result: copy ""
    stop-rule: none
    end-rule: [to end (stop-rule: [end skip])]
    frag-rule: [

  copy frag [n skip | end-rule] (frag: any [frag ""] print frag append 
  result frag)

  copy frag [to #" " | end-rule] (frag: any [frag ""] print frag append 
  result frag append bl copy result clear result)]
    parse/all txt [some [frag-rule stop-rule]]
    bl
]

split-text: func [txt [string!] n [integer!]
    /local frag fraglet bl frag-rule bs ws
][  ws: charset [#" " #"^-" #"^/"]
    bs: complement ws
    bl: copy []
    frag-rule: [
        any ws
        copy frag [
            [1 n skip 
                opt[copy fraglet some bs]
            ]
            | to end skip
        ]
        (all [fraglet join frag fraglet]
         insert tail bl frag 
         print frag
        )
    ]
    parse/all txt [some frag-rule]
    bl
]

it was the copy frag 1 n skip

Gabriele: the [copy frag [n skip | to end] (insert tail result any 
[frag""])] looks too complicated for the PARSE setting words to NONE 
justification, I would at least prefer to add it to the ticket as 
an example.

i use 
 "a" any[ "b" | "c" | skip ] to end
Even slower and less elegantly, but works.

OK, thanks. Didn't know this. But this solution will work for me 
as well. In a sense this is interesting, as skip isn't a real token, 
but a command - but it's treated as a token. :-)

Maybe i used this?
 parse s ["a" some[ "be" break | "ce" break | skip] p: to end]

if nothing is found, it skips to the end. returns true, but if you 
require something after it,
that fails (because already at end).

or "end skip". with break the parsed part counts as success. with 
end skip it counts as failure and backtracks.

the general way:

 rule: [  ( dummy-rule: [] if not ok? [ dummy-rule: [end skip] ) dummy-rule 
 ]

I didn't do a really useful example, just one to demonstrate the 
current way of faking the behavior.
Example:  [if (test) | ...]
Fix:  [(unless test [dummy: [end skip]]) dummy | ...]

See, this is why I wanted that if clause. It's so easy to mess up 
the workaround.
Fix:  [(dummy: unless test [[end skip]]) dummy | ...]

should work like thru.  "any non-caret" is like "to caret", then 
skipping it is like "thru caret". without caret it would go to end, 
and then the final skip fail.

pipe: charset "|" 
nonpipe: complement charset "|"
caret: charset "^^"
non-caret: complement caret
digits: charset [ #"0" - #"9" ]

labsupplier: 
hl7level: 
datetime:
patient:
labno:
labno2: none


nte-rule: [ "NTE" pipe digits pipe 1 skip pipe copy notes to newline 
(append txt notes) ]
oru-rule: [ "ORU" pipe copy labno some digits pipe ]
datetime-rule: [ copy datetime some digits ] 

msh-rule: [ "MSH" pipe some nonpipe pipe copy labsupplier some nonpipe 
pipe some nonpipe pipe copy hl7level 
	some nonpipe 2 skip datetime-rule 2 skip oru-rule thru newline 
]

msa-rule: [ "MSA" pipe 3 skip copy labno2 some digits thru newline 
]

pid-rule: [ "PID" 2 skip some nonpipe pipe some digits pipe some 
nonpipe pipe copy patient some nonpipe 

 2 pipe copy dob some digits pipe copy gender [ #"F" | #"M" ] thru 
 newline 
]
obr-rule: [ "OBR" pipe 1 digits pipe copy drcode some nonpipe
	pipe some nonpipe pipe copy panelcode some nonpipe
	pipe 1 skip pipe copy bleeddate some digits
	pipe copy reportdate some digits 
	pipe 2 skip pipe 2 skip

 5 pipe copy bleeddate some digits 2 pipe copy requestdr some nonpipe	
	3 pipe copy nzcouncilcode some nonpipe thru newline
]

txt: copy ""
cnt: 1

obx-rule: [ "OBX" pipe copy cntr some digits ( 

  if cnt <> to-integer cntr [ print "halted as out of sequence" halt] 
  cnt: cnt + 1 
	) 
	pipe  
		[
			st-rule | 
			ft-rule 
	]
]



ft-rule: [ "FT" pipe some non-caret any caret copy comm some non-caret 
any caret 3 skip 

 copy comments some nonpipe (repend txt [ comm " " comments newline 
 ]) thru newline ]


st-rule: [ "ST" pipe some non-caret any caret copy testtype some 
non-caret  
	any caret 3 skip copy testresult some nonpipe 
	pipe [ pipe | copy units some nonpipe pipe ]
	copy range some nonpipe thru newline

 ( repend txt [ testtype " " testresult " " units " " range newline 
 ] )
]
	
record-rule: [
	( cnt: 1 txt: copy "" )
	msh-rule
	msa-rule
	pid-rule
	obr-rule
	obx-rule
	[ some obx-rule ]
	nte-rule
]

parse read %hl7data.txt record-rule
print [ labsupplier hl7level datetime patient 
labno labno2 dob gender panelcode bleeddate reportdate 
requestdr nzcouncilcode newline txt
]

hl7msg: make object! [
	msh: []
	msa: []
	pid: []
	obr: []
	obx: []
	nte: []
]

datafile: %hl7data.txt

parse-hl7msg: func [datafile [string!]
	/local segment segbl v
] [
	hl7: make hl7msg []
	trim/head/tail datafile
	append datafile {^/}
	line-rule: [copy segment to "^/" 1 skip (
			segbl: parse/all segment "|"
			either segbl/1 = "OBX" [
				insert/only tail hl7/obx skip segbl 1
			] [
				v: to-word segbl/1
				insert hl7/:v skip segbl 1
			]
		)
	]
	parse/all datafile [ some line-rule ]
	hl7
]

test: parse-hl7msg read datafile

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

Or you can do something like:

fp: open/lines %file.txt
until [
	line: first fp
	if find skip line 115 "Page" [print "new page"]
	tail? fp: next fp
]
close fp

This is a way without copies:
str: "----+-----"

for Count 10 125 10 [change skip str either Count < 100 [8][7] Count 
prin str]

Not sure this is a case for parse......You seem to have four types 
of line:
-- those with "page" in a specific location on the line
-- those with "name" in a specific location on the line
-- those with "member" in a specific location on the line

-- others which are to be ignored .... eg your orginal line 6 "Line 
6       600    Desc 1 text         12/23/03"

What I would do is:
* use read/lines to get a block

* for each line in the block, identify what record type it is by 
the fixed literal .... something like: if "page" = copy/part skip 
line 25 4 [....]

* perhaps use parse to extract the items I need, once I know the 
line type
***

If you just use parse in the way you propose, you run the risk of 
mis-identifying lines when there is a member called "page" or "name"

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

In the meanwhile, ou can do it yourself:

pickz hi b 0
pickz lo b 1
lsl hi 8
add hi lo
skip b 2

Series in rebcode are offset-1 based like normal (except image positions 
in DRAW). Would it be a good idea to make them offset-zero based 
in rebcode? Example: if I wanna read a pixel value at a certain position 
in REBOL, I could write:
image/1
or
first skip image position
(If position was 0x0, I'll get the first pixel.)

If I pick an image in rebcode at offset 0, I get an out of range 
error. It's a tough decision, but what seems most 'correct'?

I get generic add by doing this:
    to-dec a
    to-dec b
    addd a b

You can skip one or both conversions if you can trace the type flow 
and be sure of the data types of the arguments.

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.