AltME groups: search

Thanks PeterWood. I like to think I am ok with the most basic concepts, 
so now I am trying to learn things that will help me some my real 
life probelms in a better way.  I use parse pretty much every day 
& always have a rebol console up on my work PC, but ANY SOME & OPT 
& |  I do not understand in context.  I understand them in abstract 
terms, but not how to apply them in conjuction with [] . I do understand 
your examples of some & any (these examples are usefull to me). skipping 
an un-known number of chars to get to the next match is the bit I 
find hard to understand how to construct, paticularly if it needs 
to be done in the context of a previous match.

The compliment syntax & the    to 1 3 digit   where digit is a charset 
seems to be "unreliable" as far as I can understand.

I dont think I have ever seen the PARSE copy operation documented. 
  I will have  a hunt for it.

have you ever read the parse documentation in the old RT publisehd 
rebol 2.3 pdf  ?  its a good reference... there are only minor changes 
from that version up to the latest... I don't think any of the examples 
would fail in the current parse.

chpter 15 or the Rebol Core Manual  http://www.rebol.com/docs/core23/rebolcore-15.html
 may have a use of this syntax in a complicated example, but no description 
of what is happening exactly.

Yes, I have read it a lot, but it seems more of a reference for people 
who already know, rather then an explanation of Parse operations.

Thanks BrianH, I was sort of guessing it must be like a variation 
of copy thru "x" that does not skip like thru...  I think I get that 
now. Thanks.

[ and ] are a grouping construct.

This is my nemisis. I can't understand how this prints XXXX then 
XX , not XX  three times.  It seems to have a will of its own.

parse/all { X X  XX X X} [some[[copy x "X" (prin x) [copy y "X" (print 
y) | skip] | skip]]]    
I have been stuck on this (in various forms) for over a week now

parse/all { X X  XX X X} [some [copy x "X" (prin x) [copy y "X" (print 
y) | skip] | skip]]

Character at a time:
- the outer skip
- copy x "X" (prin x)
- the inner skip
- copy x "X" (prin x)
- the inner skip
- the outer skip
- copy x "X" (prin x)
- copy y "X" (print y)
- the outer skip
- copy x "X" (prin x)
- the inner skip
- copy x "X" (prin x)
- the outer skip

Try this:

>> parse/all { X X  XX X X} [some [copy x "X" (prin x) [copy y "X" 
(print y) | skip (prin "i")] | skip (prin "o")]]
oXiXioXX
oXiXo== true

Ah. that is a good trick to print i & o with the skips, this will 
help a lot, thanks.

Isee from your analysis that my error is to expect the inner skip 
to skip back to the beginning of that loop...  not sure why I expected 
that, but it is clearly wrong. I dont know if there is a way to make 
the inner loop behave like that, at an earlier point I did hve OPT 
in front of it...  I will be able to make progress with my experiments 
now armed with the new trick you have taught me, but for now I have 
to go & get some sleep I am afraid.  Thanks again.

>> parse/all { X X  XX X X} [(prin 'a) some [(prin 'b) "X" (prin 
'c) [(prin 'd) "X" (print 'e) | (prin 'f) skip (prin 'g)] (prin 'h) 
| (prin 'i) skip (prin 'j)] (prin 'k)]
abijbcdfghbcdfghbijbcde
hbijbcdfghbcdfijbik== true

Now the fij is a bug in parse - it should be fgh.

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.

I have been reminded that   |skip   is a word  | skip   is OR skip. 
 it is so easy to miss the space between | & skip

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

Mhinsob, if you load an ip address (from a string) you got a tuple, 
so what is different in your request ?
>> type? probe load "1.2.3.4" 
1.2.3.4
== tuple!

Possibly checking that it's a valid IP address?
>> length? 1.2.3.4
== 4
>> length? 1.2.3.4.5
== 5
>> length? 1.2.3.44.5
== 5

The get-modes looks interesting. Can it produce information about 
any ip address I might give it?  like 172.22.37.55/28 

I suppose that is an example of a very common network address "type"

Hi. is there a special function to remove the last element of a string 
please? this works, but seems a bit cryptic.
reverse next reverse {a.b.c.}        Thanks.

Wrapping it in a func makes it less cryptic. :-)

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.

