Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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