AltME groups: search

That's the big question. I didn't get that far yet, as I was fighting 
with Symbian C++ on the phone first - sorry. But I try to find something 
in the docs or on the web now.

Robert - my experience is only that e.g. for Nokia, you need their 
Suite. Symbian communicates via mrouter.exe, which you can download 
separately. Have you ever tried to get various phones connected via 
bluetooth? A nightmare. Bluetooth "simulates" serial connection. 
Symbians are used to initiate connection themselves. So they will 
disconnect PC and try to connect back. But they communicate with 
mroute.exe, which serves as gateway or so ...

Try to look at MobilEdit at http://www.mobiledit.com

Good input. Petr, try to find out what it would need to code such 
an API with a scripting language. Just to get a better picture about 
the problem domain.

I have a contact that makes the UI for new mobiles. I try to get 
some information from him.

I'm curious about how try errors in tuple conversions - For example 
if I do a try [error? error:  to-tuple "abcd"] it doesn't evaluate 
correctly

and with 
error? error: try [to-tuple "abcd"]
?

I would assume that would work - let me try that

Hi Jean .... I have a timer style you could try .....  would just 
need a tweak to add a reset button.

Let me know if you would like to try it and I will email you off=-ine

Hello PhilB,
Yes I would be interested to try it.

We have done this also.  WE did not have this problem though that 
I know of.  Try only replacing the smallest icon to start.

guys - screenshots!!! Screenshots!! I know myself - if I can't find 
tour or screenshot with any product I try to investigate, I somehow 
consciously start to give it a big minus :-)

Pekr: "ML is not primary source of docs ..."  Absolutely true, and 
that's how it should be. But the ML can be a starting point for someone 
trying to research a topic or unearth an obscure snippet of information.....Which 
is why REBOL.org indexes the ML in lots of different ways: to make 
it easy to find stuff hidden in 43 000 messages.

If you haven't already, try playing with the topic index:
http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-topic-index.r

It's work-in-progress so it's incomplete, but it can be the fastest 
way to some primary information.

try to look at http://www.xnview.com- they have something like 300+formats 
to read, 40+ to write. We even did some initial C wrapper with Cyphre 
for it ...

Thanks, Pekr. That looks pretty good. I'll try it out.

Please note that there is a very limited time to make a decision 
here. So if you have any idea / can help in any way, please speak. 
Otherwise, we're probably going to either just implement RIF or try 
to work something from scratch.

I have also suspicion, that some of you guys, e.g. Gabriele (I mean 
it in a friendly non complaining mode :-), don't mind having everything 
in one .exe. Neither do I in fact, View is still small in today's 
terms - but - if we talk small devices - it is not. Go and try to 
download it via GPRS I use with my cell phone - it does not look 
like a small app to upgrade in any way :-)

i usually just tend to avoid recursion when it is not really needed, 
and i try to stay alert when i need it ;)

I'll try Gregg's split function

Hmm, no - I'm wrong.  Try parse/all first though (for to " ")

Sorry, try  [#[datatype! datatype!]  that should restrict the match 
to only datatype values.

1. Hide them from myself :) I don't mind having lots of global variables 
in a small script, but I really don't like it in larger programs. 
To keep things well organized I prefer if variables aren't valid 
in a larger context than necessary, to avoid overwriting, accidental 
use etc. Does context [ ... ] add alot of overhead btw? Maybe I should 
try to use that more often

2. I don't use alot of recursion so far. some [...] usually works 
equally well in my applications. But it's definitely a valid point, 
and I'll try to keep it in mind

I'm just not getting the hang of parsing. I've read tutorials an 
looked at scripts but when I try to adapt it to my work it fails.

Oldes, thanks for your suggestion. It works when I do a simple one 
line rule as you suggested but when I try to use multiple rules it 
fails.

Example of what I'm trying to do:
Example of the text document:

BrianH, eh? read/lines would still try to read the whole document 
wouldn't it ?

Or are you just suggesting that as a way which is then easily modified 
to allow larger than memory documents?