Hi Brian, I see some goodies there. What I am doing is too trivial 
to want to link any large blocks of code just for that so I will 
just code the bit I need I think.  I was puzzled because DATE returns 
the info with the month as  a word, but date/month returns an integer, 
so I imagined there must me more to DATE! than just a structure containing 
integers?

(I found a couple of errors in the text)

Thanks...  I can work with that information, but I am curious as 
to how referencing the whole date gives Jul  but there seems no option 
fot the month as a word.... not that I want it, but I am curious 
how that works.

which reminds me .. date functions should have a /utc refinement 
:)

Gavin Menzies, the english "historian" claims the americas were "discovered" 
by a chinese fleet in 1421 ...

I'll only trust wikipedia when they put the "a" back in ... as wikipaedia

WTF ... did Ladislav's time zone undergo a shift  ... or is he flying 
??

so does Rebol always reference the system/locale when printing a 
DATE! but only store the inteeger values?  or does it store the date 
in julian format & do more complex stuff to output even things like 
date/year

A couple stations use +12:00.

what a complete mess ...

So, its just as confusing as for the rest of us, but at a smaller 
scale.

I think your statement about "all Antarctic bases ... " is a tad 
off!

I want to capture on-key events while a table widget has focus. I 
tried using " on-click [system/view/focal-face: face system/view/caret: 
face/text]
 on-key [print event/key]
" as the user-guide suggests 
for non-editable widgets, but all I got was a crash. Any suggestions?

I'm no rebgui user, but I can tell you there is a rebgui group here. 
  maybe you can find your answer there  :-)  the best way to search 
for stuff is to use the altme web archive on rebol.org, cause it 
includes even the old posts.  Altme limits back log to make the GUI 
more responsive.


the rebgui Atlme archive on rebol.org:  http://www.rebol.org/aga-display-posts.r?post=r3wp303x1

is there a way to move a file from one path to another without copying? 
or should I use call "mv ... ? thank you!

I haven't come across such a file move function. I guess, you need 
to call the operating system.

Ah, can't be used for what Will is after.!

This function cannot be used to move a file from one directory to 
another. 

Just checked, it correctly moved a text file from one directory to 
another on Ubuntu

from the rename help:
ARGUMENTS:
     old -- path to the old file (Type: file url)
     new -- new name (not a path) (Type: file url string)


but it indeed works if you use a destination path relative to the 
origin path, in my case 0.002 seconds instead of 0.300 using call 
"mv..   thanks all 8-)

why does call have a pretty fixed 300 ms delay? Is it a coincidense 
on my machine or is it enforced somewhere?
timer [call/wait ""]
;   0:00:00.301991

300 ms: maybe there's a hardcoded "wait" for the other process to 
start, or something like that. it seems to be too much consistent 
to just be the shell startup time.

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

300ms is a LOT of time for webapps, it would be really appreciated 
if a build without that limitation could be made available, Thank 
you Gabriele for taking care 8-)

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 ..

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.

Well.. It's not a biggie. Was just something a noob wanting to evalluate 
Rebol might miss.  :-)


Also I finally found a way to make text bigger on AltME window.. 
With today´s screens the default is a bit smallish.

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.

Well, he wrote a lot, but there are still only 80.

