AltME groups: search

If you are reading from a hard drive there is no point to using a 
chunk size of less than 4096. For floppies, 512 will do.

is faster... a little bit... 0:00:00.859

Your solution is similar to what I suggested, but is missing a couple 
speedups:

- Getting an estimate of how many characters the value would take 
on the high end, and using that as the initial read part.

- Chunk value reflecting hard disk sector value (the OS may load 
in 4096 byte blocks)

BrianH, finding out the size that is sure to encompass the desired 
block in all my input files requires prescanning the entirety of 
all of the files at least once. That's a good optimization for my 
specific case, but I want to make the function general enough that 
it can be used in other situations where the data may not be so consistent, 
and the desired block may not be always near the beginning or end.

I'm using REBOL to control a test by using the Parse dialect to check 
information returned from the test environment. From other looking 
around, it seems that the best approach would be to implement a Telnet 
scheme to handle the input/response give and take with the test environment, 
but I can't find an implementation I've been able to tweak. So.....my 
question is, has anyone had success with loading a Telnet client 
as a dll/shared library and getting Telnet functionality that way?

Check rebol.org - I recall the existence of a telnet scheme. But 
isn't telnet mostly just unadorned TCP?

Not anymore, as it references a script from a site that doesn't exist 
anymore.

Thanks. I posted here because it was a Tcl/Expect-like capability 
someone might have implemented already.

sort of like an assert mixed in with a default  ?

Expect is a TCL thing which handles interaction with external programs 
through their human-oriented UIs.

Why would the R3 error with   parse "a b c" ["a" "b" "c"]    as compared 
to 2.7.7 not be a severe bug in CodeCure ?

Should the docs say that a block! rule implies /all?

Hi! Quick question about parsing REBOL code itself... I'm putting 
together an entry for a contest which is line-constrained (no more 
than 250 SLOC), so I want to crush my code down as much as possible 
while still having something that actually looks like code (I know 
about using the compression, but I want something that looks like 
a program).


I'm starting with Carl's REBOL parser from the cookbook, but it seems 
to skip the colons for initializers ("x: x + 1" -> [x x + 1]). Here's 
my current hack of his parser:

tokens: copy []
parse read %contest-entry.r blk-rule: [
    some [
        str:
        newline |

        #";" [thru newline | to end] new: (probe copy/part str new) |
        [#"[" | #"("] (append tokens str/1) blk-rule |
        [#"]" | #")"] (append tokens str/1) break |

        skip (set [value new] load/next str  append tokens :value) :new
    ]
]


Any ideas why it might be skipping the vital ":" character? Thanks 
very much!

Hi! Thanks for taking a look at the code. 


I went over it again, it seems that part of the problem was in the 
fact that the parsed objects weren't transliterated into strings 
as I had expected. I.e. if you look at the output of the code snippet 
above, it seems OK, but examination of the types of the data in the 
tokens array turn up things that don't convert to strings too well 
without help. I've puzzled over Carl's pretty printer, and I _think_ 
I understand why now... 


Either way, I was able to modify it to give me the kind of output 
I wanted. To repay you for your kind attention, I will post my code 
here, but in crushed form, so it doesn't take up too much space... 
; - )


REBOL [ Title: "REBOL Compressor" ] emit-space: func [ pos ] [ append 
out pick

[ #" " "" ] found? not any [ find "[(" last out find ")]" first pos 
] ] emit:

func [ from to ] [ emit-space from word: copy/part from to long: 
( length? out )

+ length? word if 80 < long [ append lines out out: copy "" ] append 
out
copy/part from to ] lines: copy [ ] clean-script: func [
Returns new script text with standard spacing.
 script "Original Script text"

/local str new ] [ out: append clear copy script newline parse script 
blk-rule:

[ some [ str: some [ newline ] ( ) | #";" [ thru newline | to end 
] new: ( ) | [

#"[" | #"(" ] ( emit str 1 ) blk-rule | [ #"]" | #")" ] ( emit str 
1 ) break |

skip ( set [ value new ] load/next str emit str new ) :new ] ] append 
lines out

remove lines/1 print [ length? lines "lines." ] lines ] write/lines 
%crushed.r
clean-script read %c.r print read %crushed.r

Thanks!

which is why its a good habit to use use probe instead of print in 
most cases where you trace data

JoshF, if this script stands alone then I would make these changes:

- Add as locals to EMIT: WORD and LONG.

- Add to CLEAN-SCRIPT's locals: LINES, OUT, EMIT-SPACE, EMIT, BLK-RULE, 
VALUE
- Move into CLEAN-SCRIPT's body:
	1	lines: copy []
	2	The EMIT-SPACE function
	3	The EMIT function