I'll try that Graham. Thanks

Best thing to do is try it out as it really takes very little time 
to setup and try and you will know probably if it is suitable for 
you in about 10 minutes.

A long time ago, I offered to try a lecture.  Don't feel worthy. 
 So I thought I'd throw out a few (mis)understandings and have them 
corrected to build up a level of comfort that I wouldn't be leading 
a group of high potential rebols down a garden path.


So; one of the critical mistakes in PARSE can be remembered as  "so 
many", or a butchery of some [ any [ , so many.

some asks for a truth among alternatives and any say's "yep, got 
zero of the thing I was looking for", but doesn't consume anything. 
 SOME says, great and then asks for a truth.  ANY say "yep, got zero 
of the thing I was looking for", and still doesn't move, ready to 
answer yes to every question SOME can ask.  An infinite PARSE loop.


Aside: to protect against infinite loops always start a fresh PARSE 
block with [()   the "immediate block" of the paren! will allow for 
a keyboard escape, and not the more drastic Ctrl-C.


So, I'd like to ask the audience; what other PARSE command sequences 
can cause infinite loops?


end?  and is it only  "end", "to end" but "thru end" will alleviate 
that one?  end end end end being true?

>> parse "" [some [() end end end]]
(escape)
>> parse "" [some [() thru end end end]]
== false
>> parse "" [some [() to end end end]]
(escape)
>> 


Ok, but thru end is false.  Is there an idiom to avoid looping on 
end, but still being true on the first hit?

Other trip ups?

Anton, thanks. I'll try that now. Sorry to take so long to respond---I've 
been eating.

Just don't try to parse illegal REBOL syntax as if it were legal 
and you'll be fine. You have string parse for non-REBOL strings.

Now that is interesting. LOAD and TO-BLOCK do that. It would be interesting 
to write a set of rules in PARSE that read REBOL syntax and generate 
REBOL data or warnings instead of errors. For your purposes you might 
consider LOAD/NEXT in a loop inside of TRY blocks.

uhmm, well, Steeve, as for me, if my proposal is going to be implemented, 
I don't care if I am credited or not. Because - parser REPs are floating 
here or there for some 8 years maybe :-) As for BrianH and his judgements 
- he might not be better in parse than others, but I would not try 
to upset him - BrianH is our guru here. Along with Gabriele, Cyphre, 
and after loss of Ladislav, he is one of the most skilled rebollers. 
I think that his intention is to help REBOL being better. He might 
be also the one, who will bring JIT or compiler in the future, and 
he understand consequences of what he suggests ...

I am the editor of the PARSE proposals.


It was decided that I perform this role because Carl is focused on 
the GUI work right now and someone qualified had to do it. With Carl 
busy and Ladislav not here, I am the one left who has the most background 
in parsing and the most understanding of what can be done efficiently 
and what can't. When the PARSE REPs of old were discussed, I was 
right there in the conversation and the originator of about half 
of them, mostly based on my experience with other parsers and parser 
generators. Because of this I am well aware of the original motivation 
behind them, and have had many years to think them through. It's 
just head start, really.


I am also the author of the current implementation of COLLECT and 
KEEP, based on Gabriele's original idea, which was a really great 
idea. It is also really limited. Collecting information and building 
data structures out of it is the basic function that programming 
languages do, and something that REBOL is really good at. I am not 
in any way denigrating the importance of building data structures. 
I certainly did not mean to imply that your appreciation of that 
important task was in any way less important.