[Pehaps this discussion belongs more naturally in the Advocacy group, 
rather than a newcomers' questions group]

Thanks, I´ll do so when I have something spesific in mind..  I was 
wondering how much Rebol has changed in last 10 or so years, in a 
sense that If I find an neat script what are chances it still works 
as it´s shoudl be.  At the moment I have this feeling that this current 
v2 Rebol shoudl be bit more compatible than upcoming V3 ?

I have no plans on jumping into R3 at this point, since there are 
so much even on R2 I need to learn. But for the future reference, 
is there any plan for a tool (or mode in Rebol itself) to help Flagging 
out those R2->3 differences... For example, I remember seeing that 
PICK works differently on R3 (right, unlike R2 which is offsetted 
by one), it'll be quite hard to spot all those from source alone, 
since parameters are often defined at runtime?


Some changes will of course be obvious (for spotting), like sockets, 
since their parameters have been canged a lot. but difference on 
data readiding/writing (ascii/binary/unicode etc) may hide itself 
quite a while.

Yes, there is a difference in Pick behaviour, but keep in mind, that 
behaviour is different only in exceptional cases

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.

Plus there is a project to backport some of the R3 improvements to 
R2 so you can use some of the fun new toys. A project I should get 
back to soon, I might add. Some things won't be compatible but it's 
amazing how much can be made to work.

yes, it might be possible. there were also talks about emulating 
VID at some point. maybe that's better left for a hobby project.

i'm not sure it's easy. The flow of GUI events is drived very differently. 
It's could be a burden to simulate the R2 behavior.

ahah, a lighter syntax ?

In fact, the Inline function can be implemented as a mezzanine, which 
would serve as a proof, that you can do without it, if you wish.

But, the same applies to the Compose function, it can be implemented 
as a mezzanine too.

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..

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 parsing model of R3 is based on a theory that didn't exist when 
I was last in college :)

Re the practicality: a good Parse dialect may be very practical (can 
be used to implement dialects, parse texts, match various patterns, 
etc.), but, at the same time, the design of it is rather a theoretical 
task.

Yes, although there is a possibility, that a new requirement/need 
appears.

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.

That was a community written book ... different purpose

I helped starting the wikibook before R3 was announced. When R3 was 
announced, I though "well, damn, we'll have to start over, when R3 
is out in a couple of months." :-)

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 think there is currently.  The community should decide on 
the best method though.  I think simply changing the extension could 
be useful such as .r3   Other languages use extensions to differ 
between code version such as .c verses .cpp    However, another method 
is simply to put a stamp message in the header such as:

REBOL [
     Title: "My coolest Program"
     Stamp:  R3
]

There is no such way. Some scripts work for many versions of REBOL, 
some don't. A way to tell is to use the NEEDS entry in the headers. 
See:
http://www.rebol.com/docs/core23/rebolcore-5.html#section-2

But it's not widely used.

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.

all the scrpts made accross the 10 last years usng REbl 2 wll then 
not be usable with R3 ... Ans this have been discussed lke 2  years 
ago when carl proposed to do a major verson upgrade that was wth 
the discuton arund the "Because no one knows it  do i change rebol's 
name ?". It was sad to say that rebol after 10  yeas was stll in 
the underground limbus....

Is this based on a small sample of your own scripts?  Any largish 
scripts tested yet?

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.

if your code is slow, can always speed it up by running a faster 
cpu :)

Or, you'll have a job for life!

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

Shadwolf: "all the scrpts made accross the 10 last years usng REbl 
2 wll then not be usable with R3" - if that is a statement, than 
it is demonstrably false

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.

Cool, can you post a link to that?

There is also a community-run MediaWiki site at http://www.rebol.net/wiki/Main_Page

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.

Shame... to much of a barrier to entry.

Rather, everyone should be allowed to post anything.

A moderator should be able to push stuff to some "sideline" (not 
delete though).  This will simply keep the s/n high.

When REBOL is no longer a clique, more people will will feel like 
they are "welcome" to join in.

That's why we have two wikis, so the manual can become more official, 
like a book. We only want answers in the manual. We have other places 
for questions: The community wiki, chat, CureCode.

clique is a french word Reichart ;-)

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 ..

Reichart, CHAT shouldn't be a barrier to entry. We are trying to 
make it more accessible.