AltME groups: search

I am wondering if there is a better or simpler way to get the index 
when using FIND? and the value is not found, my attempt seems more 
complex that I would have expected from Rebol, so I suspect there 
is a method or function I have not yet discovered.  :-)   Thanks.
a: find {abd} "e"
either none? a [i: 0][i: index? a]

Because the argument to index? is supposed to be a series and 'none 
is not a series.

One can say that FIND limits its input to series! to eliminate errors 
as early as possible. Imagine if FIND accepted NONE and we had some 
intricate series of FINDs on a single block 'a:

find find find/reverse find a 'e string! 'f integer!
== none


If 'a is a dynamic block (not known when you write the code) where 
is the error?


It's not a great example, but it raises the question of how forgiving 
you want your functions to be, when you write them. I consider that 
you generally want to catch errors as early as possible, to avoid 
having to write "forgiving" code that can take up space and complicate 
things and worst of all, make the code much harder to debug. But 
it's only one school of thought.

I see now HenriK, thanks for the explanation. So it encourages you 
to write code that is as deterministic as possiable and also make 
it more likely that you will need to understand your data fully too.

Yes; ANY is a shortcut for OR'ing vaues together, and ALL is a shortcut 
for AND.

I use ANY and ALL a lot because they can be handy in situations where 
an EITHER can be too cumbersome, such as inline result output for 
printing:

print any [select names name "No Name Found"]

In other cases they take up more space than an EITHER.

unlike a series of and/or  any/all will stop evaulating conditions 
at the first condition that deternims the result

so the first true for any  and the first false for all

I take that back, I've messed up a couple times and created uncontrolled 
growth in the memoized data. You do have to watch out for that. :-)

Yes, ANY and ALL evaluate the block.

And parens are evaluated by default.

One of my biggest AHA moments in REBOL was seeing that there is no 
code, only data that *may be* evaluated, and knowing when evaluation 
occurs is key (and easy to trip over :-).

Using blocks and *not* evaluating their contents--perhaps "deferring 
evalutation" is a better way to say it--is also a powerful aspect 
of REBOL. Being able to prevent parens from being evaluated is a 
good example.

ALL is not an operation in the parse dialect. ANY and SOME are looping 
operations in parse.

There were almost no changes to existing operations. Most of the 
proposals were for new operations that would replace complex code 
patterns, and those would be faster, easier and less buggy than the 
code patterns they replace.

I have been working on my Parse understanding and came up with this:
parse/all {aX--baX~~a--aX~~} [some
  [
    "a" h: some[ 
      [ 
        ["--" :h copy result to "--" (print result) thru "a" h:]
        |["~~" :h copy result to "~~" (print result) thru "a" h:]
      ] |[skip]
    ]
  ]
]
I am extracting the text between "a" and either "--" or "~~" 

Is my method a reasonable aproach or is there a simpler or more readable 
way to do this sort of thing please?

If it's a fixed length format .. why bother use parse and just use 
copy/part ?

Thanks for the examples, I will be digesting them for a while I think.

I started looking at a real life problem where the ending sequence 
of what I wanted to extract was two different things (". " OR "." 
newline), that led me to look at this sort of structure & try to 
understand how parse rules can be adapted.  My example is educational 
only, not from real life. It was intended to be a short example of 
non-fixed length format with multiple cases to extract and 2 different 
end-of-data-to-extract markers. I think a better example of what 
I intended should have XX as the data to extract in one case. {aX--baX~~a--aX~~aXX~~} 
perhaps.   Thanks.

Looks like the instructions are written for someone who already knows 
how to use it...
- run the script  ## this dosn't seem to do anything

- Run the parse-analysis.r script and use the tokenise-parse function 
to get the base data.  ## dont understand what this means, tried 
a few things but they all give errors.

The example works, but I cant even see the parse expressions in it 
so I dont understand why it works or how to adapt it for my own example.

When I first looked at this in April I got quite frustrated because 
it looked as if it was there to help newbies learn about parse, but 
it was too hard for newbies to understand how to use... now I can 
at least understand how to run the example.  Thanks

I often have trouble visualizing how things work, and I don't feel 
that I really understand something until I can do that.  With PARSE, 
even though it can be tedious and create volumes of output, it may 
help to write some simple grammars and have it print output for every 
rule. Have a probe at the start of the rule, and a probe if it's 
successful, nesting the output helps a lot too.