The role of an editor is not just to collect proposals, but to make 
sure they fit with the overall goal of the project. This sometimes 
means rejecting proposals, or reshaping them. This is not a role 
that I am sorry about - someone has to do it to make our tool better. 
We are not Perl, this is not anything goes, we actually try to make 
the best decisions here. I hate to seem the bad guy sometimes, but 
someone has to do it :(


PARSE is a portion of REBOL that is dedicated to a particular role. 
It recognizes patterns in data, extracts some of the data, and then 
calls out to the DO dialect to do something with the data. It doesn't 
really do anything to the data itself - everything happens in the 
DO dialect code in the parens. It is fairly simple really, and from 
carefully designed simplicity it gets a heck of a lot of power and 
speed. That is its strength.


The thing that a lot of people don't remember when making improvements 
to a dialect like PARSE is that PARSE is only one part of REBOL. 
If something doesn't go into PARSE, it can go into another part of 
REBOL. We have to consider the language as a whole when we are doing 
things like this.

Here is the overall rationale for the PARSE dialect proposals:

- All new features need to be simple to explain and use, and fast 
at runtime.
- A good feature would be one of these:

  - An extremely powerful enhancement of PARSE's language recognition.

  - A fix to a design flaw in an existing feature, or a compatibility 
  fix.

  - A serious improvement to a sufficiently common use case, or common 
  error.


The reason I didn't want to put COLLECT and KEEP into PARSE is because 
it is a small part of a much bigger problem that really needs a lot 
of flexibility. Different structure collection and building situations 
require different behavior. It just so happens that the DO dialect 
is much better suited to solving this particular problem than the 
PARSE dialect is. Remember, PARSE is a native dialect, and as such 
is rather fixed.


There are some PARSE proposals that make parse actually do something 
with the data itself: CHANGE, INSERT and REMOVE. We were very careful 
when we designed those proposals. In particular, we wanted to provide 
the bare minimum that would be necessary to handle some very common 
idioms that are usually done wrong, even by the best PARSE programmers. 
Sometimes we add stuff into REBOL that is just there to solve a commonly 
messed up problem, so that a well debugged solution would be there 
for people to choose instead of trying to solve it again themselves, 
badly. (This is why the MOVE function got added to R3 and 2.7.6, 
btw.) Even with that justification those features might not make 
it into PARSE because they change the role of PARSE from recognition 
to modification. I have high hopes, though.


Another proposal that might not make it into PARSE is RETURN. RETURN 
is another ease-of-use addition. In particular, the thing it makes 
easy is stopping the parse in the middle to return some recognized 
information. However, it changes the return characteristics of PARSE 
in ways that may have unpredictable results, and may not have enough 
benefit. The proposal that has a better chance of making it is BREAK/return, 
though I'd like to see both (we can hope, right?).


Most of the REPs from Gabriele's doc have been covered. Most of them 
have been changed because we have had time in the last several years 
to give them some thought; the only unchanged ones are NOT and FAIL, 
so far. Some have been rejected because they just weren't going to 
work at all (8 and 12). THROW and DO are still under discussion - 
the proposals won't work as is, but the ideas behind them have merit. 
The rest have been debated and changed into good proposals. Note 
that the DO proposal would be rejected outright for R2, but R3's 
changes to word binding make it possible to make it safe (as figured 
out during a conversation with Anton this evening).


There are other features that are not really changes to the PARSE 
dialect, and so are out of scope for these proposals. That doesn't 
mean that they won't be implemented, just that they are a separate 
subject. That includes delimiter parsing (sorry, Petr), tracing (sorry, 
Henrik), REBOL language syntax (sorry, Graham), and port parsing 
(sorry, Steeve, Anton, Doc, Tomc, et al). If it makes you feel better, 
while discussing the subject with Anton here I figured out a way 
to do port parsing with the R3 port model (it wouldn't work with 
the R2 port model). I will bring these all up with Carl when it comes 
to that.


I hope that this makes the situation and my position on the subject 
clearer. I'm sorry for any misunderstandings that arose during this 
process.

All this parse stuff is over my head .. I try to avoid headaches. 
 Let the experts work it out I say.

ok i try again a new proposal:
ALL [rule1 | rule2 | rule3] 

each rule must be fullfiled one time but in any order (combinatory).

it's equal to [[rule1 rule2 rule3] | [rule1 rule2 ruel3] | [rule2 
rule1 rule3] etc...]

we can try to ask Carl

