Browsers ,vim Vs. Emacs etc....
[1/9] from: athiele::abraxis::com at: 15-Mar-2002 16:44
Why not stick to the topic ? I believe this is the Rebol list.
Can we please discuss Rebol issues rather than aol`s intent with netscape
what your favorite OS is, or Why Emacs is so cool?
I have already received invaluable help from others with Rebol
programming.
but the non Rebol related issues are getting out of hand.
Maybe it`s me, and I should just unsubscribe.
Adrian
[2/9] from: sunandadh:aol at: 15-Mar-2002 17:51
Adrian:
> Why not stick to the topic ? I believe this is the Rebol list.
Apologies if I've helped with the topic drift -- this list is remarkable for
staying on topic -- and for being flame retardant, so hang in a bit longer.
The signal to noise ratio is exemplary.
Normally the digressions -- when they occur -- are towards computer science /
language design rather than commercial browser issues.
Perhaps this digression is a sign of the list becoming a bit more
commercially savvy. Or maybe it's just spring up here in the northern
hemisphere, and we're all getting a bit frisky.
Writing standards-compliant, platform-independent, widely-deployable code are
key issues for me. They are reasons for me to want to use Rebol. So questions
around these issues raise my interest.
Oh, and Joel: as an ex-CICS systems programmer who has taught COBOL
programming in the dim and distant, I can tell you that 75 to 80 of the
world's business data is held in people's head, or on paper in TSU/SSU (*)
Sunanda.
(*) Supposed IBMese for Tall and Short Storage Units -- filing cabinets to us
plebs.
[3/9] from: al:bri:xtra at: 16-Mar-2002 12:08
Browser and OS wars get out of hand really quickly. So please talk this talk
elsewhere.
Let's make this a place for Rebol!
BTW, I've updated my site. There's new stuff in my:
http://valley.150m.com/Rebol/Values.r
script.
Anyone know why the next version of Rebol/Core isn't out yet? :)
Andrew Martin
ICQ: 26227169 http://valley.150m.com/
[4/9] from: joel:neely:fedex at: 15-Mar-2002 19:27
Hi, Adrian,
Adrian wrote:
> Why not stick to the topic ? I believe this is the Rebol
> list. Can we please discuss Rebol issues rather than aol`s
<<quoted lines omitted: 3>>
> Rebol programming. but the non Rebol related issues are
> getting out of hand.
Fair enough. (And spoken like a gentleman.)
-jn-
--
; sub REBOL {}; sub head ($) {@_[0]}
REBOL []
# despam: func [e] [replace replace/all e ":" "." "#" "@"]
; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"}
print head reverse despam "moc:xedef#yleen:leoj" ;
[5/9] from: joel:neely:fedex at: 15-Mar-2002 19:45
Hi, Sunanda,
[SunandaDH--aol--com] wrote:
> Oh, and Joel: as an ex-CICS systems programmer who has taught
> COBOL programming in the dim and distant, I can tell you that
> 75 to 80 of the world's business data is held in people's head,
> or on paper in TSU/SSU (*)
>
> (*) Supposed IBMese for Tall and Short Storage Units -- filing
> cabinets to us plebs.
>
ROFL! Thanks, I needed that!
ObRebolRelevance:
This brings to mind a topic I've pondered over the years, and
which I think was mentioned on this list a while back.
Since much data from mainframes, or obtained via OCR (from TSU/SSU
sources, of course! ;-), is in fixed-record layout, it would be
interesting to have a program that would attempt to infer "field"
positions and lengths by examining the content of the data.
This would involve a heuristic approach IMHO.
There are "horizontal" issues, such as the fact that alphanumeric
fields (e.g. names and addresses) are typically left-justified
and right-padded with blanks, while numeric fields are typically
either right-justified or decimal-position aligned, and left-
padded with either zeros or blanks.
There are also "vertical" issues, in that a series of lines with
the same content in the same position(s) probably contain hints
about the fields. When trailing blanks (after alphanumeric data)
in some lines are replaced with alphanumeric data and fewer
trailing blanks, that's a hint of a variable alphanumeric field.
etc...
Wouldn't REBOL be a good tool to write such a sort-of-AI task in?
Wouldn't that make an interesting demonstration of the power of
REBOL for the commercial/business environment?
-jn-
(But I do think the guy quoted in the article meant "electronic
business data"...)
--
; sub REBOL {}; sub head ($) {@_[0]}
REBOL []
# despam: func [e] [replace replace/all e ":" "." "#" "@"]
; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"}
print head reverse despam "moc:xedef#yleen:leoj" ;
[6/9] from: greggirwin:mindspring at: 16-Mar-2002 11:31
Joel, et al
<< Since much data from mainframes, or obtained via OCR (from TSU/SSU
sources, of course! ;-), is in fixed-record layout, it would be
interesting to have a program that would attempt to infer "field"
positions and lengths by examining the content of the data. >>
Do you remember our "table parsing" discussion some time ago? This strikes
me as a very similar problem, but with some added rules that may make things
a little trickier.
I'm not a COBOL/CICS/Mainframe guy, but I have had to deal with their data
at times. Most recently, I wrote a copy-lib parser (pseudo parser is
probably more accurate) so I could extract the format of a record and
generate a VB class from it, which then understands how to convert data
to/from a fixed buffer, but provides a native object for use in VB authored
apps. Records come and go via TCP sockets.
I haven't seen any really good examples of dealing with fixed length data in
REBOL, but it should certainly be possible. Start with a good dialect on the
REBOL side. Given a copylib, you could generate code in the dialect, or
maybe just interpret the copylib directly. The biggest problems I ran into
were strange and ambiguous things in copylibs. If you wanted it to be
complete, it would have to cover a pretty wide range of possibilities, but
PARSE should be well up to the task.
--Gregg
[7/9] from: petr:krenzelok:trz:cz at: 17-Mar-2002 1:11
Joel Neely wrote:
>Since much data from mainframes, or obtained via OCR (from TSU/SSU
>sources, of course! ;-), is in fixed-record layout, it would be
>interesting to have a program that would attempt to infer "field"
>positions and lengths by examining the content of the data.
>
Hmm, what is the problem? :-) I did some work here. We use CICS systems
in our company (till we move fully to SAP R3). Guys prepare download/job
for us, it is on AIX side, and we download it using http (I just wrapped
our programmer's solution, as they suggested to download my files
manually using IE) .....
>This would involve a heuristic approach IMHO.
>
>There are "horizontal" issues, such as the fact that alphanumeric
>fields (e.g. names and addresses) are typically left-justified
>and right-padded with blanks, while numeric fields are typically
>either right-justified or decimal-position aligned, and left-
>padded with either zeros or blanks.
>
Yes, and there is no problem, is there any? The record has fixed length
field structure and that is important. Anyway, what we do is - we import
(append) such data into .dbf files (simple one command in foxpro/clipper
- "use empty.dbf", "append from downloaded.txt" ...
One day I needed to do some stuff and I wanted to use Rebol. So I opened
our dbf maintaining tool, and exported structure by typing "copy stru to
struct.txt". It nicely prints structure to the text file, telling me
filed names, field types, their length, etc. I created small function,
which parses such definition file and I called it "stru: get-structure
struct.txt". It returns rebol object.
Then I use "read/lines" in rebol and "foreach record file [rec:
map-object stru record .....]" to process the file. I don't do any
automatic type conversion, as I don't need it yet, but there is no
problem making 'map-object function clever enough to do some type
conversion ...
>There are also "vertical" issues, in that a series of lines with
>the same content in the same position(s) probably contain hints
<<quoted lines omitted: 3>>
>etc...
>Wouldn't REBOL be a good tool to write such a sort-of-AI task in?
Well, I either don't understand the problem correctly, or I just can
find out, why to call such trivial task being an AI issue :-) With
Rebol, it is fun, not an AI :-)
>Wouldn't that make an interesting demonstration of the power of
>REBOL for the commercial/business environment?
>
business environments use SQL or ODBC imo or XBase tools at least imo ....
Cheers,
-pekr-
[8/9] from: joel:neely:fedex at: 17-Mar-2002 14:59
Hi, Petr,
Petr Krenzelok wrote:
> Hmm, what is the problem? :-) I did some work here. We use CICS
> systems in our company (till we move fully to SAP R3). Guys
> prepare download/job for us... The record has fixed length
> field structure and that is important...
>
> Well, I either don't understand the problem correctly, or I just
> can find out, why to call such trivial task being an AI issue :-)
>
I wasn't thinking about the cases when I'm handed a fixed-record
data file with documentation of the field layouts, nor the cases
in which someone else has done the work to format/download the
data for me. (I wish life were always that simple...)
I'm thinking of those times when I've had the fun of figuring out
the data layout for myself after being handed a file without the
necessary documentation, for a variety of reasons:
- there's no documentation nor source code for the creation of
the file,
- it was data extracted from a proprietary package from a defunct
vendor,
- the file was custom-constructed by someone who has since left
the company, the city, the country, and (possibly) this earth;
- etc...
The reason I refer to the task as AI-like is that a human being,
especially one who knows the problem domain, can often make good
guesses/inferences about field positions/locations based on such
things as common encoded data, familiar items (e.g. dates, times,
employee or account numbers, monetary figures, etc.) However,
such inferences/guesses are often context sensitive and subject
to change as more data become available.
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
[9/9] from: petr:krenzelok:trz:cz at: 18-Mar-2002 6:23
Joel Neely wrote:
>Hi, Petr,
>Petr Krenzelok wrote:
<<quoted lines omitted: 19>>
>- the file was custom-constructed by someone who has since left
> the company, the city, the country, and (possibly) this earth;
:-)) ... or the file comes from some UFO? ;-) Well, generally speaking -
it is a bad situation, if you have to analyse some data with zero level
info ...
>- etc...
>The reason I refer to the task as AI-like is that a human being,
<<quoted lines omitted: 4>>
>such inferences/guesses are often context sensitive and subject
>to change as more data become available.
Yes. I am not sure some kind of AI based automat can sort it out
properly. I too, ended in situation when I obtained mainframe csv file,
not knowing the structure. We did it manually that way - we started to
define .dbf file, guessing what the structure could be. What helped us
was, we knew what some data mean/represent (e.g. recognising customer
name, contract description, etc.) ...
So, I can leave this thread, as I have really no knowledge of how to
build the system you described. I have even never seen something along
the lines of AI automat digging into some data ....
-pekr-
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted