World: r3wp

But we are in "parse" topic so we were making parse solution.

LOAD parses.

ok.. the precise topic is: Parse (Discussing of PARSE dialect)... 
anyway.. I started as well asking why not to use load/next.

btw.. the second function is not complete as it does not check for 
block but any rebol value.

Btw... what would be best way to get the last block of the file without 
loading complete file?

impossible

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)

Last block... OPEN/seek perhaps, then SKIP ?

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.

So I'm going to persist with PARSE.

Steeve, do you mean to say that it's impossible to get the last block 
without loading the complete file?

what about using something like open/seek at port ((size? file) - 
chunk-size) chunk-size?

http://www.rebol.com/article/0199.html

Getting chunks in reverse, from the end of the file towards the start, 
is not hard. It's the parse rule to go with it that's difficult.
But first I want to figure out the parse rule that goes forward.

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?

http://www.rebol.org/view-script.r?script=telnet-client.r

Thanks for the recommendation.

Apparently the actual scheme is here (bad form on the script submission): 
http://www.reboltech.com/library/scripts/telnet.r

I've used Frank Sievertsens telnet.r script from rebol.org. It works 
well for my needs.

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

Never mind, it is here: http://www.rebol.org/view-script.r?script=telnet.r

I've got it locally, if rebol.org fails.

Thanks all, I'll give those another shot.

And come back here if you need help with the parsing part :)

What would have been the correct place to post?

Networking

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

It's OK. We all use the "I'm New" group on occasion, even when we 
have been here for years :)  Group purism is for redirecting flame 
wars.

I think Expect in REBOL would be very cool. We could call it Rexpect 
('ree-speckt).  :-)

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.

There's even versions of expect that handle GUIs, but that is likely 
out of scope here. Character UIs would be sufficient. It's sor of 
like screen scraping for mainframe interaction.

By the way, I got that chunky-load-first-block parse working the 
other day.

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 ?

because the R3 behavior is correct. you are not parsing spaces in 
the above example.

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!

What version of Rebol are you using?
Seems to work ok for me in R2.
What's the input which fails?

Works for me too.

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!

If you note that load/next is used when values are parsed, you can 
see why values aren't strings. MOLD can be your friend as FORM (and 
PRINT) will hide datatype details from you. e.g.

>> print first [x]
x
>> print first [x:]
x
>> print first ['x]
x
>> print first [:x]
x

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.

I couldn't figure out how to make DO work in Parse.  My answer here 
shows an example that I tried: http://stackoverflow.com/questions/3478589/rebol-parse-problem

R3's PARSE DO operation only works with block parsing, not string 
parsing.

>> parse [2] [do (1 + 1)]
== true

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.

Hrrrm.  I haven't messed with block parsing much, but it breaks any 
obvious intuition that >> parse [[2]] [do [(1 + 1)]] is true and 
>> parse [2] [do [(1 + 1)]] is also true.  :-{

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