- Change this line:
	out: append clear copy script newline 
to:
	out: copy ""

(There's no point copying the string SCRIPT when the next thing you 
do is CLEAR it.)
- Remove this line:
	remove lines/1

(There seems no point in initializing OUT with a single newline char 
if it is only to be removed ultimately.)


After, that, you should have only one word, CLEAN-SCRIPT, defined 
globally, referring to a function with no side-effects.

Given your example, you wouldn't want to use DO anyhow since you 
would be creating a charset in a loop, creating a new charset for 
each iteration. It is better to create it once ahead of time.

Is there a foundational reason for DO not being available for string 
parsing, or is it just not implemented?

you're using a block parse rule to parse a string .. so we switched 
to using a data block to parse

I think he meant to ask "and what if RULE is created dynamically 
(ie. loaded from a file) and thus its words are global, and are not 
 (or cannot be) created by functions?"

Nicolas, I refer to your first example.

The error is that FUNC binds the words in its body block to its context, 
but this binding does not extend to reaching inside the block referred 
to by the RULE word.

This error might have arisen because of a small typo, parsing "text", 
not "test", which RULE matches.

Fork, I didn't know about the paren-in-a-block form of the DO parameter. 
That is weird. I can't figure out why that form would be supported 
- it wasn't in the proposal.

Is there a foundational reason for DO not being available for string 
parsing, or is it just not implemented?

There are a lot of things that you can do in block parsing that you 
can't in string parsing. In this case, the result of DO is compared 
directly as a REBOL value. Strings don't directly contain REBOL values 
the way that blocks do. Even if you tried to limit the result types 
of the expression and trigger an error if they don't match, what 
you are left with isn't useful enough to justify adding it, imo. 
For instance, in your example it was a bad idea to use DO. We'll 
see though.

Micha, there was a direct solution proposed for this in the parse 
proposals, specifically to deal with local variables in recursive 
parse rules. However, it turns out that PARSE isn't really recursive: 
It fakes it. So there was no way to support this feature in a parse 
directive. The best way to do the local variables is to put the PARSE 
call and the rules in a function, and if you have to use recursive 
rules, recursively call that function in an IF (...) operation. It 
really works well, in a roundabout sort of way.

micha, you can also just push and pop values in a block you use like 
a stack.  you push before setting to a variable, you pop after the 
rule.

you just have to make sure to only push/pop once a complete rule 
is matched.  meaning you handle that in a paren at the END of the 
rule.

there are a few example floating around, you should find one if you 
google it.

Remember that Micha's English isn't good. I don't think he can understand 
what you guys are saying without a lot of effort in translation. 
It might be better to try to make your points in code.

The best way to do the local variables is to put the PARSE call and 
the rules in a function, and if you have to use recursive rules, 
recursively call that function in an IF (...) operation. It really 
works well, in a roundabout sort of way.
 - this is too much of a roundabout for most cases, I have to add

I guess, that it is the time to propose a reasonable and efficient 
method

I defined a USE-RULE function yielding a rule with local variables. 
Now I wonder where to publish it.

REBOL.org, or perhaps your own site for now? Or as a wiki page linked 
from PARSE docs?

Thanks Ladislav. 

What do 'fni and 'fnii stand for?


I would certainly add a comment or doc string that USE-RULE is recursive/thread 
safe, which is why it's not much simpler.

FNI is just "fixed guts" of the CONTEXT-FN put in the CONTEXT-FN 
function body as a function to not intefere with the context. FNII 
is "dynamic guts" of CONTEXT-FN. By assigning different functions 
to the FNII variable we adjust what the CONTEXT-FN is actually doing.

yes, I wanted to have a FNII variable referring to a function having 
access to the CONTEXT-FNs context without being influenced directly 
by the context

It's another great example of bending REBOL to your will with a great 
deal of control.

set 'use-rule func [

    "Create a recursion and thread-safe parse rule with local variables. 
    R2/R3 compatible."
    words [block!] "Local word(s) to the parse rule"
    rule  [block!] "Parse rule"
] [
    make object! [

        ; Create a new function context. 'Inner-body refers to a function 

        ; with access to CONTEXT-FN's context without being influenced 
        ; directly by the context.
        spec: copy [/local]
        append spec words
        inner-body: func ['word] [inner-inner-body word]
        context-fn: func spec reduce [:inner-body first words]
        

        ; Bind the rule the caller gave us to the new context we just created.
        inner-inner-body: func [word] [bind/copy rule word]
        bound-rule: context-fn
        

        ; Now define the use rule. Because this is an "active" rule,
        ; with state we need to include some state variables used
        ; by the internal PARSE call ('pos and 'success).
        pos: none
        success: none
        inner-inner-body: func [word] [

            ; If the parse of the rule succeeds, we set the parse position

            ; to the where the rule match ended, otherwise we don't change

            ; the parse position and use [end skip] to return a false 
            ; result (for R2 compatibility).
            success: either parse pos [bound-rule pos: to end] [
                [:pos]
            ] [
                [end skip]
            ]
        ]
        set 'rule copy/deep [pos: (context-fn) success]
    ]
    rule
]

set 'use-rule func [

    "Create a recursion and thread-safe parse rule with local variables. 
    R2/R3 compatible."
    words [block!] "Local word(s) to the parse rule"
    rule  [block!] "Parse rule"
] [
    make object! [

        ; Create a new function context. 'Inner-body refers to a function 

        ; with access to CONTEXT-FN's context without being influenced 
        ; directly by the context.
        spec: copy [/local]
        append spec words
        inner-body: func ['word] [inner-inner-body word]
        context-fn: func spec reduce [:inner-body first words]
        

        ; Bind the rule the caller gave us to the new context we just created.
        inner-inner-body: func [word] [bind/copy rule word]
        bound-rule: context-fn
        

        ; Now define the use rule. Because this is an "active" rule,
        ; with state we need to include some state variables used

        ; by the internal PARSE call ('pos and 'success). They are used to 
        ; "transfer" the inner parse state to the "outer parse".
        pos: none
        success: none
        inner-inner-body: func [word] [

            ; If the parse of the rule succeeds, we set the parse position

            ; to the where the rule match ended, otherwise we don't change

            ; the parse position and use [end skip] to return a false 
            ; result (for R2 compatibility).
            success: either parse pos [bound-rule pos: to end] [
                [:pos]
            ] [
                [end skip]
            ]
        ]
        set 'rule copy/deep [pos: (context-fn) success]
    ]
    rule
]

Typos in comments. Just a minute.

set 'use-rule func [

    "Create a recursion and thread-safe parse rule with local variables. 
    R2/R3 compatible."
    words [block!] "Local word(s) to the parse rule"
    rule  [block!] "Parse rule"
] [
    make object! [

        ; Create a new function context. 'Inner-body refers to a function 

        ; with access to CONTEXT-FN's context without being influenced 
        ; directly by the context.
        spec: copy [/local]
        append spec words
        inner-body: func ['word] [inner-inner-body word]
        context-fn: func spec reduce [:inner-body first words]
        

        ; Bind the rule the caller gave us to the new context we just created.
        inner-inner-body: func [word] [bind/copy rule word]
        bound-rule: context-fn
        

        ; Now define the use rule. Because this is an "active" rule,

        ; with state, we need to include some state variables used

        ; by the internal PARSE call ('pos and 'success). They are used to 
        ; "transfer" the inner parse state to the "outer parse".
        pos: none
        success: none
        inner-inner-body: func [word] [

            ; If the parse of the rule succeeds, we set the parse position

            ; to the point where the rule match ended, otherwise we don't 

            ; change the parse position and use [end skip] to return a false 
            ; result (for R2 compatibility).
            success: either parse pos [bound-rule pos: to end] [
                [:pos]
            ] [
                [end skip]
            ]
        ]
        set 'rule copy/deep [pos: (context-fn) success]
    ]
    rule
]

Brian, do you think, that a more "seamless" way how to do the above 
in parse shall be considered, or that this approach is good enough 
as it stands now?

( that was a pun :) )

Regarding the above "three different variable types" - as far as 
the interpreter is concerned, there is no difference between the 
'start 'end and 'copy variables. You used them in a specific way, 
but, later, you can very well use another expression, where you write:

user: copy start to "whatever" etc.


So, you can easily see, that neither the 'start nor the 'user variable 
has any "variable type" you could infer based upon their usage in 
one specific expression.

if you call 'temp a "rebol level variable" in the above example expression, 
how would you call it in the expression below?

(temp: either 1 > 0 [none] [[end skip]]) temp

and hence is probably a regular rebol level word, just used inside 
the parse dialect?

In my opinion, all of the above 'start 'end 'user and 'temp words 
are "regular" REBOL words, while e.g. the 'copy word above is actually 
a parse dialect keyword

To be even more precise;

The 'copy word above is also a "regular" rebol word (it just happens, 
additionally, to be interpreted by PARSE as a keyword in the PARSE 
dialect).

Hi, I rewrote http://www.fm.tul.cz/~ladislav/rebol/evaluate.rto 
contain slightly more comments and to use the USE-RULE function, 
so that it now became a more complex example of its usage.

