World: r3wp

It might work for you if you not in need of multi-user (simultaenous 
access)

The next version of TRETBASE which is in work is multi-user and supports 
indexing.

But not finished.

I'm using mysql for the online component but I need a local storage 
method too for offline use

It might work for that.  Can also do the images conversion for you 
in REBOL format which is nice.

That was one of the things that had me thinking of using it.

What I would need is a simple method to sync them

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.

Is there a difference between a "space" and a "tab"? Can you parse 
for tab and not sapce?

I would think you would have to parse/all .. and a space is #" " 
and a tab is #"^-"

or you can use charsets

Parse/all...works
thanks

amacleod, small tip:

help char!

thanks

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?

>> parse "" [any [()]]
(escape)

it's one of the most simple ways how to halt rebol if you don't include 
the parens.

These condition are already fixed in R3

x: "12---dflksdf+++fhkw---sd+++sad"


How can I remove everything to "---" thru "+++" to end up with "12fhkwsad"

parse x [any [to "---" here: thru "+++" there: (remove/part here 
there) :here]]

Notice, after the remove that I have reset the parse index to the 
beginning of the removed part, ready to continue parsing the rest 
of the data.

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

No problem, Louis. You're welcome.

Works great! Many, many thanks.

parse [a] ['a] ;== true

parse ['a] reduce [to-lit-word 'a] ; == false (why?)

forget it. I was confused for a second, but is there a way to parse 
that 'a correctly? The same goes for get-word! and set-word!.

I should clarify: I would like to parse a specific get-word!, lit-word! 
or set-word! as opposed to parsing on the type and then checking 
the value in some kind of action afterwards:


parse ['a 'b 'c] ['a 'b 'c] ;== true (I know this is the wrong parser 
block, but it's something to that effect I would like to see)

If I remember correctly, this was a problem of parse (and may still 
be)...

You may have to use a workaround.

thought so :-)

If you can go with a reduced block, this can work:

parse reduce ['a 'b 'c] ['a 'b 'c]

what if there are set-words in it? I wanted to parse the content 
of an object, which can be a mixture of word types.

Is there any objection to matching type -> checking value other than 
the inconvience?

You could also preprocess the block using an alternative to 'reduce 
--


 parse blk [any [mk: lit-word! (mk: change mk switch mk/1 [...]) :mk 
 | skip]]

In general that restriction of parse is part of an overall pattern 
in REBOL of encouraging you to use lit-words as lit-words rather 
than some other kind of datatype. Lit-words in REBOL are generally 
used to express literal expressions of words, rather than being used 
as a distinct datatype. In general you convert them to words before 
use.

It's usually a bad idea to use lit-words as keywords - they make 
better values. If you are comparing to a particular lit-word value, 
that is using it as a keyword. If any lit-word value would do and 
their meaning is semantic rather than syntactic, that works. In general, 
PARSE is better for determining syntactic stuff - use the DO dialect 
code in the parens for semantic stuff.

Not that I don't want a LIT or LITERAL directive in PARSE that would 
turn off the PARSE-dialect treatment of the next value in the spec.

It would only be for block parsing though.

term: [word! | into term]
parse [a b [c]] [some term]  ;== true
parse [a b [c d]] [some term]  ;== false

I'm a bit confused by that.  I need to parse recursively.

duh... never mind.

Solution:

terms: [some [word! | into terms]]
parse [a b [c d]] terms  ;== true

blk: [aa "test" bb "two"  cc  "#block"]
rules: [some [cc set cc string! ]]
parse blk rules

no go? 

I have a more complicated rule set that chokes on the "#block" string.. 
does it think it's an issue! ?

... rules looks like this rather.. 
rules: [some ['cc set cc string! ]]

Your parser would stop at 'aa, since you never specify it in the 
rule block.

Perhaps something like:

rules: [some [['cc set cc string!] | [word! string!]]

rules: [some [set  ww  word! set ss string! (do reduce [to-set-word 
ww ss]) ]]

>> parse/all {2008-10-30|"This is" NOK|http://www.example.com}"|"
== ["2008-10-30" "This is" " NOK" "http://www.example.com"]

I caught this on the mailing list. Bug?

Yes, this is an old bug.
It does not work, if " is next to your delimiter.
Insert a blank, and it works again.