I'm not sure whether this is OT, but since I was unable to find any
other newLISP-specific newsgroups or mailing lists, and do not wish to
participate in a moderated Web-based forum, I am sending this message
to this list.
According to Section 7 of the "newLISP v.10.0.2 Manual and Reference"
(see http://www.newlisp.org/newlisp_manual.html#expressions), it
should be possible to enter multiline expressions into the REPL as
follows:
>As shown in the following snippet from an interactive session, multiline expressions can be entered by enclosing them between [cmd] and [/cmd] tags:
>
> > [cmd]
> (define (foo x y)
> (+ x y))
> [/cmd]
> (lambda (x y) (+ x y))
> > (foo 3 4)
> 7
> > _
>
>Each [cmd] and [/cmd] tag is entered on a separate line. This mode is useful for pasting multiline code into the interactive console.
This works fine in the command-line version of newLISP, as follows:
>newLISP v.10.0.1 on Win32 IPv4, execute 'newlisp -h' for more info.
>
>> [cmd]
>(define (foo x y)
> (+ x y))
>[/cmd]
>(lambda (x y) (+ x y))
>> (foo 3 4)
>7
>>
However, when I try to run the same command in the REPL in the
GUI-based IDE, newLISP-GS, the following error occurs:
>newLISP v.10.0.1 on Win32 IPv4, execute 'newlisp -h' for more info.
>
>> [cmd]
>(define (foo x y)
> (+ x y))
>[/cmd]
>nil
>
>ERR: missing parenthesis : "...))\n[cmd]\n(define (foo x y)\n (+ x y\248\232\""
>>
I am running newLISP v.10.0.1 on Windows XP Professional, Service Pack
2.
This problem has been persisting since v.9.4.5. Is this a bug? This
problem does not seem to be documented in the above-mentioned manual.
Have any other users been experiencing this problem?
-- Benjamin L. Russell
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^
On Mar 11, 6:02 am, Benjamin L. Russell <············@Yahoo.com>
wrote:
> I'm not sure whether this is OT, but since I was unable to find any
> other newLISP-specific newsgroups or mailing lists, and do not wish to
> participate in a moderated Web-based forum, I am sending this message
> to this list.
>
> According to Section 7 of the "newLISP v.10.0.2 Manual and Reference"
> (seehttp://www.newlisp.org/newlisp_manual.html#expressions), it
> should be possible to enter multiline expressions into the REPL as
> follows:
>
> >As shown in the following snippet from an interactive session, multiline expressions can be entered by enclosing them between [cmd] and [/cmd] tags:
>
> > > [cmd]
> > (define (foo x y)
> > (+ x y))
> > [/cmd]
> > (lambda (x y) (+ x y))
> > > (foo 3 4)
> > 7
> > > _
>
> >Each [cmd] and [/cmd] tag is entered on a separate line. This mode is useful for pasting multiline code into the interactive console.
>
> This works fine in the command-line version of newLISP, as follows:
>
> >newLISP v.10.0.1 on Win32 IPv4, execute 'newlisp -h' for more info.
>
> >> [cmd]
> >(define (foo x y)
> > (+ x y))
> >[/cmd]
> >(lambda (x y) (+ x y))
> >> (foo 3 4)
> >7
>
> However, when I try to run the same command in the REPL in the
> GUI-based IDE, newLISP-GS, the following error occurs:
>
> >newLISP v.10.0.1 on Win32 IPv4, execute 'newlisp -h' for more info.
>
> >> [cmd]
> >(define (foo x y)
> > (+ x y))
> >[/cmd]
> >nil
>
> >ERR: missing parenthesis : "...))\n[cmd]\n(define (foo x y)\n (+ x y\248\232\""
>
> I am running newLISP v.10.0.1 on Windows XP Professional, Service Pack
> 2.
>
> This problem has been persisting since v.9.4.5. Is this a bug? This
> problem does not seem to be documented in the above-mentioned manual.
> Have any other users been experiencing this problem?
No.
But all your problems would go away if you tried a Common Lisp
environment. Under Windows, probably Lispworks www.lispworks.com or
Allegro www.franz.com. I have not tried any of the open source
environments there. Other people can help.
Cheers
--
Marco
From: Pascal J. Bourguignon
Subject: Re: [newLISP] potential bug in REPL in newLISP-GS in newLISP v.10.0.1
Date:
Message-ID: <7c1vt4dyl4.fsf@pbourguignon.anevia.com>
Benjamin L. Russell <············@Yahoo.com> writes:
> [...]
> According to Section 7 of the "newLISP v.10.0.2 Manual and Reference"
> [...]
>>As shown in the following snippet from an interactive session, multiline expressions can be entered by enclosing them between [cmd] and [/cmd] tags:
>>
>> > [cmd]
>> (define (foo x y)
>> (+ x y))
>> [/cmd]
>> (lambda (x y) (+ x y))
>> > (foo 3 4)
>> 7
>> > _
>>
>>Each [cmd] and [/cmd] tag is entered on a separate line. This mode
>>is useful for pasting multiline code into the interactive console.
There must be a fatal flaw in this system, if you have to tag your
multiline expressions with an horror such as [cmd][/cmd].
The algorithms to read expressions, whatever the number of lines, have
been know and implemented in Lisp for 50 years. Perhaps you should
try a Lisp that includes the teachings of history? Try Common Lisp.
http://clisp.cons.org has a MS-Windows executable, and when entering a
multiline expression in the emacs IDE (eg. via M-x inferior-lisp RET),
there's no discernable difference to when entering it directly in the
console.
--
__Pascal Bourguignon__
From: Cesar Rabak
Subject: Re: [newLISP] potential bug in REPL in newLISP-GS in newLISP v.10.0.1
Date:
Message-ID: <gp8s60$a0g$2@aioe.org>
Pascal J. Bourguignon escreveu:
> Benjamin L. Russell <············@Yahoo.com> writes:
[snipped]
>>> Each [cmd] and [/cmd] tag is entered on a separate line. This mode
>>> is useful for pasting multiline code into the interactive console.
>
> There must be a fatal flaw in this system, if you have to tag your
> multiline expressions with an horror such as [cmd][/cmd].
>
> The algorithms to read expressions, whatever the number of lines, have
> been know and implemented in Lisp for 50 years. Perhaps you should
> try a Lisp that includes the teachings of history? Try Common Lisp.
>
> http://clisp.cons.org has a MS-Windows executable, and when entering a
> multiline expression in the emacs IDE (eg. via M-x inferior-lisp RET),
> there's no discernable difference to when entering it directly in the
> console.
>
IMNSHO Marco and Pascal have shown another reason for not splitting
newLISP NG from here.
From: Kaz Kylheku
Subject: Re: [newLISP] potential bug in REPL in newLISP-GS in newLISP v.10.0.1
Date:
Message-ID: <20090319122439.415@gmail.com>
On 2009-03-11, Cesar Rabak <·······@yahoo.com.br> wrote:
> IMNSHO Marco and Pascal have shown another reason for not splitting
> newLISP NG from here.
You mean that newLISP is a stinking pile of shit, and people who have been
unwittingly tripped into becoming newLISP users deserve to be educated about
the real thing?
You have hit upon the point that if newLISP is topical in comp.lang.lisp (which
it undeniably is), I can post such a view in comp.lang.lisp without being off
topic. But if I post the same thing to a newLISP newsgroup, that is
Jon-Harrop-style trolling; it strongly resembles advocating F# in
comp.lang.lisp, doesn't it!
Yet, I would not be in favor of comp.lang.lisp being moderated to suppress such
postings. Maybe Harrop has a point; perhaps some people who are dabbling in
Lisp in fact have needs that are better met with F# and they just don't
recognize that.
Could it be that one reason that Benjamin Russel wants an unmoderated newsgroup
about newLISP is that such dissenting views would not be suppressed in that
newsgroup? Why is Benjamin eschewing the existing forums to ask about an
apparent bug in newLISP on Windows? Maybe those forums are hostile to bug
reports, considering them to be some kind of attack on newLISP.
In the end, it may be up to real Lisp hackers to repair newLISP. Suppose
someone has developed a big application around newLISP, and somehow you are
left in charge of it. There are bugs in newLISP which are destabilizing that
application. The drooling pool of newLISP-using idiots have no clue how to fix
this. Where do you go for help? Whoever will help you fix that problem
will probably have to be a real programmer. Someone who intimately knows C,
Lisp, software development, as well as the underlying platforms and other
tools. I.e. precisely the sort of person who regards newLISP to be a pile of
shit and is not welcome among the newLISP morons.
On Wed, 11 Mar 2009 19:51:09 +0000 (UTC), Kaz Kylheku
<········@gmail.com> wrote:
>On 2009-03-11, Cesar Rabak <·······@yahoo.com.br> wrote:
>
>[...]
>
>Could it be that one reason that Benjamin Russel wants an unmoderated newsgroup
>about newLISP is that such dissenting views would not be suppressed in that
>newsgroup? Why is Benjamin eschewing the existing forums to ask about an
>apparent bug in newLISP on Windows? Maybe those forums are hostile to bug
>reports, considering them to be some kind of attack on newLISP.
(Incidentally, my last name, "Russell," is spelled with two l's.)
Actually, that's not the reason. The real reason is one of
convenience; I read and write in more than thirty newsgroups and
mailing lists, and it is much easier to add just one more newsgroup or
mailing list in my newsreader than to be forced to open a browser and
log into a Web-based forum each time.
Also, people tend to write differently in moderated and unmoderated
forums. Unmoderated forums are much more likely to contain unexpected
and highly controversial content, which often makes them much more
interesting.
Also, Web-based forums tend to contain a lower percentage of users
whose lives are focused on technical material. USENET readers tend to
be more geeky, and for some people, that can be a lot of fun....
-- Benjamin L. Russell
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^
From: William James
Subject: Re: [newLISP] potential bug in REPL in newLISP-GS in newLISP v.10.0.1
Date:
Message-ID: <gp91j507ub@enews5.newsguy.com>
Benjamin L. Russell wrote:
> > As shown in the following snippet from an interactive session,
> > multiline expressions can be entered by enclosing them between
> > [cmd] and [/cmd] tags:
> >
> > > [cmd]
> > (define (foo x y)
> > (+ x y))
> > [/cmd]
Is Lutz retarded? Can't he count parentheses?
Why do you need [cmd]?
Ruby:
c:\> irb --prompt xmp
def foo a, b
a + b
end
==>nil
foo 3, 5
==>8
On 11 Mar 2009 18:57:41 GMT, "William James" <> wrote:
>Benjamin L. Russell wrote:
>
>> > As shown in the following snippet from an interactive session,
>> > multiline expressions can be entered by enclosing them between
>> > [cmd] and [/cmd] tags:
>> >
>> > > [cmd]
>> > (define (foo x y)
>> > (+ x y))
>> > [/cmd]
>
>Is Lutz retarded? Can't he count parentheses?
Actually, the above-mentioned code snippet contains a correct number
of matching parentheses. Here is the same code as above, stripped of
the "[cmd]" and "[/cmd]" tags:
(define (foo x y)
(+ x y))
For simplicity, let's remove the innermost pair of matching
parentheses and the enclosed code (this leaves us with invalid newLISP
code, but that doesn't matter here, since we are only counting
parentheses):
(define
(+ x y))
I count two opening and two closing parentheses. What is wrong with
the parentheses?
>Why do you need [cmd]?
>
>Ruby:
>
>c:\> irb --prompt xmp
>def foo a, b
> a + b
>end
> ==>nil
>foo 3, 5
> ==>8
Point taken and noted. Indeed, newLISP probably shouldn't require the
"[cmd]" and "[/cmd]" tags.
In fact, I was quite annoyed when Lutz replied to my bug report in the
newLISP Fan Club as follows (see
http://www.alh.net/newlisp/phpbb/viewtopic.php?p=14973#14973):
>In the newLISP-GS Java front-end the bottom monitor is only a minimal terminal implementation in a Java Swing text area. Only designed for simple one-liners and not designed to be as comfortable as a shell window (which on Mac OS X and other Unix also does tab-expansion to built-in functions).
>
>There are keyboard shut-cuts (shown in the menus) to quickly open, clear or close a new editor in a tab, and then run the contents through the bottom monitor. This would be a typical workflow with Window key-strokes:
>
>Shift-Ctrl-N -> open a new tab
>
>... type your multiline code snippet ..
>
>Alt-R -> evaluate the tab content in the monitor
>
>Alt-Shift-R -> for a fresh monitor newLISP process, if required
>
>Ctrl-N -> clear the tab or
>
>Ctrl-W -> close the tab
>
>You can close the tab with Ctrl-W and use Alt-1, Alt-2 to switch between the top tabbed editor area and the bottom monitor.
>
>There is also a key-combination to switch tabs, but I don't recall them at the moment. They are part of the Java Swing tabbed window implementation.
Limiting the embedded REPL of the newLISP IDE to one-liners and
requiring everything else to be entered into a separate tab is
unreasonably inconvenient. I can't understand why he doesn't just try
to fix the bug, rather than expect every user to use a workaround.
One of the reasons that I don't like Web-based forums is because of
responses of this kind. If a user submits a bug report, the response
should be to try to fix the bug, not to expect a tedious workaround
from every user. This is especially the case with very basic bugs
that affect efficiency, such as this one.
-- Benjamin L. Russell
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^
On Mar 12, 6:25 am, Benjamin L. Russell <············@Yahoo.com>
wrote:
> On 11 Mar 2009 18:57:41 GMT, "William James" <> wrote:
>
> >Benjamin L. Russell wrote:
>
> >> > As shown in the following snippet from an interactive session,
> >> > multiline expressions can be entered by enclosing them between
> >> > [cmd] and [/cmd] tags:
>
> >> > > [cmd]
> >> > (define (foo x y)
> >> > (+ x y))
> >> > [/cmd]
>
> >Is Lutz retarded? Can't he count parentheses?
>
> Actually, the above-mentioned code snippet contains a correct number
> of matching parentheses. Here is the same code as above, stripped of
> the "[cmd]" and "[/cmd]" tags:
>
> (define (foo x y)
> (+ x y))
>
> For simplicity, let's remove the innermost pair of matching
> parentheses and the enclosed code (this leaves us with invalid newLISP
> code, but that doesn't matter here, since we are only counting
> parentheses):
>
> (define
> (+ x y))
>
> I count two opening and two closing parentheses. What is wrong with
> the parentheses?
>
> >Why do you need [cmd]?
>
> >Ruby:
>
> >c:\> irb --prompt xmp
> >def foo a, b
> > a + b
> >end
> > ==>nil
> >foo 3, 5
> > ==>8
>
> Point taken and noted. Indeed, newLISP probably shouldn't require the
> "[cmd]" and "[/cmd]" tags.
>
> In fact, I was quite annoyed when Lutz replied to my bug report in the
> newLISP Fan Club as follows (seehttp://www.alh.net/newlisp/phpbb/viewtopic.php?p=14973#14973):
>
>
>
> >In the newLISP-GS Java front-end the bottom monitor is only a minimal terminal implementation in a Java Swing text area. Only designed for simple one-liners and not designed to be as comfortable as a shell window (which on Mac OS X and other Unix also does tab-expansion to built-in functions).
>
> >There are keyboard shut-cuts (shown in the menus) to quickly open, clear or close a new editor in a tab, and then run the contents through the bottom monitor. This would be a typical workflow with Window key-strokes:
>
> >Shift-Ctrl-N -> open a new tab
>
> >... type your multiline code snippet ..
>
> >Alt-R -> evaluate the tab content in the monitor
>
> >Alt-Shift-R -> for a fresh monitor newLISP process, if required
>
> >Ctrl-N -> clear the tab or
>
> >Ctrl-W -> close the tab
>
> >You can close the tab with Ctrl-W and use Alt-1, Alt-2 to switch between the top tabbed editor area and the bottom monitor.
>
> >There is also a key-combination to switch tabs, but I don't recall them at the moment. They are part of the Java Swing tabbed window implementation.
>
> Limiting the embedded REPL of the newLISP IDE to one-liners and
> requiring everything else to be entered into a separate tab is
> unreasonably inconvenient. I can't understand why he doesn't just try
> to fix the bug, rather than expect every user to use a workaround.
That's probably because newLisp espouses a limited form of the design
goal of INTERCAL. Whereas INTERCAL wants to be a programming language
different from all the other ones, newLisp wants to be a Lisp
different from all the other Lisps. :)
Cheers
--
Marco
PS. You should not follow up on posting of people who do not do their
homework. :)
Marco Antoniotti <·······@gmail.com> writes:
> That's probably because newLisp espouses a limited form of the design
> goal of INTERCAL. Whereas INTERCAL wants to be a programming language
> different from all the other ones, newLisp wants to be a Lisp
> different from all the other Lisps. :)
Hmm, that's kind of the vibe I got from clojure too...
[I've never used clojure, but looking at clojure code is kind of like a
game of "count the small-but-gratuitous syntactic differences!"...]
-Miles
--
"An atheist doesn't have to be someone who thinks he has a proof that
there can't be a god. He only has to be someone who believes that the
evidence on the God question is at a similar level to the evidence on
the werewolf question." [John McCarthy]
From: Kaz Kylheku
Subject: Re: [newLISP] potential bug in REPL in newLISP-GS in newLISP v.10.0.1
Date:
Message-ID: <20090319094913.720@gmail.com>
On 2009-03-11, Benjamin L Russell <············@Yahoo.com> wrote:
> I'm not sure whether this is OT, but since I was unable to find any
> other newLISP-specific newsgroups or mailing lists, and do not wish to
> participate in a moderated Web-based forum, I am sending this message
> to this list.
Why don't you want to inquire about newLISP bugs in a newLISP mailing list or
forum? Do you suspect that your message would be moderated down? (That would be
sad). Or is that moderation introduces an unacceptable delay?
Generally, people use their Lisp implementation's mailing lists for bugs.
Of course, implementation bugs get discussed here. Typically this happens when
the bug is involved in a question of language compliance. E.g. ``I've compared
the behavior of such and such a construct on three different implementations of
Lisp, and I think mine may be buggy; is there a right behavior, and what is
it?'' Then if it is confirmed to be a bug, it's time to go to the mailing list
for SBCL, CLISP or whatever.
> According to Section 7 of the "newLISP v.10.0.2 Manual and Reference"
> (see http://www.newlisp.org/newlisp_manual.html#expressions), it
> should be possible to enter multiline expressions into the REPL as
> follows:
>
>>As shown in the following snippet from an interactive session, multiline
>>expressions can be entered by enclosing them between [cmd] and [/cmd] tags:
But documentation does not say ``this can bomb in a bizarre way if entered into
a GUI REPL on Windows''. Even if that was the case, it could still be regarded
as a bug. You cannot just document bugs away.
> However, when I try to run the same command in the REPL in the
> GUI-based IDE, newLISP-GS, the following error occurs:
I.e. the authors don't test the software with a suite which includes
cases which resemble examples from the documentation. It's not reasonable
for the REPL to behave differently, at least not in this way.
>>newLISP v.10.0.1 on Win32 IPv4, execute 'newlisp -h' for more info.
>>
>>> [cmd]
>>(define (foo x y)
>> (+ x y))
>>[/cmd]
>>nil
>>
>>ERR: missing parenthesis : "...))\n[cmd]\n(define (foo x y)\n (+ x y\248\232\""
You clearly entered the characters "x y))\n", yet the error message
insinuates that the software considers that portion of the input to be
"x y\248\232\"" which bears no relation to anything you typed or pasted.
It looks a lot like one of two kinds of situations: perhaps memory which looked
like "x y))\n" was improperly overwritten to look like "x y\248\232\"". Or
perhaps some erroneous calculation resulted in only the data "x y" being
extracted from the GUI, and copied without the null terminating byte that is
required in C strings; the "\242\232\"" is just memory which follows.
On Wed, 11 Mar 2009 19:01:21 +0000 (UTC), Kaz Kylheku
<········@gmail.com> wrote:
>On 2009-03-11, Benjamin L Russell <············@Yahoo.com> wrote:
>> I'm not sure whether this is OT, but since I was unable to find any
>> other newLISP-specific newsgroups or mailing lists, and do not wish to
>> participate in a moderated Web-based forum, I am sending this message
>> to this list.
>
>Why don't you want to inquire about newLISP bugs in a newLISP mailing list or
>forum? Do you suspect that your message would be moderated down? (That would be
>sad). Or is that moderation introduces an unacceptable delay?
>
>Generally, people use their Lisp implementation's mailing lists for bugs.
Actually, I did submit a bug report to the newLISP Fan Club (see
http://www.alh.net/newlisp/phpbb/viewtopic.php?p=14962#14962).
However, Lutz's response there was to claim that the bug wasn't a bug,
and to ask me to use a workaround (see
http://www.alh.net/newlisp/phpbb/viewtopic.php?p=14973#14973); viz.:
>In the newLISP-GS Java front-end the bottom monitor is only a minimal terminal implementation in a Java Swing text area. Only designed for simple one-liners and not designed to be as comfortable as a shell window (which on Mac OS X and other Unix also does tab-expansion to built-in functions).
>
>There are keyboard shut-cuts (shown in the menus) to quickly open, clear or close a new editor in a tab, and then run the contents through the bottom monitor. This would be a typical workflow with Window key-strokes:
>
>Shift-Ctrl-N -> open a new tab
>
>... type your multiline code snippet ..
>
>Alt-R -> evaluate the tab content in the monitor
>
>Alt-Shift-R -> for a fresh monitor newLISP process, if required
>
>Ctrl-N -> clear the tab or
>
>Ctrl-W -> close the tab
>
>You can close the tab with Ctrl-W and use Alt-1, Alt-2 to switch between the top tabbed editor area and the bottom monitor.
>
>There is also a key-combination to switch tabs, but I don't recall them at the moment. They are part of the Java Swing tabbed window implementation.
>
>Of course, implementation bugs get discussed here. Typically this happens when
>the bug is involved in a question of language compliance. E.g. ``I've compared
>the behavior of such and such a construct on three different implementations of
>Lisp, and I think mine may be buggy; is there a right behavior, and what is
>it?'' Then if it is confirmed to be a bug, it's time to go to the mailing list
>for SBCL, CLISP or whatever.
Well, they don't have a mailing list, and apparently their Web-based
forum doesn't quite work, because the person in charge who responded
there claimed that it wasn't really a "bug." If it doesn't work as it
should and requires a workaround, isn't that what is called a "bug?"
Apparently, I need to find more technically-oriented people to address
a bug report. I wonder where I can find them? From what I have seen
so far, at least not on their forum.
>> According to Section 7 of the "newLISP v.10.0.2 Manual and Reference"
>> (see http://www.newlisp.org/newlisp_manual.html#expressions), it
>> should be possible to enter multiline expressions into the REPL as
>> follows:
>>
>>>As shown in the following snippet from an interactive session, multiline
>>>expressions can be entered by enclosing them between [cmd] and [/cmd] tags:
>
>But documentation does not say ``this can bomb in a bizarre way if entered into
>a GUI REPL on Windows''. Even if that was the case, it could still be regarded
>as a bug. You cannot just document bugs away.
Right!
>> However, when I try to run the same command in the REPL in the
>> GUI-based IDE, newLISP-GS, the following error occurs:
>
>I.e. the authors don't test the software with a suite which includes
>cases which resemble examples from the documentation. It's not reasonable
>for the REPL to behave differently, at least not in this way.
Agreed! I wish Lutz saw things in that way....
>>>newLISP v.10.0.1 on Win32 IPv4, execute 'newlisp -h' for more info.
>>>
>>>> [cmd]
>>>(define (foo x y)
>>> (+ x y))
>>>[/cmd]
>>>nil
>>>
>>>ERR: missing parenthesis : "...))\n[cmd]\n(define (foo x y)\n (+ x y\248\232\""
>
>You clearly entered the characters "x y))\n", yet the error message
>insinuates that the software considers that portion of the input to be
>"x y\248\232\"" which bears no relation to anything you typed or pasted.
>It looks a lot like one of two kinds of situations: perhaps memory which looked
>like "x y))\n" was improperly overwritten to look like "x y\248\232\"". Or
>perhaps some erroneous calculation resulted in only the data "x y" being
>extracted from the GUI, and copied without the null terminating byte that is
>required in C strings; the "\242\232\"" is just memory which follows.
That's technically a "bug," if I understand the term correctly. Lutz
on the newLISP Fan Club claims that it isn't a bug.
"Houston, we have a problem."
-- Benjamin L. Russell
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^
From: William James
Subject: Re: [newLISP] potential bug in REPL in newLISP-GS in newLISP v.10.0.1
Date:
Message-ID: <gpaipr01cpr@enews5.newsguy.com>
Benjamin L. Russell wrote:
> However, Lutz's response there was to claim that the bug wasn't a bug,
> and to ask me to use a workaround (see
> http://www.alh.net/newlisp/phpbb/viewtopic.php?p=14973#14973); viz.:
...
>
> Well, they don't have a mailing list, and apparently their Web-based
> forum doesn't quite work, because the person in charge who responded
> there claimed that it wasn't really a "bug." If it doesn't work as it
> should and requires a workaround, isn't that what is called a "bug?"
You're aware that Lutz is the author of NewLisp?
On 12 Mar 2009 08:57:31 GMT, "William James" <·········@yahoo.com>
wrote:
>Benjamin L. Russell wrote:
>
>> However, Lutz's response there was to claim that the bug wasn't a bug,
>> and to ask me to use a workaround (see
>> http://www.alh.net/newlisp/phpbb/viewtopic.php?p=14973#14973); viz.:
>
>...
>
>>
>> Well, they don't have a mailing list, and apparently their Web-based
>> forum doesn't quite work, because the person in charge who responded
>> there claimed that it wasn't really a "bug." If it doesn't work as it
>> should and requires a workaround, isn't that what is called a "bug?"
>
>
>You're aware that Lutz is the author of NewLisp?
Yes. That's the reason that I wrote, "'Houston, we have a problem.'"
-- Benjamin L. Russell
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^
On Mar 12, 5:34 am, Benjamin L. Russell <············@Yahoo.com>
wrote:
> On 12 Mar 2009 08:57:31 GMT, "William James" <·········@yahoo.com>
> wrote:
[...]
> >You're aware that Lutz is the author of NewLisp?
> Yes. That's the reason that I wrote, "'Houston, we have a problem.'"
If it's at all possible (you haven't, e.g., inherited a large legacy
system written in NewLisp), I strongly suggest switching to a quality
implementation of Scheme or Common Lisp. For one thing, if that one is
*also* saddled with bugs that an intransigent developer refuses to
address, you can move to a different implementation while not having
to switch to a whole new language.
There really are some advantages to using standardized languages.
Cheers,
Pillsy
On Thu, 12 Mar 2009 07:24:02 -0700 (PDT), Pillsy <·········@gmail.com>
wrote:
>On Mar 12, 5:34?am, Benjamin L. Russell <············@Yahoo.com>
>wrote:
>> On 12 Mar 2009 08:57:31 GMT, "William James" <·········@yahoo.com>
>> wrote:
>[...]
>> >You're aware that Lutz is the author of NewLisp?
>
>> Yes. ?That's the reason that I wrote, "'Houston, we have a problem.'"
>
>If it's at all possible (you haven't, e.g., inherited a large legacy
>system written in NewLisp), I strongly suggest switching to a quality
>implementation of Scheme or Common Lisp. For one thing, if that one is
>*also* saddled with bugs that an intransigent developer refuses to
>address, you can move to a different implementation while not having
>to switch to a whole new language.
FYI, Lutz finally fixed the bug; viz. (see
http://www.alh.net/newlisp/phpbb/viewtopic.php?p=14982#14982):
>The problem with [cmd][/cmd] tags in the newLISP-GS Java front-end has been fixed. Download a new guiserver.jar from:
>
>http://www.newlisp.org/downloads/development/guiserver.jar
>
>and install on Win32 as: $PROGRAMFILES/newlisp/guiserver.jar
>
>or install on Mac OS X and other Unix as: /usr/share/newlisp/guiserver.jar
I downloaded, installed, and tested the patch, and the bug is now
fixed.
Nevertheless, I wish that he had admitted that the bug was indeed a
bug in the first place, instead of having written earlier (see
http://www.alh.net/newlisp/phpbb/viewtopic.php?p=14973#14973) as
follows:
>Only designed for simple one-liners and not designed to be as comfortable
>as a shell window (which on Mac OS X and other Unix also does tab-expansion
>to built-in functions).
That statement implied that the issue was one by design, implying
possible permanence, rather than one by flaw, implying later
resolution.
Although this bug is now fixed, now I'm worried about how he'll
respond to the next bug report. Suppose that a function in a graphics
library exceeds the border when drawing in a non-maximized window, and
I submit another bug report. There's no guarantee that he might not
reply with something similar to the following:
>Only designed for maximized windows and not designed to be as flexible as a
>drawing application (which on Mac OS X and other Unix also is designed to work
>with the API).
>There really are some advantages to using standardized languages.
You may be right. I'm also looking at Qi, and although that language
doesn't have such a fancy GUI IDE, it seems to have a more solid
foundation and better support.
-- Benjamin L. Russell
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^
From: Kaz Kylheku
Subject: Re: potential bug in REPL in newLISP-GS in newLISP v.10.0.1
Date:
Message-ID: <20090313094914.-85@gmail.com>
On 2009-03-13, Benjamin L Russell <············@Yahoo.com> wrote:
> Although this bug is now fixed, now I'm worried about how he'll
> respond to the next bug report.
A good strategy then might be a gentle reminder that the curious
behavior of initially refusing to admit there is a bug and then
later fixing it may be of interest to a psychologist. :)
On Thu, 12 Mar 2009 07:24:02 -0700 (PDT), Pillsy <·········@gmail.com>
wrote:
>[...]
>
>There really are some advantages to using standardized languages.
I hadn't yet responded to the suggestion about "standardized"
languages. You suggested either Scheme or Common Lisp, but the latest
standard for Scheme, R6RS, violates the spirit of Scheme (in
particular, the reference to the following first sentence of the
introduction to every Scheme Report that I have read so far):
>`Programming languages should be designed not by piling feature on
>top of feature, but by removing the weaknesses and restrictions that
>make additional features appear necessary.'
On the other hand, Common Lisp is a Lisp-2 dialect of Lisp, and I had
a bad experience with Common Lisp in college because of a variety of
factors, which, IIRC, had to do with a combination of the size of the
language, the inability of redefininig variables and functions already
defined, and the separate namespaces for functions and variables.
Perhaps this is just my style of programming, but I strongly prefer
the single namespace of a Lisp-1 dialect.
What is needed is a small language, no larger than R5RS Scheme, that
supports first-class continuations, tail calls, and reflection, which
is preferably a Lisp-1 dialect, which preferably both comes with a
DrScheme-style GUI interface and the ability to work seamlessly in a
REPL in Emacs, and which runs without hanging in the "Open File"
dialog box every few seconds in Windows XP Professional, Service Pack
2, with mapped network drives (DrScheme hangs in that dialog box for
several seconds every dozen seconds or so on Windows XP Pro, SP2, with
mapped network drives). Preferably, it should also work on Mac OS X
10.5.x Leopard, since that is my OS at home (I am forced to use
Windows XP at work). Since I am a hobbiest, and not a professional
software developer, the language need not come with a large library.
However, it needs to have a solid semantics so that I can work with
the kinds of exercises that appear in SICP.
-- Benjamin L. Russell
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^
Benjamin L. Russell <············@Yahoo.com> writes:
> On the other hand, Common Lisp is a Lisp-2 dialect of Lisp, and I had
> a bad experience with Common Lisp in college because of a variety of
> factors, which, IIRC, had to do with a combination of
> the size of the language,
Actually, Common Lisp is only 17 special operators.
All the rest are library functions, and macros.
Compare this with C or C++, where only the operator precedence levels
are more than 17!
> the inability of redefininig variables and functions already defined,
What strange implementation did you use? Are you sure it was Common Lisp?
C/USER[9]> (defparameter *p* 1)
*P*
C/USER[10]> *p*
1
C/USER[11]> (defparameter *p* "hi")
*P*
C/USER[12]> *p*
"hi"
C/USER[13]>
You can even redefine the functions while other threads call them (but
granted, threads are not in CL, it's an extension):
S/CL-USER[30]> (defun f () (print 1))
F
S/CL-USER[31]> (f)
1
1
S/CL-USER[32]> (SB-THREAD:MAKE-THREAD (lambda () (loop :repeat 100 :do (sleep 2) (f))))
#<SB-THREAD:THREAD RUNNING {100407EC91}>
S/CL-USER[33]> (f)
1
1
S/CL-USER[34]>
1
1
1
1
1
1
1
1
(defun f () (princ "deux") (terpri))
STYLE-WARNING: redefining F in DEFUN
1
F
S/CL-USER[35]> deux
deux
deux
deux
deux
deux
deux
(defun f () (princ (function f)) (terpri))
STYLE-WARNING: redefining F in DEFUN
F
S/CL-USER[36]> #<FUNCTION F>
#<FUNCTION F>
#<FUNCTION F>
#<FUNCTION F>
#<FUNCTION F>
> and the separate namespaces for functions and variables.
How is that different to, for example C++, where there are also
several namespaces?
#include <iostream>
struct f {
int f;
};
int f(f* f){
return(f->f);
}
int main(){
struct f g={42};
std::cout<<f(&g)<<std::endl;
return(0);
}
Granted, C, C++ collapse the namespaces for functions and variables,
but keep other things in separate namespaces.
> Perhaps this is just my style of programming, but I strongly prefer
> the single namespace of a Lisp-1 dialect.
Yes, it's a matter of taste.
> What is needed is a small language, no larger than R5RS Scheme, that
> supports first-class continuations, tail calls, and reflection, which
> is preferably a Lisp-1 dialect, which preferably both comes with a
> DrScheme-style GUI interface and the ability to work seamlessly in a
> REPL in Emacs, and which runs without hanging in the "Open File"
> dialog box every few seconds in Windows XP Professional, Service Pack
> 2, with mapped network drives (DrScheme hangs in that dialog box for
> several seconds every dozen seconds or so on Windows XP Pro, SP2, with
> mapped network drives). Preferably, it should also work on Mac OS X
> 10.5.x Leopard, since that is my OS at home (I am forced to use
> Windows XP at work). Since I am a hobbiest, and not a professional
> software developer, the language need not come with a large library.
> However, it needs to have a solid semantics so that I can work with
> the kinds of exercises that appear in SICP.
Well definitely you want a scheme. DrScheme includes mzscheme that
you can use from emacs inferior-lisp. However, I'm not able to use
it since they've includede r6rs. So I'd advise MIT-scheme which stays
sane (but there's no GUI).
--
__Pascal Bourguignon__
···@informatimago.com (Pascal J. Bourguignon) writes:
>
> [...] However, I'm not able to use it since they've includede r6rs.
The language (and DrScheme) did not change for r6rs.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
Eli Barzilay <···@barzilay.org> writes:
> ···@informatimago.com (Pascal J. Bourguignon) writes:
>>
>> [...] However, I'm not able to use it since they've includede r6rs.
>
> The language (and DrScheme) did not change for r6rs.
Well nowdays, when I run mzscheme, the conses are not mutable anymore.
I never had the time (nor the will) to learn the complicated and
changing library loading invokations needed to revert to r5rs
behavior...
Actually this is the reason why I use CL instead of scheme. Everytime
I learned something in scheme, I had to learn it again next time
because things were different (with a different implementation or just
a different report published). Scheme is a moving target that moved
too fast when I was learning lisp. The second time I came back to CL,
everything was still where I left them, and I could make progress.
Then I could come back to it a third and again and again.
--
__Pascal Bourguignon__
On 13 Mar, 16:05, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Eli Barzilay <····@barzilay.org> writes:
> > ····@informatimago.com (Pascal J. Bourguignon) writes:
>
> >> [...] However, I'm not able to use it since they've includede r6rs.
>
> > The language (and DrScheme) did not change for r6rs.
>
> Well nowdays, when I run mzscheme, the conses are not mutable anymore.
That's not r6rs. It's an "extension" of plt scheme.
> I never had the time (nor the will) to learn the complicated and
> changing library loading invokations needed to revert to r5rs
> behavior...
>
> Actually this is the reason why I use CL instead of scheme. Everytime
> I learned something in scheme, I had to learn it again next time
> because things were different (with a different implementation or just
> a different report published). Scheme is a moving target that moved
> too fast when I was learning lisp. The second time I came back to CL,
> everything was still where I left them, and I could make progress.
> Then I could come back to it a third and again and again.
Isn't r6rs a superset of r5rs?
> --
> __Pascal Bourguignon__
···@informatimago.com (Pascal J. Bourguignon) writes:
> Eli Barzilay <···@barzilay.org> writes:
>
>> ···@informatimago.com (Pascal J. Bourguignon) writes:
>>>
>>> [...] However, I'm not able to use it since they've includede
>>> r6rs.
>>
>> The language (and DrScheme) did not change for r6rs.
>
> Well nowdays, when I run mzscheme, the conses are not mutable
> anymore.
(a) that's completely unrelated to r6rs; (b) the default `cons' is
immutable, there is still a mutable version under a different name
(`mcons'); (c) if all you care about is r5rs (or r6rs), then these
languages use the mutable variant by default.
> I never had the time (nor the will) to learn the complicated and
> changing library loading invokations needed to revert to r5rs
> behavior...
The old way was to use the "r5rs" language from the language selection
dialog.
The new way is to use the "r5rs" language from the language selection
dialog.
A second way was to write a (module ...) expression -- and that same
expression will work the same now as well.
> Actually this is the reason why I use CL instead of
> scheme. Everytime I learned something in scheme, I had to learn it
> again next time because things were different (with a different
> implementation or just a different report published). Scheme is a
> moving target that moved too fast when I was learning lisp. The
> second time I came back to CL, everything was still where I left
> them, and I could make progress. Then I could come back to it a
> third and again and again.
Yes, Scheme is more dynamic, and PLT Scheme even more than that. CL
in comparison has been very static. Whether this is an advantage or a
disadvantage is pure flamebait.
Vend <······@virgilio.it> writes:
> On 13 Mar, 16:05, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>>
>> [... immutable conses ...]
>
> That's not r6rs. It's an "extension" of plt scheme.
It's a restriction.
> Isn't r6rs a superset of r5rs?
No.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
From: William James
Subject: Re: potential bug in REPL in newLISP-GS in newLISP v.10.0.1
Date:
Message-ID: <gpeqc7021dd@enews5.newsguy.com>
Eli Barzilay wrote:
> Yes, Scheme is more dynamic, and PLT Scheme even more than that. CL
> in comparison has been very static.
Then why is comp.lang.scheme so static?
From: William James
Subject: Re: potential bug in REPL in newLISP-GS in newLISP v.10.0.1
Date:
Message-ID: <gpehj003fa@enews4.newsguy.com>
Pascal J. Bourguignon wrote:
> Actually this is the reason why I use CL instead of scheme. Everytime
> I learned something in scheme, I had to learn it again next time
> because things were different (with a different implementation or just
> a different report published). Scheme is a moving target that moved
> too fast when I was learning lisp. The second time I came back to CL,
> everything was still where I left them, and I could make progress.
> Then I could come back to it a third and again and again.
The behavior of the dead is rather immutable.
William James schrieb:
>
> The behavior of the dead is rather immutable.
"Common Lisp doesn't look any deader than usual to me and I like it"
Slightly modified quote from David Thornley - sorry, couldn't resist :)
-- Mario
On 13 Mar 2009 21:01:20 GMT, "William James" <> wrote:
>Pascal J. Bourguignon wrote:
>
>> Actually this is the reason why I use CL instead of scheme. Everytime
>> I learned something in scheme, I had to learn it again next time
>> because things were different (with a different implementation or just
>> a different report published). Scheme is a moving target that moved
>> too fast when I was learning lisp. The second time I came back to CL,
>> everything was still where I left them, and I could make progress.
>> Then I could come back to it a third and again and again.
>
>The behavior of the dead is rather immutable.
The most cooperative man is a dead one.
On Fri, 13 Mar 2009 13:05:03 +0100, ···@informatimago.com (Pascal J.
Bourguignon) wrote:
>Benjamin L. Russell <············@Yahoo.com> writes:
>> On the other hand, Common Lisp is a Lisp-2 dialect of Lisp, and I had
>> a bad experience with Common Lisp in college because of a variety of
>> factors, which, IIRC, had to do with a combination of
>
>> the size of the language,
>
>[...]
>
>> the inability of redefininig variables and functions already defined,
>
>What strange implementation did you use? Are you sure it was Common Lisp?
IIRC, the implementation was Franz (Allegro) Common Lisp. We were
required to lug around a heavy reference manual of over a thousand
pages, most of which were devoted to library functions.
>
>C/USER[9]> (defparameter *p* 1)
>*P*
>C/USER[10]> *p*
>1
>C/USER[11]> (defparameter *p* "hi")
>*P*
>C/USER[12]> *p*
>"hi"
>C/USER[13]>
Hm ... let me try that out.
>You can even redefine the functions while other threads call them (but
>granted, threads are not in CL, it's an extension):
>
>S/CL-USER[30]> (defun f () (print 1))
>
>F
>
>S/CL-USER[31]> (f)
>
>1
>1
>
>S/CL-USER[32]> (SB-THREAD:MAKE-THREAD (lambda () (loop :repeat 100 :do (sleep 2) (f))))
>
>#<SB-THREAD:THREAD RUNNING {100407EC91}>
>
>S/CL-USER[33]> (f)
>
>1
>1
>
>S/CL-USER[34]>
>1
>1
>1
>1
>1
>1
>1
>1
>(defun f () (princ "deux") (terpri))
>STYLE-WARNING: redefining F in DEFUN
>1
>F
>
>S/CL-USER[35]> deux
>deux
>deux
>deux
>deux
>deux
>deux
>(defun f () (princ (function f)) (terpri))
>STYLE-WARNING: redefining F in DEFUN
>F
>
>S/CL-USER[36]> #<FUNCTION F>
>#<FUNCTION F>
>#<FUNCTION F>
>#<FUNCTION F>
>#<FUNCTION F>
Aha! You still get warnings when redefining functions. Maybe that
was part of the problem; I wanted to define such basic functions as
sqrt() for an introductory computer science course without
encountering any error messages. Common Lisp dialects usually return
error messages when basic functions are redefined, but not at least
some dialects of Scheme (for example, MzScheme does not complain when
I redefine sqrt(), a basic function, to behave as factorial()). I
wound up flipping through the entire Franz reference book every time I
wanted to define a new function in order to preclude an error message.
>
>
>
>> and the separate namespaces for functions and variables.
>
>How is that different to, for example C++, where there are also
>several namespaces?
I don't use C++. I mainly use Scheme and Haskell. In general, I try
to stick to the functional paradigm, and to avoid the object-oriented
paradigm.
>[...]
>
>> What is needed is a small language, no larger than R5RS Scheme, that
>> supports first-class continuations, tail calls, and reflection, which
>> is preferably a Lisp-1 dialect, which preferably both comes with a
>> DrScheme-style GUI interface and the ability to work seamlessly in a
>> REPL in Emacs, and which runs without hanging in the "Open File"
>> dialog box every few seconds in Windows XP Professional, Service Pack
>> 2, with mapped network drives (DrScheme hangs in that dialog box for
>> several seconds every dozen seconds or so on Windows XP Pro, SP2, with
>> mapped network drives). Preferably, it should also work on Mac OS X
>> 10.5.x Leopard, since that is my OS at home (I am forced to use
>> Windows XP at work). Since I am a hobbiest, and not a professional
>> software developer, the language need not come with a large library.
>> However, it needs to have a solid semantics so that I can work with
>> the kinds of exercises that appear in SICP.
>
>Well definitely you want a scheme. DrScheme includes mzscheme that
>you can use from emacs inferior-lisp. However, I'm not able to use
>it since they've includede r6rs. So I'd advise MIT-scheme which stays
>sane (but there's no GUI).
That's the problem. I like both MIT/GNU Scheme and PLT Scheme, but
they both have shortcomings in meeting my preferences. What would be
ideal would be either a version of MIT/GNU Scheme with an additional
DrScheme-style interface without the file explorer intermittent
hanging problem, or a version of PLT Scheme that sticks to the
functional paradigm and eschews the object-oriented paradigm, conforms
only to R5RS and smaller dialects of Scheme, and fixes the file
explorer intermittent hanging problem. Neither of these exist.
-- Benjamin L. Russell
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^
Benjamin L. Russell <············@Yahoo.com> writes:
> encountering any error messages. Common Lisp dialects usually
> return error messages when basic functions are redefined, but not at
> least some dialects of Scheme (for example, MzScheme does not
> complain when I redefine sqrt(), a basic function, to behave as
> factorial()).
MzScheme will not give you a warning message, but it is more extreme:
you never get to *redefine* `sqrt', all you can do is *rebind* it. In
other words, library code that uses `sqrt' will continue to work as
usual -- it's only your code that will see the new binding.
> [...] a version of PLT Scheme that sticks to the functional paradigm
> and eschews the object-oriented paradigm,
If you don't require the class system (or *a* class system, if you
count Swindle too), then you don't have to deal with OO code, in a
similar way that you get this:
> conforms only to R5RS [...],
just use `#lang r5rs' and you get extremely close to having *only*
r5rs.
> and fixes the file explorer intermittent hanging problem. [...]
I really don't see how you put this item with the rest: the file
explorer problem is something that happened only on your machine; I
don't know of anyone who was able to replicate it let alone debug it.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
Benjamin L. Russell <············@Yahoo.com> writes:
> Aha! You still get warnings when redefining functions.
Yes, that's considered a good thing, to avoid overriding an existing
function unwittingly.
> Maybe that
> was part of the problem; I wanted to define such basic functions as
> sqrt() for an introductory computer science course without
> encountering any error messages. Common Lisp dialects usually return
> error messages when basic functions are redefined,
Yes, again, this is considered a good thing. This is not specified by
the standard, but most implementation have package locks, and keep the
CL package locked to avoid overriding these functions.
However, they also provide the tools needed to unlock (temporarily) a
package so you still can override a standard function.
But the CL standard provides a way to write your own function using
the same name as a standard one, by way of SHADOWING the symbol:
(defpackage "MY-CL" (:use "CL") (:shadow "SQRT"))
(in-package "MY-CL")
(defun sqrt (x) (format nil "~A Senatus Populusque Romanus ~:*~A" x))
> but not at least
> some dialects of Scheme (for example, MzScheme does not complain when
> I redefine sqrt(), a basic function, to behave as factorial()). I
> wound up flipping through the entire Franz reference book every time I
> wanted to define a new function in order to preclude an error message.
You only had to learn about SHADOW, in the PACKAGE chapter...
> I don't use C++. I mainly use Scheme and Haskell. In general, I try
> to stick to the functional paradigm, and to avoid the object-oriented
> paradigm.
Good resolution!
--
__Pascal Bourguignon__