Don't get discouraged, it's not an easy thing to grok for a lot of 
people.

This makes it easy to test input that doesn't parse and, if I can't 
find the problem or location quickly, turn on the trace and see exactly 
where it fails. 


I've also thought about, and asked Carl for, a way to get the position 
where the parse failed, including a line number.

The main thing I do is, at some point that happens a lot in the code, 
display the data.  Makes it easier to step through the code and do 
- in your head - what the code is doing.  If it suddenly doesn't 
match up, the loic somewhere was wrong.  For example, when working 
on the last one, I had to debug part of it and did this:

parse/all {aX--baX~~a--aX~~aXX~~} [                              
          

   some [                                                           
             

      ["a" S: (? S) some [E: ["--" | "~~"] (print copy/part S E) break 
      | skip] | skip] 
   ]
]

You're already familiar with to,thru,  end and to end: 

>> parse "abcdefghi" ["a" to "i"]
 
== false
>> parse "abcdefghi" ["a" thru "i"]
 
== true
>> parse "abcdefghi" ["abcde" to end]

== true

Sub-rules can be optional by using the | (or) and enclosing the options 
in a block:


>> parse "abcdefghi" ["abcde" (print "abcde found") ["fghi" (print 
"fghi found") | "xyz"(print "xyz found")]]                       
                                                   
abcde found
fghi found
== true

Some and Any are forms of repetition, this shows the difference:

>> parse "aaa1000" [some "a" to end]

== true

>> parse "aaa1000" [any "a" to end] 

== true

>> parse "bbb1000" [any "a" to end]   

== true

>> parse "bbb1000" [some "a" to end]

== false

OK, here's what happens: The next recognized pattern is COPY/part'ed 
and assigned to the variable. If the length of the matched pattern 
is 0, #[none] is assigned to the variable.

[ and ] are a grouping construct.

regarding 

parse/all "fd doixx s x x x oie    x } " [some [copy d   "x" (print 
d) | skip]]
what did you expect?

If you know what you are looking for you can extend it to


parse/all "fd doixx s x x x oie    x } " [some [copy d   ["x"   | 
"y" | "z" ]    (print d) | skip]]
and you will get your searched values.

But maybe I just don't understand the problem.

Thanks Brian, I am finaly getting it I think. the prin 'a etc is 
better than debugging techniquies I have tried because it is small 
and dosen't add too much to the complexity, I can see I could reduce 
this method further with something like a: does [prin 'a]

Thanks sqlab, no need to excuse yourself please, your examples are 
great & I learnt a new use for COPY in PARSE. This has made your 
examples clear to me now, so thanks for spending your time helping 
me.  


The problem I have set myself is purely to understand parse more 
clearly so I have enough know-how to write any scripts I need without 
spending all day doing it. That is why I start off anking one question, 
then jump to another question if I don't fully understand the help 
I get.  


I have used parse a fair bit all ready, but limited myself to very 
simple concepts. see http://www.rebol.org/script-information.r?script-name=cisco-extract.r
and marvel that it even works ;-)   Thanks.

Right, I would say that the following snippit is the most educational 
thing I have done with PARSE.  It shows me a lot of things about 
what is happening & validates the construction and use of charsets 
& whatever the 'address block is called.     Thanks everyone for 
your help.

