World: r3wp

I just found something interesting.

I remember Gabriele saying he thought PARSE would convert chars it 
encountered in its rule with strings before using, so these are equivalent:
	parse "a" [#"a"]
	parse "a" ["a"]

(Of course, the first one is a char and not a string, so consumes 
less memory.)

But I was just thinking it might be clearer to use strings instead 
of chars in the parse rule.
Then I discovered you can use issues:
	parse "a" [#a]

and the escape characters is interesting as you only need to type 
one of them in the issue:
	parse "^^" [#^]

Anyway, that's a side-issue.

I would not use it.. I think you chould use char! where you expect 
char!. btw... the script is updated, but would require some test-cases 
(for chunk bordes inside strings/blocks/comments) to make it safe 
for use.

Thankyou very much for this contribution.

It's time for me to sleep. Good night.

Anton, the cost of disk reads dwarfs the cost of LOAD/next. And PARSE 
is much slower at loading REBOL data than LOAD. You might consider 
finding out the max size of the value you are loading, rounded up 
to multiples of 4096 (disk blocks), and just READ/part a bit more 
than that from the disk for each file. Then LOAD/next from the resulting 
string. There is no reason to do speculative reads once you have 
an upper bound on the size you will need to read. In a language like 
REBOL, minimizing disk reads sometimes means minimizing the number 
of calls to READ, not just the amount read.

My script is much more faster.. when I do:

tm: func [count [integer!] code [block!] /local t][t: now/time/precise 
loop count code probe now/time/precise - t]
tm 10 [
	dir: %/F/REBOL\altme\worlds\rebol3\chat\
	foreach file read dir [
		load-first-block dir/:file
	]
]

tm 10 [
	dir: %/F/REBOL\altme\worlds\rebol3\chat\
	foreach file read dir [
		first load/next dir/:file
	]
]

the result is:
0:00:01.047
0:00:06.39

of course with chunk size of 1024

0:00:00.968 for chunk 512

Oldes, did you notice that I wrote READ/part, not READ ?

And loading from the resulting string, not the file?

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.

load-first-block2: func[file /local port buffer result tmp ][
	port: open/direct file
	buffer: copy ""
	result: none
	chunks: 0
	until [
		chunks: chunks + 1
		if any [
			chunks > 10
			none? tmp: copy/part port 512
		] [close port return none]
		insert tail buffer tmp
		not error? try [result: first load/next buffer]
	]
	close port
	result
]

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

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.