REBOL Newbie tries to convert C source to REBOL (long posting)
[1/11] from: WisD00M::gmx::net at: 20-Nov-2003 22:25
Hi everybody !
I am currently trying to port an ANSI C application over to REBOL.
I am pretty much a newbie to REBOL - and was pretty impressed by
its capabilities.
My problem now is, porting looked a lot easier than it actually turns out to
be for me.
I seem to lack some fundamental things in REBOL - maybe I just think too
one-dimensional
because of my ASM/C - background, indeed, in C I do parse the whole data
BYTE by BYTE - something that
doesn't seem effective with REBOL - as there seem to be more efficient
methods available,
as I understand it.
Actually, I would think the application should be fairly easy to
be implemented with REBOL - it's bascially only 'simple' string processing -
not much more. That's why I thought I should give it a try - also to be able
to compare REBOL performance with my compiled C-application.
basically, this is what my C source does:
1) open a data file (approx. 1 MB data)
filename: "test.dat"
data: read filename
2) parse the file for sections - every section is indicated by square
brackets
and is valid to the next (new) section
like this: (example data)
--------------------------------------------
[sec1]
dataline1 111.11 N012.11.029 E034.31.110
dataline2 131.11 N012.11.099 E034.31.110
dataline3 111.11 N015.11.099 E034.31.110
[sec2]
datalinex HFD 111.11 N012.11.099 E034.31.114
dataliney LKA 131.41 N011.11.049 E031.31.116
datalinez JIH 111.11 N012.11.019 E032.31.114
--------------------------------------------
So each sections contains several hundreds of lines with data,
the data syntax is different with each section. That's why I initially
separate the data only by whitespaces in C and take care of the exact syntax
at
a later time, using parsing rules specified in another array.
3) In C I would now simply determine each section's offsets within the
memory
and then store (memcpy) each section into its own multi-dimensional array
using the offsets
I determined in the previous loop, where each line of data is directly
accessible
- but also every part of the data line (separated by whitespaces).
At first I would go and compute every section's beginning like this:
________________________________________
sections: make block! 40
parse data [
any [to "[" copy sec indx: thru "]"
(append sections index? indx)
{/*
For debugging purposes I also emit the name of each section
that's found.
*/}
(print sec)
]
]
________________________________________
Then I got the position of each section in the data-series and compute
the offset of each section by calculating the difference between 2 adjacent
sections.
Accordingly, in C I would then go to extract/copy the data within the two
offsets
and put it all in another array to work with.
That's exactly where my problems start to overwhelm me.
While reading the file in, and parsing it for sections does seem to
work fairly well (and with MUCH less code !), I am having difficulties to
create the
multi-dimensional arrays for each section where all data is individually
accessible stored.
So as an example, having parsed [sec1] I want every element in each line to
be individually
accessible to simplify conversion.
4) Although the arrays don't work yet I tried to port the parsing routines
over -
In C I take the "parent" array that contains all sub-arrays and parse each
section individually. Parsing is done in C with a certain set of rules (also
stored in an array)
- using regular expressions, I 'expect' a certain data format for particular
sections.
If a rule is matched I parse with that rule and separate the data into
sub-arrays.
In REBOL the latter seems fairly easy using the parse command:
5) when all data has been processed and separated by its corresponding rule
I need to
convert the data for each section into a different format.
With C I am again using regular expressions to implement conversion. That's
why I
stored the recognition-rule and the conversion-rule in the same array
6) Final conversion of the original data will be to CSV-format - including
most data that was
read, but occasionally not all data is needed or an abbreviated form is
sufficient.
Maybe you guys got some thoughts on my problem - I don't want/need actual
code - rather some
hints how to accomplish my goals in REBOL. As you may be able to tell from
the way I describe
the problem, I might indeed be too heavily thinking in C. By the way: are
you aware of any
tutorials or books, particularly targeted at C-programmers. This seems
really to be a situation
where previous programming-experience limits my way of thinking. I did read
a lot of stuff on
the REBOL webpages, but still do have problems, grasping the inner concepts
within in REBOL.
Another question that just came to my mind: is there any decent REBOL code
editor available?
Simple syntax highlighting would be one thing - but I am thinking more of a
supportive
editor that also supports syntax completion or smart tooltips, helping a
newbie like me.
I guess, the power of REBOL is also some kind of problem for such an editor,
as single
objects/words can mean different things and dialects can easily be extended.
Maybe some really good REBOL-programmer should go and program an editor
for REBOL IN REBOL (view) ;-)
I'd really love to see a REBOL-editor being implemented in REBOL - it could
easily be
enhanced by everybody, there might even be some kind of "plugin" concept
considered -
using rebol scripts, that are executed on demand.
Using REBOL/VIEW it would also be available on pretty much all platforms.
Thanks for any help and comments - and sorry for this rather long eMail ;-)
P.S.: Is there any kind of REBOL-specific FORUM available on the web ? If
not: why not ? I would be willing to
create one - if there's demand.
--
regards
_________________
---------
Mike
GMX Weihnachts-Special: Seychellen-Traumreise zu gewinnen!
Rentier entlaufen. Finden Sie Rudolph! Als Belohnung winken
tolle Preise. http://www.gmx.net/de/cgi/specialmail/
+++ GMX - die erste Adresse für Mail, Message, More! +++
[2/11] from: greggirwin:mindspring at: 20-Nov-2003 16:24
Hi Mike,
Thanks for the detailed post. I really want to dig into it and see if
I can help, but I'm terribly busy at the moment. I'm guessing someone
else will chime in but, if not, ping me directly in a week or two (if
you can wait that long) to remind me about it.
-- Gregg
[3/11] from: tomc:darkwing:uoregon at: 20-Nov-2003 15:51
too much to address while at work, but for disscussions try altme
http://home.zonnet.nl/rebolution/fora.html
On Thu, 20 Nov 2003, Mike Loolard wrote:
[4/11] from: AJMartin:orcon at: 24-Dec-2003 22:49
Hi, Mike!
Mike wrote:
> P.S.: Is there any kind of REBOL-specific FORUM available on the web ? If
not: why not ? I would be willing to create one - if there's demand.
Not quite a forum, but a chat program, AltME, is available from:
http://www.altme.com/
And look for the "Rebol" world.
> 1) open a data file (approx. 1 MB data)
> filename: "test.dat"
> data: read filename
> 2) parse the file for sections - every section is indicated by square
brackets and is valid to the next (new) section
> like this: (example data)
--------------------------------------------
[sec1]
dataline1 111.11 N012.11.029 E034.31.110
dataline2 131.11 N012.11.099 E034.31.110
dataline3 111.11 N015.11.099 E034.31.110
[sec2]
datalinex HFD 111.11 N012.11.099 E034.31.114
dataliney LKA 131.41 N011.11.049 E031.31.116
datalinez JIH 111.11 N012.11.019 E032.31.114
--------------------------------------------
I looked at the data above and noticed that it's not directly 'load-able
with Rebol as these values "N012.11.029" will get turned into Rebol words.
So the next plan is to use 'parse. The basic application of 'parse, where
whitespace is important is:
parse/all data rules
Now to work out the rules that are needed. I can see that there are several
sections in the line which seem to be terminated by newlines. So:
rules: [
some section_rule
end
]
I can see that each section starts with a open square bracket, then there's
a section name (which seems important) followed by a closing square bracket,
(perhaps optional whitespace?) and a newline. After that, there's any number
of data lines, which seem to form a table of values of various types, with
perhaps a trailing empty line?
section_rule: [
#"[" copy Section_Name to #"]" skip any #" " newline
; The 'skip steps over the "unconsumed" "]".
any [
data_line_rule
]
newline
]
data_line_rule: [
any value_item_rule any #" " newline
]
> I need to convert the data for each section into a different format.
value_item_rule: [
copy Item to #" " some #" "
]
The above rule pick out each item between space characters. So you just need
to parse each item on each line in each section and convert to appropriate
Rebol data-type. My %Patterns.r script file could be useful at this point.
I'd use it something like this:
value_item_rule: [
copy Item to #" " some #" " (
if Item [
Item: if parse/all Item [
time^ end (Item: to time! Item)
| money^ end (Item: to money! Item)
| integer^ end (Item: to integer! Item)
; and so on for the expected data types.
] [
Item
]
]
insert tail Data_Line Item
)
]
> 6) Final conversion of the original data will be to CSV-format - including
most data that was read, but occasionally not all data is needed or an
abbreviated form is sufficient.
This part is a bit trickier; some of my scripts in my %Values.r can be very
helpful here. I'd be putting each section into it's own block, with each
line as separate blocks within the surrounding block. That way it can be
more easily torn apart, twisted around and put back together. (I do a lot of
this at the school I work at.)
Here's the first block, just loaded straight into Rebol:
>> sec1: [
[ [dataline1 111.11 N012.11.029 E034.31.110]
[ [dataline2 131.11 N012.11.099 E034.31.110]
[ [dataline3 111.11 N015.11.099 E034.31.110]
[ ]
== [
[dataline1 111.11 N012.11.029 E034.31.110]
[dataline2 131.11 N012.11.099 E034.31.110]
[dataline3 111.11 N015.11....
Then using my 'transpose to give the array a 90 degree twist:
>> probe sec1_columns: transpose sec1
[[dataline1 dataline2 dataline3] [111.11 131.11 111.11] [N012.11.029
N012.11.099 N015.11.099] [E034.31.110 E034.3
1.110 E034.31.110]]
== [[dataline1 dataline2 dataline3] [111.11 131.11 111.11] [N012.11.029
N012.11.099 N015.11.099] [E034.31.110 E03
4.31.110 E034.31.1...
Then swapping columns arround, so the last column is first and the first
column is last:
>> probe t: transpose reduce [last sec1_columns second sec1_columns third
sec1_columns first sec1_columns]
[[E034.31.110 111.11 N012.11.029 dataline1] [E034.31.110 131.11 N012.11.099
dataline2] [E034.31.110 111.11 N015.1
1.099 dataline3]]
== [[E034.31.110 111.11 N012.11.029 dataline1] [E034.31.110 131.11
N012.11.099 dataline2] [E034.31.110 111.11 N01
5.11.099 dataline3...
Then converting to CSV format (using my %CSV.r script):
>> probe mold-csv t
{E034.31.110,111.11,N012.11.029,dataline1
E034.31.110,131.11,N012.11.099,dataline2
E034.31.110,111.11,N015.11.099,dataline3
}
== {E034.31.110,111.11,N012.11.029,dataline1
E034.31.110,131.11,N012.11.099,dataline2
E034.31.110,111.11,N015.11.099,dataline3
}
I hope that helps!
Andrew J Martin
Speaking in tongues and performing miracles.
ICQ: 26227169
http://www.rebol.it/Valley/
http://valley.orcon.net.nz/
http://Valley.150m.com/
[5/11] from: tomc:darkwing:uoregon at: 20-Nov-2003 21:20
response on bottom
On Thu, 20 Nov 2003, Mike Loolard wrote:
> Hi everybody !
> I am currently trying to port an ANSI C application over to REBOL.
<<quoted lines omitted: 137>>
> To unsubscribe from this list, just send an email to
> [rebol-request--rebol--com] with unsubscribe as the subject.
hopefuly this will get your mind moving slightly differently
data: {
[sec1]
dataline1 111.11 N012.11.029 E034.31.110
dataline2 131.11 N012.11.099 E034.31.110
dataline3 111.11 N015.11.099 E034.31.110
[sec2]
datalinex HFD 111.11 N012.11.099 E034.31.114
dataliney LKA 131.41 N011.11.049 E031.31.116
datalinez JIH 111.11 N012.11.019 E032.31.114
}
sections: make block! 40
row-data: complement charset "[^/" ; accept any char not \[ nor \n
row: [copy r some row-data newline ; break section into rows by \n
(insert/only tail blk parse r none) ; break row into fields by ws
]
parse data [
some [
to "["
copy sec [thru "]"] (print sec)
thru newline
; well you are all ready here so...
; instead of storing the location and all that ...
; just deal with it now.
(insert/only tail sections blk: make block! 500)
any row
]
]
; to see what native types rebol would see in each field
foreach sec sections[
foreach row sec[
foreach field row[
prin [type? load field field " " ]
]
print ""
]
]
;probe sections
[6/11] from: antonr:iinet:au at: 21-Nov-2003 17:05
Hi,
What does the application do and why does it do it?
What does the data describe?
Handling blocks:
my-block: copy [] ; initialize the big block of data
; now within your parse rule
parse-rule: [
...
; at this point you have extracted section-name (eg. "sec1")
append my-block reduce [section-name copy []]
...
; at this point you have extracted some section data
; into data1 data2 data3 etc.. so store it
append last my-block reduce [data1 data2 data3]
]
That should have extracted all the data into my-block, which
should look like this:
my-block: [
"sec1" [
"dataline1" "111.11" "N012.11.029" "E034.31.110"
"dataline3" "111.11" "N015.11.099" "E034.31.110"
]
"sec2" [
"datalinex" "HFD" "111.11" "N012.11.099" "E034.31.114"
"dataliney" "LKA 131.41" "N011.11.049" "E031.31.116"
"datalinez" "JIH 111.11" "N012.11.019" "E032.31.114"
]
]
I've got all values as strings, but depending what they are you
could use numbers, words and issues for easier handling later.
I don't know - what do you want to do with the data?
After finishing the extraction, you can get to the block of lines
for each section like this:
section1-data: select my-block "sec2"
;== ["dataline1" "111.11" "N012.11.029" "E034.31.110" ...
To step through each line you could do this:
foreach [line-title data1 data2 data3] section1-data [
print [line-title data3]
]
I am assuming, for each section, that each line has the same number of
elements. If not, then I recommend putting each line into a block of
its own, so it looks like this:
my-block: [
"sec1" [
["dataline1" "111.11" "N012.11.029" "E034.31.110"]
["dataline3" "111.11" "N015.11.099" "E034.31.110"]
]
...
]
To get that data now, you can do this:
foreach line section1-data [
?? line ; show the contents of the block
print [line/1 line/4]
line/3: copy "N012.11.028" ; change third item
]
Read more comments interspersed below:
> Hi everybody !
> I am currently trying to port an ANSI C application over to REBOL.
<<quoted lines omitted: 117>>
> inner concepts
> within in REBOL.
Did you do any Java? "Everything is a pointer" is kind of more
like rebol. Ask any questions here you want. We'll help you.
> Another question that just came to my mind: is there any decent REBOL code
> editor available?
<<quoted lines omitted: 17>>
> using rebol scripts, that are executed on demand.
> Using REBOL/VIEW it would also be available on pretty much all platforms.
This has often been wished for already.
I think it's a bit of a waste of time at the moment.
There are plenty of good text editors out there, and rebol syntax
highlighting for them too.
See my page on text editors:
http://www.lexicon.net/anton/FreeEditors.html
> Thanks for any help and comments - and sorry for this rather long
> eMail ;-)
> P.S.: Is there any kind of REBOL-specific FORUM available on the web ? If
> not: why not ? I would be willing to
> create one - if there's demand.
> Mike
There is RebolFrance.net - if you can read French it helps.
and Vanilla
http://www.compkarori.com/cgi-local/vanilla.r?selector=display&snip=start
and Agora-Dev
http://rebol.agora-dev.org/
Anton.
[7/11] from: WisD00M::gmx::net at: 22-Nov-2003 5:18
REBOL Newbie tries to convert C source to REBOL (long posting) Part II
Hi !
I've replied to all responses within one eMail - so if I didn't forget
anybody,
you should find my comments and answers to your mail below!
First of all: thanks to everybody who offered support and provided useful
feedback. I really appreciate all your efforts !!
I didn't expect such a prompt response - and then so many replies !
On "altme", the chat client: I am certainly going to have a look into it !
Are many of you really using it ?
A J Martin > I looked at the data above and noticed that it's not directly
'load-able
A J Martin > with Rebol as these values "N012.11.029" will get turned into
Rebol words.
Well I didn't seem to have any problems loading the data - the specific
needs to be addressed at a later time anyway - so insofar it's absolutely
okay to initially have the data separated by whitespaces.
A J Martin > So the next plan is to use 'parse. The basic application of
'parse, where
A J Martin > whitespace is important is:
A J Martin > parse/all data rules
Indeed, I am already using parse - I've read some interesting stuff about it
- on the REBOL.COM
webpages, but also in other tutorials. When fooling around with parse I did
have some
problems though:
I read it would be possible to provide parse with patterns to look for - so
I tried
something like:
REBOL [ ]
;________________________________________
;data is now a variable containing several lines of data i.e.
; -> datalinex HFD 111.11 N012.11.099 E034.31.114
foreach line data [
print parse line [rules] ;just to return whether the rules specified where
matched or not
]
;________________________________________
However,using actual patterns didn't seem to work for me.
Looking at the line of data provided in the comment above,
I would want to check whether a line of data has the following form:
any characters, one whitespace, 3 numbers, 1 dot, 2 numbers, 1 whitespace, 1
char N | S,
3 numbers,1 dot, 2 numbers, 1 dot, 3 numbers, 1 whitespace, 1 char E|W, 3
numbers,1 dot, 2
numbers, 1 dot, 3 numbers, 1 whitespace,
So, trying to put that into REBOL's "words", I came up with the following
attempt:
;--------------------------------------
REBOL []
line: "datalinex HFD 111.11 N012.11.099 E034.31.114"; example line
digits: charset "0123456789"; all numbers that are allowed
alpha: charset "abcdefghijklmnopqrstuvwxyz"; all characters that are
allowed (not case specific)
dot: #"."; a dot
whitespace: #" "; a whitespace
rule: [any alpha 1 whitespace 3 digits 1 dot 2 digits]; an abbreviated rule
to match the first three elemnts of data
print parse line [rule]; to check whether the line contains data in the
format specified by rule
;--------------------------------------
However this doesn't seem to work the way I would want it to ... probably I
am again making a stupid
beginner's mistake
A J Martin > Now to work out the rules that are needed. I can see that there
are several
A J Martin > sections in the line which seem to be terminated by newlines.
So:
A J Martin > rules: [
A J Martin > some section_rule
A J Martin > end
A J Martin > ]
A J Martin > I can see that each section starts with a open square bracket,
then there's
A J Martin > a section name (which seems important)
Well, the actual section name isn't really that important - indeed it is
practically irrelevant,
as the data in each line is supposed to get 'recognized' by its syntax -
exactly like I tried
to show a frew lines above:
I intend to create several rules for all formats that are common - and when
each section's
offsets have been determined I want to run these rules against each section
in order to determine
whether rule1, rule2, or maybe rule11 is applicable is to the data stored in
said section.
A J Martin >followed by a closing square bracket,
A J Martin > (perhaps optional whitespace?) and a newline.
Yes, that's right: each section is determined by its name being enclosed in
square brackets - with no other data on that line.
A J Martin > After that, there's any number
A J Martin > of data lines, which seem to form a table of values of various
types, with
A J Martin > perhaps a trailing empty line?
This is also correct.
regardin the code that you provided here as an example, it looks quite good
-
I will look through it and try to understand what exactly it is doing and
WHY ;-)
You mentioned a "pattern.r-file" written by you - is there any documenation
available on the
actual usage of your library file ?
The 90° swapping idea looks also interesting - but I would probably rather
base
the conversion on a ruleset for recognition of data and then the actual
conversion
to a different format.
That seems pretty logical to me - as most data in its basic form is unlike
the syntax in
each section identical. That way I could also put rules together that are
intuitive:
;for example:
rule_description: [any alpha]
rule_coordinates: [N|S|W|E 3 digits 1 dot 2 digits]
But as I said: my way of thinking doesn't seem to be right yet - cause that
part isn't doing
what it is supposed to do.
The later conversion to CSV format shouldn't really require any external
library
as soon as I sorted the data in each line apart and have converted it to a
format
that is suitable.
Just another example:
While the positional data is currently stored in a format like "N034.12.331"
I will need the last four bytes of the string ommitted/removed - so that I
got:
N034.12
Then remove the 2nd byte of the string (the 0)- then it looks like:
N34.12
Then have the first byte of that string moved to the end the string so that
I get:
34.12N
A J Martin > I hope that helps!
yes, for sure - thank you very much for your ideas and suggestions !
Tom Conlin > hopefuly this will get your mind moving slightly differently
okay, thank you for the code - as well as putting comments behind it !! :-)
I will have a look at it and try to incorporate the ideas into my script.
Anton Rolls > What does the application do and why does it do it?
The actual C application converts tables with GPS data from one format to
another one.
Besides the obvious GPS coordinates there is also some other information
included in
the file, that depending on the format might also be required to be parsed
and
converted to the other format (CSV).
Now I want to port it to REBOL in order to enhance the functionality and
ease of
usability.
Anton Rolls > What does the data describe?
Like I said: each line contains at least longitude and latitude data (GPS) -
then there
are also abbreviations and numbers that might also be needed for final
conversion.
Anton Rolls > I've got all values as strings, but depending what they are
you
Anton Rolls > could use numbers, words and issues for easier handling later.
strings are perfectly okay, I intend to check the validity of data with its
parsing
rules-so there's no need to manually check whether data is valid or not.
Anton Rolls > I don't know - what do you want to do with the data?
GPS coordinates and other data in a certain format need to be converted to a
different
format to be used with a different application.
So bacially I'm having something like this in my datafile:
["dataline1" "111.11" "N012.11.029" "E034.31.110"]
but my target format requires for example
- field #1 to be at the 2nd position
- field #2 to be at the 1st position
- fields #3 & #4 to be converted to a format without miliseconds, without a
leading 0 but with a trailing character
(either N/S or W/E)
In this example I would then need:
["111.11" "dataline1" "12.11N" "34.31E"]
And as the actual data format varies with each section I just want to
specify
rules in order to recognize the way data is stored - and when a rule is
recognized
I want to apply according to that another rule for conversion.
So in the above example my conversion rule would need to swap data elements
with eachother,
as well as splitting the GPS strings into directon, degrees,hrs,min,ms and
re-align this
data for a format acceptable for the other application.
Anton Rolls > After finishing the extraction, you can get to the block of
lines
Anton Rolls > for each section like this:
Anton Rolls > section1-data: select my-block "sec2"
This looks indeed intuitive - so it seems with that method I wouldn't have
to manually compute
the offsets of each section ? - but rather store each section's name in a
table ?
Anton Rolls > I am assuming, for each section, that each line has the same
number of
Anton Rolls > elements. If not, then I recommend putting each line into a
block of
Anton Rolls > its own, so it looks like this:
Yes, blocks seem to make sense to me, too - as each section can have a
different amount
of elementsl
Anton Rolls > Did you do any Java?
Not really
Anton Rolls > "Everything is a pointer" is kind of more
yes, I guess that's why I understood meanwhile - though the sytax is a bit
complex,
in assembler I simply consider everything a (D)WORD - so it doesn't seem to
be much
different with REBOL.
But it's not really easy to get through the code - there are so many things
to take
into consideration.
Sometimes I am really having trouble to decide whether to use literals or
words -
the evaluation seems also heavily to rely where one put brackets ...
Anton Rolls > like rebol. Ask any questions here you want. We'll help you.
thank you ! - I am already stunned by the enormous response my first posting
received here !!
Anton Rolls > This has often been wished for already.
Anton Rolls > I think it's a bit of a waste of time at the moment.
Anton Rolls > There are plenty of good text editors out there, and rebol
syntax
Anton Rolls > highlighting for them too.
Sure, there are literally tens of thousands of editors out - also most of
them with
some basic syntax highlighting.
But I thought more about an object oriented approach: an editor really
supporting
the programmer, and doing background parsing of the code that I write.
One example:
Having written some smaller View/VID test programs, I did always have to
have half a
dozen of browser windows with documentation in the background - just for
reference!
Simply, because I didn't knew for example what styles,faces and the like is
supported.
Unfortunately, the documentation about using actions & events with REBOL
view isn't very
good either - I was practically 'learning' by looking at example code from
others.
If instead the editor would be doing background parsing and watch me create
an object
or button it could really support me by displaying all possible options with
that
element.
So when I created an object at the beginning of the file
house: make object! [
door_open: false
shutdoor: does [
door_open: false
]
opendoor: does [
door_open: true
]
]
and at a later time I clone this object by writing:
greenhouse: make house []
the editor might support me by displaying the elements (variables,
functions, classes)
of that object and expected parameters for functions.
This would be even more useful if it gets extended to the whole REBOL
dialect -
the editor could show in another window or maybe with popup menu the
available
elements in the current context.
In the tutorial section on functions I read somewhere it would be possible
to
enclose a comment on the function's purpose within the function header -
that
very header might also be useful information that could get displayed.
That way it could also show what styles are supported for a given type.
Since it's dialect-based it should be pretty possible to read out
sub-elements and
display parameters and stuff like that.
So you begin to open a DRAW section within a layout and voilá: REBOL shows
what
can be done.
Seems to me like something REBOL is "born" to do ;-)
Anton Rolls > There is RebolFrance.net - if you can read French it helps.
Sorry, "mon ami": I don't understand any french ... thanks anyways !
P.S.: Does this list support attachments (ascii) ? Cause, actually I
attached some code
with my last mail but didn't see it on line (listview) - are the attachments
extracted ?
--
regards
_________________
---------
Mike
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService
Jetzt kostenlos anmelden unter http://www.gmx.net
+++ GMX - die erste Adresse für Mail, Message, More! +++
[8/11] from: AJMartin:orcon at: 24-Dec-2003 22:49
Re: REBOL Newbie tries to convert C source to REBOL (long posting) Part
Mike wrote:
> REBOL []
> line: "datalinex HFD 111.11 N012.11.099 E034.31.114"; example line
<<quoted lines omitted: 4>>
> whitespace: #" "; a whitespace
> rule: [any alpha 1 whitespace 3 digits 1 dot 2 digits]; an abbreviated
rule
> to match the first three elemnts of data
>
> print parse line [rule]; to check whether the line contains data in the
> format specified by rule
> ;--------------------------------------
Very close! Unfortunately, you've made some little mistakes. Remember that
'help is free to use (except on parse dialect words...), so don't be afraid
to use it:
>> help parse
USAGE:
PARSE input rules /all /case
DESCRIPTION:
Parses a series according to rules.
PARSE is a native value.
ARGUMENTS:
input -- Input series to parse (Type: series)
rules -- Rules to parse by (Type: block string none)
REFINEMENTS:
/all -- Parses all chars including spaces.
/case -- Uses case-sensitive comparison.
Note the /all refinement; if used it allows processing space otherwise, it
skips over spaces in the input. Similarly for /case refinement, if
specified, character comparison is case-sensitive; otherwise, not. So it's
best to decide right at the top, whether whitespace are important or not,
and whether case is important or not. Let's assume that spaces are
important, and that case is important as I noticed that data values have
upper case letters, and the leading code "datalinex" is lower case:
line: "datalinex HFD 111.11 N012.11.099 E034.31.114"
Next mistake is here:
digits: charset "0123456789"
Note that a charset only matches one character. So the above character set
should be the singular (one) "digit" not the plural (many) "digits". Let's
make that change now:
digit: charset "0123456789"
Next mistake is here:
alpha: charset "abcdefghijklmnopqrstuvwxyz"
Note that these are only the lower case letters, not the uppercase letters.
So it's the wrong name. But better is a rule for upper and lower case
letters, like these (from my %Patterns.r script):
Upper: charset [#"A" - #"Z"]
Lower: charset [#"a" - #"z"]
Alpha: union Upper Lower
Another mistake is:
whitespace: #" "
That's actually a space character. What's better is this:
SP: #" "
HT: #"^-"
LWS: charset reduce [SP HT #"^(A0)"]
WS: charset reduce [SP HT newline CR LF]
Now onto the rule:
rule: [any alpha 1 whitespace 3 digits 1 dot 2 digits]
which, apart from the word changes above, needs to be carefully checked
against the data format:
line: "datalinex HFD 111.11 N012.11.099 E034.31.114"
Note that the "HFD" doesn't have a match in the rule, so the rule will fail.
So let's write it out in English:
some lower-case letters, a space, three upper-case letters, three
digits, Period (or dot) two digits, a space, a uppercase letter, 3 digits,
dot, 2 digits, dot, 3 digits, a uppercase letter, 3 digits, dot, 2 digits,
dot, 3 digits.
That's pretty easy to convert to Rebol parse words now:
Rule: [
some Lower
SP
3 Upper SP 3 Digit Dot 2 Digit
SP
Upper 3 Digit Dot 2 Digit Dot 3 Digit
SP
Upper 3 Digit Dot 2 Digit Dot 3 Digit ; Note the duplication!
]
probe parse/all/case line Rule
And trying it out:
>> probe parse/all/case line Rule
true
== true
Success!
Notice that there is a duplication in the rule? It's a really good idea to
remove the duplicated values and say the rule once and once only.
> You mentioned a "pattern.r-file" written by you - is there any
documenation available on the actual usage of your library file ?
It hardly needs documenting. Just a simple 'do before using it in other
scripts. I've sent a copy directly to you.
Andrew J Martin
Speaking in tongues and performing miracles.
ICQ: 26227169
http://www.rebol.it/Valley/
http://valley.orcon.net.nz/
http://Valley.150m.com/
[9/11] from: AJMartin:orcon at: 24-Dec-2003 22:49
Mike wrote:
> If instead the editor would be doing background parsing and watch me
create an object or button it could really support me by displaying all
possible options with that element.
Hi, Mike.
I can see that you like the idea of C and Java IDEs. Unfortunately, Rebol
script is way too malleable and versatile for a IDE to tease it apart and
offer help. That's because words can mean many different things in the same
script, as opposed to C or Java where a word means one thing and one thing
only. For example when I write (in C#, but the principle still applies):
class Mesh {
static string title = "Mesh";
static public string Title {
get {
A C# IDE would realise that I'm writing a accessor method and can
automatically produce the appropriate "cruft" like ";" "{" and "}" and even
suggest apropriate text for me to type in or select from a drop-down list.
But with Rebol and it's support for dialects where words mean what you want
them to mean, a IDE for Rebol is build upon "shifting sand". Consider a IDE
trying to understand my Envelope function:
Envelope: func [Head [block!] Body [block!]] [
print rejoin [
"Content-Type: " 'text/html newline
newline
ML compose/deep [<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.1 plus MathML 2.0 plus SVG 1.1//EN"
"http://www.w3.org/2002/04/xhtml-math-svg/xhtml-math-svg.dtd">
html [
head [(Head)]
body [(Body)]
]
]
]
quit
]
Here's the 'help function on 'head:
>> help head
USAGE:
HEAD series
DESCRIPTION:
Returns the series at its head.
HEAD is an action value.
ARGUMENTS:
series -- (Type: series port)
And on my 'envelope function:
>> help envelope
USAGE:
ENVELOPE Head Body
DESCRIPTION:
(undocumented)
ARGUMENTS:
Head -- (Type: block)
Body -- (Type: block)
Note that the 'head inside the 'Envelope function means create a XHTML head
tag and the 'Head inside the parenthesis means to insert the contents of the
first parameter 'Head to the 'Envelope function! How would the IDE know this
with out being artificially intelligent? :)
> P.S.: Does this list support attachments (ascii) ? Cause, actually I
attached some code with my last mail but didn't see it on line (listview) -
are the attachments extracted ?
I think that attachements are absorbed without being passed on.
Andrew J Martin
Speaking in tongues and performing miracles.
ICQ: 26227169
http://www.rebol.it/Valley/
http://valley.orcon.net.nz/
http://Valley.150m.com/
[10/11] from: greggirwin:mindspring at: 22-Nov-2003 9:54
Hi Mike,
I'm pretty sure I've seen someone mention before here that they were
doing some work against this type of GIS file. Anyone remember who?
ML> On "altme", the chat client: I am certainly going to have a look into it !
ML> Are many of you really using it ?
Yes!
ML> Unfortunately, the documentation about using actions & events with REBOL
ML> view isn't very
ML> good either - I was practically 'learning' by looking at example code from
ML> others.
The How-To docs section on REBOL.com has some good stuff in it.
(http://www.rebol.com/how-to/feel.html) EasyVID and (Brett's?)
VIDNotes are other good resources.
ML> If instead the editor would be doing background parsing and watch me create
ML> an object
ML> or button it could really support me by displaying all possible options with
ML> that element.
I did a little test mod of the plain REBOL editor that emulates
Intellisense, but it's been collecting dust for a while. It was a very
crude demonstration of the concept, but it would show a list of elements
in an object, or the interface for a function (as a tooltip in the
latter case). As Andrew said, making it context aware is the tricky
part. Probably doable, but would take a bit of work.
-- Gregg
[11/11] from: nitsch-lists::netcologne::de at: 23-Nov-2003 7:09
Am Samstag, 22. November 2003 08:40 schrieb A J Martin:
> Mike wrote:
> > If instead the editor would be doing background parsing and watch me
<<quoted lines omitted: 6>>
> script, as opposed to C or Java where a word means one thing and one thing
> only.
Smalltalk has the same problem, because a method can be defined in a lot of
classes, and there is no type-declaration.
Smalltalk simply shows all possible methods.
(thats not too many usually, because of long method-names)
We could do a similar thing, presenting multiple suggestions for a word.
{
any:
rebol:like "or in other languages
parse: like a loop
}
clicking on pops up longer explanation. contexts could add own descriptions to
the help-db, like
{
any:
vid: a very weird style to show any rebol-type.
}
-Volker
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted