Hi all,
Recent discussions in comp.lang.lisp have centred around why Lisp is so
unpopular as a glue language. I believe this programming challenge will
demonstrate why Lisp is unsuitable as a glue language for Unix.
Here is the programming challenge for Unix-based Lisps: Write a portable
Lisp program that outputs to stdout whatever is input from stdin.
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
> Hi all,
>
> Recent discussions in comp.lang.lisp have centred around why Lisp is so
> unpopular as a glue language. I believe this programming challenge will
> demonstrate why Lisp is unsuitable as a glue language for Unix.
>
> Here is the programming challenge for Unix-based Lisps: Write a portable
> Lisp program that outputs to stdout whatever is input from stdin.
------------------------------------------------------------------------
#!/usr/local/bin/clisp -q -ansi -norc
(loop for line = (read-line *standard-input* nil nil)
while line
do (princ line *standard-output*) (terpri))
------------------------------------------------------------------------
You might complain that it would work dubiously on binary streams.
Then try:
------------------------------------------------------------------------
#!/usr/local/bin/clisp -q -ansi -norc
(with-open-file (stdin "/dev/stdin" :element-type '(unsigned-byte 8)
:direction :input)
(with-open-file (stdout "/dev/stdout" :element-type '(unsigned-byte 8)
:direction :output)
(loop with buffer = (make-array 4096 :element-type '(unsigned-byte 8))
for length = (read-sequence buffer stdin)
while (plusp length)
do (write-sequence buffer stdout :end length))))
------------------------------------------------------------------------
--
__Pascal Bourguignon__ http://www.informatimago.com/
I need a new toy.
Tail of black dog keeps good time.
Pounce! Good dog! Good dog!
Pascal Bourguignon <···@informatimago.com> writes:
> You might complain that it would work dubiously on binary streams.
> Then try:
I think he'd rather complain that your program isn't portable
accross lisp implementations. Once you drop that requirement,
lisp becomes a quite interesting glue language. At Netfonds,
we use common lisp extensively for small scripts.
--
(espen)
Espen Vestre <·····@vestre.net> writes:
> Pascal Bourguignon <···@informatimago.com> writes:
>
>> You might complain that it would work dubiously on binary streams.
>> Then try:
>
> I think he'd rather complain that your program isn't portable
> accross lisp implementations. Once you drop that requirement,
> lisp becomes a quite interesting glue language. At Netfonds,
> we use common lisp extensively for small scripts.
Too bad you cut the source. Let's put it again:
#!/usr/local/bin/clisp -q -ansi -norc
(with-open-file (stdin "/dev/stdin" :element-type '(unsigned-byte 8)
:direction :input)
(with-open-file (stdout "/dev/stdout" :element-type '(unsigned-byte 8)
:direction :output)
(loop with buffer = (make-array 4096 :element-type '(unsigned-byte 8))
for length = (read-sequence buffer stdin)
while (plusp length)
do (write-sequence buffer stdout :end length))))
100% standard Common Lisp. The only thing is that it may depend on
linux or at least on a system where stdin and stdout are mapped to
/dev/stdin and /dev/stdout.
Well, you're right, with sbcl I must add :if-exists :append, and for
the #! line it might be useful to write a little wrapper, but this is
no problem.
Next chalenge, please.
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live
Pascal Bourguignon <···@informatimago.com> writes:
> 100% standard Common Lisp. The only thing is that it may depend on
> linux or at least on a system where stdin and stdout are mapped to
> /dev/stdin and /dev/stdout.
I was thinking about the #!-notation, but as you say that is
/really/ not a real problem.
--
(espen)
Pascal Bourguignon <···@informatimago.com> writes:
>You might complain that it would work dubiously on binary streams.
>Then try:
>
>------------------------------------------------------------------------
>#!/usr/local/bin/clisp -q -ansi -norc
>(with-open-file (stdin "/dev/stdin" :element-type '(unsigned-byte 8)
> :direction :input)
>(with-open-file (stdout "/dev/stdout" :element-type '(unsigned-byte 8)
> :direction :output)
I think that's exactly the "problem". Lisp here makes the
unsubstantiated difference between binary streams and character
streams, and this leads to problems like you have to explicitly open a
binary stream on standard input (even though a *standard-input* stream
exists). As we all know, on Unix, there's no difference between
binary and other-typed streams, all files are binary. IMHO the Lisp
implementation should adapt itself to the conventions used by the
underlying OS. Having non-binary, and hence non-standard
stdin/out/error is just a major PITA in a Unix "glue" language.
mkb.
On Fri, 29 Apr 2005 11:02:38 +0200, Pascal Bourguignon wrote:
> Adam Warner <······@consulting.net.nz> writes:
>
>> Hi all,
>>
>> Recent discussions in comp.lang.lisp have centred around why Lisp is so
>> unpopular as a glue language. I believe this programming challenge will
>> demonstrate why Lisp is unsuitable as a glue language for Unix.
>>
>> Here is the programming challenge for Unix-based Lisps: Write a portable
>> Lisp program that outputs to stdout whatever is input from stdin.
>
> ------------------------------------------------------------------------
> #!/usr/local/bin/clisp -q -ansi -norc
> (loop for line = (read-line *standard-input* nil nil)
> while line
> do (princ line *standard-output*) (terpri))
> ------------------------------------------------------------------------
>
> You might complain that it would work dubiously on binary streams.
Where "work dubiously"=="utterly broken", yes.
> Then try:
>
> ------------------------------------------------------------------------
> #!/usr/local/bin/clisp -q -ansi -norc
> (with-open-file (stdin "/dev/stdin" :element-type '(unsigned-byte 8)
> :direction :input)
> (with-open-file (stdout "/dev/stdout" :element-type '(unsigned-byte 8)
> :direction :output)
> (loop with buffer = (make-array 4096 :element-type '(unsigned-byte 8))
> for length = (read-sequence buffer stdin)
> while (plusp length)
> do (write-sequence buffer stdout :end length))))
> ------------------------------------------------------------------------
I realised this solution moments after I made my original post ;-) This
is indeed portable across Common Lisp implementations upon Unix systems.
Let's add one qualification to the original challenge: You also have to
replace any instance of ASCII encoded "cat" with ASCII encoded "dog".
Let's use a glue language (GNU Bash) and libraries as an example:
$ echo -e "\777the cat sat on the mat" | sed s/cat/dog/ | md5sum
bbc1f55d369738f6e38c94682e1d06d1 -
The Unix locale is C or UTF-8. This means the #xFF octet is either not
well specified or a clearly invalid character. But that's OK because the
text is just a fragment of a larger Unix stream.
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
> Let's add one qualification to the original challenge: You also have to
> replace any instance of ASCII encoded "cat" with ASCII encoded "dog".
> Let's use a glue language (GNU Bash) and libraries as an example:
>
> $ echo -e "\777the cat sat on the mat" | sed s/cat/dog/ | md5sum
> bbc1f55d369738f6e38c94682e1d06d1 -
>
To be fair here, (and I'm saying this as a person far more familiar with
shell scripting languages than lisp), you are using two different
programming languages, and kicking off three processes.
So if you really wanted a fair comparison, can you do the substitution
using pure bourne, bash, ksh, csh or zsh, _without_ needing to start another
process and without using a one-liner in a second programming
language (such as sed, awk, or perl)?
By all means, shell scripting languages are really amazing and easy to
use for these throw-away one-liners because they are almost all glue.
On the other hand, this comes at a pretty hefty price. When you do
something like this...
for f in *; do
grep <something> $f | sed -e <something> | sed -e <something>
done
...the process overhead stacks up pretty darn quick, and you might be
better off re-writing the whole thing in pure lisp/perl/python anyway
(even if it takes 20 lines of lisp/perl/python to do 3 lines of sh +
sed.
>
> Regards,
> Adam
--
Kirk Job-Sluder
"The square-jawed homunculi of Tommy Hilfinger ads make every day an
existential holocaust." --Scary Go Round
"I'm trying to get people to think
about the mismatch between Common Lisp and Unix and why there may be
valid
technical reasons for avoiding Common Lisp as a glue language upon
Unix."
For those who haven't taken a good look or would like to know more,
http://www.scsh.net/ deals with these issues in depth. I've been
seriously contemplating working on something similar for CL, so this
dialogue is very welcome.
-Joseph
From: Christopher C. Stacy
Subject: Re: Lisp/Unix impedance [a programming challenge]
Date:
Message-ID: <ubr7xfqyg.fsf@news.dtpq.com>
"Joseph Wecker" <···············@emcop.com> writes:
> "I'm trying to get people to think about the mismatch between Common
> Lisp and Unix and why there may be valid technical reasons for
> avoiding Common Lisp as a glue language upon Unix."
I think this is a useful discussion, and not very contrived.
Some people have pointed out that Common Lisp is good for doing
things that are much more complex than your "challenge".
That's all well and good, but it does not address your actual
question, which is only about Unix scripting.
In article <························@o13g2000cwo.googlegroups.com>,
"Joseph Wecker" <···············@emcop.com> wrote:
> "I'm trying to get people to think
> about the mismatch between Common Lisp and Unix and why there may be
> valid
> technical reasons for avoiding Common Lisp as a glue language upon
> Unix."
>
>
> For those who haven't taken a good look or would like to know more,
> http://www.scsh.net/ deals with these issues in depth. I've been
> seriously contemplating working on something similar for CL, so this
> dialogue is very welcome.
>
> -Joseph
Having only recently discovered scsh and then immediately wishing for a
CL variant, I'd really like to hear more about such a project. When I
start using scsh for real-world tasks where I'd normally use Perl or
ksh, I'll certainly volunteer critiques and ideas. I should have plenty
to say in a couple weeks. :)
If you do get an effort underway, I'd be glad to help, if only mostly as
a tester.
-- Steve
> For those who haven't taken a good look or would like to know more,
> http://www.scsh.net/ deals with these issues in depth.
See also, http://www.webcom.com/~haahr/es/es-usenix-winter93.html
which describes "es", a unix shell with lispy features.
Kirk Job Sluder <····@jobsluder.net> writes:
>On the other hand, this comes at a pretty hefty price. When you do
>something like this...
>
>for f in *; do
> grep <something> $f | sed -e <something> | sed -e <something>
>done
>
>...the process overhead stacks up pretty darn quick, and you might be
>better off re-writing the whole thing in pure lisp/perl/python anyway
Of course you can replace the above pipeline with a single sed
invocation but I get your point. I don't think it's that much
overhead, btw. Unless you have many millions of files. But then I'd
think that most of the time would be spend in grep (or sed) scanning
the input anyways, unless of course the files are very small. For
small file sets, the effort of hoisting the Lisp runtime is probably
significant (grep and sed load very fast, especially when they're
cached.) Never underestimate simple shell scripts.
mkb.
Adam Warner <······@consulting.net.nz> writes:
> Let's add one qualification to the original challenge: You also have to
> replace any instance of ASCII encoded "cat" with ASCII encoded "dog".
> Let's use a glue language (GNU Bash) and libraries as an example:
>
> $ echo -e "\777the cat sat on the mat" | sed s/cat/dog/ | md5sum
> bbc1f55d369738f6e38c94682e1d06d1 -
>
> The Unix locale is C or UTF-8. This means the #xFF octet is either not
> well specified or a clearly invalid character. But that's OK because the
> text is just a fragment of a larger Unix stream.
Here, I have these files containing a binary quad-tree of geographical
data designed to be mmaped. I'll implement your chalenge in lisp as
soon as you show us a portable shell script that is able to use them
to find the object near given coordinates.
As a bonus, I'd propose even to implement this chanlenge in Common
Lisp too, despite the fact that there's no portable mmap feature.
But first, show us your shell program.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
On Fri, 29 Apr 2005 12:42:15 +0200, Pascal Bourguignon wrote:
> Adam Warner <······@consulting.net.nz> writes:
>> Let's add one qualification to the original challenge: You also have to
>> replace any instance of ASCII encoded "cat" with ASCII encoded "dog".
>> Let's use a glue language (GNU Bash) and libraries as an example:
>>
>> $ echo -e "\777the cat sat on the mat" | sed s/cat/dog/ | md5sum
>> bbc1f55d369738f6e38c94682e1d06d1 -
>>
>> The Unix locale is C or UTF-8. This means the #xFF octet is either not
>> well specified or a clearly invalid character. But that's OK because
>> the text is just a fragment of a larger Unix stream.
>
> Here, I have these files containing a binary quad-tree of geographical
> data designed to be mmaped. I'll implement your challenge in lisp as
> soon as you show us a portable shell script that is able to use them to
> find the object near given coordinates.
>
> As a bonus, I'd propose even to implement this challenge in Common Lisp
> too, despite the fact that there's no portable mmap feature.
>
> But first, show us your shell program.
I think your defensive response well demonstrates how unsuitable Common
Lisp is to the task of replacing "cat" with "dog" upon the Unix stream
above. It can be done using the same approach of opening octet streams to
/dev/stdin and /dev/stdout but then one has to operate upon octets and/or
convert between Common Lisp characters and octets.
I don't expect you to implement it. I'm trying to get people to think
about the mismatch between Common Lisp and Unix and why there may be valid
technical reasons for avoiding Common Lisp as a glue language upon Unix.
Your example of one of the many situations where shell scripts are
unsuitable is not in dispute.
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
>> Here, I have these files containing a binary quad-tree of geographical
>> data designed to be mmaped. I'll implement your challenge in lisp as
>> soon as you show us a portable shell script that is able to use them to
>> find the object near given coordinates.
>>
>> As a bonus, I'd propose even to implement this challenge in Common Lisp
>> too, despite the fact that there's no portable mmap feature.
>>
>> But first, show us your shell program.
>
> I think your defensive response well demonstrates how unsuitable Common
> Lisp is to the task of replacing "cat" with "dog" upon the Unix stream
> above. It can be done using the same approach of opening octet streams to
> /dev/stdin and /dev/stdout but then one has to operate upon octets and/or
> convert between Common Lisp characters and octets.
It can be done as easily as you want, that's not the point. I'm not
defensive. I'm unresponsive because of the reasons explained by
Christophe. You're trying to design specifications to hurt Common
Lisp, instead of trying to see what it's worth for. Shells are not
worth for all gluing on unix either, that's why things such as a perl
and python got their niche.
> I don't expect you to implement it. I'm trying to get people to think
> about the mismatch between Common Lisp and Unix and why there may be valid
> technical reasons for avoiding Common Lisp as a glue language upon Unix.
The mismatch is in your imagination. Most Common Lisp implementation
on unix use by default an 8-bit 1-1 encoding that allow to process
binary data as a stream of character like any other unix.
[···@thalassa tmp]$ echo "\777dog eats cat" | ./filter
\777dog eats dog
[···@thalassa tmp]$ thru < filter
#!/usr/local/bin/clisp -q -ansi -norc -E iso-8859-1
(loop for line = (read-line *standard-input* nil nil)
while line
do (when (search "cat" line)
(replace line "dog" :start1 (search "cat" line)))
(princ line *standard-output*)
(terpri))
[···@thalassa tmp]$
> Your example of one of the many situations where shell scripts are
> unsuitable is not in dispute.
Common Lisp is suitable for this too. Show us how suitable shells are?
--
__Pascal Bourguignon__ http://www.informatimago.com/
The mighty hunter
Returns with gifts of plump birds,
Your foot just squashed one.
On Fri, 29 Apr 2005 16:31:42 +0200, Pascal Bourguignon wrote:
>> I don't expect you to implement it. I'm trying to get people to think
>> about the mismatch between Common Lisp and Unix and why there may be valid
>> technical reasons for avoiding Common Lisp as a glue language upon Unix.
>
> The mismatch is in your imagination. Most Common Lisp implementation
> on unix use by default an 8-bit 1-1 encoding that allow to process
> binary data as a stream of character like any other unix.
This used to be historically true. Common Lisp used to be a better match
with Unix when Common Lisp characters mapped to octets and vice versa.
I note that your code below:
(a) Switches back to using characters instead of octets [no more opening
of /dev/stdin as (unsigned-byte 8)]
(b) Changes the default encoding which tends to belie your claim that
"Most Common Lisp implementation on unix use by default an 8-bit 1-1
encoding that allow to process binary data as a stream of character like
any other unix."
If I use the default encoding this happens:
*** - invalid byte #xFF in CHARSET:UTF-8 conversion, not a Unicode-16
[Note that -e in echo is necessary to enable interpretation of
backslash-escaped characters]
Note also that any modern Unix should default to a UTF-8 locale (and if it
doesn't it will almost certainly do so in the future). For a very long
time I have never even built the ISO-8859-1 locale on many of my systems,
including the one I'm writing this reply to you on:
$ locale -a
C
en_NZ.utf8
POSIX
<http://www.cl.cam.ac.uk/~mgk25/unicode.html>
Red Hat Linux 8.0 (September 2002) was the first distribution to take
the leap of switching to UTF-8 as the default encoding for most
locales. The only exceptions were Chinese/Japanese/Korean locales, for
which there were at the time still too many specialized tools available
that did not yet support UTF-8. This first mass deployment of UTF-8
under Linux caused most remaining issues to be ironed out rather
quickly during 2003. SuSE Linux then switched its default locales to
UTF-8 as well as of version 9.1 (May 2004). Most other distributions
can be expected to follow soon.
(c) Your approach is broken anyway. You have not heeded the CLISP
implementation notes.
> [···@thalassa tmp]$ echo "\777dog eats cat" | ./filter
> \777dog eats dog
> [···@thalassa tmp]$ thru < filter
> #!/usr/local/bin/clisp -q -ansi -norc -E iso-8859-1
> (loop for line = (read-line *standard-input* nil nil)
> while line
> do (when (search "cat" line)
> (replace line "dog" :start1 (search "cat" line)))
> (princ line *standard-output*)
> (terpri))
This will demonstrate what's wrong with the character approach
(filter2.sh):
#!/usr/bin/clisp -q -ansi -norc -E iso-8859-1
(loop for char = (read-char *standard-input* nil nil)
while char
do (print char))
Compare this [carriage returns and line feeds (newlines) pass through
unmolested]:
$ echo -e -n "\r\n\r\n" | od -a -h
0000000 cr nl cr nl
0a0d 0a0d
0000004
... with this:
$ echo -e -n "\r\n\r\n" | ./filter2.sh
#\Newline
#\Newline
... this:
$ echo -e -n "\n\n\n\n" | ./filter2.sh
#\Newline
#\Newline
#\Newline
#\Newline
... and this:
$ echo -e -n "\r\r\r\r" | ./filter2.sh
#\Newline
#\Newline
#\Newline
#\Newline
From the CLISP implementation notes:
<http://clisp.cons.org/impnotes/clhs-newline.html>
When reading from a file, CR/LF is converted to #\Newline (the usual
convention on DOS), and CR not followed by LF is converted to #\Newline
as well (the usual conversion on MacOS, also used by some programs on
Win32). If you do not want this, i.e., if you really want to
distinguish LF, CR and CR/LF, you have to resort to binary input
(function READ-BYTE).
Also note the rationale: "In CLISP, #\Newline is identical to #\Linefeed
(which is specifically permitted by [ANSI CL standard] in section
Character Names)."
"The mismatch is in your imagination."
Regards,
Adam
On Fri, 29 Apr 2005 16:31:42 +0200, Pascal Bourguignon wrote:
> #!/usr/local/bin/clisp -q -ansi -norc -E iso-8859-1
> (loop for line = (read-line *standard-input* nil nil)
> while line
> do (when (search "cat" line)
> (replace line "dog" :start1 (search "cat" line)))
> (princ line *standard-output*)
> (terpri))
As I previously established, this script did not meet the specification of
passing through non-matching octets because CLISP either eats or changes
linefeeds into newlines (depending upon whether the linefeed is proceeded
by a newline).
CLISP purports to be conforming to ANSI Common Lisp in this respect. If
it is, one is relying upon implementation-specific behaviour even in those
implementations where this code might actually work as specified.
One issue I did not raise is that this filter will eventually consume all
available memory if a continuous stream of characters does not contain
newlines (XML can be generated this way and for example OpenOffice.org's
XML document content omits newlines).
This is not how the Common Lisp community is supposed to solve simple
problems. As I would like to see at least one correct solution for
filtering 'cat' for 'dog' within Unix octet streams that may contain UTF-8
encoded text using ANSI Common Lisp code, here is my attempt:
#!/usr/bin/clisp -q -ansi -norc
(defconstant |#\c| 99)
(defconstant |#\a| 97)
(defconstant |#\t| 116)
(defconstant |#\d| 100)
(defconstant |#\o| 111)
(defconstant |#\g| 103)
(with-open-file (in "/dev/stdin" :element-type '(unsigned-byte 8))
(with-open-file (out "/dev/stdout" :element-type '(unsigned-byte 8)
:direction :output)
(let ((buffer (make-array 3 :element-type '(integer -1 255)
:initial-element -1))
(match (make-array 3 :element-type '(unsigned-byte 8)
:initial-contents (list |#\c| |#\a| |#\t|)))
(replacement (make-array 3 :element-type '(unsigned-byte 8)
:initial-contents (list |#\d| |#\o| |#\g|)))
(octet -1))
(declare (type octet (integer -1 255)))
(tagbody loop
(unless (= (aref buffer 0) -1)
(write-byte (aref buffer 0) out))
(setf octet (read-byte in nil -1))
(replace buffer buffer :start2 1)
(setf (aref buffer (1- (length buffer))) octet)
(when (search match buffer)
(write-sequence replacement out)
(fill buffer -1))
(unless (= octet -1) (go loop)))
(dotimes (i (length buffer))
(unless (= (aref buffer i) -1)
(write-byte (aref buffer i) out))))))
My approach is to generate a buffer the same size of the match array. The
buffer is empty when each element is -1. The buffer fills with octets
towards index 0. If the buffer matches the match array the replacement
array is written out and the buffer refilled with -1 elements. Once the
end of the stream is reached any remaining octets within the buffer are
written out.
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
Just one thing that bothers me in this discussion. In terms of
contrasting lisp with other solutions, it seems to be taken for granted
that the other solutions rise to the challenges made. For example:
> One issue I did not raise is that this filter will eventually consume all
> available memory if a continuous stream of characters does not contain
> newlines (XML can be generated this way and for example OpenOffice.org's
> XML document content omits newlines).
Earlier in this discussion, bash+sed was used as an example solution.
(1) However, not all seds are 8bit safe. Long lines are a problem for
most seds. No sed is well equiped to handle binary files, and code
portability between seds can't be assumed. So your example solution
fails to meet the current version of the challenge.
For that matter, portability between implementations are frequently
problematic. Some examples: bourne shell (of which bash and zsh are
variants), lisp, c (with variations on standard libraries and
compilers), python (cpython vs. jython), java (different VMs, libraries,
and compilers), awk and make. This is not counting the basic
differences between unix-like operating systems that make even
"#!/bin/bash" a pain.
Looking over the history of this discussion, the functional requirements
for this script keep changing with every post. If your prototype is to
mimic sed, then the "read-line" and "write-line" idioms come closest to
the functionality provided by sed. Which scratches my personal itch
coming to this from the sed->python->lisp path.
I am really interested in the general domain of this problem. On the
other hand, I'm completely baffled as to what the current problem is,
given how we've gone from "cat" to "sed" to something that is not at all
portable between seds.
So what *exactly* is the challenge again? And why are the variations
between lisps more critical than the variations between most standard
unix utilities?
(1) You also called this "a glue language (GNU Bash) and libraries",
forgetting that sed is not a library, but a programming language
of its own. More than a few lines of sed is a painful experience for
most people, but someone built a web server.
http://sed.sourceforge.net/local/scripts/sedhttpd.sed.html
> Regards,
> Adam
--
Kirk Job-Sluder
"The square-jawed homunculi of Tommy Hilfinger ads make every day an
existential holocaust." --Scary Go Round
Kirk Job Sluder <····@jobsluder.net> writes:
> (1) You also called this "a glue language (GNU Bash) and libraries",
> forgetting that sed is not a library, but a programming language
> of its own. More than a few lines of sed is a painful experience for
> most people, but someone built a web server.
> http://sed.sourceforge.net/local/scripts/sedhttpd.sed.html
sed is equivalent to a Turing Machine.
Actually, it's quite close to a Turing Machine.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Wanna go outside.
Oh, no! Help! I got outside!
Let me back inside!
Pascal Bourguignon wrote:
> Kirk Job Sluder <····@jobsluder.net> writes:
>
>>(1) You also called this "a glue language (GNU Bash) and libraries",
>>forgetting that sed is not a library, but a programming language
>>of its own. More than a few lines of sed is a painful experience for
>>most people, but someone built a web server.
>>http://sed.sourceforge.net/local/scripts/sedhttpd.sed.html
>
>
> sed is equivalent to a Turing Machine.
> Actually, it's quite close to a Turing Machine.
Is that supposed to be a compliment? :)
Cheers
--
Marco
On Wed, 04 May 2005 06:42:30 +0000, Kirk Job Sluder wrote:
> Earlier in this discussion, bash+sed was used as an example solution.
> (1) However, not all seds are 8bit safe. Long lines are a problem for
> most seds. No sed is well equiped to handle binary files, and code
> portability between seds can't be assumed. So your example solution
> fails to meet the current version of the challenge.
Great point! GNU sed will load the entire line into memory just like
Common Lisp's READ-LINE:
<http://www.gnu.org/software/sed/manual/html_mono/sed.html#SEC11>
Though I fully expect GNU sed is 8 bit safe. The main point is I had to
avoid Common Lisp's character/string reader in order to implement an 8 bit
safe solution.
[...]
> Looking over the history of this discussion, the functional requirements
> for this script keep changing with every post.
They last changed about five days ago on the same day of the original
(embarrassingly easy) challenge. I agree that you've raised a very
important comparison between my attempted solution and sed.
> If your prototype is to mimic sed, then the "read-line" and
> "write-line" idioms come closest to the functionality provided by sed.
It has been established that READ-LINE isn't even 7 bit safe.
> Which scratches my personal itch coming to this from the
> sed->python->lisp path.
I'm rather amused to discover that Python's 8 bit safety has been
deprecated:
<http://groups.google.co.nz/group/comp.lang.python/msg/f250f9db7c8b936e>
> I am really interested in the general domain of this problem. On the
> other hand, I'm completely baffled as to what the current problem is,
> given how we've gone from "cat" to "sed" to something that is not at all
> portable between seds.
Let's not feign excessive bafflement :-) I obviously screwed up my
original challenge and had to fix it ASAP.
> So what *exactly* is the challenge again? And why are the variations
> between lisps more critical than the variations between most standard
> unix utilities?
The Common Lisp code should be 8 bit clean, i.e. transparently pass all
data when not performing a requested transformation.
I expect standard Unix utilities to be 8 bit clean. And if they're not I
expect their replacements to be, e.g.:
<http://groups.google.co.nz/group/comp.unix.solaris/msg/2e548a4fd32118f8>
Thanks again for your very insightful comments.
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
>> Which scratches my personal itch coming to this from the
>> sed->python->lisp path.
>
> I'm rather amused to discover that Python's 8 bit safety has been
> deprecated:
> <http://groups.google.co.nz/group/comp.lang.python/msg/f250f9db7c8b936e>
As far as I understand this only affects string literals in the source
when the source file has not been annotated with its encoding.
Given that the world is slowly moving from processing byte strings
in an unknown or assumed encoding, to processing Unicode strings
serialized as various encodings, this doesn't look unreasonable for
me. This allows to treat the whole source as a representation of a
Unicode text.
It would be about the only sane choice if non-ASCII characters were
allowed in identifiers.
Of course this should not limit the ability for a program to process
binary data. The point is that program source is text.
> I expect standard Unix utilities to be 8 bit clean. And if they're not I
> expect their replacements to be, e.g.:
> <http://groups.google.co.nz/group/comp.unix.solaris/msg/2e548a4fd32118f8>
For many utilities "8 bit clean" is meaningful because they transform
the data in simple ways, but if a program treats the input as text
and needs to interpret non-ASCII characters in a non-trivial way
rather than just pass them around (e.g. sort texts using appropriate
linguistic conventions), it's not clear how it should react to
recoding errors.
>> Anyway, in my language Kogut it's cleaner and 25 times faster:
>
> Versus running interpreted in clisp, I'm not surprised.
With SBCL I got an error:
The value (INTEGER -1 255) is not of type SYMBOL.
I removed the type declaration and got:
error opening #P"/dev/stdout": File exists
After adding :if-exists :overwrite it seems to work.
But I'm not familiar with SBCL and I don't know how to execute just
the program without the REPL, and how to ensure that it's compiled to
as good code as SBCL can.
>> It relies on the fact that buffered streams can be treated as
>> sequences, with arbitrary read-ahead (lazily read).
>
> In my own private seamless extensions to ANSI Common Lisp I have
> unlimited look ahead for binary streams (there are no lazy
> techniques).
What do you mean by "no lazy techniques"? If it's unlimited and not
lazy, this would imply that the whole file is read into memory at once
- I doubt you mean this.
I meant that the input buffer is expanded while data is looked at
without being removed from the input. You can also unread as much
as you want - for unreading the buffer is expanded at its start.
> ANSI Common Lisp omits PEEK-BYTE from the language.
It would not be sufficient if it was analogous to PEEK-CHAR, as it
only allows to peek one character ahead.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
On Wed, 04 May 2005 23:54:06 +0200, Marcin 'Qrczak' Kowalczyk wrote:
> Adam Warner <······@consulting.net.nz> writes:
>
>>> Which scratches my personal itch coming to this from the
>>> sed->python->lisp path.
>>
>> I'm rather amused to discover that Python's 8 bit safety has been
>> deprecated:
>> <http://groups.google.co.nz/group/comp.lang.python/msg/f250f9db7c8b936e>
>
> As far as I understand this only affects string literals in the source
> when the source file has not been annotated with its encoding.
>
> Given that the world is slowly moving from processing byte strings
> in an unknown or assumed encoding, to processing Unicode strings
> serialized as various encodings, this doesn't look unreasonable for
> me. This allows to treat the whole source as a representation of a
> Unicode text.
>
> It would be about the only sane choice if non-ASCII characters were
> allowed in identifiers.
>
> Of course this should not limit the ability for a program to process
> binary data. The point is that program source is text.
That's good news. To me it is not clear that Lisp source should solely
be text, in the sense that macro characters should also be able to decode
raw data. Consider a wire protocol that reads and writes s-expressions. If
you control both ends of the protocol then sending an array of octets
could be as efficient as sending an appropriate macro header and then the
octets as straight binary data. There's significantly less overhead than
encoding the octets within UTF-8 text.
One of my earlier text-based macros for a wire protocol included this
array notation: #6V(unsigned-byte 8)aabbccddeeff
6 is the number of data elements to follow. (unsigned-byte 8) is one of
the supported data types. In this case hexadecimal encoded octets follow
(I could also support base64).
Imagine you could push those octets over a wire as binary in amongst
UTF-8 encoded text. One should view the entire stream as UTF-8 text
punctuated by intervals of binary data rather than intervals of corrupt
UTF-8 text. Individual macro character readers knows when to expect the
binary data. There is no ambiguity.
>> I expect standard Unix utilities to be 8 bit clean. And if they're not I
>> expect their replacements to be, e.g.:
>> <http://groups.google.co.nz/group/comp.unix.solaris/msg/2e548a4fd32118f8>
>
> For many utilities "8 bit clean" is meaningful because they transform
> the data in simple ways, but if a program treats the input as text
> and needs to interpret non-ASCII characters in a non-trivial way
> rather than just pass them around (e.g. sort texts using appropriate
> linguistic conventions), it's not clear how it should react to
> recoding errors.
>
>>> Anyway, in my language Kogut it's cleaner and 25 times faster:
>>
>> Versus running interpreted in clisp, I'm not surprised.
>
> With SBCL I got an error:
> The value (INTEGER -1 255) is not of type SYMBOL.
CLISP ignores most type declarations. In this case I accidentally
transposed the type and symbol name. (declare (type octet (integer -1
255))) should have been (declare (type (integer -1 255) octet))
> I removed the type declaration and got:
> error opening #P"/dev/stdout": File exists
> After adding :if-exists :overwrite it seems to work.
This indeed appears necessary to make the code (more) portable.
> But I'm not familiar with SBCL and I don't know how to execute just
> the program without the REPL, and how to ensure that it's compiled to
> as good code as SBCL can.
I'm also not familiar with how to write standalone scripts using SBCL.
You will be able to dump SBCL's memory image with the code precompiled
(the core file may be over 20MB).
>>> It relies on the fact that buffered streams can be treated as
>>> sequences, with arbitrary read-ahead (lazily read).
>>
>> In my own private seamless extensions to ANSI Common Lisp I have
>> unlimited look ahead for binary streams (there are no lazy
>> techniques).
>
> What do you mean by "no lazy techniques"? If it's unlimited and not
> lazy, this would imply that the whole file is read into memory at once
> - I doubt you mean this.
All I mean is that subsequent calls to peek return subsequent bytes. One
can look ahead more than one byte without affecting the reading of bytes.
> I meant that the input buffer is expanded while data is looked at
> without being removed from the input. You can also unread as much
> as you want - for unreading the buffer is expanded at its start.
It sounds like I mean the same thing. I, perhaps incorrectly, think of
lazy techniques as ones that delay computations until necessary, e.g. you
explicitly build something but it's not computed until the data is needed
(e.g. extracting elements from an infinite series object). I just didn't
want to give the impression that I was using such a technique instead of a
mundane per-stream buffer.
>> ANSI Common Lisp omits PEEK-BYTE from the language.
>
> It would not be sufficient if it was analogous to PEEK-CHAR, as it
> only allows to peek one character ahead.
Correct. No portable peek or unread of even a single byte does however
provide good motivation to build something better!
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
> I'm also not familiar with how to write standalone scripts using SBCL.
> You will be able to dump SBCL's memory image with the code precompiled
> (the core file may be over 20MB).
http://ww.telent.net/lisp/according_to/hello-world.html
* (require 'asdf)
* (require :sb-executable)
* (compile-file "hello")
* (sb-executable:make-executable "hello" "hello.fasl")
Adam Warner <······@consulting.net.nz> writes:
> CLISP ignores most type declarations. In this case I accidentally
> transposed the type and symbol name. (declare (type octet (integer -1
> 255))) should have been (declare (type (integer -1 255) octet))
I added the fixed declaration back.
Luis Oliveira <·······@gmail.com> writes:
> http://ww.telent.net/lisp/according_to/hello-world.html
>
> * (require 'asdf)
> * (require :sb-executable)
> * (compile-file "hello")
> * (sb-executable:make-executable "hello" "hello.fasl")
Thanks, this makes the SBCL version 22% faster than the faster Kogut
version. (Kogut compiles via C.)
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
On Fri, 06 May 2005 06:42:40 +0200, Marcin 'Qrczak' Kowalczyk wrote:
> Adam Warner <······@consulting.net.nz> writes:
>
>> CLISP ignores most type declarations. In this case I accidentally
>> transposed the type and symbol name. (declare (type octet (integer -1
>> 255))) should have been (declare (type (integer -1 255) octet))
>
> I added the fixed declaration back.
>
> Luis Oliveira <·······@gmail.com> writes:
>
>> http://ww.telent.net/lisp/according_to/hello-world.html
>>
>> * (require 'asdf)
>> * (require :sb-executable)
>> * (compile-file "hello")
>> * (sb-executable:make-executable "hello" "hello.fasl")
>
> Thanks, this makes the SBCL version 22% faster than the faster Kogut
> version. (Kogut compiles via C.)
Mighty fine of you Marcin. Just for completeness you may be able to
squeeze out some additional speed just by adding this line to the top of
the code:
(declaim (optimize (compilation-speed 0) (debug 0) (safety 0) (speed 3)))
<http://www.lispworks.com/documentation/HyperSpec/Body/d_optimi.htm>
The above line of code indicates to the implementation that I don't care
about how long the code takes to compile; I don't want any debugging info
to be compiled in; I want the implementation to have absolute faith in my
type declarations; and speed is extremely important. I omitted SPACE so it
remains at a neutral value of 1.
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
> Mighty fine of you Marcin. Just for completeness you may be able to
> squeeze out some additional speed just by adding this line to the top of
> the code:
>
> (declaim (optimize (compilation-speed 0) (debug 0) (safety 0) (speed 3)))
1.5% faster.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Adam Warner <······@consulting.net.nz> writes:
> This is not how the Common Lisp community is supposed to solve
> simple problems. As I would like to see at least one correct
> solution for filtering 'cat' for 'dog' within Unix octet streams
> that may contain UTF-8 encoded text using ANSI Common Lisp code,
> here is my attempt:
When run in UTF-8 encoding, it outputs a warning:
WARNING: *FOREIGN-ENCODING*: reset to ASCII
Anyway, in my language Kogut it's cleaner and 25 times faster:
let cat = GenMap "cat" Code->List;
let dog = GenMap "dog" Code->List;
let input = BinaryReader RawStdIn;
let output = BinaryWriter RawStdOut;
loop {
if (input %BeginsWith cat) {
WriteTo output dog;
DoRemovePart input 0 3;
again()
}
else {
let byte = ReadByteFrom input;
if (~IsNull byte) {
WriteTo output [byte];
again()
}
}
};
FlushTo output #sync;
It relies on the fact that buffered streams can be treated as
sequences, with arbitrary read-ahead (lazily read).
It can be further made twice faster by checking for "at" only after
the byte read was the code of "c".
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
On Wed, 04 May 2005 12:18:07 +0200, Marcin 'Qrczak' Kowalczyk wrote:
> Adam Warner <······@consulting.net.nz> writes:
>
>> This is not how the Common Lisp community is supposed to solve
>> simple problems. As I would like to see at least one correct
>> solution for filtering 'cat' for 'dog' within Unix octet streams
>> that may contain UTF-8 encoded text using ANSI Common Lisp code,
>> here is my attempt:
>
> When run in UTF-8 encoding, it outputs a warning:
>
> WARNING: *FOREIGN-ENCODING*: reset to ASCII
That's fixed in the latest version and/or CVS:
<http://www.podval.org/~sds/clisp/NEWS>
* The FFI variable *FOREIGN-ENCODING* can now be a multibyte encoding.
The warning "*FOREIGN-ENCODING*: reset to ASCII" at startup is gone.
> Anyway, in my language Kogut it's cleaner and 25 times faster:
Versus running interpreted in clisp, I'm not surprised. I didn't even
invoke the -C flag which bytecode compiles the code while loading. CLISP
code also runs approximately proportional to the number of individual
bytecode operations. This means explicitly looping over individual octets
is way more expensive than invoking READ-LINE/READ-SEQUENCE.
Of course the algorithm I built up piecemeal in twenty or so minutes could
be improved!
Many thanks for your example Kogut code.
> let cat = GenMap "cat" Code->List;
(map-into (make-array 3) #'char-code "cat")
I didn't have to build octet arrays nor avoid CHAR-CODE.
(map-into (make-array 3 :element-type '(unsigned-byte 8)) #'char-code "cat")
would have been superior (though it does assume Common Lisp's CHAR-CODE
maps standard characters to ASCII character codes, which should be fine in
practice).
> let dog = GenMap "dog" Code->List;
> let input = BinaryReader RawStdIn;
> let output = BinaryWriter RawStdOut;
This looks nicer than
(with-open-file (in "/dev/stdin" :element-type '(unsigned-byte 8))
(with-open-file (out "/dev/stdout" :element-type '(unsigned-byte 8)
:direction :output)
Though it doesn't matter in this case the Common Lisp version will
properly clean up in the event of an error.
Some Common Lisp syntax just needs a clean up for scripting purposes.
For example with-octet-output-file could replace the combination of
with-open-file, :element-type '(unsigned-byte 8) and :direction :output.
> It relies on the fact that buffered streams can be treated as
> sequences, with arbitrary read-ahead (lazily read).
In my own private seamless extensions to ANSI Common Lisp I have unlimited
look ahead for binary streams (there are no lazy techniques). ANSI Common
Lisp omits PEEK-BYTE from the language.
> It can be further made twice faster by checking for "at" only after
> the byte read was the code of "c".
Indeed. Thanks again,
Adam
On Fri, 29 Apr 2005 11:02:38 +0200, Pascal Bourguignon wrote:
> Adam Warner <······@consulting.net.nz> writes:
>
>> Hi all,
>>
>> Recent discussions in comp.lang.lisp have centred around why Lisp is so
>> unpopular as a glue language. I believe this programming challenge will
>> demonstrate why Lisp is unsuitable as a glue language for Unix.
>>
>> Here is the programming challenge for Unix-based Lisps: Write a portable
>> Lisp program that outputs to stdout whatever is input from stdin.
>
> ------------------------------------------------------------------------
> #!/usr/local/bin/clisp -q -ansi -norc
> (loop for line = (read-line *standard-input* nil nil)
> while line
> do (princ line *standard-output*) (terpri))
> ------------------------------------------------------------------------
>
> You might complain that it would work dubiously on binary streams.
Where "work dubiously"=="utterly broken", yes.
> Then try:
>
> ------------------------------------------------------------------------
> #!/usr/local/bin/clisp -q -ansi -norc
> (with-open-file (stdin "/dev/stdin" :element-type '(unsigned-byte 8)
> :direction :input)
> (with-open-file (stdout "/dev/stdout" :element-type '(unsigned-byte 8)
> :direction :output)
> (loop with buffer = (make-array 4096 :element-type '(unsigned-byte 8))
> for length = (read-sequence buffer stdin)
> while (plusp length)
> do (write-sequence buffer stdout :end length))))
> ------------------------------------------------------------------------
I realised this solution moments after I made my original post ;-) This
is indeed portable across Common Lisp implementations upon Unix systems.
Let's add one qualification to the original challenge: You also have to
replace any instance of ASCII encoded "cat" with ASCII encoded "dog".
Let's use a glue language (GNU Bash) and libraries as an example:
$ echo -e "\377the cat sat on the mat" | sed s/cat/dog/ | md5sum
bbc1f55d369738f6e38c94682e1d06d1 -
The Unix locale is C or UTF-8. This means the #xFF octet is either not
well specified or a clearly invalid character. But that's OK because the
text is just a fragment of a larger Unix stream.
Regards,
Adam
Pascal Bourguignon wrote:
> Adam Warner <······@consulting.net.nz> writes:
>
> > Hi all,
> >
> > Recent discussions in comp.lang.lisp have centred around why Lisp
is so
> > unpopular as a glue language. I believe this programming challenge
will
> > demonstrate why Lisp is unsuitable as a glue language for Unix.
> >
> > Here is the programming challenge for Unix-based Lisps: Write a
portable
> > Lisp program that outputs to stdout whatever is input from stdin.
>
>
------------------------------------------------------------------------
> #!/usr/local/bin/clisp -q -ansi -norc
> (loop for line = (read-line *standard-input* nil nil)
> while line
> do (princ line *standard-output*) (terpri))
>
------------------------------------------------------------------------
>
> You might complain that it would work dubiously on binary streams.
> Then try:
Actually, there isn't any way to write it in ANSI C that will work on
binary streams either. The ANSI C streams stdin, stdout and stderr are
specified as text streams. Many POSIX programs assume that text streams
are just binary streams, but that is not necessarily so. For instance,
on Cygwin, you can configure text files to follow the DOS convention.
So even to solve this challenge using C, you have to use the POSIX
extensions, like the use of the raw file descriptors STDIN_FILENO and
STDOUT_FILENO and the functions read() and write().
You can ``glue'' to these functions from Lisp like from any other
language.
What makes or breaks a language implementation for the purpose of being
``UNIX glue'' is simply the presence or absence of a bundled set of
POSIX bindings. Why? Because a ``glue program'' consists mostly of
calls to these API's, so that if you have to create the bindings
yourself, you spend 90% of your effort doing that, and 10% in the
actual program.
If all the Lisp implemnetations agreed on a UNIX API, then you'd have a
portable target for doing systems programming in Lisp. Moreover, you
could pull any Lisp implemnetation off the shelf, and use it instantly
and productively to write these glue programs. Here is one such effort:
http://www.cliki.net/Common-Lisp-POSIX
Now on the other hand if you are developing a significant application,
beyond mere systems programming glue, it may be worth it to write your
own bindings, where you won't be spending 90% of your effort.
On Fri, 29 Apr 2005 20:36:03 +1200, Adam Warner wrote:
> Hi all,
>
> Recent discussions in comp.lang.lisp have centred around why Lisp is so
> unpopular as a glue language. I believe this programming challenge will
> demonstrate why Lisp is unsuitable as a glue language for Unix.
>
> Here is the programming challenge for Unix-based Lisps: Write a portable
> Lisp program that outputs to stdout whatever is input from stdin.
(with-open-file (in "/dev/stdin" :element-type '(unsigned-byte 8))
(with-open-file (out "/dev/stdout" :element-type '(unsigned-byte 8)
:direction :output)
(loop (write-byte (read-byte in) out))))
Let's try one more time:
Write a portable Lisp program that faithfully reproduces stdin via
*standard-input* and outputs it to stdout via *standard-output*.
Regards,
Adam
On Fri, 29 Apr 2005 21:10:05 +1200, <······@consulting.net.nz> wrote:
> On Fri, 29 Apr 2005 20:36:03 +1200, Adam Warner wrote:
>
> Let's try one more time:
>
> Write a portable Lisp program that faithfully reproduces stdin via
> *standard-input* and outputs it to stdout via *standard-output*.
This is a hilarious thread!
--
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
Adam Warner <······@consulting.net.nz> writes:
> Write a portable Lisp program that faithfully reproduces stdin via
> *standard-input* and outputs it to stdout via *standard-output*.
Why this requirement? And, in addition, why the "portable" (by which
I suppose you mean "portable between Lisps", but I dunno, do you care
if it runs as advertised on SCO Unix, for instance)? It seems to me
that you're asking a question in anticipation of dismissing any
answer.
(with-open-file (in "/dev/stdin" :element-type '(unsigned-byte 8))
(with-open-file (out "/dev/stdout" :element-type '(unsigned-byte 8)
:if-exists :append)
(let ((*standard-input* in)
(*standard-output* out))
(loop (write-byte (read-byte *standard-input*) *standard-output*)))))
Of course, this is just a stupid function to prove that I can meet the
spec as written, rather than what you'd find in the wild.
Guessing wildly at your "point": that usually input and output undergo
character translation of some kind, and indeed there is in this sense
a slight impedance mismatch between the Unix world of octets and the
Lisp world of characters; believe it or not, this doesn't stop people
from getting stuff done, even Unix glue code.
Christophe
On Fri, 29 Apr 2005 10:38:31 +0100, Christophe Rhodes wrote:
> Adam Warner <······@consulting.net.nz> writes:
>
>> Write a portable Lisp program that faithfully reproduces stdin via
>> *standard-input* and outputs it to stdout via *standard-output*.
>
> Why this requirement? And, in addition, why the "portable" (by which
> I suppose you mean "portable between Lisps", but I dunno, do you care
> if it runs as advertised on SCO Unix, for instance)? It seems to me
> that you're asking a question in anticipation of dismissing any
> answer.
>
> (with-open-file (in "/dev/stdin" :element-type '(unsigned-byte 8))
> (with-open-file (out "/dev/stdout" :element-type '(unsigned-byte 8)
> :if-exists :append)
> (let ((*standard-input* in)
> (*standard-output* out))
> (loop (write-byte (read-byte *standard-input*) *standard-output*)))))
>
> Of course, this is just a stupid function to prove that I can meet the
> spec as written, rather than what you'd find in the wild.
CLISP: *** - WRITE-BYTE on #<INPUT UNBUFFERED FILE-STREAM (UNSIGNED-BYTE
8) #P"/dev/stdout"> is illegal
ECL: "/dev/stdin" has an invalid binary header 10
Broken at OPEN.
GCL (CVS): Error in PROGN [or a callee]: Cannot write to the stream
#<input stream "/dev/stdout">
ABCL: Debugger invoked on condition of type STREAM-ERROR:
Illegal seek
Debugger invoked on condition of type TYPE-ERROR:
The value #<FILE-STREAM {1321F5}> is not a character input stream.
> Guessing wildly at your "point": that usually input and output undergo
> character translation of some kind, and indeed there is in this sense
> a slight impedance mismatch between the Unix world of octets and the
> Lisp world of characters; believe it or not, this doesn't stop people
> from getting stuff done, even Unix glue code.
Claiming it is only a slight impedance mismatch doesn't make it any
more true.
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
> On Fri, 29 Apr 2005 10:38:31 +0100, Christophe Rhodes wrote:
>> (with-open-file (in "/dev/stdin" :element-type '(unsigned-byte 8))
>> (with-open-file (out "/dev/stdout" :element-type '(unsigned-byte 8)
>> :if-exists :append)
>> (let ((*standard-input* in)
>> (*standard-output* out))
>> (loop (write-byte (read-byte *standard-input*) *standard-output*)))))
>>
>> Of course, this is just a stupid function to prove that I can meet the
>> spec as written, rather than what you'd find in the wild.
>
> CLISP: *** - WRITE-BYTE on #<INPUT UNBUFFERED FILE-STREAM (UNSIGNED-BYTE
> 8) #P"/dev/stdout"> is illegal
>
> [ and three similar error messages from three other implementations ]
Whoops. Pasteo. Writing to an input stream is definitely not
portable, Unix or no.
I'd say
(with-open-file (in "/dev/stdin" :element-type '(unsigned-byte 8))
(with-open-file (out "/dev/stdout" :element-type '(unsigned-byte 8)
:direction :output :if-exists :overwrite)
(let ((*standard-input* in)
(*standard-output* out))
(loop (write-byte (read-byte *standard-input*) *standard-output*)))))
which works, except that (Oh the irony: today is a good day for bugs
in "my" software) aborting out of that loop will cause SBCL to attempt
to delete /dev/stdout. Nevertheless.
>> Guessing wildly at your "point": that usually input and output undergo
>> character translation of some kind, and indeed there is in this sense
>> a slight impedance mismatch between the Unix world of octets and the
>> Lisp world of characters; believe it or not, this doesn't stop people
>> from getting stuff done, even Unix glue code.
>
> Claiming it is only a slight impedance mismatch doesn't make it any
> more true.
Well, no, claims are orthogonal to truth. Clearly, taking you at face
value, you are finding it a greater impedance mismatch than some
others, though I find your example unconvincing for many reasons, as
it has artificial restrictions ("portability", which I note you still
haven't defined, "through *standard-input* and *standard-output*",
which is clearly an irrelevance) and is an uninteresting problem.
Espen, in one reply to you, doesn't find such a great mismatch. What
then am I to believe? Well, for one thing, I saw a pretty convincing
talk in Amsterdam from Espen last weekend, which helps me to draw some
conclusions as to the value of his opinions on related matters.
Christophe
On Fri, 29 Apr 2005 12:15:49 +0100, Christophe Rhodes wrote:
> Adam Warner <······@consulting.net.nz> writes:
>
>> On Fri, 29 Apr 2005 10:38:31 +0100, Christophe Rhodes wrote:
>>> (with-open-file (in "/dev/stdin" :element-type '(unsigned-byte 8))
>>> (with-open-file (out "/dev/stdout" :element-type '(unsigned-byte 8)
>>> :if-exists :append)
>>> (let ((*standard-input* in)
>>> (*standard-output* out))
>>> (loop (write-byte (read-byte *standard-input*) *standard-output*)))))
>>>
>>> Of course, this is just a stupid function to prove that I can meet the
>>> spec as written, rather than what you'd find in the wild.
>>
>> CLISP: *** - WRITE-BYTE on #<INPUT UNBUFFERED FILE-STREAM (UNSIGNED-BYTE
>> 8) #P"/dev/stdout"> is illegal
>>
>> [ and three similar error messages from three other implementations ]
>
> Whoops. Pasteo. Writing to an input stream is definitely not
> portable, Unix or no.
>
> I'd say
>
> (with-open-file (in "/dev/stdin" :element-type '(unsigned-byte 8))
> (with-open-file (out "/dev/stdout" :element-type '(unsigned-byte 8)
> :direction :output :if-exists :overwrite)
> (let ((*standard-input* in)
> (*standard-output* out))
> (loop (write-byte (read-byte *standard-input*) *standard-output*)))))
>
> which works, except that (Oh the irony: today is a good day for bugs
> in "my" software) aborting out of that loop will cause SBCL to attempt
> to delete /dev/stdout. Nevertheless.
Very good. It still fails in ECL and ABCL but they may be implementation
bugs.
>>> Guessing wildly at your "point": that usually input and output undergo
>>> character translation of some kind, and indeed there is in this sense
>>> a slight impedance mismatch between the Unix world of octets and the
>>> Lisp world of characters; believe it or not, this doesn't stop people
>>> from getting stuff done, even Unix glue code.
>>
>> Claiming it is only a slight impedance mismatch doesn't make it any
>> more true.
>
> Well, no, claims are orthogonal to truth. Clearly, taking you at face
> value, you are finding it a greater impedance mismatch than some
> others, though I find your example unconvincing for many reasons, as
> it has artificial restrictions ("portability", which I note you still
> haven't defined
I restricted it to Unix-based Lisps, i.e. code which runs upon common
Unix-based Lisps without modification.
>, "through *standard-input* and *standard-output*",
> which is clearly an irrelevance) and is an uninteresting problem.
The requirement was so trivial that no one had to start operating upon
octets as if they were text and vice versa. Writing octets to a Common
Lisp character stream and Common Lisp characters to an octet stream is
both an interesting problem and non-trivial in portable Common Lisp
compared to how easily one may pun upon Unix and C streams.
The difference is apparent when one tries to knock up a Common Lisp
program to emulate a trivial Unix script. This may be one good reason
Common Lisp is not a popular glue/scripting language upon Unix.
Let's consider this from a different perspective: How many languages in
common use upon Unix are less expressive than Common Lisp at substituting
a string within a stdin/stdout filter using each language's standard
library?
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
> The difference is apparent when one tries to knock up a Common Lisp
> program to emulate a trivial Unix script. This may be one good reason
> Common Lisp is not a popular glue/scripting language upon Unix.
>
> Let's consider this from a different perspective: How many languages in
> common use upon Unix are less expressive than Common Lisp at substituting
> a string within a stdin/stdout filter using each language's standard
> library?
I don't have an answer to that question. However, how do you explain
this oddity in a language that values the principle of least surprise?
$ perl -e 'print "true\n" if ("1" == 1);'
true
Another thing about "glue" languages is that they really only work
well when the glue can stick. Lisp is very good at gluing other Lisp
code together. And Lisp is no worse at reading from one stream and
writing out to another than many other general purpose programming
languages.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
No excuses. No apologies. Just do it.
--- Erik Naggum
From: Kalle Olavi Niemitalo
Subject: Re: Lisp/Unix impedance [a programming challenge]
Date:
Message-ID: <874qdo1w72.fsf@Astalo.kon.iki.fi>
David Steuber <·····@david-steuber.com> writes:
> However, how do you explain this oddity in a language that
> values the principle of least surprise?
I'll be surprised if Perl is such a language.
> $ perl -e 'print "true\n" if ("1" == 1);'
> true
$ perl -we 'print "true\n" if ("1 apple" == "1 orange");'
Argument "1 orange" isn't numeric in numeric eq (==) at -e line 1.
Argument "1 apple" isn't numeric in numeric eq (==) at -e line 1.
true
From: Karl A. Krueger
Subject: Re: Lisp/Unix impedance [a programming challenge]
Date:
Message-ID: <d51nce$e37$1@baldur.whoi.edu>
David Steuber <·····@david-steuber.com> wrote:
> I don't have an answer to that question. However, how do you explain
> this oddity in a language that values the principle of least surprise?
>
> $ perl -e 'print "true\n" if ("1" == 1);'
> true
Perl is, indeed, weakly typed wrt the distinction between numbers and
strings that are parsable as numbers.
In the Perl debugger (the closest it has to a REPL):
DB<1> print "1.2" + 1.2 ;
2.4
DB<2> print 1 + "1.0e4";
10001
DB<3> print "1.0" + "2 beers and a snark souffle";
3
Perl is not an untyped language, though. In Perl, it is operations and
not pieces of data that seem to really carry type.
The + operation imposes numeric type on its arguments, and stops the
program if it cannot do so. For instance, under "use strict", certain
things are not allowed which otherwise would be:
DB<11> print ["foo"] + "yourmom";
Argument "yourmom" isn't numeric in addition (+) at (eval 14)[/usr/share/perl/5.8/perl5db.pl:619] line 2.
(Without "use strict", "yourmom" would be coerced to zero and the array
reference ["foo"] to its memory location. Yes, really. Perl doesn't
let you do C-style pointer arithmetic, but it will happily hand you the
integer value of that array pointer. Now who is impractical?)
The point of type in a language is to ensure that it doesn't try to
execute operations on data for which those operations are not meaningful
-- what would it mean to multiply an array by a hash table? In Perl,
you can do it, and it means to multiply their lengths:
DB<28> @ary = (1, 2, "booga");
DB<29> %has = (1 => 2, 3 => 4, 5 => 6);
DB<30> print @ary * %has ;
9
That's not quite all. The scalar value of a hash is the string composed
of its length, followed by "/", followed by the length of its current
memory allocation. But as a number, that's just its length:
DB<34> print scalar %has;
3/16
No, that isn't rational. In either sense of the word.
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
Karl A. Krueger schrob:
[...]
> Perl is not an untyped language, though. In Perl, it is operations and
> not pieces of data that seem to really carry type.
> The + operation imposes numeric type on its arguments, and stops the
> program if it cannot do so. For instance, under "use strict", certain
> things are not allowed which otherwise would be:
> DB<11> print ["foo"] + "yourmom";
> Argument "yourmom" isn't numeric in addition (+) at (eval 14)[/usr/share/perl/5.8/perl5db.pl:619] line 2.
Not completely true; it's "use warnings" that triggers the above
message, and it doesn't stop the program; it just emits a warning.
$ perl -Mstrict -le 'print "foo" + "bar"'
0
$ perl -Mwarnings -le 'print "foo" + "bar"'
Argument "bar" isn't numeric in addition (+) at -e line 1.
Argument "foo" isn't numeric in addition (+) at -e line 1.
0
> (Without "use strict", "yourmom" would be coerced to zero and the array
> reference ["foo"] to its memory location. Yes, really. Perl doesn't
> let you do C-style pointer arithmetic, but it will happily hand you the
> integer value of that array pointer. Now who is impractical?)
> The point of type in a language is to ensure that it doesn't try to
> execute operations on data for which those operations are not meaningful
> -- what would it mean to multiply an array by a hash table? In Perl,
> you can do it, and it means to multiply their lengths:
> DB<28> @ary = (1, 2, "booga");
> DB<29> %has = (1 => 2, 3 => 4, 5 => 6);
> DB<30> print @ary * %has ;
> 9
> That's not quite all. The scalar value of a hash is the string composed
> of its length, followed by "/", followed by the length of its current
> memory allocation. But as a number, that's just its length:
> DB<34> print scalar %has;
> 3/16
> No, that isn't rational. In either sense of the word.
Not completely true either (see perldoc perldata). A hash in scalar
context evaluates to string consisting of the number of used buckets and
the number of allocated buckets, separated by a slash. To get the number
of (key,value) pairs you should use "keys":
$ perl -wle '%h = (0 .. 99); print for scalar %h, scalar keys %h'
36/64
50
Every value in Perl can be converted to a number and a string. The
arithmetic and numeric comparison operators provide numeric context for
their operands; . and the string comparison ops use string context.
HTH, Lukas
--
use warnings; use strict;
sub hacker'Perl { "Perl @_,"} sub another'Just
{print"Just @_ "}
Just another Perl hacker,
>Adam Warner wrote:
>On Fri, 29 Apr 2005 12:15:49 +0100, Christophe Rhodes wrote:
>> (with-open-file (in "/dev/stdin" :element-type '(unsigned-byte 8))
>> (with-open-file (out "/dev/stdout" :element-type '(unsigned-byte
8)
>> :direction :output :if-exists :overwrite)
>> (let ((*standard-input* in)
>> (*standard-output* out))
>> (loop (write-byte (read-byte *standard-input*)
*standard-output*)))))
> Very good. It still fails in ECL and ABCL [...]
The failure in ECL is due to the fact that, by default, all binary
streams have a header specifying the number of bits used for
writing/reading. This is required to support strange byte sizes, such
as (unsigned-byte 3), etc.
CLISP does something similar, but does not use headers when the byte
size is a multiple of 8. However, that means you cannot open a file
with size (unsigned-byte 4) and then read it back with (unsigned-byte
8).
I have changed the CVS code of ECL so that by default headers are not
used and byte sizes are rounded to a multiple of 8. If the user wants
strange byte sizes, he should specify it with an additional argument to
OPEN: :USE-HEADER-P T.
So, summing up, Pascal's script now works with ECL (as of CVS)
Regards,
Juanjo
BTW, this is how the script should look with ECL:
#!/home/jlr/bin/ecl -shell
(with-open-file (stdin "/dev/stdin" :element-type '(unsigned-byte 8)
:direction :input :use-header-p nil)
(with-open-file (stdout "/dev/stdout" :element-type '(unsigned-byte 8)
:direction :output :use-header-p nil)
(loop with buffer = (make-array 4096 :element-type '(unsigned-byte
8))
for length = (read-sequence buffer stdin)
while (plusp length)
do (write-sequence buffer stdout :end length
))))
(quit)
And sorry for the horrible quoting due to my use of google groups.
Juanjo
Adam Warner <······@consulting.net.nz> writes:
> On Fri, 29 Apr 2005 10:38:31 +0100, Christophe Rhodes wrote:
>
>> Adam Warner <······@consulting.net.nz> writes:
>>
>>> Write a portable Lisp program that faithfully reproduces stdin via
>>> *standard-input* and outputs it to stdout via *standard-output*.
>>
>> Why this requirement? And, in addition, why the "portable" (by which
>> I suppose you mean "portable between Lisps", but I dunno, do you care
>> if it runs as advertised on SCO Unix, for instance)? It seems to me
>> that you're asking a question in anticipation of dismissing any
>> answer.
>>
>> (with-open-file (in "/dev/stdin" :element-type '(unsigned-byte 8))
>> (with-open-file (out "/dev/stdout" :element-type '(unsigned-byte 8)
:direction :output
>> :if-exists :append)
>> (let ((*standard-input* in)
>> (*standard-output* out))
>> (loop (write-byte (read-byte *standard-input*) *standard-output*)))))
>> [...]
> Claiming it is only a slight impedance mismatch doesn't make it any
> more true.
Bugs in programs is no impedance mismatch.
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live
Adam Warner <······@consulting.net.nz> writes:
> On Fri, 29 Apr 2005 20:36:03 +1200, Adam Warner wrote:
>
>> Hi all,
>>
>> Recent discussions in comp.lang.lisp have centred around why Lisp is so
>> unpopular as a glue language. I believe this programming challenge will
>> demonstrate why Lisp is unsuitable as a glue language for Unix.
>>
>> Here is the programming challenge for Unix-based Lisps: Write a portable
>> Lisp program that outputs to stdout whatever is input from stdin.
>
> (with-open-file (in "/dev/stdin" :element-type '(unsigned-byte 8))
> (with-open-file (out "/dev/stdout" :element-type '(unsigned-byte 8)
> :direction :output)
> (loop (write-byte (read-byte in) out))))
>
> Let's try one more time:
>
> Write a portable Lisp program that faithfully reproduces stdin via
> *standard-input* and outputs it to stdout via *standard-output*.
Ok then, let me try to *design* a chalenge for the shells:
Write a portable shell (sh, bash, zsh, ksh, shall I add csh and tcsh?)
program that does symbolic manipulation of polynomials, matrices,
rational functions, integration, Todd-coxeter, graphing, bigfloats.
Why should we not use /dev/stdin and /dev/stdout the shells scripts can
use them?
And note that for text input, which is the case for 99% of the unix
filters uses, my first script that did use *standard-input* and
*standard-output* is perfectly valid and portable, and could still be
used with a slightly non-portable modification, specifying some 1-1
charset encoding.
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: Lisp/Unix impedance [a programming challenge]
Date:
Message-ID: <REM-2005may01-001@Yahoo.Com>
> From: Adam Warner <······@consulting.net.nz>
> I believe this programming challenge will demonstrate why Lisp is
> unsuitable as a glue language for Unix.
A glue language is the stuff that feeds stdout from one program, or
stream from a data file, to stdin of another program, or stream to a
log file, and stuff like that, right? For example, in the following two
Unix command lines:
ls > tmp1
ls | cat > tmp2
'ls' and 'cat' are programs being called, while > and | are the glue
that pipes stuff from one place to another, right?
> Write a portable Lisp program that outputs to stdout whatever is
> input from stdin.
That's not a challenge for glue, it's a challenge for a replacement for
the called program 'cat' in the second script above. You seem to have
confused the called-program from the calling-glue.
A correct challenge (in the second case above) would be to write a
Common Lisp program that calls the programs 'ls' and 'cat', passing the
output from 'ls' to input to 'cat', and writing the output from 'cat'
into a file tmp2, complaining if the file already exists.
A more interesting challenge would be to write a program in any
language whatsoever which took an s-expression as input and called the
program 'mkdir' repeatedly as needed to build a hierarchy of
directories according to the various levels in that s-expression. In
CMUCL this would be a rather easy task. How easy would it be in sh or
csh or bash or perl or C or C++ or Java?
Even more interesting: Same input s-expression except the directories
already exist, and the task is to check all *.java files in those
specific directories against corresponding *.class files and compile a
list of any which are out of date (need compilation), producing a new
s-expression matching the original but now populated with names of all
out-of-date *.java files.
·······@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
>> From: Adam Warner <······@consulting.net.nz>
>> I believe this programming challenge will demonstrate why Lisp is
>> unsuitable as a glue language for Unix.
>
> A glue language is the stuff that feeds stdout from one program, or
> stream from a data file, to stdin of another program, or stream to a
> log file, and stuff like that, right? For example, in the following two
> Unix command lines:
> ls > tmp1
> ls | cat > tmp2
> 'ls' and 'cat' are programs being called, while > and | are the glue
> that pipes stuff from one place to another, right?
For some unix programs (MacOSX applications), you'd need AppleScript
or Distributed Objects instead of shell to glue them together...
>> Write a portable Lisp program that outputs to stdout whatever is
>> input from stdin.
>
> That's not a challenge for glue, it's a challenge for a replacement for
> the called program 'cat' in the second script above. You seem to have
> confused the called-program from the calling-glue.
>
> A correct challenge (in the second case above) would be to write a
> Common Lisp program that calls the programs 'ls' and 'cat', passing the
> output from 'ls' to input to 'cat', and writing the output from 'cat'
> into a file tmp2, complaining if the file already exists.
You're right, but we may consider: program1 | glue | program2
assuming that the output of program1 is not compatible with the input
of program2, we want to write a glue "scritp" that will transform the
data.
> A more interesting challenge would be to write a program in any
> language whatsoever which took an s-expression as input and called the
> program 'mkdir' repeatedly as needed to build a hierarchy of
> directories according to the various levels in that s-expression. In
> CMUCL this would be a rather easy task. How easy would it be in sh or
> csh or bash or perl or C or C++ or Java?
>
> Even more interesting: Same input s-expression except the directories
> already exist, and the task is to check all *.java files in those
> specific directories against corresponding *.class files and compile a
> list of any which are out of date (need compilation), producing a new
> s-expression matching the original but now populated with names of all
> out-of-date *.java files.
I have only 83 programs in my /bin. Let's rewrite them in Common Lisp
to consume and produce lisp data. Then the ultimate glue will be
Common Lisp ;-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: Lisp/Unix impedance [a programming challenge]
Date:
Message-ID: <REM-2005jun22-003@Yahoo.Com>
> From: Pascal Bourguignon <···@informatimago.com>
> For some unix programs (MacOSX applications), you'd need AppleScript
> or Distributed Objects instead of shell to glue them together...
I've never had access to MacOSX so I don't know about this. Are you
saying the stdio and stdout of such applications is not a character
stream as it was with traditional Unix/Linux, but is some more
structured kind of stream, maybe like MacLisp FIleArrays could handle,
although Mac data instead of Lisp data in the specifics, but still the
same basic idea of object stream instead of character stream? (Note
this is *not* the same as Java Object I/O which is merely a
serialization of writing or reading a single object at a time to/from a
character stream, much like prin1 and read are in Lisp.)
> we may consider: program1 | glue | program2 assuming that the output
> of program1 is not compatible with the input of program2, we want to
> write a glue "script" that will transform the data.
Ah, different meaning of "glue" here. I was thinking of "glue" as a
script that combines several small applications into one large
application, rather than a filter that is called after one small
application and before another small application within a large script.
So I guess we really have two questions:
- What is the best way to make stdio format-converting filters.
- What is the best toplevel scripting language.
I personally consider Lisp the best scripting language, and either Lisp
or awk as the best stdio filter depending on circumstances. Of course
if Lisp is running the toplevel script, then having Lisp functions to
do the stdio filtering from one called application to the next avoids
an extra level of process switching, since the filter function can be
loaded into the same Lisp environment that is already running the
script. So maybe a Lisp implementation of awk would be optimal for
stdio filtering (impedance matching) in cases where awk itself could do
the task. Alternately, some experiments with SmallTalk/Lisp variants
(such as Wegbreit's ECL (Extensible Computer Language)) generated
functions from each-case syntax-transform specifications rather than
from formal function/method definitions, and likewise a context-free
grammar-compiler we (Suppes et al) used at Stanford IMSSS for
experiments with natural language parsing/understanding/transforming
would parse per a template then construct a corresponding Lisp
structure per reassembling parts of input that matched variables of the
template, and emulating that sort of thing from inside Lisp might be
better (more flexible, equally efficient) compared to emulating awk.
> I have only 83 programs in my /bin. Let's rewrite them in Common
> Lisp to consume and produce lisp data.
If any of them currently produce text streams that represents some
structured data but in a crude way, having it produce s-expressions in
a nice clean way would seem to be an improvement. Then skipping the
prin1 part, generating the internal pointy structures would be one
additional improvement. Personally I consider tab-delimited fields in
newline-delimited records to form tables using flat text I/O to be a
poor substitute for s-expressions over that same flat text I/O,
especially if the data really has more than two levels of hierarchy
where you use ad-hoc notations within that a single tab-delimited
field, or you use separate tables that are semantically but not
syntactically linked, to be much inferior to s-expressions. (And XML is
much too verbose, and hard to visualize, compared to s-expressions, for
most applications.)
So can you pick five of those Unix applications/commands whose output
most urgently begs to be truly structured (s-expr or XML) rather than
flat text, for our first trial exercise?
By the way, it occurs to me that business datasets naturally are
multi-level hierarchial. For example the whole history of a company's
accounts receivable could be divided into fiscal years, which are
divided into months, which are divided into days. Likewise they are
divided by company division/city, and then by department, and then by
team, and then by individual who was handling the record. Likewise they
are divided by major project area, and then by product line, and then
by detailed size of product, and then by packaging quantity. And with
s-expressions that is parsed into pointy structures it's trivial to
rearrange data that was divided first by date and secondarily by
something else, to be first by something else then by date, or to
filter out all data outside some specified range of date or product
etc. So I wonder why COBOL never adopted s-expressions and pointy
structures as a way to pass datasets around, between separate programs
and files, and between procedures within a single application,
respectively? Now that XML is so popular for program/file/stream
dataset-communication and DOM for inside-program storage/passing, is
COBOL being adapted to work with XML/DOM?
·······@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
>> From: Pascal Bourguignon <···@informatimago.com>
>> For some unix programs (MacOSX applications), you'd need AppleScript
>> or Distributed Objects instead of shell to glue them together...
>
> I've never had access to MacOSX so I don't know about this. Are you
> saying the stdio and stdout of such applications is not a character
> stream as it was with traditional Unix/Linux,
The Workspace Manager, or the Finder don't set up file descriptors for
stdin/stdout/stderr when you double-click on the icon of an application.
(Or perhaps just redirect stderr to the console).
> but is some more
> structured kind of stream, maybe like MacLisp FIleArrays could handle,
> although Mac data instead of Lisp data in the specifics, but still the
> same basic idea of object stream instead of character stream?
A specific application could try to read and write stdin and stdout,
with any format, but since the GUI doesn't help the user to set up any
kind of stream or pipe, it would not be functional.
> (Note
> this is *not* the same as Java Object I/O which is merely a
> serialization of writing or reading a single object at a time to/from a
> character stream, much like prin1 and read are in Lisp.)
There's also serialization methods in OpenStep, that you could use to
transmit objects on streams or pipes. Could be useful for command
line tools...
What _applications_ respond to is events exchanged with the GUI.
AppleScript let applications communicate with these events flows,
sending tokens requesting the execution of specific functions. Each
application can publish an API of objects and messages it can respond
to when received as events, as it does with respect to the GUI with
menu items, and it responds to the menu selection events.
>> we may consider: program1 | glue | program2 assuming that the output
>> of program1 is not compatible with the input of program2, we want to
>> write a glue "script" that will transform the data.
>
> Ah, different meaning of "glue" here. I was thinking of "glue" as a
> script that combines several small applications into one large
> application, rather than a filter that is called after one small
> application and before another small application within a large script.
>
> So I guess we really have two questions:
> - What is the best way to make stdio format-converting filters.
The best way is to have a set of applications all using the same stdio
format. The second best is to define a small set of common formats
and write converters to and from these common formats.
$ ls /usr/local/bin/*2ps /usr/local/bin/ps2*
/usr/local/bin/pdf2ps* /usr/local/bin/ps2pdf12* /usr/local/bin/ps2ps*
/usr/local/bin/ps2ascii* /usr/local/bin/ps2pdf13* /usr/local/bin/ps2ps*
/usr/local/bin/ps2epsi* /usr/local/bin/ps2pdf14*
/usr/local/bin/ps2pdf* /usr/local/bin/ps2pdfwr*
The specifics of implementing these filters depend of course of the
specific format and constraints of your tools. We've seen it might be
delicate to filter random binary data with current Common Lisp
implementations...
> - What is the best toplevel scripting language.
The best programming language.
Scripting is plain programming.
You must distinguish programming use of a language from interactive
CLI use of same if at all possible. Shells are nice for interactive
use, but they're PITAs for programming.
> I personally consider Lisp the best scripting language, [...]
I consider it too. All my new scripts are written in Common Lisp.
>> I have only 83 programs in my /bin. Let's rewrite them in Common
>> Lisp to consume and produce lisp data.
>
> If any of them currently produce text streams that represents some
> structured data but in a crude way, having it produce s-expressions in
> a nice clean way would seem to be an improvement. Then skipping the
> prin1 part, generating the internal pointy structures would be one
> additional improvement. Personally I consider tab-delimited fields in
> newline-delimited records to form tables using flat text I/O to be a
> poor substitute for s-expressions over that same flat text I/O,
> especially if the data really has more than two levels of hierarchy
> where you use ad-hoc notations within that a single tab-delimited
> field, or you use separate tables that are semantically but not
> syntactically linked, to be much inferior to s-expressions. (And XML is
> much too verbose, and hard to visualize, compared to s-expressions, for
> most applications.)
Indeed, one point of the current state is that an "interactive"
command which outputs text formated for human consuption can also quite
easily (if flakily) be further processed by another program.
Eg: ls -l|awk '{print $3}'|sort -u
But it is also easy to format S-expression output to be human
readable, as we lisp programmers all know.
> So can you pick five of those Unix applications/commands whose output
> most urgently begs to be truly structured (s-expr or XML) rather than
> flat text, for our first trial exercise?
>
> By the way, it occurs to me that business datasets naturally are
> multi-level hierarchial. For example the whole history of a company's
> accounts receivable could be divided into fiscal years, which are
> divided into months, which are divided into days. Likewise they are
> divided by company division/city, and then by department, and then by
> team, and then by individual who was handling the record. Likewise they
> are divided by major project area, and then by product line, and then
> by detailed size of product, and then by packaging quantity. And with
> s-expressions that is parsed into pointy structures it's trivial to
> rearrange data that was divided first by date and secondarily by
> something else, to be first by something else then by date, or to
> filter out all data outside some specified range of date or product
> etc. So I wonder why COBOL never adopted s-expressions and pointy
> structures as a way to pass datasets around, between separate programs
> and files, and between procedures within a single application,
> respectively? Now that XML is so popular for program/file/stream
> dataset-communication and DOM for inside-program storage/passing, is
> COBOL being adapted to work with XML/DOM?
The mindsets between LISP I/O and COBOL I/O are completely different.
It's a real miracle that LISP I/O appeared, on those card based
computers. It was entirely anti-natural. (It did appear because lisp
was designed theorically first).
Perhaps string processing improved in recent iterations of COBOL, but
the natural way is to work with static buffers (80-column punch cards
or 132-column printer lines).
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
__Pascal Bourguignon__ http://www.informatimago.com/
From: Christopher C. Stacy
Subject: Re: Lisp/Unix impedance [a programming challenge]
Date:
Message-ID: <ufyv9chlj.fsf@news.dtpq.com>
Pascal Bourguignon <···@informatimago.com> writes:
> Perhaps string processing improved in recent iterations of COBOL, but
> the natural way is to work with static buffers (80-column punch cards
> or 132-column printer lines).
It's great for interacting with certain kinds of formatted data.
And sometimes it makes very good sense to buffer rather than cons.
(defsection :working-storage
(dividend :picture "9(6)" :value 0)
(percentage :picture "9999" :value 0)
(line-no :picture "99" :value 0)
(1-replenish-report-heading
(10 filler :picture "X(116)" :value #\Space)
(10 page)
(15 pagekon :value page :picture "X(5)"))
(2-replenish-report-heading
(02 one-thru-sixty-one :picture "X(61)"
:value " STOCK MFR CATALOG ITE")
...))
(hris :)
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: Lisp/Unix impedance [a programming challenge]
Date:
Message-ID: <REM-2005jun26-001@Yahoo.Com>
> From: Pascal Bourguignon <···@informatimago.com>
> The Workspace Manager, or the Finder don't set up file descriptors for
> stdin/stdout/stderr when you double-click on the icon of an application.
I cite from:
http://www.google.se/groups?selm=871x8pegen.fsf%40thalassa.informatimago.com
> For some unix programs (MacOSX applications), ...
How could those MacOSX applications be approriately termed "unix
programs" if they don't deal with stdio? Stdio is one of the defining
characteristics of unix programs. Even if some program runs on unix, if
it doesn't do stdio then isn't really a "unix program", it's a non-unix
program running on unix.
Even on Windows, if Jcreator or Visual C++ starts to run an
application, even if that application doesn't actually do any stdio
whatsoever, still a DOS window is opened for stdio. From the term "unix
program" I assumed the applications you're working with do about the
same thing. I can understand if they keep such a window invisible until
such time as the program acutally writes to stdio or tries to read from
stdin, but I don't see why stdio would not even be available if it's
trying to run a "unix program" on the Mac.
By the way, one GUI metaphor common on the Mac (at least way back in
System 7 which I use) is to drag a data file on top of an application's
icon, which pipes that file into the usual input channel of the
application, replacing the usual open of file using find-file dialog.
It would seem a simple extension of such a GUI metaphor to establish a
multi-program pipeline by dragging the next-to-last program on top of
the last program, then the 2nd-from-last on top of next-to-last, and
finally the data file on top of the first application. To establish
stdout to file, drag last application on top of empty output file or
non-empty output file to be appended. (I would have thought that by now
Apple would have thought of something like that, and when I read about
"unix programs" I just assumed that's what you were referring to.)
> Shells are nice for interactive use, but they're PITAs for
> programming.
Your use of PITA (Prefer Initialization To Assignment) makes no sense
to me here.
lisp-shell (REP), or java-shell (BeanShell), are just fine for both
programming and simply calling an already-written program. If your
remark is some kind of degrading of them, then I disagree with you.
> The mindsets between LISP I/O and COBOL I/O are completely different.
So the COBOL people are so stuck in a rut that they can't see beyond
their noses and can't see any possible change to COBOL 1964 ?
On Sun, 26 Jun 2005 00:00:20 -0700, <·······@Yahoo.Com> wrote:
>
> So the COBOL people are so stuck in a rut that they can't see beyond
> their noses and can't see any possible change to COBOL 1964 ?
I'd be surprised if COBOL changed. The whole point of that language
would be lost in a change.
--
The LOOP construct is really neat, it's got a lot of knobs to turn!
Don't push the yellow one on the bottom.
From: Karl A. Krueger
Subject: Re: Lisp/Unix impedance [a programming challenge]
Date:
Message-ID: <d9pf2v$hbk$1@baldur.whoi.edu>
Robert Maas, see http://tinyurl.com/uh3t <·······@yahoo.com> wrote:
> How could those MacOSX applications be approriately termed "unix
> programs" if they don't deal with stdio? Stdio is one of the defining
> characteristics of unix programs. Even if some program runs on unix, if
> it doesn't do stdio then isn't really a "unix program", it's a non-unix
> program running on unix.
Really? Most X11 programs do not "do stdio", and yet are certainly Unix
programs. You can't pipe a command into xterm. You can't pipe a Web
page or a URL into Mozilla Firefox. You can't pipe the current time
into oclock, or an image into xsetroot.
Perhaps it would be useful to be able to do so, but dismissing Unix
programs that don't "do stdio" as "non-Unix programs" is precisely the
"No True Scotsman" fallacy.
http://en.wikipedia.org/wiki/No_true_Scotsman
The presumption that Unix is just the command line is rather amusing in
the context of comp.lang.lisp, where we all frequently see similar
misconceptions about Lisp debunked: Just as Lisp has had data
structures other than lists for decades, Unix has had GUIs (and GUI
tools that don't "do stdio") for decades, too.
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
"Karl A. Krueger" <········@example.edu> writes:
> You can't pipe a command into xterm. You can't pipe a Web
> page or a URL into Mozilla Firefox.
Well, I can drag&drop a text document into a running Emacs on both
MS-Windows and an Amiga (and could do so for the last 15 years), but
on UNIX, it's still not possible (or it doesn't work out of the box on
by Ubuntu/Hoary system). Guess which has better useability?
Similarly, on an Amiga, and on MS-Windows and MacOS, I can send a
command to any GUI web-browser using ARexx (DDE on MS-Windows, and
Applescript(?) on Mac), which is a standardized mechanism, and the
browser will open the URL. On UNIX, the best I've heard of is
"netscape -remote url".
I wished such means were widespread UNIX, and it's not stdio/pipes
that's missing.
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
Joerg Hoehle wrote:
> On UNIX, the best I've heard of is
> "netscape -remote url".
The problem is that on unix there are a range of
desktop environments with different abilities.
Note that particular unix desktop environments such as KDE
have rather more than that, you may be just using a shit one
- try "dcop" on the command line of a unix or linux box running KDE,
you can script some quite complex interactions with KDE applications.
It doesn't quite match the ability of Amiga ARexx, but it's not as bad
as you make out, either. Maybe as DBUS (see freedesktop.org) is
adopted by both KDE and GNOME, the support for such things should
generalise, at least if GNOME catches up to KDE a bit.
> it's still not possible (or it doesn't work out of the box on
> by Ubuntu/Hoary system
Hm. Remind me not to recommend Ubuntu to people, sounds
like it's inflicted with GNOME or somethng :-)
Funny enough, dragging a text document from the KDE
file manager onto a running emacs also works out-of-box
for me on Debian (and I doubt that's a debian-specific
property), has done for ages as far as I recall
though I've never been an amazingly huge fan of drag-drop
myself. Even back on the amiga of yore I tended not
to use it much unless that was the only way an application
author provided some functionality.
Joerg Hoehle <······@users.sourceforge.net> writes:
> "Karl A. Krueger" <········@example.edu> writes:
> > You can't pipe a command into xterm. You can't pipe a Web
> > page or a URL into Mozilla Firefox.
>
> Well, I can drag&drop a text document into a running Emacs on both
> MS-Windows and an Amiga (and could do so for the last 15 years), but
> on UNIX, it's still not possible (or it doesn't work out of the box on
> by Ubuntu/Hoary system). Guess which has better useability?
>
> Similarly, on an Amiga, and on MS-Windows and MacOS, I can send a
> command to any GUI web-browser using ARexx (DDE on MS-Windows, and
> Applescript(?) on Mac), which is a standardized mechanism, and the
> browser will open the URL. On UNIX, the best I've heard of is
> "netscape -remote url".
>
> I wished such means were widespread UNIX, and it's not stdio/pipes
> that's missing.
>
I find these types of comparisons and arguments quite flawed. It seems
to be a real apples and oranges comparison. People insist on comparing
one system, which has probably been obtained for free or for very
little cost to a comercial system which has cost a considerable amount
and then point out all the added "sugar" they get with the commercial
one over the free one.
These arguements are also generally wrong. I was using a drag and drop
desktop on Red Hat Linux almost 10 years ago. The desktop itself was a
commercial CDE clone - so I was able to get the same desktop "sugar"
on Linux by paying for it just like you pay for MS Windows, Amiga or
Mac.
I've been running emacs and other programs on Linux for 10 years in
have been able to send an html file to a running browser and see it
with no problems at all and this has been with various browsers, not
just netscape.
The usability argument is also inherently flawed because it means
different things to different users. What one person might consider
essential usability another doesn't even care about. Personally, I
don't like drag and drop. However, I really like the ability to solve
problems with a few small utilities which communicate with each other
via pipes, stdin/sdtout/stderr etc. For me and the way I work, Linux
has far greater usability than Windows/Mac/Amiga. This does not mean I
think Linux is necessarily the "best" environment with the best
desktop - its simply the best for me.
Some users want a solution which meets their requirments right out of
the box with no or minimal configuration. Other users like to look at
lots of different approaches and select the one which suits them best
and yet others like something which they can heavily customize to meet
their needs. None is better than the other per se. Its all a matter of
different strokes for different folks. I consider myself very lucky as
the free out of the box environment of Linux suits my style of working
better than more expensive commercial solutions - but this was just
luck. It could have been the other way around and I might have
developed a working style whih really suited the Windows
environment. Luckily, I was first introduced to computers when most
people had nothing more than a vt100 terminal and X windows was
beginnig to become the GUI for Unix. Back then, MS Windows didn't
exist and the most 'graphical' UI you coud get was something like
Midnight Commander. The Mac was looking pretty good at this time, but
I guess that was due to it being based on some user interfaces being
developed/used at Xerox.
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
On 09 Jul 2005 18:36:48 +1000, Tim X <····@spamto.devnul.com> wrote:
> I find these types of comparisons and arguments quite flawed. It
> seems to be a real apples and oranges comparison. People insist on
> comparing one system, which has probably been obtained for free or
> for very little cost to a comercial system which has cost a
> considerable amount and then point out all the added "sugar" they
> get with the commercial one over the free one.
What I see is usually the other way around. Users of a free system
(which almost always means Linux) insist on comparing it with
commercial systems and explaining to everybody that "their" system is
vastly superior.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Tim X wrote:
> However, I really like the ability to solve
> problems with a few small utilities which communicate with each other
> via pipes, stdin/sdtout/stderr etc. For me and the way I work, Linux
> has far greater usability than Windows/Mac/Amiga.
No particular need to lump Amiga in there in that respect: it always had
a powerful somewhat-unix-like CLI.
"Tim X" <····@spamto.devnul.com> wrote:
[snip]
> environment. Luckily, I was first introduced to computers when most
> people had nothing more than a vt100 terminal and X windows was
> beginnig to become the GUI for Unix. Back then, MS Windows didn't
> exist and the most 'graphical' UI you coud get was something like
> Midnight Commander. The Mac was looking pretty good at this time, but
I used Windows from Win/386 onwards, and for the majority of that time,
Norton Commander (tm no doubt) was my weapon of choice. Midnight Commander
is much better, incidentally.
Can't stand the Windows GUI - does that make me some kind of circus freak?
Can't use Windows Explorer without foaming at the mouth, either...
> I guess that was due to it being based on some user interfaces being
> developed/used at Xerox.
If only the way this post reads now was the way things were...
>
> Tim
> --
> Tim Cross
> The e-mail address on this message is FALSE (obviously!). My real e-mail
> is
> to a company in Australia called rapttech and my login is tcross - if you
> really need to send mail, you should be able to work it out!
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: Lisp/Unix impedance [a programming challenge]
Date:
Message-ID: <REM-2005jul27-013@Yahoo.Com>
> From: "Karl A. Krueger" <········@example.edu>
> Most X11 programs do not "do stdio", and yet are certainly Unix
> programs.
My only significant X11 experience is on my RedHat Linux GNOME laptop,
where X11 (I think it's that anyway, all I really know is that it
claims to be an X window) is used to implement a terminal window
whereby I'm talking to a Unix shell, whereby all the Unix-style piping
etc. work just fine in that shell. I have no idea whether the GUI
applications such as the games (freecell or mines) or the directory
browser (has tree structure on left, and listing of one directory on
right) uses X11 or not. Gnu Emacs comes up in its own window, instead
of sharing the term window as Lynx does, so maybe Gnu Emacs is an X11
appliation, I have no idea. I do know that (send-string-to-terminal
..) or somesuch actually sends the string to stdout of the controlling
shell, over in the x term window I mentionned above, so apparently
whether it's an x11 application or not it still knows how to write to
stdout. I've never checked whether it can likewise read from stdin of
the controlling shell because I never had any use for that capability.
Assuming what you sa about *other* Unix X11 programs, not Gnu Emacs,
but maybe those games I mentionned, maybe Netscape (which complains via
a pop-up modal dialog about being unable to open stdout or somesuch
every time it starts up), then I'll have to qualify my claim about Unix
programs somehow. Do you know the correct jargon for Unix programs that
use stdio as described in any regular introductory Unix book (such as
McGilton&Morgan which make not the slightest mention of X or X11) as
opposed to Unix programs that work only with X11 and have no concept of
stdio?
> The presumption that Unix is just the command line is rather amusing
> in the context of comp.lang.lisp, where we all frequently see similar
> misconceptions about Lisp debunked: Just as Lisp has had data
> structures other than lists for decades, Unix has had GUIs (and GUI
> tools that don't "do stdio") for decades, too.
I'm not talking about something like CL which has not only
old-fashioned linked lists implemented as CDR-linked daisy chains of
standard pairs, but also has newer kinds of structures such as strings
and OO-class-objects. I'm talking about something like a castrated lisp
that didn't implement linked lists or even lists implemented as
extendable arrays in any form whatsoever, yet still claimed to be a
"lisp". If the programming system has no way whatsoever to build
anything isomorphic to a list or a-list etc., then I'd question whether
it was really a lisp, just as somebody with six legs and an exoskeleton
wouldn't qualify as any kind of human much less a "true Scotsman".
So a program that runs on Unix, but can't do stdio whatsoever, isn't
really what I'd consider a regular Unix program in the original sense.
If it can do stdio, but mostly uses X11 GUI then I'd accept it fine.
But if you know of an appropriate term for a program that runs on Unix
and is able to do stdio in the usual way, please tell me that jargon.
By the way, my only access to Unix (not Linux) is via VT100 dialup,
whereby I can't run any program in any mode other than stdio.
So if any application requires X11, doesn't work with stdio,
then from my point of view it doesn't exist.
Robert Maas, see http://tinyurl.com/uh3t <·······@yahoo.com> wrote:
>etc. work just fine in that shell. I have no idea whether the GUI
>applications such as the games (freecell or mines) or the directory
>browser (has tree structure on left, and listing of one directory on
>right) uses X11 or not. Gnu Emacs comes up in its own window, instead
X11 is the underlying infrastructure, including the display drivers,
drawing primitives, display network code and everything. Gnome etc.
are just layers on top of X11, and even direct rendering stuff
(opengl, xvid) is provided through X server extensions. Type "man
X" on your Linux box for a rather elaborate overview.
>whether it's an x11 application or not it still knows how to write to
>stdout. I've never checked whether it can likewise read from stdin of
There is no distinction between programs using X11 and "ordinary"
Unix programs just in the same way as there's no distinction between
programs that use the curses library and those who don't. We're not
on Windows95 here where only specifically marked programs could run
in the GUI and not on DOS and vice versa. Of course the X programs
need to be able to connect to an X server, otherwise they'll have
no display to draw graphics on. ;)
>So a program that runs on Unix, but can't do stdio whatsoever, isn't
>really what I'd consider a regular Unix program in the original sense.
Many X programs actually write stuff to stdout (or stderr), debug
messages, error messages, etc. Many people simply don't see those
most of the time because they start those programs through the
window manager or desktop environment and not from a terminal window.
>By the way, my only access to Unix (not Linux) is via VT100 dialup,
>whereby I can't run any program in any mode other than stdio.
>So if any application requires X11, doesn't work with stdio,
>then from my point of view it doesn't exist.
Well, you can redirect the display to your local machine (you said
it's Linux and running an X server). Might be a bit slow, though.
I also prefer tty-only programs when logged in remotely (and generally
also).
mkb.
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: Lisp/Unix impedance [a programming challenge]
Date:
Message-ID: <REM-2005aug07-002@Yahoo.Com>
> From: Matthias Buelow <····@incubus.de>
> you can redirect the display to your local machine
No, I can't, for multiple reasons.
> (you said it's Linux and running an X server).
The X server is only for localhost. There's no PPP service (it costs
extra beyond the $19/55 per month I've been paying for shell with VT100
dialup access), and the modem doesn't work at all currently (it got
wedged into a state where it isn't online but thinks it is so there's
no way to get into command mode to reset it, and even when removed from
all electric power for many hours the modem still thinks it's online).
Do you know to fix a XIrcom "RealPort Ethernet+Modem 56 REM56G-10"
without any money to pay for an expert to work on it?
> I also prefer tty-only programs when logged in remotely (and
> generally also).
I much prefer text-only access except when I actually want to see some
visual image that can't be rendereed as ASCII art, such as images from
NASA/ESA space probes/telescopes etc., or e-photos of women to meet.
The public library allows only one hour of InterNet access per day, and
it has only MS-IE available, complete with incessant overlaying pop-up
ads that can't be dismissed. (ALT-TAB seems to be the only way to get
back to what I was trying to work on, but there's no way to get back
the text I was typing when the pop-up had already came up but human
response time is such that a lot of typing continues until I notice the
pop-up is eating all my type-in.)
ObLisp: Is there anyone who would like to try online (CGI) demos of
some of the Lisp software I've written? Is there anyone who would like
to see a list of software I've written, some of which has already been
converted to CGI demo but most of which I won't bother to convert until
and unless somebody shows an interest in seeing it?
Is there anybody other than myself who has a list of software they've written?
Robert Maas, see http://tinyurl.com/uh3t <·······@yahoo.com> wrote:
>The X server is only for localhost. There's no PPP service (it costs
>extra beyond the $19/55 per month I've been paying for shell with VT100
>dialup access), and the modem doesn't work at all currently (it got
$19 for shell access?! I pay little more for a DSL flatrate...
mkb.
Matthias Buelow <···@incubus.de> writes:
>
>>The X server is only for localhost. There's no PPP service (it costs
>>extra beyond the $19/55 per month I've been paying for shell with
>>VT100 dialup access), and the modem doesn't work at all currently (it
>>got
>
> $19 for shell access?! I pay little more for a DSL flatrate...
freeshell.org has free shell accounts ($36 lifetime to avoid
auto-deletion).
--
Robert Uhl <http://public.xdi.org/=ruhl>
Microsoft .NET is more than a suite of software products--it's a
marsupial-filled popcorn-machine rolling down a hill out of control and
smashing into a bingo parlour full of crossdressing kleptomaniac
vampires. --Tanuki
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Don't trust "lifetime" (was: Lisp/Unix impedance [a programming challenge])
Date:
Message-ID: <REM-2005aug26-001@Yahoo.Com>
> From: Robert Uhl <·········@NOSPAMgmail.com>
> freeshell.org has free shell accounts
Do they provide all the services that I already have with my current
shell account?
http://www.rawbw.com/~rem/NewPub/mySituation.html#isp
> ($36 lifetime to avoid auto-deletion).
When I was a child, my parents fell for that sucker line. They paid a
bunch of extra money for a lifetime subscription to the annual
supplements to Collier's Encyclopedia. The very next year Collier's
declared bankruptcy and neither returned my parent's money nor ever
sent another annual supplement as promised. Recently I see they're back
in business, still not honoring their old contracts. Is that legal?
More recently:
- I bought an umbrella from Macy's, while it was on special, with a
manufacturer's lifetime warrantee. After a few years it was getting
ragged so I took it in per warrantee, but Macy's said they wouldn't
replace it, they would only refund how much it originally costs, which
was much less than it'd cost for a replacement. So I kept the bad
umbrella instead of getting a $5 refund and having no money to have any
umbrella at all.
- I bought a backpack from a bike shop on University in Palo Alto, yeah
the one everyone around there knows, the big main bike shop in that
part of town, whose name escapes me at the moment. It had a lifetime
guarantee from the store. After a few years it had gotten ragged, so I
took it in to be replaced, but they refused, saying they were referring
to the lifetime of the backpack, not my lifetime, and as far as they
were concerned the backpack was dead now, so the warantee no longer
applies. I'll never shop at that store again.
If a stable company like IBM (or Macy's) offered anything lifetime, I'd
be suspicious, but might take a chance, but not with Macy's ever again,
but when some unknown organization with flaky financial background such
as freeshell.org offers anything lifetime I disregard it as worthless.
On Fri, 26 Aug 2005 13:00:15 -0700, ·······@Yahoo.Com (Robert Maas,
see http://tinyurl.com/uh3t) wrote:
>When I was a child, my parents fell for that sucker line. They paid a
>bunch of extra money for a lifetime subscription to the annual
>supplements to Collier's Encyclopedia. The very next year Collier's
>declared bankruptcy and neither returned my parent's money nor ever
>sent another annual supplement as promised. Recently I see they're back
>in business, still not honoring their old contracts. Is that legal?
>
>More recently:
>- I bought an umbrella from Macy's, while it was on special, with a
> ..
>- I bought a backpack from a bike shop on University in Palo Alto, yeah
...
Is this about Lisp?...
A.L..
On Robert Maas, see http://tinyurl.com/uh3t <·······@Yahoo.Com> wrote:
> > From: Robert Uhl <·········@NOSPAMgmail.com>
> > freeshell.org has free shell accounts
>
> Do they provide all the services that I already have with my current
> shell account?
Can you read?
> If a stable company like IBM (or Macy's) offered anything lifetime, I'd
> be suspicious, but might take a chance, but not with Macy's ever again,
> but when some unknown organization with flaky financial background such
> as freeshell.org offers anything lifetime I disregard it as worthless.
Unknown organization? Flaky financial background?
An entire newsgroup bends over backwards to provide helpful information to
you and you turn all of it down, often with shaky "arguments".
I'm starting to see why you've been unemployed for 10 years.
·······@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
>
>> freeshell.org has free shell accounts
>
> Do they provide all the services that I already have with my current
> shell account?
You have the domain; check out the website.
> http://www.rawbw.com/~rem/NewPub/mySituation.html#isp
However, since I'm such a nice and pleasant person, I'll do it for you
just this once:
OS: NetBSD 2.02_STABLE
Accessible vie dialup, telnet & ssh
Support: available, I imagine
Shells: sh, csh, ksh, ksh93, pdksh, bash, tcsh & zsh
Editors: ed, ex, vi, nvi, bvi, vim, vile, emacs, uemacs, beav, zile, ce,
jed, jove, pico, nano, ee, hnb, ne, ve
Space: 100MB home/100MB web for the $36 lifetime price; $20/yr for each
100MB extra
Web Page: available by default
PHP: available
CGI: available
Lisp: available
Java: no available
Perl: 5.8.7, better than your ISP provides
In other words, a better deal for less money.
>> ($36 lifetime to avoid auto-deletion).
>
> When I was a child, my parents fell for that sucker line.
freeshell.org has been around since '87. Certainly, it's possible that
they could go out of business--but given the $20/mo you pay now, their
$36/lifetime will pay for itself in two months--every month after that
is gravy.
Your excuses for not finding work sound like your excuses for not
finding a better provider, and both sets of excuses sound an awful lot
like my own excuses for not finding a date. You've inspired me to
resolve that particular issue--perhaps someday you'll be inspired to
resolve your own.
--
Robert Uhl <http://public.xdi.org/=ruhl>
One foot is approximately the distance travelled by light in one nanosecond.
One metre is the distance travelled by light in 3.335641... nanoseconds.
Which is more scientific?
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: Lisp/Unix impedance [a programming challenge]
Date:
Message-ID: <REM-2005aug14-005@Yahoo.Com>
> From: Matthias Buelow <····@incubus.de>
> $19 for shell access?! I pay little more for a DSL flatrate...
(1) I can't afford "little more" than I already pay, so even if your
service is everything I already have plus more, I can't afford it.
(2) I don't have a computer capable of running PPP/DSL so your service
would be of no use to me beyond what I already have.
(3) My service provides not just Unix shell but VT100 dialup into that
Unix shell as well as TELNET access into it if I'm ever on some other
computer and want to check my shell account, and also my shell account
lets me set up CGI and PHP. Does your service provide all of those plus
also the PPP/DSL?
(4) Are you in Germany? Even if could afford your service and even if I
had a new computer that could do PPP/DSL and even if your service
included everything I already have plus more, I can't afford
international long distance calls into your dialups in Germany.
Please answer item 3 above.
Robert Maas, see http://tinyurl.com/uh3t <·······@yahoo.com> wrote:
>(1) I can't afford "little more" than I already pay, so even if your
>service is everything I already have plus more, I can't afford it.
I was just implying that you're being ripped off if all you get is
a shell account for that money, and that such a price usually
includes at the very minimum a proper Internet connection (that is,
PPP over modem line.)
>(2) I don't have a computer capable of running PPP/DSL so your service
>would be of no use to me beyond what I already have.
If you have a serial line, you can run PPP, that's all the hardware
you need (ok, and a modem, which you've got, obviously). DSL is a
completely different thing.
>(3) My service provides not just Unix shell but VT100 dialup into that
>Unix shell as well as TELNET access into it if I'm ever on some other
>computer and want to check my shell account, and also my shell account
>lets me set up CGI and PHP. Does your service provide all of those plus
>also the PPP/DSL?
I have my own server hosted on the 'net (shared with 3 friends to
keep the cost down.) Costs EUR 100.- per month (now at ca. EUR 80.-
when I last looked at their prices), so around 25.- for each of us,
for a decent machine, with 1000GB traffic per month included, and
there're cheaper offers even at less "professional" hosting providers
that might be completely sufficient. I guess similar offers are
available in the U.S. I'm not saying that you should get one of
those. An ordinary PPP dialup would be a great improvement already
in your case and normally a shell account is in the package for
free (if your ISP has any shell servers at all.)
mkb.
·······@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
> > From: Matthias Buelow <····@incubus.de>
> > $19 for shell access?! I pay little more for a DSL flatrate...
>
> (1) I can't afford "little more" than I already pay, so even if your
> service is everything I already have plus more, I can't afford it.
>
> (2) I don't have a computer capable of running PPP/DSL so your service
> would be of no use to me beyond what I already have.
>
> (3) My service provides not just Unix shell but VT100 dialup into that
> Unix shell as well as TELNET access into it if I'm ever on some other
> computer and want to check my shell account, and also my shell account
> lets me set up CGI and PHP. Does your service provide all of those plus
> also the PPP/DSL?
>
> (4) Are you in Germany? Even if could afford your service and even if I
> had a new computer that could do PPP/DSL and even if your service
> included everything I already have plus more, I can't afford
> international long distance calls into your dialups in Germany.
>
> Please answer item 3 above.
Robert, yet again, after another suggestion, you immediately come back
with reasons why the suggestion is no good. Just stop with the excuses
and just have a look around - $19 per month for Internet access which
does not at the very least provide PPP access is absolutely rediculous
- you continually talk about how little you have in the way of funds,
yet when people point out that what your paying is crazy, you just
have more excuses. At the very least, go out and check the market as I
am pretty certain you will be quite surprised.
Also, what do you mean you don't have a computer capable of PPP - what
the hell is it you do have? PPP has been around for a long time and
people can run it effectively on a 386. Nearly all linux distros have
supported PPP for over 10 years. Windows has supported it since at
least Win97, possibly win95 (though I seem to remember you had to
install winsock etc). Not sure when the Mac came with support for it,
but its certainly been there for a while.
Also note that nearly all ISPs will provide you with web space and
support for PHP and usually perl at no extra cost. Many also provide
mysql database access (though often they will charge for
that). Getting a Unix shell account can be a bit harder to
find. However, if you have PPP access, you can probably even find
"free" unix shell accounts out there.
Also, check out the University you graduated from. Many Universities
now provide services to alumni, such as free mail accounts, web space
and possibly even shell accounts.
Its really time you got out there and re-visited the market. $19 per
month is no longer a good price for the service you are getting.
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: Lisp/Unix impedance [a programming challenge]
Date:
Message-ID: <REM-2005aug20-004@Yahoo.Com>
> From: Tim X <····@spamto.devnul.com>
> $19 per month for Internet access which does not at the very least
> provide PPP access is absolutely rediculous
If you know of any ISP in my local area which provides all the services
I get from my current ISP:
- Local dialups that support VT100 into Unix shell at 19200 BPS, with
no limit on number of hours per day I can be dialed in.
- TELNET access into same shell.
- 200 MB of disk space.
- public_html, cgi-bin, PHP, etc.
but which costs less per month, please tell me about it.
Otherwise what's your point??
> what do you mean you don't have a computer capable of PPP
Please read:
http://www.rawbw.com/~rem/NewPub/mySituation.html
then if you have a question not covered there, feel free to ask.
> Getting a Unix shell account can be a bit harder to find.
Indeed, already in 2000 when I found this one, they were getting hard
to find, and I don't know if there is even one other in this area any
more. A shell account is absolutely essential for installing CGI
applications that will be avaiable all the time instead of only when my
personal computer happens to be on the phone.
·······@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
> > From: Tim X <····@spamto.devnul.com>
> > $19 per month for Internet access which does not at the very least
> > provide PPP access is absolutely rediculous
> If you know of any ISP in my local area which provides all the services
> I get from my current ISP:
> - Local dialups that support VT100 into Unix shell at 19200 BPS, with
> no limit on number of hours per day I can be dialed in.
> - TELNET access into same shell.
> - 200 MB of disk space.
> - public_html, cgi-bin, PHP, etc.
> but which costs less per month, please tell me about it.
> Otherwise what's your point??
I can't state any clearer - YOU CAN GET BETTER VALUE THAN THAT.
Also, any ISP who supports PPP can also support dumb serial
connection. In fact, when PPP was first becomming available and many
OSs didn't have "chat" type functionality, to establish the PPP
connection, you would connect to the terminal server and type
PPP. These days, most modem banks/routers are configured to
automatically negotiate PPP, but if that fails, it drops back to an
old style serial connection.
Prior to moving onto DSL, I had a dial-up modem which cost me $9.95
per month, had no time limit, no data download limits, multiple e-mail
accounts, web space (with CGI). The only downside was that at that
price, the ISP did not provide a very broad connection to the
Internet, so at peak periods it could be a bit slow - but still faster
than anything your modem would handle anyway.
> > what do you mean you don't have a computer capable of PPP
> Please read:
> http://www.rawbw.com/~rem/NewPub/mySituation.html
> then if you have a question not covered there, feel free to ask.
There is no reason technically you cannot run PPP on your MAC. It may
be slow and graphics programs run remotely would be unusable (such as
running firefox on your shell account via X) but it would
work fine. You could also pick up a better modem for next to
nothing. If you suspend your Internet access for a couple of months
you will have enough to buy a modem with reasonable speed.
I'm actually a bit amazed you have a modem that is soooo old it only
runs at 19k - they haven't even made modems that slow for nearly 20
years. I purchased a 24k modem in 1986 or 1987! Or is it the terminal
emulator that restricts it to that speed - if it is, then get a
version of Kermit (it exists for the Mac and for the version/model you
are running).
I'm afraid your "situation" is very much of your own making. I'm not
questioning the fact you have had it tough and finances have been
difficult, but you seem to be taking the role of a victim and not
looking for ways to help yourself.
> > Getting a Unix shell account can be a bit harder to find.
>
> Indeed, already in 2000 when I found this one, they were getting hard
> to find, and I don't know if there is even one other in this area any
> more. A shell account is absolutely essential for installing CGI
> applications that will be avaiable all the time instead of only when my
> personal computer happens to be on the phone.
I realise now nearly all your beliefs seem to be based on assumptions
and not on facts or actual information you have found from research. A
shell account is most definitely NOT absolutely necessary to install
CGI scripts - absolute and utter rubbish.
All of the ISPs I've used allow you to have web space and allow you to
run CGI scripts. Some may have restrictions on the languages available
and some may require that you allow them to look at the script to vet
it for security purposes (but that seems less common now with the
growth in techniques to restrict the environment or user the script
runs as). However, the majority of them no longer allow shell
logins. They all provide mechanisms for installing pages and cgi
scripts.
By the way, your claim you cannot download any data is also bogus. I
suggest you look into a little program called Kermit. People were
downloading data over serial lines using modems like yours long before
PPP and dial-up TCP/IP based connections. You could easily ftp data
from remote hosts into your shell account and then download it to your
MAC - it will be slow, but as you are not charged per hour, whats the
issue.
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
> more. A shell account is absolutely essential for installing CGI
> applications
Wrong again.
You can use a ftp client to transfer your CGI scripts to your cgi directory
on your ISP's server.
>>>>> "TX" == Tim X <Tim> writes:
[...]
TX> I'm actually a bit amazed you have a modem that is soooo old
TX> it only runs at 19k - they haven't even made modems that slow
TX> for nearly 20 years. I purchased a 24k modem in 1986 or 1987! [...]
For dial-up? I doubt it. Around that time, (for consumers) the best
available was 2400+MNP5 (9600bps with compression). Telebit had some
proprietary (called PEP or something I believe) scheme that went up to
14.4k bps or perhaps 19.2 (raw), but I don't know if it was available
in 87. Microcom (?) had stuff too but AFAIR theirs was not that fast.
Or could it be that I am getting senile?
cheers,
BM
Bulent Murtezaoglu <··@acm.org> writes:
> >>>>> "TX" == Tim X <Tim> writes:
> [...]
> TX> I'm actually a bit amazed you have a modem that is soooo old
> TX> it only runs at 19k - they haven't even made modems that slow
> TX> for nearly 20 years. I purchased a 24k modem in 1986 or 1987! [...]
>
> For dial-up? I doubt it. Around that time, (for consumers) the best
> available was 2400+MNP5 (9600bps with compression). Telebit had some
> proprietary (called PEP or something I believe) scheme that went up to
> 14.4k bps or perhaps 19.2 (raw), but I don't know if it was available
> in 87. Microcom (?) had stuff too but AFAIR theirs was not that fast.
> Or could it be that I am getting senile?
>
Your right - it was a 14k and it was around 88. However, that makes me
realise I was using a 2400 modem prior to that and over a serial line
and was able to download software via kermit and sometimes
sz/rz. Still, I'm amazed robert is still using such an old modem when
yu can get something soooo much faster for next to nothing these
days.
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
Tim X <····@spamto.devnul.com> writes:
> Still, I'm amazed robert is still using such an old modem when
> yu can get something soooo much faster for next to nothing these
Or even for nothing at all.
I gave away all my old modems including three or four 56k modems.
Tim X wrote:
> Prior to moving onto DSL, I had a dial-up modem which cost me $9.95
> per month, had no time limit, no data download limits, multiple e-mail
> accounts, web space (with CGI). The only downside was that at that
> price, the ISP did not provide a very broad connection to the
> Internet, so at peak periods it could be a bit slow - but still faster
> than anything your modem would handle anyway.
Hm, maybe Australia (is that where you live? your email looks like it)
is different, but in Germany a modem flatrate used to cost about �35, so
I never got one...
$10 seems VERY cheap to me. Even today that would be much cheaper than
the DSL plug alone (without any connection fees!). For people like me
that don't need to download much, but want to be online most of the time
that would be an interesting deal, but I've never heard of anything near
that.
> I'm actually a bit amazed you have a modem that is soooo old it only
> runs at 19k - they haven't even made modems that slow for nearly 20
> years. I purchased a 24k modem in 1986 or 1987! Or is it the terminal
> emulator that restricts it to that speed - if it is, then get a
> version of Kermit (it exists for the Mac and for the version/model you
> are running).
Hm, in 1999 I got a nice Acermodem at 56k for �50, very trusty and
robust. Stuff like that should be on ebay for maybe $10...
--
I believe in Karma. That means I can do bad things to people
all day long and I assume they deserve it.
Dogbert
Ulrich Hobelmann <···········@web.de> writes:
> Tim X wrote:
> > Prior to moving onto DSL, I had a dial-up modem which cost me $9.95
> > per month, had no time limit, no data download limits, multiple e-mail
> > accounts, web space (with CGI). The only downside was that at that
> > price, the ISP did not provide a very broad connection to the
> > Internet, so at peak periods it could be a bit slow - but still faster
> > than anything your modem would handle anyway.
>
> Hm, maybe Australia (is that where you live? your email looks like
> it) is different, but in Germany a modem flatrate used to cost about
> 35, so I never got one...
Yep, I'm in Australia. Dial-up was quite expensive here in the mid
90's. I was involved in an ISP startup at that time. Originally, they
only allowed per hour charges which started around $2 or $1.50 (Can't
remember for sure). However, as our government introduced private
telco providers, there has been a large decrease in price. You can get
512k ADSL now for less than $30 (though there are some limitations on
dta downloads and you do get what you pay for in that the really cheap
ones tend to have low Internet bandwidth etc). Very few ISPs here now
charge on an hourly rate for dial-up. We have a few telco providers
who now offer very low package deals (i.e. you have to have your
phone, moble and adsl with them). The University I work at offers
modem connections for $4 per month plus an hourly charge of a couple
of cents (the hourly charge is there to manage demand as they don't
have a very large modem bank).
> $10 seems VERY cheap to me. Even today that would be much cheaper
> than the DSL plug alone (without any connection fees!). For people
> like me that don't need to download much, but want to be online most
> of the time that would be an interesting deal, but I've never heard of
> anything near that.
I'd be surprised if there hasn't been a major drop in dial-up charges
in europe since DSL has become more prevalent. There has certainly
been a substantial drop in hardware costs for things like Cisco modem
cards, making it cheaper to have modem banks and it difficult for
dial-up to compete with an 'always on' adsl connection which does not
tie up phone lines and doesn't involve at least a local call charge
each time you connect.
> > I'm actually a bit amazed you have a modem that is soooo old it only
> > runs at 19k - they haven't even made modems that slow for nearly 20
> > years. I purchased a 24k modem in 1986 or 1987! Or is it the terminal
> > emulator that restricts it to that speed - if it is, then get a
> > version of Kermit (it exists for the Mac and for the version/model you
> > are running).
>
> Hm, in 1999 I got a nice Acermodem at 56k for 50, very trusty and
> robust. Stuff like that should be on ebay for maybe $10...
>
Exactly - I have sitting on the shelf a 2400, 14k 33k and 52k modems -
none of them are even worth enough to bother trying to sell. I keep
the fastest one just in case my adsl doesn't work and for a couple of
customers who have direct modem connections and no direct Internet
link.
Anyone who still uses a 19200 modem is doing so because they want to -
if they don't, they can find an alternative very easily.
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Value/modem/PPP/download (was: Lisp/Unix impedance [a programming...])
Date:
Message-ID: <REM-2005aug22-010@Yahoo.Com>
> From: Tim X <····@spamto.devnul.com>
> I can't state any clearer - YOU CAN GET BETTER VALUE THAN THAT.
Actually I would like you to state it clearer: Do you mean everything I
currently have at lower cost, or do you mean something extra I don't
currently have and which I could immediately use, at no increased cost?
You can't do that??? You are not capable of resolving that ambiguity???
FYI, here's what I have currently:
http://www.rawbw.com/~rem/NewPub/mySituation.html#isp
About the only additional things I'd like and be able to use are listed
in the next section after that.
> There is no reason technically you cannot run PPP on your MAC.
But is there any reason with only 8 metabytes I can't anything
resembling decent performance at all when running PPP with MS IE &
MailAndNews, and why IE freezes my whole machine when I try to run it
now?
> You could also pick up a better modem for next to nothing.
Better than the 56K modem on my Mac, which is already faster than my
VT100 emulator can run, which is every bit as fast as I ever need to
eyeball textual data flying by? Or better than the modem in my laptop
that doesn't work at all currently? Like the TV ads that say our brand
is 40% better, you have to say what you're comparing to or your remark
is meaningless.
> I'm actually a bit amazed you have a modem that is soooo old it only
> runs at 19k
I'm amazed you aren't capable of reading:
VT100 emulator (USASCII *only*, max speed 19200 BPS)
modem (SupraExpress56 data/FAX)
and correctly understanding what I think is quite clear there.
What do you think the "56" in the name of the modem means, the pre-y2k
notation for the year it was built??
> A shell account is most definitely NOT absolutely necessary to install
> CGI scripts - absolute and utter rubbish.
Without PPP runnable in any decent way on my computer, a shell account
is necessary for *any* decent net access whatsoever, CGI or anything
else you care to name and quibble over. Also it's awfully difficult to
debug software in an interactive mode on a server without a shell
account there. For example, do you know of *any* free Web site whereby
I could go into a read-eval-print loop via CGI, and enter one
expression at a time, and in case of an error go into an interactive
break loop, and have all the usual commands for executing commands from
inside the break or exiting the break up to various restarts, and
maintain my context over a multi-hour session, and eventually form my
lines of code into function definitions and install them in the same
session and continuing as if my new function definitions were part of
the API? And then switch from inteactive mode to running my full
application in CGI mode any time I want without having to move any
files to another machine or even to another directory on the same
machine?
> By the way, your claim you cannot download any data is also bogus.
I haven't made that claim, except in regard to my laptop where the
modem doesn't work at all currently. With my Mac, I can upload and
download just fine, although the FreeBSD version of Kermit has a bug
whereby it expects all files to be in DOS format before download and it
uploads all files into DOS format, so I have to convert Unix files to
DOS format before download and convert files back to Unix format after
upload. (For small files I use copy&paste over VT100 emulator, which
doesn't have that problem. I go through that Kermit hassle only for
large files.)
But note that Kermit handles only text files. Even a single character
that is not 7-bit USASCII causes Kermit to crash at that point in the
file.
> You could easily ftp data from remote hosts into your shell account
> and then download it to your MAC ...
I already do that for applications that are available in BinHex format,
which is a text conversion format (similar to UUENCODE but handles
Macintosh resource/data forks and special desktop data), whereby I can
download the BinHes file to my Mac and then unBinHex it there. But for
Mac applications that aren't available in BinHex format, I don't know
how to even find out on Unix what kind of Mac file they are (pure
resource fork, pure data fork, or MacBinary format) before somehow
converting them to BinHex format for download.
·······@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
> But is there any reason with only 8 metabytes I can't anything
There is no reason to be running with only 8MB (unless you're
masochist) when 128MB SDIMMs can be found in the garbage. I doubt in
the middle of Silicon Valley they're so efficient at recycling that
you could not find working computer stuff 20 times more powerful than
what you have just keeping your eyes open while walking in the right
streets.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Cats meow out of angst
"Thumbs! If only we had thumbs!
We could break so much!"
On Robert Maas, see http://tinyurl.com/uh3t <·······@Yahoo.Com> wrote:
> > From: Matthias Buelow <····@incubus.de>
> > $19 for shell access?! I pay little more for a DSL flatrate...
>
> (1) I can't afford "little more" than I already pay, so even if your
> service is everything I already have plus more, I can't afford it.
Err, get a job then.
> (2) I don't have a computer capable of running PPP/DSL so your service
> would be of no use to me beyond what I already have.
Uh, what machine made in the last 15 years isn't capable of supporting a
PPP connection?
> (3) My service provides not just Unix shell but VT100 dialup into that
> Unix shell as well as TELNET access into it if I'm ever on some other
> computer and want to check my shell account, and also my shell account
> lets me set up CGI and PHP. Does your service provide all of those plus
> also the PPP/DSL?
Before I went DSL my dialup provider gave me that for $9.95 a month.
Maybe if you spent as much time working as you do complaining here about
how poor you are then you wouldn't be poor anymore.
Just a thought.
·······@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
>
>> $19 for shell access?! I pay little more for a DSL flatrate...
>
> (1) I can't afford "little more" than I already pay, so even if your
> service is everything I already have plus more, I can't afford it.
I think that his point was that better services should be available for
$20.
> (2) I don't have a computer capable of running PPP/DSL so your service
> would be of no use to me beyond what I already have.
Nonsense--PPP is over a decade old. If your box is running *BSD or any
Linux, you can use PPP. If it has an Ethernet card, you can use DSL.
> (3) My service provides not just Unix shell but VT100 dialup into that
> Unix shell as well as TELNET access into it if I'm ever on some other
> computer and want to check my shell account, and also my shell account
> lets me set up CGI and PHP. Does your service provide all of those
> plus also the PPP/DSL?
freeshell.org provides dialup for $10/mo., $27/quarter, $48/half or
$84/yr. That includes telnet & SSH (much more secure than telnet), a
full shell, access to multiple languages and so forth.
Incidentally, if your provider gives you telnet access, why don't you
telnet in from the library and develop your pages interactively? Fire
up telnet and IE, then edit-reload-debug to your heart's content.
--
Robert Uhl <http://public.xdi.org/=ruhl>
I love ASR, you have total freedom of speech as long as it's punctuated
correctly. --`Chris Hacking'
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: TELNET (was: Lisp/Unix impedance [a programming challenge])
Date:
Message-ID: <REM-2005aug20-005@Yahoo.Com>
> From: Robert Uhl <·········@NOSPAMgmail.com>
> if your provider gives you telnet access, why don't you telnet in
> from the library and develop your pages interactively?
Because the public library doesn't provide telnet.
On 08-20, Robert Maas, see http://tinyurl.com/uh3t <·······@Yahoo.Com> wrote:
> > From: Robert Uhl <·········@NOSPAMgmail.com>
> > if your provider gives you telnet access, why don't you telnet in
> > from the library and develop your pages interactively?
>
> Because the public library doesn't provide telnet.
Do they provide floppy drives or a CD-ROM? If so you can always bring your
own telnet binary.
John wrote:
> Do they provide floppy drives or a CD-ROM? If so you can always bring your
> own telnet binary.
another idea is to use one of the 664000 results on Google "telnet applet".
The server side can be installed on his CGI account, but I'm sure Robert
has another excuse why this doesn't work and everyone and everything is
against him.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
> From: Frank Buss <····@frank-buss.de>
> another idea is to use one of the 664000 results on Google "telnet
> applet".
I'm pretty sure the public library doesn't have Java in any form on
their computers, so an applet wouldn't be able to run, but I haven't
ever actually tried it, so maybe if I have any leftover time I'll try
it. But with only one or two minutes maximum leftover time, I won't
have time to search Google while I'm there, so I'll have to search from
home and then set up a special set of links to the best possibilities
to try.
> The server side can be installed on his CGI account
What do you mean by "server side"? Do you mean the ordinary HTML
WebPage that contains the APPLET tag, or the Java class which is the
applet itself? By the way, I already have such a file here:
http://www.rawbw.com/~rem/Java/Lab7.html
which should suffice for a quick test whether the library supports Java
applets at all. So I won't actually need to find the telnet applet for
this initial test.
·······@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
> > The server side can be installed on his CGI account
>
> What do you mean by "server side"?
The telnet daemon.
--
Seek simplicity and mistrust it.
Alfred Whitehead
A witty saying proves nothing.
Voltaire
> From: <······@bigpond.net.au>
> > > The server side can be installed on his CGI account
> > What do you mean by "server side"?
> The telnet daemon.
CGI operates on the HTTP port. TELNET uses a different port.
The TELNET daemon listens on the TELNET port, not the HTTP port.
Accordingly what you posted seems to make no sense.
·······@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
> > From: <······@bigpond.net.au>
> > > > The server side can be installed on his CGI account
> > > What do you mean by "server side"?
> > The telnet daemon.
>
> CGI operates on the HTTP port. TELNET uses a different port.
> The TELNET daemon listens on the TELNET port, not the HTTP port.
> Accordingly what you posted seems to make no sense.
The telnet daemon would be installed on the account that you use
to run your CGI programs.
Try improving your reading skills.
> From: <······@bigpond.net.au>
> > > > > The server side can be installed on his CGI account
> > > > What do you mean by "server side"?
> > > The telnet daemon.
> > CGI operates on the HTTP port. TELNET uses a different port.
> > The TELNET daemon listens on the TELNET port, not the HTTP port.
> > Accordingly what you posted seems to make no sense.
> The telnet daemon would be installed on the account that you use
> to run your CGI programs.
You're talking complete nonsense now. The telnet daemon is installed by
the sysadmin. It listens on TCP/IP port number 23. *all* telnet
connections to this shell machine come in over the very same port.
After a connection is established on that port, the login program
prompts for account name and password, and then if login is successful
a shell is spawned for the appropriate account. It is not possible for
anyone else on the system to install their own TELNET daemon because
port 23 is already occupied by the system TELNET daemon, and any other
process trying to listen on the same port wouldn't work at all.
LIkewise the HTTP daemon is installed by the sysadmin, and it listens
on TCP/IP port number 80. After a connection is established, the URL
determines whether html/txt or other static Web pages will be delivered
over the TCP/IP stream, or whether some dynamic service such as CGI or
JSP will be invoked instead. In the case of CGI, the URL also specifies
whose private CGI directory contains the CGI application, and what
filename within that directory will be invoked. That program is then
run under the same uid which owns that cgi-bin directory.
It is impossible for a CGI application to set up a daemon to listen on
either the TELNET port 23 or the HTTP port 80. It is impossible for
*any* private-account program to set up either kind of listener.
On the other hand, a TELNET client program can be run from any ordinary
user account, either from a normal shell, or from a CGI application. In
the case of a TELNET client running under a normal shell, it can be
interactive, whereby the user types something into TELNET and sees a
response then uses that to decide what to type into TELNET next etc.
But from a CGI application, there's only a single encoded form-contents
passed in and a single WebPage passed back out and then the HTTP
connection is closed and the CGI application dies. So from a CGI
application, only canned (pre-algorithmized) scripts can be run.
Are you confusing a TELNET client with a TELNET daemon/server??
Technically, I don't run my CGI programs, the CGI part of the HTTP
daemon/server runs my CGI programs, on behalf of whoever is running
the HTTP client which passed the http://host/~user/cgi-bin/name.cgi
URL to my ISP's HTTP server.
·······@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
> You're talking complete nonsense now. The telnet daemon is installed by
> the sysadmin. It listens on TCP/IP port number 23.
> It is not possible for
> anyone else on the system to install their own TELNET daemon because
> port 23 is already occupied by the system TELNET daemon, and any other
> process trying to listen on the same port wouldn't work at all.
LOL !!!
You would simply configure your telnetd to use another port.
For example here is how you do it for one implementation
http://telnetd.sourceforge.net/deployment/daemon.html
However, I guess that this is far beyond your abilities.
After all, you still havent figured out how to install a browser on your
computer.
·······@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
>> From: <······@bigpond.net.au>
>> > > The server side can be installed on his CGI account
>> > What do you mean by "server side"?
>> The telnet daemon.
>
> CGI operates on the HTTP port. TELNET uses a different port.
> The TELNET daemon listens on the TELNET port, not the HTTP port.
> Accordingly what you posted seems to make no sense.
You don't seem to know much about the web...
CGI = Common Gateway Interface doesn't work on the HTTP port at all!
It works on stdin/stdout and environment variables.
http://hoohoo.ncsa.uiuc.edu/cgi/primer.html
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: TELNET (was: Lisp/Unix impedance [a programming challenge])
Date:
Message-ID: <REM-2005aug21-002@Yahoo.Com>
> From: John <········@mailinator.com>
> Do they provide floppy drives or a CD-ROM?
Yes, but only for uploading or downloading data files through MS-IE.
It's strictly against library usage rules to run anything from our own
diskette etc., and there's no start menu or right-click or any other
way by which it'd even be possible to run anything other than MS-IE
which is the program running at system start-up.
> If so you can always bring your own telnet binary.
What would be the point of uploading a binary from my diskette to some
Web site that accepts uploads?
Note that MS-IE is configured to allow all JavaScript and viruses/worms
that any Web site might want to impose. Most of the time I am at the
library using their InterNet machines I suffer incessant pop-ups that
flash all over the screen and there's no way to get rid of them except
alt-tab to switch the toplevel window from the pop-up to something
else. There's no way to actually get rid of the pop-ups entirely. If
you know of any WebSite that will use JavaScript to illegaly install
TELNET on the computer and start it running, then I'd be able to do
what you want, but still I'd be violating library rules to even try
that.
Robert Maas, see http://tinyurl.com/uh3t wrote:
> If
> you know of any WebSite that will use JavaScript to illegaly install
> TELNET on the computer and start it running, then I'd be able to do
> what you want, but still I'd be violating library rules to even try
> that.
I don't know about "illegally" and "install", but try this one
http://www.mosha.net/01-telnet-gateway/javascript.shtml
If it works, I only ask for 35% of whatever you make from your program
:-)
BTW, I doubt that a public library disables things like Java and
Macromedia Flash. Too many lusers would complain.
·······@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
> If you know of any WebSite that will use JavaScript to illegaly install
> TELNET on the computer and start it running, then I'd be able to do
> what you want
That will be the effect of running a telnet java applet.
--
Seek simplicity and mistrust it.
Alfred Whitehead
A witty saying proves nothing.
Voltaire
From: Christopher C. Stacy
Subject: Re: TELNET (was: Lisp/Unix impedance [a programming challenge])
Date:
Message-ID: <ull2wvuxt.fsf@news.dtpq.com>
John <········@mailinator.com> writes:
> On 08-20, Robert Maas, see http://tinyurl.com/uh3t <·······@Yahoo.Com> wrote:
> > > From: Robert Uhl <·········@NOSPAMgmail.com>
> > > if your provider gives you telnet access, why don't you telnet in
> > > from the library and develop your pages interactively?
> >
> > Because the public library doesn't provide telnet.
>
> Do they provide floppy drives or a CD-ROM? If so you can always bring your
> own telnet binary.
Usually libraries configure Windows so that you cannot launch
any programs except for the ones they have set up; you can't
run programs off a floppy or over the net. (I discovered this
when I wanted to run PuTTY from the library.)
Christopher C. Stacy <······@news.dtpq.com> wrote:
> John <········@mailinator.com> writes:
>
>> On 08-20, Robert Maas, see http://tinyurl.com/uh3t <·······@Yahoo.Com> wrote:
>> > > From: Robert Uhl <·········@NOSPAMgmail.com>
>> > > if your provider gives you telnet access, why don't you telnet in
>> > > from the library and develop your pages interactively?
>> >
>> > Because the public library doesn't provide telnet.
>>
>> Do they provide floppy drives or a CD-ROM? If so you can always bring your
>> own telnet binary.
>
> Usually libraries configure Windows so that you cannot launch
> any programs except for the ones they have set up; you can't
> run programs off a floppy or over the net. (I discovered this
> when I wanted to run PuTTY from the library.)
That however depends on the way the systems have been set up. I once
encountered an internet cafe whose desktops where supposedly locked down
tight: only browsing, nothing else. Of course, the fools were running Windows,
so "locked down tight" was relative. Turned out the locked the "usual"
ways of running stuff, but typing "file:///c:\command.com" into the
Internet Exploder URL bar still provided me with an open DOS prompt. From
which I proceded to run the PuTTY binary on my floppy disk ;-)
Regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Alexander Schreiber <···@usenet.thangorodrim.de> writes:
> so "locked down tight" was relative. Turned out the locked the "usual"
> ways of running stuff, but typing "file:///c:\command.com" into the
> Internet Exploder URL bar still provided me with an open DOS prompt. From
> which I proceded to run the PuTTY binary on my floppy disk ;-)
Another way is to drag and drop a copy of 4dos into a Word document.
In its usual brain-damaged way, Word obligingly, embeds the command
interpreter into the document.
Then you open the document in word and double click on the embedded
interpreter.
--
Seek simplicity and mistrust it.
Alfred Whitehead
A witty saying proves nothing.
Voltaire
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: TELNET (was: Lisp/Unix impedance [a programming challenge])
Date:
Message-ID: <REM-2005sep01-007@Yahoo.Com>
> From: <······@bigpond.net.au>
> Another way is to drag and drop a copy of 4dos into a Word document.
I do not believe that is possible from inside InterNet Explorer.
Specifically, there is no way in IE to create any draggable icon of any
kind. The only thing that can be dragged is the IE window (and any
pop-up advertisement window that appears). If you believe I'm mistaken,
please tell me which IE menus to use in which way to accomplish that,
and I'll try it next time I'm on an InterNet terminal at the public
library.
> Then you open the document in word and double click on the embedded
> interpreter.
The only way to open a Word document from within IE is if you have the
URL for it (by typing it into the address bar, or by clicking on a link
to it), and even then I don't think it uses MS-Word, rather uses
an IE plug-in that displays MS-Word documents without being able to
edit them. But even viewing MS-Word documents might be impossible at
the public library. I'll have to try that. Do you have a WebPage that
consists of a MS-Word document with embedded clickable interpreter, so
that I could try viewing your document and if that works then I could
try double clicking on the image of the embedded interepretor to see
whether it's an executable icon instead of just a paint-rendered image?
Again, if I'm mistaken, tell me how to open a Word document from within
InterNet Explorer by any means other than the URL. Since MS-Word is not
installed on those computers, I don't see how you can open a word
document inside MS-Word itself, no matter what IE menus you use.
But feel free to tell me how to prove myself wrong, and I'll try it.
"Robert Maas, see http://tinyurl.com/uh3t" schrieb:
>
> > From: <······@bigpond.net.au>
> The only way to open a Word document from within IE is if you have the
Maybe you can copy it to the clipboard and reread it from there?
Use WordPerfect Format to save somewhere (works on many plattforms)
MSHTA.exe or the old sgml standarts come to mind ... MDI Interface?
stefan
Alexander Schreiber wrote:
> Turned out the locked the "usual"
> ways of running stuff, but typing "file:///c:\command.com" into the
> Internet Exploder URL bar still provided me with an open DOS prompt.
I assume this was an old Windows 98 system. For Windows XP this works:
file:///c:\windows\system32\cmd.exe
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss <··@frank-buss.de> wrote:
> Alexander Schreiber wrote:
>
>> Turned out the locked the "usual"
>> ways of running stuff, but typing "file:///c:\command.com" into the
>> Internet Exploder URL bar still provided me with an open DOS prompt.
>
> I assume this was an old Windows 98 system.
Yes, otherwise I wouldn't have gotten a DOS prompt ;-)
> For Windows XP this works:
>
> file:///c:\windows\system32\cmd.exe
Although it _is_ possible to properly lockdown XP. The catch:
- you have to know your enemy^W^WWindows pretty damn well,
- it's a lot of work,
- you'll never know if you plugged _all_ the holes
Cow-orkers at a former place of work locking down Windows XP laptops (no
floppy, crypted disks, USB ports locked down, ... ). After a lot of
work, the believed they had everything nailed shut. Another cow-orker
walks up to such a laptop, activates Bluetooth/IrDA[0] on his mobile
phone and the laptop cheerfully chirps "A new device has been detected,
setting up connection ...". Much laughter (by us UNIX guys) and much
groaning (by the Windows guys) ensued ... ;-)
Regards,
Alex.
[0] Not sure which.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: TELNET (was: Lisp/Unix impedance [a programming challenge])
Date:
Message-ID: <REM-2005sep02-012@Yahoo.Com>
> From: Alexander Schreiber <····@usenet.thangorodrim.de>
> typing "file:///c:\command.com" into the Internet Exploder URL bar
> still provided me with an open DOS prompt.
I tried that last time I was at the public library. Result:
A DOS window flashed for a tiny fraction of a second, just long enough
for me to read the word "illegal".
I also tried something with cmd.exe somebody else suggested. Result:
windows cannot find ...
I also tried running my Java applet. Result:
Not operational at all. None of the buttons did anything.
In "Java console" it said vector.add no such method.
(Apparently only java.lang is installed, not java.util)
I also tried the JavaScript/TELNET Web page that somebody suggested. Result:
fw-1 at sunnyvale-bh: access denied
I also tried to save images (gif/jpg) from Web pages, to diskette. Results:
Error: The drive cannot find the sector requested.
Or it just hangs for several minutes, and when I try to abort it kills
I.E. losing everything I was in (Yahoo! Mail login, etc.)
Robert Maas, see http://tinyurl.com/uh3t wrote:
> I also tried running my Java applet. Result:
> Not operational at all. None of the buttons did anything.
> In "Java console" it said vector.add no such method.
> (Apparently only java.lang is installed, not java.util)
java.util is standard, but very old Microsoft JVM supports Java 1.1, only,
so try addElement, because Vector#add was introduced with Java 1.2.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Robert Maas, see http://tinyurl.com/uh3t wrote:
> > From: Robert Uhl <·········@NOSPAMgmail.com>
> > if your provider gives you telnet access, why don't you telnet in
> > from the library and develop your pages interactively?
>
> Because the public library doesn't provide telnet.
The purpose of this telnet thing is to allow you to
browse your site with IE _and_ to tweak the webpage
content and/or cgi programs simultaneously, right?
Then why don't you write up another cgi program that
allows you to edit HTML files and cgi program via
HTML form?
Shiro Kawai wrote:
> The purpose of this telnet thing is to allow you to
> browse your site with IE _and_ to tweak the webpage
> content and/or cgi programs simultaneously, right?
>
> Then why don't you write up another cgi program that
> allows you to edit HTML files and cgi program via
> HTML form?
:D I've been wondering about that. Something like a simple Wiki
shouldn't be too much work.
--
I believe in Karma. That means I can do bad things to people
all day long and I assume they deserve it.
Dogbert
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: TELNET (was: Lisp/Unix impedance [a programming challenge])
Date:
Message-ID: <REM-2005aug22-013@Yahoo.Com>
> From: "Shiro Kawai" <···········@gmail.com>
> The purpose of this telnet thing is to allow you to
> browse your site with IE _and_ to tweak the webpage
> content and/or cgi programs simultaneously, right?
Yes.
> Then why don't you write up another cgi program that
> allows you to edit HTML files and cgi program via
> HTML form?
It's too dangerous.
If I set up a password system whereby only certain people can run my
CGI software that provides free information, the worst that can happen
if there's a flaw in that security system is is that some unauthorized
person gets some free information for a while until I fix the problem.
But if I set up a password system whereby I can edit my CGI software
remotely, and there's a flaw in security, somebody will come in and
re-write my CGI program to take control of my entire account and delete
all my files (except the CGI stuff) and spam five hundred million
e-mail to every one on the net, and I'll lose my account even before I
get back home from the library.
Writing a CGI form to edit one HTML-only file, or one directory of
various HTML-only files, no PHP or CGI, would be reasonable, and might
be useful in some cases, and I might try it sometime. The worst that
could happen if somebody breaks security is that they'd edit my file to
be larger than my entire disk allocation, which would cost me extra
money if I don't notice it within one week. I already have a way to
view secret HTML or TXT files using a CGI script. I already have a way
to edit a short-message file, one for each of server accounts I set up,
via a CGI script, with a limit of 2000 characters per file. It wouldn't
be too hard to merge the two ideas into a single edit-and-view with a
more reasonble file-size limit such as 30k characters. If I ever finish
my urgent tasks that already consume *all* my one-hour-maximum allowed
time per day at library on days I have time and energy to bicycle
there, so that I would have any spare time there, I might set up
something like that to let me use the time editing HTML and viewing it.
MediaWiki already has something like that (but without filesize limit
AFAIK), except it doesn't support regular HTML markup, rather most
markup is entered using a completely different syntax which is then
converted to HTML internally but you can never see that HTML, and you
probably don't have all HTML options available, such as CSS.
Robert Maas, see http://tinyurl.com/uh3t wrote:
> > Then why don't you write up another cgi program that
> > allows you to edit HTML files and cgi program via
> > HTML form?
>
> It's too dangerous.
Robert. You were talking about using *TELNET* from the public
library. That is already dangerous. If you want the same level
of security, use HTTP authentication. Anybody who can monitor
the ethernet traffic can stole the password, but it's the same
as telnet.
If you still feel insecure, you can also set up another password
layer in CGI. And you can set it up with a timer so that it
only allows login while you're at the library. You can set up
another CGI which deletes the file-editor CGI if invoked, so that
when you're done in the library you can invoke it and have a
peace of mind that nobody will do bad things after you leave
there. You can adopt one-time password, and/or prepare
random number table and use challenge-response authentication
(e.g. the CGI program gives a number, and you make some calculation
with your RNT and type it in. You can set the CGI program so
that it never uses the same challenge, preventing the replay
attack.) Another idea is to write a 'wrapper' cgi that takes
the edited program and run in the sandbox environment.
It doesn't prevent, for example, man-in-middle attack, but we're
not talking about online banking. (And it's just as secure as telnet).
Generally I don't use and recommend such a CGI program that edit
another CGI programs. The proposed solution here should be
considered a temporary one to achieve your most immeidate goals.
Once you clear the first goal, you can move forward and discard
this solution.
> If I ever finish
> my urgent tasks that already consume *all* my one-hour-maximum allowed
> time per day at library on days I have time and energy to bicycle
> there, so that I would have any spare time there, I might set up
> something like that to let me use the time editing HTML and viewing it.
I proposed a feasible technical solution to overcome one of your
obstacles. The solution can be implemented in an hour
by somebody with reasonable knowledge on cgi and network
(and you can do it at your home, without using one-hour limit
in the public library).
The proposed solution will also eliminate your spending time to
look for telnet program that can be used in the public library,
to find out the way to run IE or use PPP on your Mac, and to
write a lengthy post explaining why you cannot do it.
Robert Maas, see http://tinyurl.com/uh3t <·······@yahoo.com> wrote:
>> From: Robert Uhl <·········@NOSPAMgmail.com>
>> if your provider gives you telnet access, why don't you telnet in
>> from the library and develop your pages interactively?
>
>Because the public library doesn't provide telnet.
Get mindterm, dump that on the web space, and use it from within
IE (it's a Java ssh applet).
mkb.
·······@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
> > From: "Karl A. Krueger" <········@example.edu>
> > Most X11 programs do not "do stdio", and yet are certainly Unix
> > programs.
>
> My only significant X11 experience is on my RedHat Linux GNOME laptop,
> where X11 (I think it's that anyway, all I really know is that it
> claims to be an X window)
If you're going to comment on things like this, try coming into the
21st century; or if not that, at least the late 1980s.
> By the way, my only access to Unix (not Linux) is via VT100 dialup,
I don't think you even have any idea what Unix is. Try googling for
unix and hitting the first link.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
From: Christopher C. Stacy
Subject: Re: Lisp/Unix impedance [a programming challenge]
Date:
Message-ID: <uu0i7zmx7.fsf@news.dtpq.com>
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> ·······@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
>
> > > From: "Karl A. Krueger" <········@example.edu>
> > > Most X11 programs do not "do stdio", and yet are certainly Unix
> > > programs.
> >
> > My only significant X11 experience is on my RedHat Linux GNOME laptop,
> > where X11 (I think it's that anyway, all I really know is that it
> > claims to be an X window)
>
> If you're going to comment on things like this, try coming into the
> 21st century; or if not that, at least the late 1980s.
>
> > By the way, my only access to Unix (not Linux) is via VT100 dialup,
>
> I don't think you even have any idea what Unix is. Try googling for
> unix and hitting the first link.
I suspect that he has been using Unix since the late 1970s, at least.
From: Kent M Pitman
Subject: Re: Lisp/Unix impedance [a programming challenge]
Date:
Message-ID: <uacjz379a.fsf@nhplace.com>
······@news.dtpq.com (Christopher C. Stacy) writes:
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > ·······@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
[...]
> > > By the way, my only access to Unix (not Linux) is via VT100 dialup,
> >
> > I don't think you even have any idea what Unix is. Try googling for
> > unix and hitting the first link.
>
> I suspect that he has been using Unix since the late 1970s, at least.
I agree with what I sense is Chris's implication here, that is, that
Thomas Burdick's remarks are a bit overboard and unnecessarily
unfriendly here. I don't see that making ad hominem attacks like this
really promotes a friendly dialog. Each of us has his/her own
particular circumstances, needs, preferences, etc. and it isn't necessary
to be snipping at one another just because we have different needs.
When I was starting out, I used to approach the issue of language
standardization as one in which I and my company needed to be shown to
be right and others needed to be shown as wrong, in a kind of
power-oriented way. I'd even see people move from Organization A to
Organization B and have them change positions and I'd say "geez,
they've sold out their principles for a paycheck" as if the only
reason someone might change a position in that position was because
they'd been bought off. But, in fact, I came at some point to
understand that a lot of us would have very different attitudes on the
same issues if we stood in the shoes of others among us. That is, if
we realize that we just aren't all out to solve the same problem and
so our surroundings and needs _legitimately_ affect how we think about
things. In fact, as a Technical Contributor to ANSI CL, I argued
strongly for certain changes to the language, but as Project Editor, I
had to be neutral and not abuse my role as the person at the keyboard
by putting in my own changes just because it was easy. That wasn't me
selling out, it was just me being affected by my situation and role.
So rather than criticizing someone for not using display technology,
perhaps you could spend a few minutes considering whether there is
ever a conceivable situation where you yourself could end up needing a
non-display technology--even if only because you ended up working for
someone else that liked or needed it. And in so doing, ask yourself
"does that mean I've suddenly become stupid/old-fashioned, or is it
perhaps just not a conclusion you want people to be drawing".
Thinking this way can lead to a lot more tolerance and understanding.
Also, the fact that there is a newer way of doing something does not
obviate the usefulness of the old, just as movies do not obviate the
usefulness of books, TV news does not obviate the usefulness of
newspapers, etc. I wouldn't even doubt that in a few generations,
people might lose the ability to read and write (or type) because
video interfaces might work well enough that it seems superfluous to
waste a lot of time typing. But even if text requires effort to
create and is more gray, more boring, etc., it still has advantages
over pictures.
Actually, one of the key reasons I use either Linux or Unix, when I
do, is that it has a competent non-display environment. It would be
nice if using a command shell under Windows didn't feel like working
with blinders on a command line that's been made deliberately hard to
type to. An Emacs over a *nix shell is pretty usable at controlling
the entire machine with a useful (if not elegant) command language.
It's hard to say as much about a DOS shell under Emacs.
(In fact, I don't completely understand why Windows should even have a
DOS shell, except to support legacy programs. It seems to me they should
have long ago designed a "Windows shell" with a more modern feel... but
then, I'm still running Windows 2000--perhaps it's there waiting in XP.)
Point and click interfaces have definite limitations that command
languages with conditionals, iteration expressions, environment
variables and other programmatic variables, regular expressions,
etc. do not have.
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: Lisp/Unix impedance [a programming challenge]
Date:
Message-ID: <REM-2005aug11-006@Yahoo.Com>
> From: ····@conquest.OCF.Berkeley.EDU (Thomas F. Burdick)
> > My only significant X11 experience is on my RedHat Linux GNOME laptop,
> > where X11 (I think it's that anyway, all I really know is that it
> > claims to be an X window)
> If you're going to comment on things like this, try coming into the
> 21st century; or if not that, at least the late 1980s.
If you mean purchase new expensive stuff instead of use the old stuff I
already have, that's not an option for me because I have no money to
buy even food much less expensive new computer stuff. If you really
want me to get new glitzy computer stuff, how about offering me some
paying work? Post brief descriptions of five small projects, each of
which should take no longer than a month to complete, which you'd like
to see done and for which you have adequate funds to pay for my
programming services, and maybe I'll accept a contract for one of them.
Or read the various proposals for programming projects that I've made
in the newsgroups from time to time and offer to provide financial
support for me to develop one of them. For example, I'd like to write a
"pocket calculator" CGI/PHP application that handles not just numbers
but other kinds of Lisp data objects, applying not just arithmetic and
trigonometric functions to these objects but all the common Lisp
utilities appropriate for the particular parameter types.
> I don't think you even have any idea what Unix is. Try googling for
> unix and hitting the first link.
I've been using various commercial Unix shell accounts since about
1992. Even though I haven't played with most of the random obscure
arcane utilities available on Unix (and I only tried awk within the
past year as an answer to a challenge whether awk was a real
programming language or not), still I have an idea what Unix is and
don't need your condescending attitude and advice.
·······@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
> For example, I'd like to write a
> "pocket calculator" CGI/PHP application that handles not just numbers
> but other kinds of Lisp data objects, applying not just arithmetic and
> trigonometric functions to these objects but all the common Lisp
> utilities appropriate for the particular parameter types.
You mean like the REPL available in the admin module of UCW?
Why would anybody pay you to do something that's already done and
available freely and gratis?
--
__Pascal Bourguignon__ http://www.informatimago.com/
You're always typing.
Well, let's see you ignore my
sitting on your hands.
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: Lisp/Unix impedance [a programming challenge]
Date:
Message-ID: <REM-2005aug15-009@Yahoo.Com>
> From: Pascal Bourguignon <····@mouse-potato.com>
> You mean like the REPL available in the admin module of UCW?
> Why would anybody pay you to do something that's already done and
> available freely and gratis?
Are you referring to this?
Linkname: UnCommon Web
URL: http://common-lisp.net/project/ucw/
It seems to be totally different from what I had in mind.
I said my idea would look like a pocket calculator, where you enter
data into registers then you perform operations on them the the results
go into registers, except that you can work with not just numbers but
strings and other common types of data objects. There's no program
source-code syntax involved.
UCW seems to be heavily dependent on HTML and CL syntax, very different.
I doubt anyone just starting to learn computer programming would be
able to learn via UCW without a tutor coaching him/her virtually all
the way, whereas my proposed system would be a self-sufficient online
tutorial of how to process data and how to organize that processing
into "programs", and it wouldn't be tied to any particular programming
language that the user sees.
·······@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
> > From: Pascal Bourguignon <····@mouse-potato.com>
> > You mean like the REPL available in the admin module of UCW?
> > Why would anybody pay you to do something that's already done and
> > available freely and gratis?
>
> Are you referring to this?
> Linkname: UnCommon Web
> URL: http://common-lisp.net/project/ucw/
>
> It seems to be totally different from what I had in mind.
>
> I said my idea would look like a pocket calculator, where you enter
> data into registers then you perform operations on them the the results
> go into registers, except that you can work with not just numbers but
> strings and other common types of data objects. There's no program
> source-code syntax involved.
Like a spreadsheet?
Gregm
Apparently I missed this post a few days ago...
Robert Maas, see http://tinyurl.com/uh3t wrote:
>> From: "Karl A. Krueger" <········@example.edu>
>> Most X11 programs do not "do stdio", and yet are certainly Unix
>> programs.
>
> My only significant X11 experience is on my RedHat Linux GNOME laptop,
> where X11 (I think it's that anyway, all I really know is that it
> claims to be an X window) is used to implement a terminal window
> whereby I'm talking to a Unix shell, whereby all the Unix-style piping
> etc. work just fine in that shell. I have no idea whether the GUI
An X window application emulating a VT100.
> applications such as the games (freecell or mines) or the directory
> browser (has tree structure on left, and listing of one directory on
> right) uses X11 or not. Gnu Emacs comes up in its own window, instead
Well, if it's X window running, then all those windows are X
windows. If you need emacs inside the shell, call "emacs -nw",
but usually X11 mode is much nicer, IMHO.
> Assuming what you sa about *other* Unix X11 programs, not Gnu Emacs,
> but maybe those games I mentionned, maybe Netscape (which complains via
www.mozilla.org That browser is somewhat newer than whatever
Netscape you might have, and it can do SSL and show you how your
website looks to other people. Try Firefox, the more lightweight
version. Yes, it's still fat and slow. Live with it.
> a pop-up modal dialog about being unable to open stdout or somesuch
> every time it starts up), then I'll have to qualify my claim about Unix
> programs somehow. Do you know the correct jargon for Unix programs that
> use stdio as described in any regular introductory Unix book (such as
> McGilton&Morgan which make not the slightest mention of X or X11) as
> opposed to Unix programs that work only with X11 and have no concept of
> stdio?
Most unix apps have two (or three) layers: the library layer for
some special purpose, the command line interface to actually use
that library, and the GUI that sits on top of it, implemented in
some X11 toolkit. Just because Unix originally didn't have X11,
and VMS or whatever had X11, too, doesn't mean that they aren't
Unix apps. Anyway, they're apps that run on your laptop, so why
not use them??
> So a program that runs on Unix, but can't do stdio whatsoever, isn't
> really what I'd consider a regular Unix program in the original sense.
What if it's just a GUI that actually USES a CLI app, by piping
something through it? Isn't that Unix? If you don't the GUI,
don't use it. But if you want it, it's there. For your website,
I strongly suggest you try a GUI browser on it, and on other
websites, to see how your page looks to other people.
> If it can do stdio, but mostly uses X11 GUI then I'd accept it fine.
What would be the use of that? Most GUI apps are started from a
GUI shell, i.e. the Gnome desktop, the menu in window maker, or
whatever environment you're using (probably Gnome on Redhat). If
you want a CLI, you know where you can get it.
> But if you know of an appropriate term for a program that runs on Unix
> and is able to do stdio in the usual way, please tell me that jargon.
A CLI app?
> By the way, my only access to Unix (not Linux) is via VT100 dialup,
> whereby I can't run any program in any mode other than stdio.
> So if any application requires X11, doesn't work with stdio,
> then from my point of view it doesn't exist.
Unix is a Linux, just like the BSDs, like Solaris, like SCO.
There's not THE Unix, anymore. But there is the POSIX API, that's
well implemented by Linux. And hey, Linux even has ssh for secure
connections, and graphical browsers that actually EXIST for most
people. Welcome to the 21st century!
--
XML is a prime example of retarded innovation.
-- Erik Meijer and Peter Drayton, Microsoft Corporation
On Sat, 30 Jul 2005 14:49:00 +0200, Ulrich Hobelmann <···········@web.de> wrote:
> Unix is a Linux
Oh, really?
:)
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Sat, 30 Jul 2005 14:49:00 +0200, Ulrich Hobelmann <···········@web.de> wrote:
>
>> Unix is a Linux
>
> Oh, really?
>
> :)
>
Oops ;)
--
XML is a prime example of retarded innovation.
-- Erik Meijer and Peter Drayton, Microsoft Corporation
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: Lisp/Unix impedance [a programming challenge]
Date:
Message-ID: <REM-2005aug13-005@Yahoo.Com>
> From: Ulrich Hobelmann <···········@web.de>
> Try Firefox, the more lightweight version.
When I was taking classes at De Anza college, they had Mozilla Firefox
there, and I liked it better than IE (Trojan/Worm/Roach Motel). But I
no longer have access to it, and I'm pretty sure it wouldn't work on
FreeBSD Unix via a VT100 dialup, so I don't have it as an option
currently.
> they're apps that run on your laptop, so why not use them??
I didn't say that I don't use them. I just don't see a program that is
GUI-only as in the same class as a program that runs perfectly fine
from STDIO and can be used as a filter in a pipe.
> For your website, I strongly suggest you try a GUI browser on it, and
> on other websites, to see how your page looks to other people.
It doesn't really do much good to go to the public library and see how
my WebSite looks in IE, the only browser available there, and try to
remember what I don't like and needs changing until several hours later
when I'm at home trying to figure out how I might change the HTML so
that next time I'm at the library next it might look different, then at
the library trying to remember what I had changed last week and should
inspect on-screen to see what effect if any it had in IE etc. It's
totally infeasible to develop software with a one-week turnaround time
between changing the source (HTML) and seeing what effect it had (IE).
·······@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
>> From: Ulrich Hobelmann <···········@web.de>
>> Try Firefox, the more lightweight version.
>
> When I was taking classes at De Anza college, they had Mozilla Firefox
> there, and I liked it better than IE (Trojan/Worm/Roach Motel). But I
> no longer have access to it, and I'm pretty sure it wouldn't work on
> FreeBSD Unix via a VT100 dialup, so I don't have it as an option
> currently.
>
>> they're apps that run on your laptop, so why not use them??
>
> I didn't say that I don't use them. I just don't see a program that is
> GUI-only as in the same class as a program that runs perfectly fine
> from STDIO and can be used as a filter in a pipe.
>
>> For your website, I strongly suggest you try a GUI browser on it, and
>> on other websites, to see how your page looks to other people.
>
> It doesn't really do much good to go to the public library and see how
> my WebSite looks in IE, the only browser available there, and try to
> remember what I don't like and needs changing until several hours later
> when I'm at home trying to figure out how I might change the HTML so
> that next time I'm at the library next it might look different, then at
> the library trying to remember what I had changed last week and should
> inspect on-screen to see what effect if any it had in IE etc. It's
> totally infeasible to develop software with a one-week turnaround time
> between changing the source (HTML) and seeing what effect it had (IE).
Enterprises hire people to make money for them (the enterprise leaders
and share holders). The fact that you're unable to make enough money
by yourself to buy a decent computer and ADSL access is a big clue for
them you won't be able to make them enough money.
They will think: If you can find $200 to get a computer able to run
Mozilla+Linux or IE+MS-Windows, plus $20/month to get a good ADSL
connection, how are you be able to make $10,000/month for them?
So solve this little problem first:
Get you a decent computer and internet access.
It should not be too difficult for someone who qualify for Mensa.
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
On 2005-08-13, Pascal Bourguignon <····@mouse-potato.com> wrote:
> They will think: If you can find $200 to get a computer able to run
> Mozilla+Linux or IE+MS-Windows, plus $20/month to get a good ADSL
> connection, how are you be able to make $10,000/month for them?
Just to back up that point, you can finance a Dell with an Intel Celeron D
330 (2.66 GHz, 533 FSB) processor, 512 MB DDR memory, a 160 GB hard drive,
17 inch flat panel, and speakers for $20 a month (assuming your credit
rating isn't in the toilet).
Most phone companies charge $30 a month for DSL but if you live in a big
area then someone like Speakeasy can probably give you something for $20.
So conservatively speaking you can have a good computer and internet
connection for $50 a month. You could work weekends mowing lawns and make
that much.
John <········@mailinator.com> writes:
> On 2005-08-13, Pascal Bourguignon <····@mouse-potato.com> wrote:
> > They will think: If you can find $200 to get a computer able to run
> > Mozilla+Linux or IE+MS-Windows, plus $20/month to get a good ADSL
> > connection, how are you be able to make $10,000/month for them?
>
> Just to back up that point, you can finance a Dell with an Intel Celeron D
> 330 (2.66 GHz, 533 FSB) processor, 512 MB DDR memory, a 160 GB hard drive,
> 17 inch flat panel, and speakers for $20 a month (assuming your credit
> rating isn't in the toilet).
>
> Most phone companies charge $30 a month for DSL but if you live in a big
> area then someone like Speakeasy can probably give you something for $20.
>
> So conservatively speaking you can have a good computer and internet
> connection for $50 a month. You could work weekends mowing lawns and make
> that much.
And its even easier to scrounge at hamfests or swapmeets and put
together a quite reasonable machine for not much more than spare
change.
Gregm
John wrote:
> Just to back up that point, you can finance a Dell with an Intel Celeron D
> 330 (2.66 GHz, 533 FSB) processor, 512 MB DDR memory, a 160 GB hard drive,
> 17 inch flat panel, and speakers for $20 a month (assuming your credit
> rating isn't in the toilet).
Plus energy costs, of which the Celeron might eat plenty.
A used quality PC off ebay is often a better idea, IMHO, than getting a
new cheapest-possible machine. If I needed a PC right now (I have a
Mac), I'd get a Siemens Scenic (excellent, quiet enterprise machines)
running at 1GHz for maybe �150. Energy consumption is about half, as well.
(There are faster Scenics as well, 2.6GHz etc., for maybe twice the
price, but I guess they eat twice as much energy too.)
Ok, I don't think they offer credit buy, but cancelling the shell
account for a year, and working+saving instead might work.
--
I believe in Karma. That means I can do bad things to people
all day long and I assume they deserve it.
Dogbert