Hello all,
I have a simple question...
Suppose I have a text file called /home/users/me/data.txt that looks
like this
a, 1, 2, 3,
b, 4, 5, 6
c, 7, 8, 9
d, 10, 11, 12
What Common LISP commands would I need in order to be able to read
that file into an array in LISP?
And conversly, if I have an array in LISP what commands do I need to
be able to write the array to a file?
Thanks in advance.
-Nonzero
In article <····························@posting.google.com>,
··········@hotmail.com (Nonzero) wrote:
>Hello all,
>
>I have a simple question...
>
>Suppose I have a text file called /home/users/me/data.txt that looks
>like this
>
>a, 1, 2, 3,
>b, 4, 5, 6
>c, 7, 8, 9
>d, 10, 11, 12
>
>What Common LISP commands would I need in order to be able to read
>that file into an array in LISP?
Well, readline and aref would probably both be useful, and maybe LOOP.
>And conversly, if I have an array in LISP what commands do I need to
>be able to write the array to a file?
For this, map or one of its friends would probably be nice, as would format.
paul
··········@hotmail.com (Nonzero) writes:
> Hello all,
>
> I have a simple question...
>
> Suppose I have a text file called /home/users/me/data.txt that looks
> like this
>
> a, 1, 2, 3,
> b, 4, 5, 6
> c, 7, 8, 9
> d, 10, 11, 12
>
> What Common LISP commands would I need in order to be able to read
> that file into an array in LISP?
Questions:
- Is a supposed to be the string "a", or the symbol 'A?
- Is 1 an integer? Or the string "1"?
- You have commas in some places, and not in others. Is that
important?
There's not generally a _trivial_ way to do this; there are enough
questions like the above to lead to the answer consisting of quite a
number of details...
> And conversly, if I have an array in LISP what commands do I need to
> be able to write the array to a file?
That's generally easier; either a nested loop to write values, or a
straight write of the array itself.
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://www.cbbrowne.com/info/lsf.html
PURITAS NECESSE EST -- DON'T DO RANDOM BINDINGS.
From: ···@itasoftware.com
Subject: Re: Simple question about arrays and files.
Date:
Message-ID: <elnh9qdx.fsf@itasoftware.com>
········@acm.org writes:
> ··········@hotmail.com (Nonzero) writes:
> > Hello all,
> >
> > I have a simple question...
> >
> > Suppose I have a text file called /home/users/me/data.txt that looks
> > like this
> >
> > a, 1, 2, 3,
> > b, 4, 5, 6
> > c, 7, 8, 9
> > d, 10, 11, 12
> >
> > What Common LISP commands would I need in order to be able to read
> > that file into an array in LISP?
>
> Questions:
> - Is a supposed to be the string "a", or the symbol 'A?
> - Is 1 an integer? Or the string "1"?
> - You have commas in some places, and not in others. Is that
> important?
>
> There's not generally a _trivial_ way to do this; there are enough
> questions like the above to lead to the answer consisting of quite a
> number of details...
I had once to parse some random non-lisp format. The easiest way I
found to do it was to write a SED script that converted the non-lisp
stuff into something READ could handle.
In this case, you could go a long ways by prepending a "#2a(",
postpending a ")", removing the commas and putting a paren around each
line.
For things that are a bit hairier, a LEX script can do it.
I hesitate to recommend SED, LEX, and AWK, but they seem to be fairly
useful for converting random crap into a more regular format.
···@itasoftware.com writes:
> I hesitate to recommend SED, LEX, and AWK, but they seem to be fairly
> useful for converting random crap into a more regular format.
I don't know. They make it seem easy, but it's not, so I'm always
scared to death of the result, figuring they misssed lots of cases,
and it's entirely possible I'll get weird crap out of the "good" end
of the sed pipe. I end out doing so much checking of the input, it
would have been easier to have dealt with the random crap in a real
language.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: ···@itasoftware.com
Subject: Re: Simple question about arrays and files.
Date:
Message-ID: <u1wc6dk3.fsf@itasoftware.com>
···@hurricane.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> ···@itasoftware.com writes:
>
> > I hesitate to recommend SED, LEX, and AWK, but they seem to be fairly
> > useful for converting random crap into a more regular format.
>
> I don't know. They make it seem easy, but it's not, so I'm always
> scared to death of the result, figuring they misssed lots of cases,
> and it's entirely possible I'll get weird crap out of the "good" end
> of the sed pipe. I end out doing so much checking of the input, it
> would have been easier to have dealt with the random crap in a real
> language.
It's a quick and dirty hack (as is anything in sed, lex, awk, or
perl), not a production solution.
In article <············@itasoftware.com>, "jrm" <···@itasoftware.com>
wrote:
> ···@hurricane.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
>> ···@itasoftware.com writes:
>>
>> > I hesitate to recommend SED, LEX, and AWK, but they seem to be fairly
>> > useful for converting random crap into a more regular format.
>>
>> I don't know. They make it seem easy, but it's not, so I'm always
>> scared to death of the result, figuring they misssed lots of cases, and
>> it's entirely possible I'll get weird crap out of the "good" end of the
>> sed pipe. I end out doing so much checking of the input, it would have
>> been easier to have dealt with the random crap in a real language.
>
> It's a quick and dirty hack (as is anything in sed, lex, awk, or perl),
> not a production solution.
I dont know. I think the value of sed, lex, and soforth is underestimated.
Often we get something that is the output of some program and we want to
read it back in to something we're writing. The program produces
reasonably consistent output, it's just not very happily formatted output.
In this kind of instance, sed and lex and soforth (not perl in my opinion)
are excellent tools. The fact that the input to the sed or lex program is
computer generated means that it is generally possible to write a correct
program that reformats it all concisely.
In this case, I think sed, lex, awk, M4 and soforth are excellent
production level choices vs hand writing a slow lexer or parser that has
exactly the same set of potential problems as the concise version in
lex/sed/yacc/awk/m4/textutils.
From: Tim Bradshaw
Subject: Re: Simple question about arrays and files.
Date:
Message-ID: <ey3itct19ch.fsf@cley.com>
* jrm wrote:
> I hesitate to recommend SED, LEX, and AWK, but they seem to be fairly
> useful for converting random crap into a more regular format.
This is really bad advice. sed lex and awk will let you convert
stuff, of course, but they suffer from two enormous problems. Firstly
they're only slightly less unfashionable than Lisp, so they hardly
help on your CV at all. Secondly - also in common with Lisp - the
programs you write will be fairly short and comprehensible, so you'll
have hardly any job security. You should use perl instead: it's both
fashionable and completely opaque, thus ensuring that you have good
job security and if you do lose your job you have cool stuff on your
CV. For added value you should use XML as an intermediate format, and
parse this with a Java program, using corba for something-or-other
(you're bound to need it).
--tim
From: ···@itasoftware.com
Subject: Re: Simple question about arrays and files.
Date:
Message-ID: <k7x989x9.fsf@itasoftware.com>
> * jrm wrote:
>
> > I hesitate to recommend SED, LEX, and AWK, but they seem to be fairly
> > useful for converting random crap into a more regular format.
Tim Bradshaw <···@cley.com> writes:
> This is really bad advice. You should use perl instead: it's both
> fashionable and completely opaque, thus ensuring that you have good
> job security and if you do lose your job you have cool stuff on your
> CV. For added value you should use XML as an intermediate format, and
> parse this with a Java program, using corba for something-or-other
> (you're bound to need it).
I have to agree with Tim on this one. Not only will perl and XML look
better on your resume, it will require so much scaffolding that your
employer won't be able to help but be impressed with how hard you are
working. XML is a great way to enable one to expend heroic efforts on
trivial tasks.
···@itasoftware.com writes:
> > * jrm wrote:
> >
> > > I hesitate to recommend SED, LEX, and AWK, but they seem to be fairly
> > > useful for converting random crap into a more regular format.
>
> Tim Bradshaw <···@cley.com> writes:
>
> > This is really bad advice. You should use perl instead: it's both
> > fashionable and completely opaque, thus ensuring that you have good
> > job security and if you do lose your job you have cool stuff on your
> > CV. For added value you should use XML as an intermediate format, and
> > parse this with a Java program, using corba for something-or-other
> > (you're bound to need it).
>
> I have to agree with Tim on this one. Not only will perl and XML look
> better on your resume, it will require so much scaffolding that your
> employer won't be able to help but be impressed with how hard you are
> working. XML is a great way to enable one to expend heroic efforts on
> trivial tasks.
Aack! You can learn sed and awk *before* perl. That's what I did,
and I've never regretted it. Perl draws directly from both, so you'll
understand perl's roots more completely. Perl is the more general,
powerful tool, but sed and awk are still great tools for small tasks.
ps -ef | awk '/[s]yslogd/ { system("kill " $2) }'
You can do it in perl, but it's less apropos, and perl is a bigger
process:
ps -ef | perl -na -e 'system("kill $F[1]") if /[s]yslogd/'
The biggest benefit, though, is that your comprehension of UNIX will
increase, since you will be familiar with the old school (e.g. sed
with non-extended regular expressions), the new school (perl with
sophisticated regular expressions), and the transition (awk with
extended regular expressions). You'll also be more comfortable
working with the "lowest common denominator" on old or weird UNIX
systems.
The more you can learn the better! There's no need to avoid good
tools (e.g., sed, awk, and lex) just because they won't look good on
your C.V. You can learn perl *and* the others.
--
--Ed Cashin integrit file-verification system:
·······@terry.uga.edu http://integrit.sourceforge.net/
Note: If you want me to send you email, don't munge your address.
In article <··············@terry.uga.edu>, "Ed L Cashin"
<·······@terry.uga.edu> wrote:
> The more you can learn the better! There's no need to avoid good tools
> (e.g., sed, awk, and lex) just because they won't look good on your C.V.
> You can learn perl *and* the others.
I think you missed the sarcasm in the previous articles.
"Daniel Lakeland" <········@silnospamcon.com> writes:
> In article <··············@terry.uga.edu>, "Ed L Cashin"
> <·······@terry.uga.edu> wrote:
>
> > The more you can learn the better! There's no need to avoid good tools
> > (e.g., sed, awk, and lex) just because they won't look good on your C.V.
> > You can learn perl *and* the others.
>
> I think you missed the sarcasm in the previous articles.
Oh, I'm sorry. You are right. This community is a bit more cynical
than I'm used to. ;)
--
--Ed Cashin integrit file-verification system:
·······@terry.uga.edu http://integrit.sourceforge.net/
Note: If you want me to send you email, don't munge your address.
"Daniel Lakeland" <········@silnospamcon.com> writes:
> In article <··············@terry.uga.edu>, "Ed L Cashin"
> <·······@terry.uga.edu> wrote:
>
> > The more you can learn the better! There's no need to avoid good tools
> > (e.g., sed, awk, and lex) just because they won't look good on your C.V.
> > You can learn perl *and* the others.
>
> I think you missed the sarcasm in the previous articles.
Oh, I'm sorry. You are right. I skimmed the article. This community
is a bit more cynical than I'm used to. ;)
--
--Ed Cashin integrit file-verification system:
·······@terry.uga.edu http://integrit.sourceforge.net/
Note: If you want me to send you email, don't munge your address.
Daniel Barlow <···@telent.net> writes:
> Ed L Cashin <·······@terry.uga.edu> writes:
>
> > ps -ef | awk '/[s]yslogd/ { system("kill " $2) }'
>
> Don't Try This At Home, Kids. Or anywhere, in fact.
>
> :; cd /tmp
> :; cat >foo
> #!/bin/sh
> sleep 86400
> :; chmod +x foo
> ;; ln foo '-0 0 ;cd;cd ..;cd etc;rm * syslogd'
> :; ./'-0 0 ;cd;cd ..;cd etc;rm * syslogd' &
>
> and now wait for root to run the command quoted above.
That is fancy, but on my machine it won't do anything but kill the
sleeper, since $2 in the awk code is the second whitespace-delimited
column of output from "ps -ef", which is the PID.
On what kind of system would that do anything harmful?
--
--Ed Cashin integrit file-verification system:
·······@terry.uga.edu http://integrit.sourceforge.net/
Note: If you want me to send you email, don't munge your address.
Ed L Cashin <·······@terry.uga.edu> writes:
> > > ps -ef | awk '/[s]yslogd/ { system("kill " $2) }'
I wrote:
> > :; ./'-0 0 ;cd;cd ..;cd etc;rm * syslogd' &
Ed wrote:
> That is fancy, but on my machine it won't do anything but kill the
> sleeper, since $2 in the awk code is the second whitespace-delimited
> column of output from "ps -ef", which is the PID.
Yeah, I'm sorry. I wrote it under the mistaken impression that I
was thinking straight.
I should have stuck to the more general message "this will kill all of
your processes that have ``syslogd'' anywhere in their arguments; this
is probably a bad thing". For example, sendmail rewrites its command
line as it goes merrily about its business; if I had more time to poke
at the sendmail source I'm sure I could contrive an example which
would kill a sendmail process or two.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> Ed L Cashin <·······@terry.uga.edu> writes:
> > > > ps -ef | awk '/[s]yslogd/ { system("kill " $2) }'
>
> I wrote:
> > > :; ./'-0 0 ;cd;cd ..;cd etc;rm * syslogd' &
>
> Ed wrote:
> > That is fancy, but on my machine it won't do anything but kill the
> > sleeper, since $2 in the awk code is the second whitespace-delimited
> > column of output from "ps -ef", which is the PID.
>
> Yeah, I'm sorry. I wrote it under the mistaken impression that I
> was thinking straight.
>
> I should have stuck to the more general message "this will kill all of
> your processes that have ``syslogd'' anywhere in their arguments; this
> is probably a bad thing". For example, sendmail rewrites its command
> line as it goes merrily about its business; if I had more time to poke
> at the sendmail source I'm sure I could contrive an example which
> would kill a sendmail process or two.
Sure, yes. That's a good point. If you're concerned about that
danger, as you should be in automated scripts, for example, you'd have
to be more specific than my "kill everything that looks like syslogd".
--
--Ed Cashin integrit file-verification system:
·······@terry.uga.edu http://integrit.sourceforge.net/
Note: If you want me to send you email, don't munge your address.
Tim wrote:
> For added value you should use XML as an intermediate format, and
> parse this with a Java program, using corba for something-or-other
> (you're bound to need it).
in order to forfill your patriotic duty and keep the American economy
afloat -- as this will cripple the speed of execution sufficiently to
require everbody to buy a 4.7THz RISC processor running on an E15k
supercomputer...
:)w
Tim Bradshaw <···@cley.com> writes:
> * jrm wrote:
>
> > I hesitate to recommend SED, LEX, and AWK, but they seem to be fairly
> > useful for converting random crap into a more regular format.
>
> This is really bad advice. sed lex and awk will let you convert
> stuff, of course, but they suffer from two enormous problems. Firstly
> they're only slightly less unfashionable than Lisp, so they hardly
> help on your CV at all. Secondly - also in common with Lisp - the
> programs you write will be fairly short and comprehensible, so you'll
> have hardly any job security. You should use perl instead: [...]
In addition to these 3/2 good reasons, the second one being apparently
only 1/2-serious, you should add: portability.
If one is doing one's primary programming in an application and a
particular subproblem is only trivially easier in another language, it
isn't worth the configuration problems of using two languages. There
are good reasons to sometimes resort to other languages, but this is
not one of them.
From: Tim Bradshaw
Subject: Re: Simple question about arrays and files.
Date:
Message-ID: <ey37kt911o2.fsf@cley.com>
* Kent M Pitman wrote:
> If one is doing one's primary programming in an application and a
> particular subproblem is only trivially easier in another language, it
> isn't worth the configuration problems of using two languages. There
> are good reasons to sometimes resort to other languages, but this is
> not one of them.
I'm not sure I can parse this right, but if you're implying that perl
is less languages than awk sed and lex, I think that this is clearly
wrong. perl is more languages than any finite number of languages.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Kent M Pitman wrote:
> > If one is doing one's primary programming in an application and a
> > particular subproblem is only trivially easier in another language, it
> > isn't worth the configuration problems of using two languages. There
> > are good reasons to sometimes resort to other languages, but this is
> > not one of them.
>
> I'm not sure I can parse this right, but if you're implying that perl
> is less languages than awk sed and lex, I think that this is clearly
> wrong. perl is more languages than any finite number of languages.
But of course, Lisp is an even greater (non-finite) number of
languages, because with much pain and hacking at the reader, and much
macrology, one could include the Perl languages in Lisp (left as an
exercise to the reader). I don't belive the reverse is possible.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: ···@itasoftware.com
Subject: Re: Simple question about arrays and files.
Date:
Message-ID: <y9lo6dlp.fsf@itasoftware.com>
···@hurricane.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Tim Bradshaw <···@cley.com> writes:
>
> > * Kent M Pitman wrote:
> > > If one is doing one's primary programming in an application and a
> > > particular subproblem is only trivially easier in another language, it
> > > isn't worth the configuration problems of using two languages. There
> > > are good reasons to sometimes resort to other languages, but this is
> > > not one of them.
> >
> > I'm not sure I can parse this right, but if you're implying that perl
> > is less languages than awk sed and lex, I think that this is clearly
> > wrong. perl is more languages than any finite number of languages.
>
> But of course, Lisp is an even greater (non-finite) number of
> languages, because with much pain and hacking at the reader, and much
> macrology, one could include the Perl languages in Lisp (left as an
> exercise to the reader). I don't belive the reverse is possible.
OH, it is, but that way lies insanity.
···@itasoftware.com wrote in message news:<············@itasoftware.com>...
> ···@hurricane.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> > But of course, Lisp is an even greater (non-finite) number of
> > languages, because with much pain and hacking at the reader, and much
> > macrology, one could include the Perl languages in Lisp (left as an
> > exercise to the reader). I don't belive the reverse is possible.
>
> OH, it is, but that way lies insanity.
Have you looked at the stuff that is apparently going to be in perl 6,
and the things that are already in perl 5? They have closures already
(they even call them closures), and there seems to be a whole lot more
Lisp stuff in perl 6. Not only is it possible, but they seem to be
going all-out to do it as far as I can tell. And perl people
generally regard insanity as the single most desirable feature in a
language so that won't stop them.
Of course they probably don't understand what it it they are doing and
would deny it if they did, and they will probably always fail to meet
some important criteria such as a syntax statistically distinguishable
from line noise...
--tim
From: Juliusz Chroboczek
Subject: Re: Simple question about arrays and files.
Date:
Message-ID: <87lmhius1q.fsf@pps.jussieu.fr>
Tim Bradshaw:
>> > one could include the Perl languages in Lisp (left as an
>> > exercise to the reader). I don't belive the reverse is possible.
TB> Have you looked at the stuff that is apparently going to be in perl 6,
TB> and the things that are already in perl 5?
I have. It made me sick.
The main reason why Lisp is such a simple and elegant language is that
everything is (conceptually) a reference to an object with indefinite
extent. You'll never get this property by adding new features to a
language that doesn't have it in the first place. (Smart quotation by
Tony Hoare elided.)
(X3J13 tried to destroy this property by including the DYNAMIC-EXTENT
declaration. The careful wording of the X3J13 issue shows how uneasy
some people felt about this ``feature''.)
Juliusz
Juliusz Chroboczek <···@pps.jussieu.fr> writes:
> The main reason why Lisp is such a simple and elegant language is that
> everything is (conceptually) a reference to an object with indefinite
> extent. You'll never get this property by adding new features to a
> language that doesn't have it in the first place. (Smart quotation by
> Tony Hoare elided.)
>
> (X3J13 tried to destroy this property by including the DYNAMIC-EXTENT
> declaration. The careful wording of the X3J13 issue shows how uneasy
> some people felt about this ``feature''.)
In my dialect of English, one required element of "to try" is "to intend
as a primary consequence". To either "not intend" or "not have as a
primary intent" is a defense. (For example, to be topical, the US are
NOT "trying" to kill civilians in Afghanistan even though they are doing
deliberate things whose outcome is sometimes known to lead to this; the
civilian casualty result is "collateral", and if another way could be found
to achieve the primary purpose without such collateral effect, it would be.)
Back to "more important" matters, X3J13 did not "try" to cause the effect
you suggest; that was collateral damage, IMO.
[Spin control:] What X3J13 actually tried to do was to reduce the market
pressure to dump the language entirely for C because Lisp forced you
to cons in situations where it wasn't obviously needed and this made
it look gratuitously like a language meant for people who want to
micro-manage storage allocation was a better language. DYNAMIC-EXTENT
is very much a survival characteristic that has helped to show that
one can get program efficiency without being overly concrete. The
careful wording of the issue is, in part, related to the concern about
not overspecifying it and consequently tying implementations to doing
it in only one possible way.
Also, sometimes that kind of thing becomes due to the particular
individuals that are involved in the discussion/proposal and their
personal style of wording. As the comments section of that proposal
notes, there were two competing presentations, and Steele's version
was preferred for sounding more formal. (Perhaps making it sound
better thought out, though as I recall he made it up rather hastily
over a lunch break in an in-person meeting, and I was quite surprised
it survived the test of time... Then again, we could have patched it
with a later cleanup issue if a mistake had been made, but we fortunately
found no need.)
From: Juliusz Chroboczek
Subject: Re: Simple question about arrays and files.
Date:
Message-ID: <87hes5b46m.fsf@pps.jussieu.fr>
>> The main reason why Lisp is such a simple and elegant language is that
>> everything is (conceptually) a reference to an object with indefinite
>> extent.
>> (X3J13 tried to destroy this property by including the DYNAMIC-EXTENT
>> declaration.
Kent M Pitman:
KMP> In my dialect of English, one required element of "to try" is "to
KMP> intend as a primary consequence".
So it is in the one that my teachers painstakingly tried to teach me.
Sorry if my formulation was overly provocative.
(Ceterum censeo DYNAMIC-EXTENT to be a shameful wart.)
Juliusz
Thomas F. Burdick wrote:
> But of course, Lisp is an even greater (non-finite) number of
> languages, because with much pain and hacking at the reader, and much
> macrology, one could include the Perl languages in Lisp (left as an
> exercise to the reader). I don't belive the reverse is possible.
Hmmm. This depends whether scheme is a lisp or not...
;)w
···@itasoftware.com writes:
> ········@acm.org writes:
>
> > ··········@hotmail.com (Nonzero) writes:
> > > Hello all,
> > >
> > > I have a simple question...
> > >
> > > Suppose I have a text file called /home/users/me/data.txt that looks
> > > like this
> > >
> > > a, 1, 2, 3,
> > > b, 4, 5, 6
> > > c, 7, 8, 9
> > > d, 10, 11, 12
> > >
> > > What Common LISP commands would I need in order to be able to read
> > > that file into an array in LISP?
> >
> > Questions:
> > - Is a supposed to be the string "a", or the symbol 'A?
> > - Is 1 an integer? Or the string "1"?
> > - You have commas in some places, and not in others. Is that
> > important?
> >
> > There's not generally a _trivial_ way to do this; there are enough
> > questions like the above to lead to the answer consisting of quite a
> > number of details...
> I had once to parse some random non-lisp format. The easiest way I
> found to do it was to write a SED script that converted the non-lisp
> stuff into something READ could handle.
> In this case, you could go a long ways by prepending a "#2a(",
> postpending a ")", removing the commas and putting a paren around
> each line.
> For things that are a bit hairier, a LEX script can do it.
> I hesitate to recommend SED, LEX, and AWK, but they seem to be
> fairly useful for converting random crap into a more regular format.
Well, it's obviously a safer exercise than recommending, oh, say, Perl
:-)
--
(reverse (concatenate 'string ··········@" "enworbbc"))
http://www.cbbrowne.com/info/sgml.html
Signs of a Klingon Programmer #8: "What is this talk of 'release'?
Klingons do not make software 'releases.' Our software 'escapes'
leaving a bloody trail of designers and quality assurance people in
its wake."
···@itasoftware.com writes:
> I hesitate to recommend SED, LEX, and AWK, but they seem to be fairly
> useful for converting random crap into a more regular format.
Ooh, can I be the first to say it?
"Some people, when confronted with a Unix problem, think "I know, I'll
use sed." Now they have two problems."
-- Jamie Zawinski
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
From: markku laukkanen
Subject: Re: Simple question about arrays and files.
Date:
Message-ID: <3BE233E0.58F00BA6@nokia.com>
Nonzero wrote:
> Hello all,
>
> I have a simple question...
>
> Suppose I have a text file called /home/users/me/data.txt that looks
> like this
>
> a, 1, 2, 3,
> b, 4, 5, 6
> c, 7, 8, 9
> d, 10, 11, 12
>
> What Common LISP commands would I need in order to be able to read
> that file into an array in LISP?
Very many, one of the nicest (maybe a little bit tricyk however) one
would be to define reader macro character for a, b, c ,d and character ,
:-)
PKY
>
>
> And conversly, if I have an array in LISP what commands do I need to
> be able to write the array to a file?
>
> Thanks in advance.
> -Nonzero
Christopher Stacy <······@spacy.Boston.MA.US> wrote in message news:<·············@spacy.Boston.MA.US>...
> Didn't we already do this homework problem about a week ago?
It's not a HW problem :-)
I'm trying to teach myself Genetic Programming.
The next step that I am trying to accomplish is to have my program
write each generation to a file, and read generations from files so
that I my program does not have to start over at generation 0 each
time.
In article <····························@posting.google.com>, "Nonzero"
<··········@hotmail.com> wrote:
> Christopher Stacy <······@spacy.Boston.MA.US> wrote in message
> news:<·············@spacy.Boston.MA.US>...
>> Didn't we already do this homework problem about a week ago?
>
>
> It's not a HW problem :-)
>
> I'm trying to teach myself Genetic Programming.
>
> The next step that I am trying to accomplish is to have my program write
> each generation to a file, and read generations from files so that I my
> program does not have to start over at generation 0 each time.
Ok, then.
If you're writing and reading the data,why not pick a format that lisp
will be happy with?
such as the output of (write obj :readably t :circular t :escape t)
which you can read back in with "read"
Of course I'm assuming that all the sub-elements of your array can be
written readably. (ie. strings, symbols, numbers, lists of same etc)
In article <····························@posting.google.com>,
··········@hotmail.com (Nonzero) wrote:
>Christopher Stacy <······@spacy.Boston.MA.US> wrote in message
news:<·············@spacy.Boston.MA.US>...
>> Didn't we already do this homework problem about a week ago?
>
>
>It's not a HW problem :-)
>
>I'm trying to teach myself Genetic Programming.
>
>The next step that I am trying to accomplish is to have my program
>write each generation to a file, and read generations from files so
>that I my program does not have to start over at generation 0 each
>time.
If you''re doing all of this yourself, then it would be best to choose a
printed representation (the thing that goes to the file) that's as easy
to read back in as possible. You should be able simply to write the
array elements out as is and use READ to bring them back in...
Heck, you could even use a few extra statements to set your program
running on the next generation. If you control what's written to that
text file, there's no reason not to put arbitrary lisp code in there and
load it right up.
paul OK, there are some reasons, but they're probably not important here
On 2 Nov 2001, Nonzero wrote:
> OK, I realised that I can do this with something simpler, a one-d
> array. I'm still having problems reading and writing from the files.
(with-open-file (input "my-file-here" :direction :input)
(loop for data = (read input nil)
when data do (parse data)
while data)))
(defun parse (line)
"Convert the input LINE into something meaningful and store it
elsewhere."
(error "Parser is not implemented"))
and:
(with-open-file (output "my-file-here" :direction :output :if-exists :error)
(loop for entry ; ... iterate over your data structure here...
while entry
do ) ; ... print output in your format here with (format output ...)
Implementing the innards of this is left as a useful exercise to you,
and recovering as the various people who actually /know/ Common Lisp
correct my foolish mistakes to me. ;)
Daniel
--
He uses hate as a weapon to defend himself; had he been strong,
he would never have needed that kind of weapon.
-- Kahlil Gibran