I hope everyone struggling with local variables in PARSE to find 
this a much more comfortable way.

On the other hand, I expect the %evaluate.r to have a value of its 
own, since it shows how to handle expressions using PARSE, while 
being able to respect different priority/associativity rules sets.

http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse#Local_variables_in_parse_rules
, a new subsection in the REBOL Programming wikibook.

http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse#Local_variables_in_parse_rules

a new section in the REBOL Programming wikibook

hi, i would you to parse a string like this {number: 123456 name: 
abcd message: i like rebol}

a get number, name and msg . is that possible ? and how ?

using 'TO or THRU rules is garanteed to make you life a nightmare 
for arbitrary string parsing, unless its very linear in content.

isn't there a rebol string parser on rebol.org which has the basic 
parsing rules to filter out rebol data?

with a few search I didn't zero-in on it, but I seem to recall seeing 
that before.

otherwise, you can just do a line by line parsing, filtering out 
"keywords" at the start and then loading the data after the ":"

here is an overblown example, with lots of extra prints, so you can 
see it running... it parses your above example text.
--------------------------------
rebol []

data: {Number : 10017
Name       : Disable Message Partner
Application: MXS
Severity   : Info
Type       : Alarm Event
Date-Time  : 20/09/10 12:39:43
GMT        : Mon Sep 20 10:39:43 2010}


; rules

token: ["Number" | "Name" | "Severity" | "Type" | "Date-Time" | "GMT" 
| "Application"]
space: charset " ^-"
spaces: [any space]

content: complement charset "^/" ; all but newlines.
contents: [some content]


; used as variables in the rules
v-token: none
v-content: none
parse/all data [
	some [
		(
			print "^/0>"
		)
		copy v-token token 
		(
			print "1>"
			probe v-token
		)
		spaces ; ignore
		(
			print "2>"
		)
		":" ; end of token
		(
			print "3>"
		)
		spaces ; ignore
		(
			print "4>"
		)
		copy v-content contents ;grab all but newline
		(
			print "5>"
			probe v-content
		)
		[
			; this is important, it ensures that you've got a whole line.
			[some "^/"] | end
		]
		(
			print "6>"
		)
		(
			; do something with your data here
			?? v-token
			?? v-content
		)
	]

]


probe "."

ask "done"

thank you steeve but i need it for a production server  to parse 
log file for nagios

the best is to copy it to a file and run it.

claude... so, did you try to run it as a script?


one thing I would do... since this is a strange error is to retype 
this:

 " ^-"


in your editor... to make sure its not using the wrong ascii character 
on your os... it should not be a problem... but there is something 
weird going on here.

i do a copy/paste http://host4.altme.com/altweb/rebol3/chat210.html
into a file.r  and i execut it . i have got the same error

oh.. he's gone... 

anyone else care to test it?  this is a strange bug...

i will try it on the server tomorrow morning (it is a windows one 
;-) ) i will keep you informed

thanks a lot for your tecahting

That is a distinct possibility.

Ways to identify the problem:

- In AltME, copy Max's entire post which contains the code. You can 
do this with a right click when no text is selected in the message.

  Switch to the rebol console and type:   checksum read clipboard:// 
     and tell us what you get.

- Then you can also type:  print mold read clipboard://    and examine 
what is printed carefully.

- Try to reproduce the problem with shorter code and shorter input. 
Two lines of input should do.

maxim thank a lot it's works perfectly ;-) . yesterday i was tried 
i think

maxim just a last question

the last token is Text but the message is after a newline. how to 
take it with your parse rules

just for your information. i try this to parse error message of a 
swift alliance server

but if you ever have a token without data, the whole parsing will 
fail, cause this rule will effectively (try to)  load the next token 
as data.

obviously we could alter the rules again to account for data-less 
tokens, but this would require a bit different structure.

if you have time to show me how i am ok. but for now i must take 
my children to school and go to work. thanks a lot again

for example..

some [["a" | "aa"]]


here we will never reach "aa" because "a" will be satisfied and the 
alternative will never be attempted ... so instead of matching "aa" 
you'd always match "a" twice .

where as specifying [some ["aa" | "a"]]  will always match "aa" IF 
there is still more than one "a" to parse... and will only ever reach 
"a" if the sequence is an odd number of "a" characters (or just one, 
obviously).


so "aaaa"  will match the "aa" rule twice, and "aaa"  will  match 
 "aa" then "a" .

IMHO, this is the basic premise of all of parse.   once you really 
understand how this applies to a rule which has sub rules... you 
really understand parse.... and then you can start doing more funky 
stuff.