Try to play with this: http://oldes.multimedia.cz/rebol/expr-test.r

example: 


parse/all s [some ["12345" here: (print "*" here: tail here) :here 
skip]]


basically, in the paren, you assing the tail of the data being parsed, 
and force parse to move to it, then try going beyond....  the skip 
makes it return false, otherwise it returns true.

so I'll try to cook up an example of how it would be used, and the 
effect it would have... then you can tell me if I'm nuts  ;-)

I'll try to explain complement.  I like to think of a charset being 
a list of valid chars that can be tested for.  However, say you need 
all characters of the alphabet minus a few.  Instead of defining 
multiple ranges of characters as in charset "A-FH-K N-T V-Wa-z0-9" 
which effectively skips the chars G L & U, you could simply state 
complement[GLU], which would exclude these three characters from 
the charset but include all others.

Try http://en.wikipedia.org/wiki/Complement_(set_theory)

hm.. just a sec so I try few things

maybe your solution for A | B would work.. I will try

I will try to think of one

It means, basically:
	SOME: Do this 1 or more times, until fail or end is reached:

  [Try "b", if that fails, try "c". If that fails, try "a"]     <--- 
  Given "a" "b" "c", this rule always succeeds.

Thank you, I'll try Pekr solution. I don't need the "<" and ">" characters.
However, where I can found some good parse documentation?

Pavel, try:

mold/all none

Shadwolf - but that is your bug ;-) Simply put, you try to mix parse-like 
behaviour with how 'any behaves. 'any and 'all are just functions, 
so in the case of 'any it returns any true condition match, so any 
["!" ";"] always returns "!", because it is evaluated as 'true.

Pekr, try to run your 2) and 3) in trace mode, you'll see that there's 
no bug, parse rules evaluation looks consistent to me.

My...

The problen in the method i proposed has nothing to do with the line 
by line approach.

Can't you figure that ? It's only because i try do recognise headers 
whitout knowing them.


I can rewrite your solution without using your line by line approach 
in 5 minutes (you didn't do yours in 30 secs btw).
It will be smaller and faster than yours.
But i don't see the interest, i thougth anyone could figure that.

What info do you need, the path or what comes after it? If the data 
after it is only a limited set of possible answers, you can try to 
skip to those in turn.

the more i try to understand parse the less i understand it

i want to try to make a tutorial about parse but my knowledge of 
it is poor 

 so as we have a wiki we could start a project to write a documentation 
  with the goal to make people understand what is the interrest of 
 parse

One of the best ways to learn is to try to figure out enough to teach 
others :)

in the block rule i will explain the big lines and then i will try 
to apply those consepts to build a simple dialect that i will comment 
.

Gregg well ... i'm not against contributing but I think one of the 
good way is for lower ranked programmer to express their problems 
and try to construct a doc helped by gurus to answers their ask then 
if it's readable and understandable by me I assum anyone could understand 
it 

My point is once people end rading the doc they will say "yeah i 
understoud what it's all about so now lets play with parse :P" if 
that only goal can be achieve I think a big step will be done.

Hi All,  I'm new to PARSE, so I've come here to learn a little more. 
 I'm working on and off on a little testing project of my own for 
R3.

My goal is to navigate through some website(s), capture Rebol code, 
and the expeceted responses such as this page: 
http://rebol.com/r3/docs/functions/try.html

I'd like to capture the text inside a block like this:
[ "cmd" {if error? try [1 + "x"] [print "Did not work."]}
rsp
   {Did not work.} 
cmd
  {if error? try [load "$10,20,30"] [print "No good"]}
rsp
  {No good}]


Can anyone point me to some parse example code which can "tear apart" 
an HTTP page based on text and the type of text?

I realize I may be biting off a bit more than I can chew, but I'd 
still like to give it a try.
Thanks in advance.

You can just set your block that you want to parse to a word.  Such 
as:

blk: [ "cmd" {if error? try [1 + "x"] [print "Did not work."]}
rsp
   {Did not work.} 
cmd
  {if error? try [load "$10,20,30"] [print "No good"]}
rsp
  {No good}]

; and then do this:

>> parse blk [some [set s string! (print s)]]

Hi Paul,  I may have mis-stated what I'm after.  You see the site 
 http://rebol.com/r3/docs/functions/try.htmlhas displayable rebol 
code and responses within the html.  If you captured the html code 
you would find something like this:
<html>
<head>
...(additional html code and text)...

<title>REBOL 3   Functions: try</title>TRY returns an error value 
if an error happened,
otherwise it returns the normal result of the block.</p>

<pre>if error? try [1 + "x"] [print "Did not work."]             
                    <-- in this e.g. the tag <pre> will preceed the 
rebol command until the next tag

<span class="eval">Did not work.</span></pre>                    
      <-- the tag <span class="eval">  will preceed the response 

<pre>if error? try [load "$10,20,30"] [print "No good"]          
          <-- this is the next rebol command

<span class="eval">No good</span></pre>                          
       <-- this is the next response
<h2 id="section-3">Related</h2>


I want to be able to interrogate the html code, parse it and capture 
the rebol commands and responses (if any), then put that into your 
above block example.

I have this code which does this:

cmd-txt: "unasg"  cmd-term: "<"

pre-txt: "unasg"  pre-bgn:  "<pre>"               pre-end: "</pre>"

rsp-txt: "unasg"  rsp-bgn:  {<span class="eval">} rsp-end: {</span>}
site-url:	http://rebol.com/r3/docs/functions/try.html

page-txt: to-string read site-url
probe parse page-txt [thru pre-bgn copy pre-txt to pre-end]
probe parse pre-txt  [copy cmd-txt to cmd-term]
probe parse pre-txt  [thru rsp-bgn copy rsp-txt to rsp-end]

print [{"cmd"} "{" cmd-txt "}"]
print [{"rsp"} "{" rsp-txt "}"]

will yield this:
cmd

 { if error? try [1 + "x"] [print "Did not work."]          <-- this 
 is close to what I want to do
}
rsp
 { Did not work. }


This is close to what I want, but it is not foolproof.  For example, 
I would like to capture all displayable text that is separated from 
any html tags.  In my code example, if a displayable greater than 
symbol  < was displayed, then the parse would stop prematurely.


I am guessing someone has already created some code to "pull apart" 
a html web page, separating displayable text from invisible markup 
code.

more to what Graham is saying is, try...
>> load/markup http://rebol.com/r3/docs/functions/try.html


you will be returned a block of strings and tags, which you could 
use the tag? word to test if each element is a tag or not to seperate 
HTML from regular Strings.

which would return...
Cmd:  if error? try [1 + "x"] [print "Did not work."]
RSP:  Did not work.
== true

which would return...
Cmd:  {if error? try [1 + "x"] [print "Did not work."]
} RSP:  "Did not work."

with the result...
Cmd:  {if error? try [1 + "x"] [print "Did not work."]
}
RSP:  "Did not work."

Brian, try it with INSERT if you want, it's the same useless thing.

>> parse a: "123" [STAY "456" insert "0"] a
== "0123"

Exactly the same thing that:

>> parse a: "123" [insert "0"] a
== "0123"

i give it a try

what do I mean? the "full"

    a: [thru b]

can be defined as a "shorcut" for

    a: [b | skip a]


you can try, that this works for any rule B as far as you don't need 
to use too deep a recursion. As opposed to that, the THRU keyword 
does not accept any rule B, as documented in Carl''s blog

try without the '

i guess not, but i will try

will try ...

why do you repeat it? I try to point out, that it might share internal 
representation, and that might be buggy?

Ladislav - in comment to ticket #1248, you write:


According to the documentation, that can be found in http://www.rebol.net/wiki/Parse_Project