digit: charset [#"0" - #"9"]
address: [1 3 digit "." 1 3 digit "." 1 3 digit "." 1 3 digit]

a: does [prin 'a] b: does [prin 'b] c: does [prin 'c] d: does [prin 
'd] e: does [prin 'e] f: does [prin 'f]
parse/all {1 23 4.5.6.12 222.1.1.1 7 8} [some[

 (a) copy x address (prin x) some[ (b) copy y address break | skip 
 (c)] (print y) | skip (d)
]]
adadadadada4.5.6.12bcb222.1.1.1

I am just learning everything I can, so knowing about Block Parsing 
sounds good to. tuples! are quite good for IP addresses, but ip addresses 
often need exactly 4 parts. I wonder why there are no datatypes specific 
for networking? e.g. networks & masks & inverse masks and domain 
names. and DNS records.

I wonder why there are no datatypes specific for networking?

In general we like our types to be more widely applicable. However, 
we have tuple!, url!, and port!. The rest can be handled by functions.

Hi. If I obtain a date from a file and it is a DATE!  what is in 
that date?  for example I know it contains date/month, but can I 
get it to return the month as a string with a leading 0 or anything 
like that?  Or is it up to me to code the formatting I need from 
integer date values? Is this documented anywhere or can I see any 
of the source some how.  Thanks.

Discovery means less and less every day :(

mhinson, MOLD and FORM never reference system/locale - REBOL syntax 
is English-based.

... just teasing ... Malaysia and Singapore have had  daylight savings 
al the year round since sometime in the last century.

McMurdo and Amundsen-Scott use +12.

It's right there in the dictionary, under "Port, File, and IO Functions":
http://www.rebol.com/docs/dictionary.html

*Waiting on new process (instead of returning immediately)

*Process must run and end (launching of the shell, shell interprets 
string, etc)
*Process must be reaped
*Possibly other stuff
>> time [call/wait {}] 1
== 0:00:00.300538
>> time [call {}] 1     
== 0:00:00.010613

(I think Carl once published the code for CALL... I need to find 
it and have a look.)

Just quick hello..  I'm totally new to AltME and have used Rebol 
only years ago. I was somewhat active at older mailing list nearly 
ten years ago, but various things happened and Rebol was not among 
top priorities.. since things have changed quite a lot ..

Hello, and welcome!

I hope, you find what you seek here. And don't be afraid to ask, 
there are many nice and helpful people here.

R2 still has a few lingering issues, but development hasn't stopped 
on it. The focus now is on R3, but the community at large is still 
kind of on the sidelines. Carl and a core group are working on key 
elements, including the host interface release and extension model. 
Depending on when you last looked at R2, there may be some new things 
there for you to find as well.

I did DL R3 and run the gfx-view Demo on it. Looks really nice,  
for example fonts seem to render much better than on REBOL/View 2.7.6.3.1 
-- for some reason this seems to mess especially badly with bolded 
characters.

Hello again all,  I'm BrianD (but be glad that's not my alias or 
it would make the Wiki back-and-forth with BrianH even harder to 
read).

I was introduced to Rebol a couple of years ago to look at a codebase 
written in it, and to address the first bug I found in that codebase 
I decided to see "what it would take" to write an enumerated type: 
http://hostilefork.com/2009/06/13/enumerated-type-for-rebol2/

Earlier this year I started a project to take every single scrap 
of idea that I'd ever had or project I'd started and push it to some 
state of completion.  So I tripped across that code, and decided 
to clean it up and submit it to the rebol code archive.

But in the interim I'd lost my AltME password, and Rebol's community 
had become something of a moving target anyway.  So I looked at R3 
chat.

So I am new, and I am also not that new.  I'd like to propose that 
Rebol embrace visibility in new mediums, like StackOverflow.  Anyone 
with an RSS reader might want to subscribe to the latest Rebol-related 
questions: http://stackoverflow.com/feeds/tag?tagnames=rebol&sort=newest

And my favorite is wiki.  Now here we are -- you want to recategorize. 
 How do you?

Personally i think we need more web boards ... and not this dark 
net stuff

One thing that I noticed (an obviously *doh* moment) is that it's 
hard not to accidently start trying to reinvent the wheel with Rebol 
programs. There are so many excellent tools, utilities, and games 
allready made..  Question is more ofthem than not, where do I find 
what´s been made, how well it´s been kept updates etc.?

...most script will not work...
 - an uninformed and unsourced opinion

Hmm I need to read some things again to be sure I have even got it 
right..  (and I'm sure this is issue that has been wel discussed. 
before, sorry)

Ladislav? Really? So just go and try rebol.org submissions, one by 
one, and then tell me, how many of them actually will work ...

Even if such a statement was correct, I insist, that mine is correct 
too: uninformed and unsourced opinion.l

A good idea that, especially once we get out of alpha and things 
stop changing so much. Most of the core semantic changes have gone 
through already - current development focus is in areas with no corresponding 
concepts in R2. We'll see how much the multitasking affects things, 
and the proposed object! changes.

the time invested in learning R2 is not lost when you switch to R3.

Just avoid to pass to much time on GUI aspects and Ports handling, 
they are/will-be completly redisigned.

Joanna asked about the forward compatibility: R2->R3. There is quite 
decent backward compatibility (R3->R2), as BrianH is proving, and, 
of course, the forward compatibility is even better.

Steeve: well, sometimes things take time..  It took me decade (or 
was it two) before I got <build  does> .more or less right.  And 
I still don't get Lisp.. (nor have I tried it in years)..

It might be easier to get this than it is to get Lisp. Lisp says 
that code is data, but it isn't necessarily so. Code realli *is* 
data in REBOL, at runtime, and the whole language is bilt around 
it. Once you get that it's amazing how easy the rest gets.

As a half.funny sidenote. I was reading http://www.rebol.net/wiki/Parse_Project
and there is comment about people having CompSci degrees.. I have 
one, and I still feel a bit dumb ...

nah.. I think I just need to stretch my brains a bit and try to remember 
those things I did learn at the Uni years ago..

And I''ve never been so much on theory side..  I've preferered practical 
things..

As a practical ... I ment things like Embedded,  measurement  & control 
with some asm+c code, self-made wireless protocols etc.. Of those 
I know something (and got  my master´s degree).

The most recent Parse finding is probably CureCode #1401, which serves 
as a proof, that While is more "universal/fundamental" than Any (or 
Same), which may be found "crippled" in some situations, just because 
it "knows better than the user what to do" - I personally hate such 
software and am happy we convinced Carl to at least introduce the 
While keyword/operator.

All of the real parsing gurus are happy that while was added, and 
all of the parsing newbies will stick to any and some :)

And I feel need of Huge set of examples and cookbooks just for the 
new parser..  (plus couple asperins)

Too many. We're trying to move that stuff into DocBase (for community 
stuff) and the manual (for official stuff).

