World: r4wp

Sometimes things aren't clearer when you reduce them, but sometimes 
it can work well.

Thank you Bo, Ladislav, and Gregg  -- I'll use all your suggestions 
:-)

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

The same note applies to RULER-2

When Carl had me write my first Rebol script, his goal was to see 
if I understood how scripting in Rebol is different than most other 
languages.  One of the helpful things he told me was that if you 
see patterns in your scripts, then you are likely not scripting as 
efficiently as possible.

Bo, that's a great quote.

LOL, I was just posting a rant on FB that can be summed up as "if 
you do it over and over again, make a BLOODY shortcut".

Ladislav,  Excellent notes!!!  For whatever reason, (old coding habits 
I guess) I started with defining the object RULER-1 and then manipulating 
it.  I now see what you are saying about  using the INSERT/DUP.  
As to notes about HEAD, I realize now that I confused INSERT and 
APPEND, (thinking it inserts at tail, when it doesn't.


I welcome any and all comments to help me get out of my paradigm!!

As to notes about HEAD, I realize now that I confused INSERT and 
APPEND

 - APPEND used in a similar way as above would not need HEAD either

Neither INSERT nor APPEND modify the index attribute of their argument 
(the index attribute of series is immutable, in fact)

Having a series with index 1 (the head has this index), neither INSERT 
nor APPEND can change the index of the series. What they do is something 
else - they return a series with a different index.

To illustrate this further, let's consider a trivial example:

    a: 1
    b: 2

    add a b ; == 2


You can examine A and B now and see that the ADD function did not 
change A or B, but it returned 2 (another value). Similarly, INSERT 
does modify the argument series, but not its index, however it returns 
a series with a different index.

Is this clear?

Your example should be "== 3" I guess?

:-)

(best of us can be wrong sometimes. Just to LOL, no pun intended)

>> add: :multiply
>> a: 1
== 1
>> b: 2
== 2
>> add a b
== 2

You can always find a solution :-)

/LAST refinement doesn't return the last match when used with /REVERSE 
refinement. Is that a known issue?

>> FIND/reverse/last tail "aoboco" "o"
== "o"
>> FIND/reverse tail "aoboco" "o"
== "o"

>> FIND "aoboco" "o"
== "oboco"
>> FIND/last "aoboco" "o"
== "o"

Hello, someone needs Sublime Text 2 editor  syntax highlight file, 
see http://rebol.informe.com/forum/rebol-2-f8/sublime-text-2-t59.html
Do you know where he may find it?

find/reverse and find/last are somewhat identical but not from the 
same point of start. So you have to use one XOR the other.

Endo, what result do you expect for

  FIND/reverse/last tail "aoboco" "o"

?

Your example should be 

== 3" I guess?" - actually, I had a: 1 and b: 1 originally, and I 
somehow "managed" to change B to 2 :-(

Gregg: When use /REVERSE refinement it searches backwards from the 
current position. So I expect to find the /last "o" (in the negative 
direction) which is "oboco".
aOboco
 the captial O is the LAST one in backward direction.

I understand that the last "o" is still the right most one. But I 
expected the other one at first glance.

Understood. That would make it redundant with /REVERSE, rather than 
overriding it.

To my understanding "find/last serie value" is the same thing than 
"find/reverse tail serie value".

But it found the first value backward from the position, so "o" is 
correct result.

Which script do you suggest me to use for parsing XML files for R'? 
There are many on rebol.org.

I mainly want XML to object, so I can export data from .xlsx file. 
XML to blocks might work but I may need to work on objects for more 
functionality.

* for R2

If I remember correctly, you can't go 1 to 1 from xml to object. 
You can to block.


I've only used my xml2rebxml.r, which produces a block. You could 
work from there, pull out the elements, you need, and produce an 
object.
http://www.rebol.org/view-script.r?script=xml2rebxml.r

The RebXML format is described here:
http://www.fys.ku.dk/~niclasen/rebxml/rebxml-spec.html

Thank you Geomol. I saw AltXML from Christopher Ross-Gill, I'll try 
both. Thanks.

Chris: is that normal?
>> load-xml {<si><t xml:space="preserve">test</t></si>}
== [
    <si> [
        <t> [
            #space "preserve"
            %.txt "test"
        ]
    ]
]

Why it puts %.txt ?

Chris is in Peru at present .. don't expect any answers soon.  Unless 
you talk to him on SO chat

for sure, you want stuff to be tag pair aligned so you can easily 
loop through it... though I don't know why he uses the file type 
to  mark tag content. 

probably just to differentiate it from attribute and tags

Endo, that's just his notation for a text node - not meant to imply 
it's a file.

I see, I just confused if it's a bug or not.
>> load-xml {<a>test</a>}  ; == [ <a> "test" ]

>> load-xml {<a b="c">test</a>}   ; == [ <a> [ #b "c" %.txt "test" 
] ]

Why this doesn't work?
>> parse [1] [1] ;== false

while this one works
>> parse [a] ['a] ; == true

parse uses literal numbers for rules definition
you need to use: parse [1][integer! (process-integer-here)]

So, no chance to specify an exact number in a parse rule?

>> parse [1] [1 1 1]
== true
>> parse [1 1] [2 2 1]
== true

darn... never new we could do that!!!!  logical enough... wonder 
why I never tried it.

In R3, youi can also use the QUOTE command:

>> parse [1] [quote 1] 
== true

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]
]

>> parse-int-values "123456" [1 2 3]
== [1 23 456]

Just as an example of how you can work around it with a bit of indirection.

this is on r3
am trying to do a simple 
read http://google.com
and get 

Access error: protocol error: "Redirect to other host - requires 
custom handling."
how do i custom handle?