(or, to be more precise, maybe there is a possibility to make a variant 
not binding the rule at all, which would then deserve to be called 
"without the overhead" rather than any of my variants)

But, as you said, one of my motivations was to write it as a mezzanine 
to have some "inspiration"/experiences with it for Carl.

a regex question ...  ([0-9]{4})(-([0-9]{2})(-([0-9]{2})(T([0-9]{2}):([0-9]{2})(:([0-9]{2})(\.([0-9]+))?)?(Z|(([-+])([0-9]{2}):([0-9]{2}))))))

is apparently failing this string : 2010-10-18T07:06:25.00Z

What tool can I use to check this string against this regex ?

Regexlib has a different ISO-8601 date matching regex:
    http://regexlib.com/REDetails.aspx?regexp_id=2092

And the ability to enter any regex and target strings to test what 
happens:
    http://regexlib.com/RETester.aspx?

does R3 solve this? if not, maybe that would be a good problem to 
solve.

Henrik, with a parse rule ?

Graham, try http://gskinner.com/RegExrfor working out regexes. It 
has a really nice UI where you can hover over the components of the 
regex and see exactly what they do.

Question on StackOverflow.....there must be a better answer than 
mine, and I'd suspect it involves PARSE (better answers usually do:)

    http://stackoverflow.com/questions/4093714/is-there-finer-granularity-than-load-next-for-reading-structured-data

Anyone got a parse rule that strips out everything between tags in 
an "xml" document

How to use the new INTO parse keyword? Could it be used to avoid 
the temp parse like in this (very simplified example)?

  parse "<a>123</a>" [thru "<a>" copy tmp to "</a>" (probe tmp  probe 
  parse tmp ["123"]) to end]

Note that I know that in this example it's easy to use just one parse 
and avoid the temp.

You can take advantage of using it when parsing a block and needing 
to parse a subblock (of any-block! type) or a substring

can you give me a simple example, please?

>> parse [a b "123" c] [2 word! into [3 skip] word!]
== true

>> parse [a b c/d/e] [2 word! into [3 word!]]
== true

The substring property is just a recent addition

That is normally a "job" for a subrule

I know, but that would require complex rules, I'm lazy parser:) Btw.. 
my real example looks like:
    some [
        thru {<h2><a} thru ">" copy name to {<}
        copy doc to {^/ </div>} (
            parse doc [
                thru {<pre class="code">} copy code to {</pre} (
                    probe name
                    probe code
                )
                any [
                    thru {<h5>} copy arg to {<}
                    thru {<ol><p>} copy arg-desc to {</p></ol>}

                    ( printf ["  * " 10 " - "] reduce [arg arg-desc] )
                ]
            ]
        )
    ]

Never mind, I can live with current way anyway.. I was just wondering 
if the INTO is not intended for such a cases. Now I know it isn't.

For comparison, a similar rule can be written as follows:

some [
	thru {<h2><a} thru ">" copy name to {<}
	copy doc any [
		and {^/ </div>} break
		| thru {<pre class="code">} copy code to {</pre} (
	          	probe name
	      		probe code
	       	)
			any [
	            thru {<h5>} copy arg to {<}
	            thru {<ol><p>} copy arg-desc to {</p></ol>}
	            (printf ["  * " 10 " - "] reduce [arg arg-desc])
	  		]
  		| skip
	]
]

Aha, sorry, that is not similar enough :-( To be similar, it should 
look as follows, I guess:

some [
    thru {<h2><a} thru ">" copy name to {<}
    copy doc any [
        thru {<pre class="code">} copy code to {</pre} (
            probe name
            probe code
        )
        any [
            thru {<h5>} copy arg to {<}
            thru {<ol><p>} copy arg-desc to {</p></ol>}
            (printf ["  * " 10 " - "] reduce [arg arg-desc])
        ]
  		to {^/ </div>}
	]
]

Still not cigar, third time:

some [
    thru {<h2><a} thru ">" copy name to {<}
    copy doc [
        thru {<pre class="code">} copy code to {</pre} (
            probe name
            probe code
        )
        any [
            thru {<h5>} copy arg to {<}
            thru {<ol><p>} copy arg-desc to {</p></ol>}
            (printf ["  * " 10 " - "] reduce [arg arg-desc])
        ]
  		to {^/ </div>}
	]
]

That's not correct.. there is a reason for the temp parse and that's 
here because thru "<h5" would skip out of the div.

believe me I have.. :) the script is already ready.. I was just thinking 
if there is some special parse keyword, like INTO, so I could do 
it without the second parse next time, that's all. I use such a lazy 
parsing very often.