Reminds me of those old days I used to whack together some nasty 
stuff with sed and awk ...  Thankfully I have forgotten most of those. 
:)

Some data on R2 -> R3 conversions. I have 824 unit tests for Rebol.org 
that which can be run on both Core 2.5.6 and the latest R3 Alpha. 
All 824 pass under 2.5.6. Under R3, 670 pass and 154 fail. The tests 
only cover 32 functions (out of the hundreds if not thousands in 
the Library system). 13 of the functions will require changes to 
run under R3, 19 won't/

From the liitle time I've spent looking at the rebol.org system in 
respect of converting it to R3, the code changes required seem to 
be very small (I've only looked at the cgi and core code, no View 
or VID).


The biggest problem would seem to be the  need to change the source 
code to UTF-8. MUch of the rebol.org code is pretty old and was written 
without attention to string encoding. The newer code is mainly ISO-8859-1 
"aware" and seems to be ISO-8859-1encoded. Some of the Rebol.org 
code won't load in R3 because it contains invalid UTF-8 characters. 
Changing the source encoding is trivial but with that comes the need 
to change all the data stored in Rebol.org to UTF-8 for it to be 
processed properly.

So, I'd like to ask if there is any sureproof way of telling apart 
which scripts are for R3 and which are for older Rebols?  This may 
indeed be obvious question, but I try to ask these now as long as 
I can cause I'd expect these to be asked a lot by the time R3 is 
released.

I don't really have a problem with the REBOL3 way.  It seems this 
was discussed before and some valid concerns were raised but I don't 
recall what they were.

My point behind this forward/backward compatibility chat is primarly, 
that I'd like to see a way to stop average user on accidently loading 
old scripts on R3.  I'm sure the top-100 gurus of Rebol can dance 
their way around differences at will, but at the moment R3 (and R3/view) 
is released there will (hopefully) be considerable number of new 
users for Rebol.


Secondary would be giving an idea of a toolkit ( lint like script 
for Rebol  or perhaps some debug-mode at runtime? )  that would allow 
developer to see which parts of the code needs to checked/rewritten 
for R3 compatibility.

I do admit I have not searched trough old posts (blogs, vikis, archives. 
whtever is available) to see if this is obviously an old issue (and 
not necessary to talk again?).

Well my motto is a little different.
structural complexity allows  functional simplicity

Wich means, more you make your code compact and fast , more your 
code is reused.

i was discussing about "writing easy to understand mezzanine" again 
 "compact and fast but maybe hard to understand mezzanines"

but at some point, if your code is too slow and too huge, it will 
not be reused, so that you'll lost your investment