parse "b" [not #"a"]


yields FALSE correctly. If you want to obtain TRUE, you can try e.g.:

parse "b" [not #"a" to end] 


My question is - what it the advantage to actually not advance the 
input on the rule match? It does not look natural and I would expect 
it to match the rule and hence move past it:

>> parse "b" [not #"a" ??]
end!: "b"
== false

... as can be seen, it does not advance ...

I am not sure why "to end" attempted several times does not fail? 
Simply put - if you put any rule, it consumes the input, so I would 
expect, that once at the end of th input = the rule was matches, 
second call of "to end" should fail, no? It does not correspond to 
"to "abc"", which called consecutively would try to find ANOTHER 
match for "abc", not just the same. I don't see a reason, why "to 
end" should have an exception. It should imo definitely cause termination.

well, build it and I will try it  ;-)

if you just try to use it, your parsing may crash. So, it's doing 
nothing but it's here.

Hi! I'm trying to use REBOL's parse to make a simple calculator dialect. 
However, I'm having trouble with escaping entities (I think)...  
Here's my first try (that worked):

from Advocacy --> Graham [ to "A" | to "B" ] won't work as I want 
.. I will try to find a concrete example

to go to the closest one .. means it has to try all the rules??

The pattern is known ... the scentence starts with this is and can 
end with . or ! but they can come in any order .. if you try to parse 
with "." first you will get 
---- ops some errors upthere  .. just a sec

And Janko... if you don't use charsets at all, I think you should 
give it a try. It's not so difficult. I think that if I can write 
parser to colorize PHP code, than you can parse everything.

I'll try that, its a good variant, even better since then we clearly 
identify the 3 different parse constructs separately.

my take on "speed" is as follows - ppl sometimes object, that you 
use "interpreter". And my answer is - why should I care? The thing 
is either fast enough for me, or it is not fast enough for me. If 
you will try to edit video using REBOL level pixel manipulation, 
you surely will not be happy. But - if your app behaves real-time 
or generally time results are acceptable for you - why to worry at 
all?

try this way, with one replace  change may be more efficent , with 
2 replaces bith would need to be in the sccond half of the file , 
with three in the last third ,with 4 the last quarter ...so although 
there may exist pathological cases where it is more efficent it is 
best not to cater to them.  there  may also be an argument  for not 
allocating twice as much memory but iby the time your file is that 
large you are already running into problems (in r2 at least)

and the GC doesn't kick in too quick or it would be really slow  
(just try recycle/torture to see ;-)


so when you're doing serious work it REALLY grows... although it 
stabilizes


for example although stats often show 10MB... my OS tells me that 
its actually using 24 MB.  that will never shrink back down.

So #" " should do. I will try it. Thank you.

Ok, continuing the discussion from "Performance" group, I'd like 
to ask for some help with parsing rebol format files.

Basically, I'd like to be able to extract a block near the beginning 
or end of a file, while minimizing disk access.

The files to be parsed could be large, so I don't want to load the 
entire contents, but chunks at a time.

So my parse rule should be able to detect when the input has been 
exhausted and ask for another chunk.

(When extracting a block near the end of a file, I'll have to parse 
in reverse, but I'll try to implement that later.)

Which is why, in that algorithm, I had to iteratively: load a chunk, 
append it and try LOAD/NEXT until it succeeded.
Which gives the algorithm O(n^2) performance.

try this: http://box.lebeda.ws/~hmm/rebol/load-first-block.r

but it's not well tested. You can make the chunk size better. It's 
just 200 bytes just to not find the block easily in the first one.

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
]

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.

thank you i will test it and try to understand too ;-)

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 will try it on the server tomorrow morning (it is a windows one 
;-) ) i will keep you informed

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.

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.

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.

so, Oldes, you should try this, which should be the exact equivalent 
of your rule, except for the fact, that it does not call Parse recursively:

some [
    thru {<h2><a} thru ">" copy name to {<}
    ; copy the DOC
    copy doc to {^/ </div>}
	; remember the DOC-END
	doc-end:
	; switch to DOC parsing
	: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])
    ]
    ; switch to original input
    :doc-end
]