The 824 tests are unit tests of the production Rebol.org system which 
still runs in 2.5.6. So in that sense they are biased in favour of 
 2.5.6. My point was that many of them still work unchanged under 
R3.


The two main reasons that I started to build the Rebol.org unit tests 
was that they would help stop bugs being introduced when the code 
is enhanced and also help when it comes time to upgrade the version 
of Rebol that Rebol.org uses.


Sadly, I haven't written anywhere near the number of tests yet to 
reach my objectives.


(By the way, I wrote most of the tests before R3 was announced; I've 
recently converted them to a test framewoirk that also runs under 
R3.)

Joanna: "My point behind this forward/backward compatibility chat 
is primarly, that I'd like to see a way to stop average user on accidently 
loading old scripts on R3." - this issue already exists even in R2 
- there already are scripts, that work in older versions of R2, but 
not in the newest one (ask Peter, how many of his tests have problems 
in the latest R2), and, vice versa, some scripts written for the 
newest R2 don't work in older versions

It's refreshingly humiliating starting to get some clue  how little 
I know about Rebol and related stuff (AltMe for example) ..  :-)

Good example of short simple goodie that will twist one´s mind if 
one has not used to things like lisp, sheme and forth.. It took me 
a moment to realize what's the point in this one. but I think I got 
it..
 
 a: func [x] [print x] 
 b: func [] [a: 42]
 a b


As found from http://www.rebol.com/docs/changes.htmlat section 3.8

This is a great example of where these docs NEED to be a WIKI!


Then we can come along and break this down, give more than one example, 
and put notes and dicussion (chat) with it.

How about start by taking this current entire HTML doc from Carl, 
and simply turn it into a WIKI.
If he give his permission, then it is that easy.

Reichart, we did that for R3 already, and it is one of the plans 
for the next month for R2. Thanks for pointing out that the changes 
doc needs to be in the R2 manual wiki as well.

Anyone with an R3 chat account with enough rank can update the official 
manual. You get rank by knowing what you're talking about and not 
being a jerk who wants to mess things up. Not difficult criteria 
to achieve, so far.

Joanna, the reason for that is that REBOL has 3 different types of 
function arguments, and they have different evaluation rules. If 
you want to know how an expression should evaluate you need to know 
what kind of argument it will be going into, if any. The first expression 
evaluated is the one that returns the function value, the a expression 
in your example. Once that expression is evaluated it no longer matters 
what is assigned to 'a, since the function to be called is now referenced 
by DO.

I checked the result on 2.7.7 and A was as it shoudl be 42 ..  If 
it had been anything else I woudl have noted it as a Bug ..

currently we can't download a single message knowing his Id. We only 
can download all the base, and the remaining messages each time the 
client sync. Not a good system to my mind

Hmm.. I think I need to sart a new group here ... "I'm getting old 
and crumpy " :)

Yup, I'm all for facism (truly, I think it has its place, and works), 
but only for moderators to control s/n, not to supress voices.

I'm the co-founder of BIL (www.BILConference.com) , an open conference, 
the rule is "OPEN".  That simple.  Even from teh get go, my co-founders 
started trying to be "open" but controlling others.
It was really interesting... 



But, I STOOD STRONG on, let everyone do anything...  and... it worked, 
REALLY WELL.


That is not to say that as a group (mob) we did not "direct" people 
to help improve the s/n.

(delay, phone call) I agree about the input system, definitely, which 
is one of the reasons I encourage people to write their own chat 
clients. I'm not too good at writing REBOL GUIs, and don't have a 
web server to host a client. DevBase could work very well with a 
web client interface, afaict, if someone wants to write one of those. 
Heck, it's scriptable enough to integrate with Qtask, in theory.

Examples and docs, but it's not comprehensive in either the manual 
or DocBase yet. Needs work.

Well, I'm not trying to be a pain here..... so I will leave it at 
this....


When...anyone, can walk up to any REBOL word, learn about it, add 
to it, talk about it, for all others to share in and learn from, 
then... I'm happy.

Wikis need work too. Making them open doesn't magically get people 
to contribute their time. The wiki has been open for more than a 
year and only a few people contribute to it.

Most of the other PARSE docs are strewn amongst the conversations 
where we just redid the whole thing lately. It was quite a project. 
Those discussions are in the blog comments, CureCode and that parse 
project wiki, very little in chat.