I'm trying to get mp3-browser example from Practical Common Lisp to work
on Win32 CLISP. However loading playlist.lisp or playlist.fas results in
a rather weird error:
*** - MAKE-ARRAY: dimension 1609760771 is not of type `(INTEGER 0
(,ARRAY-DIMENSION-LIMIT))
array-dimension-limit is only 16777216. I have no idea why CLISP wants
to create an array of such extreme size when it sees
(defun make-silent-song (title &optional (file *silence-mp3*))
(make-instance
'song
:file file
:title title
:id3-size (if (id3-p file) (size (read-id3 file)) 0)))
(specifically the error occurs at (read-id3 file))
Please help, I sooo want to try it out.
--
|a\o/r|,-------------.,---------- Timofei Shatrov aka Grue ------------.
| m"a ||FC AMKAR PERM|| mail: grue at mail.ru http://grue3.tripod.com |
| k || PWNZ J00 || Kingdom of Loathing: Grue3 lvl 18 Seal Clubber |
`-----'`-------------'`-------------------------------------------[4*72]
On 2005-07-07 14:41:01 -0400, ······@news.dtpq.com (Christopher C. Stacy) said:
> I keep reading that as "Portable Common Loops", sigh...
Ditto. Sign of old age I guess...
····@mail.ru (Timofei Shatrov) writes:
> I'm trying to get mp3-browser example from Practical Common Lisp to work
> on Win32 CLISP. However loading playlist.lisp or playlist.fas results in
> a rather weird error:
>
> *** - MAKE-ARRAY: dimension 1609760771 is not of type `(INTEGER 0
> (,ARRAY-DIMENSION-LIMIT))
>
> array-dimension-limit is only 16777216. I have no idea why CLISP wants
> to create an array of such extreme size when it sees
>
> (defun make-silent-song (title &optional (file *silence-mp3*))
> (make-instance
> 'song
> :file file
> :title title
> :id3-size (if (id3-p file) (size (read-id3 file)) 0)))
>
> (specifically the error occurs at (read-id3 file))
>
> Please help, I sooo want to try it out.
Is the file you are reading (i.e. the value of *silence-mp3*) in fact
an MP3 file that begins with an ID3 tag? The problem is presumably
that READ-ID3 tries to read in an ID3 tag which at various points has
to read some bytes which tell it how big the next thing is. If the ID3
tag is not properly formatted (or if there's a bug in the code) then
it's going to read some random bytes as a length and then try to
allocate an enormous array to hold the next bit. The call to ID3-P
should prevent this code from trying to read a file with now ID3 tag
at all but that just checks that the first three bytes of the file are
"ID3" so it's no guarantee that the rest is properly formatted.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
On Thu, 07 Jul 2005 21:48:53 GMT, Peter Seibel <·····@gigamonkeys.com>
tried to confuse everyone with this message:
>Is the file you are reading (i.e. the value of *silence-mp3*) in fact
>an MP3 file that begins with an ID3 tag?
Right, it seems the header of that file is not readable with (read-id3),
although it looks like ID3v2 (maybe 2.4?). Anyway, why does Lisp execute
code in defun? I can't even change the parameter to different file
before running this function!
--
|a\o/r|,-------------.,---------- Timofei Shatrov aka Grue ------------.
| m"a ||FC AMKAR PERM|| mail: grue at mail.ru http://grue3.tripod.com |
| k || PWNZ J00 || Kingdom of Loathing: Grue3 lvl 18 Seal Clubber |
`-----'`-------------'`-------------------------------------------[4*72]
····@mail.ru (Timofei Shatrov) writes:
> On Thu, 07 Jul 2005 21:48:53 GMT, Peter Seibel <·····@gigamonkeys.com>
> tried to confuse everyone with this message:
>
>>Is the file you are reading (i.e. the value of *silence-mp3*) in fact
>>an MP3 file that begins with an ID3 tag?
>
> Right, it seems the header of that file is not readable with (read-id3),
> although it looks like ID3v2 (maybe 2.4?). Anyway, why does Lisp execute
> code in defun? I can't even change the parameter to different file
> before running this function!
Eh? Presumably because someone is calling the function. Like the two
DEFPARAMETERS that follow the DEFUN in playlist.lisp.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
On Thu, 07 Jul 2005 17:49:32 GMT, ····@mail.ru (Timofei Shatrov) tried
to confuse everyone with this message:
>I'm trying to get mp3-browser example from Practical Common Lisp to work
>on Win32 CLISP.
Also, there is a bug in HTML library. (html (:input :name "a" :value
"b")) results in "<input name='a' value='b'>VALUEb</input>", which I
suppose is not the intended result. The problem function is
parse-implicit-attributes-sexp which adds :value "b" both to arguments
and to body. It seems using rest outside of for cycle is a bad idea:
(defun parse-implicit-attributes-sexp (sexp)
(loop with tag = (first sexp)
for rest on (rest sexp) by #'cddr ;;<-- rest is still (:value
"b") when the cycle ends.
while (and (keywordp (first rest)) (second rest))
when (second rest)
collect (first rest) into attributes and
collect (second rest) into attributes
end
finally (return (values tag attributes rest)))) ;;(:value "b") goes
to second and third part.
Maybe it's CLISP-specific problem and other Lisps leave rest at nil
value (which seems logical).
--
|a\o/r|,-------------.,---------- Timofei Shatrov aka Grue ------------.
| m"a ||FC AMKAR PERM|| mail: grue at mail.ru http://grue3.tripod.com |
| k || PWNZ J00 || Kingdom of Loathing: Grue3 lvl 18 Seal Clubber |
`-----'`-------------'`-------------------------------------------[4*72]
····@mail.ru (Timofei Shatrov) writes:
> On Thu, 07 Jul 2005 17:49:32 GMT, ····@mail.ru (Timofei Shatrov) tried
> to confuse everyone with this message:
>
>>I'm trying to get mp3-browser example from Practical Common Lisp to work
>>on Win32 CLISP.
>
> Also, there is a bug in HTML library. (html (:input :name "a" :value
> "b")) results in "<input name='a' value='b'>VALUEb</input>", which I
> suppose is not the intended result. The problem function is
> parse-implicit-attributes-sexp which adds :value "b" both to arguments
> and to body. It seems using rest outside of for cycle is a bad idea:
>
> (defun parse-implicit-attributes-sexp (sexp)
> (loop with tag = (first sexp)
> for rest on (rest sexp) by #'cddr ;;<-- rest is still (:value
> "b") when the cycle ends.
> while (and (keywordp (first rest)) (second rest))
> when (second rest)
> collect (first rest) into attributes and
> collect (second rest) into attributes
> end
> finally (return (values tag attributes rest)))) ;;(:value "b") goes
> to second and third part.
>
> Maybe it's CLISP-specific problem and other Lisps leave rest at nil
> value (which seems logical).
Yeah, I think this issue (what, if any values LOOP variables will have
in finally clauses) has been discussed before here. ISTR that CLISP
does it one way and everyone else does it another. I don't recall if
folks ever reached any agreement on whether the spec required it to
work one way or another. Based on the fact that CLISP seems to be
sticking to it's way of doing things, I'd guess not.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
On Thu, 07 Jul 2005 17:49:32 GMT, ····@mail.ru (Timofei Shatrov) tried
to confuse everyone with this message:
>I'm trying to get mp3-browser example from Practical Common Lisp to work
>on Win32 CLISP.
So, it almost works... But when I want to listen to my server I get the
following error:
Caught error in play-songs:
READ-BYTE on #<CLOSED INPUT BUFFERED FILE-STREAM CHARACTER
#P"D:\\TEMP\\PLS\\nameoffile.mp3" @1> is illegal
This is for the simple play-current. For efficient play-current the
error is
Caught error in play-songs: SYSTEM::STORE: #\Null does not fit into #(0
0 0 0 0 0 0 0), bad type
What can cause these errors?
--
|a\o/r|,-------------.,---------- Timofei Shatrov aka Grue ------------.
| m"a ||FC AMKAR PERM|| mail: grue at mail.ru http://grue3.tripod.com |
| k || PWNZ J00 || Kingdom of Loathing: Grue3 lvl 18 Seal Clubber |
`-----'`-------------'`-------------------------------------------[4*72]
····@mail.ru (Timofei Shatrov) writes:
> On Thu, 07 Jul 2005 17:49:32 GMT, ····@mail.ru (Timofei Shatrov) tried
> to confuse everyone with this message:
>
>>I'm trying to get mp3-browser example from Practical Common Lisp to work
>>on Win32 CLISP.
>
> So, it almost works... But when I want to listen to my server I get the
> following error:
>
> Caught error in play-songs:
> READ-BYTE on #<CLOSED INPUT BUFFERED FILE-STREAM CHARACTER
> #P"D:\\TEMP\\PLS\\nameoffile.mp3" @1> is illegal
>
> This is for the simple play-current. For efficient play-current the
> error is
>
> Caught error in play-songs: SYSTEM::STORE: #\Null does not fit into #(0
> 0 0 0 0 0 0 0), bad type
>
> What can cause these errors?
A bug. In PLAY-CURRENT (both versions) the WITH-OPEN-FILE:
(with-open-file (mp3 (file song))
...)
should be
(with-open-file (mp3 (file song) :element-type '(unsigned-byte 8))
...)
Sorry about that. I'll add it to the errato.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
From: Sam Steingold
Subject: Re: Compiling PCL example, possible CLISP bug?
Date:
Message-ID: <ur7e63h57.fsf@gnu.org>
> * Peter Seibel <·····@tvtnzbaxrlf.pbz> [2005-07-09 21:48:26 +0000]:
>
> ····@mail.ru (Timofei Shatrov) writes:
>
>> On Thu, 07 Jul 2005 17:49:32 GMT, ····@mail.ru (Timofei Shatrov) tried
>> to confuse everyone with this message:
>>
>> READ-BYTE on #<CLOSED INPUT BUFFERED FILE-STREAM CHARACTER
>> #P"D:\\TEMP\\PLS\\nameoffile.mp3" @1> is illegal
>
> A bug. In PLAY-CURRENT (both versions) the WITH-OPEN-FILE:
>
> (with-open-file (mp3 (file song))
> ...)
> should be
>
> (with-open-file (mp3 (file song) :element-type '(unsigned-byte 8))
> ...)
note that READ-BYTE is applied to a CLOSED stream.
even if the stream is made to have the right ELEMENT-TYPE,
you will get the error if you CLOSE it before calling READ-BYTE.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.jihadwatch.org/> <http://www.camera.org>
<http://www.honestreporting.com> <http://pmw.org.il/>
"A pint of sweat will save a gallon of blood." -- George S. Patton
Sam Steingold <···@gnu.org> writes:
>> * Peter Seibel <·····@tvtnzbaxrlf.pbz> [2005-07-09 21:48:26 +0000]:
>>
>> ····@mail.ru (Timofei Shatrov) writes:
>>
>>> On Thu, 07 Jul 2005 17:49:32 GMT, ····@mail.ru (Timofei Shatrov) tried
>>> to confuse everyone with this message:
>>>
>>> READ-BYTE on #<CLOSED INPUT BUFFERED FILE-STREAM CHARACTER
>>> #P"D:\\TEMP\\PLS\\nameoffile.mp3" @1> is illegal
>>
>> A bug. In PLAY-CURRENT (both versions) the WITH-OPEN-FILE:
>>
>> (with-open-file (mp3 (file song))
>> ...)
>> should be
>>
>> (with-open-file (mp3 (file song) :element-type '(unsigned-byte 8))
>> ...)
>
> note that READ-BYTE is applied to a CLOSED stream.
> even if the stream is made to have the right ELEMENT-TYPE,
> you will get the error if you CLOSE it before calling READ-BYTE.
Mmmmm. Good point. I've lost track of where this error message was
actually coming from so I'm not sure why the file would be
closed. Perhaps the OP can make the fix I suggested and then let us
know what happens.
-Peter
P.S. Lest people think the original code was irredeemably broken, it
*does* work in Allegro where I developed it because a stream with no
explicit element type is opened as a bivalent stream. Of course I
meant to write the code to run in any Common Lisp.
P.P.S. Though I should also point out to the OP, an others using
CLISP, that you will probably have a hard time running the full
Shoutcast server example in CLISP since it requires multiple threads.
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
On Sun, 10 Jul 2005 14:36:43 GMT, Peter Seibel <·····@gigamonkeys.com>
tried to confuse everyone with this message:
>
>Mmmmm. Good point. I've lost track of where this error message was
>actually coming from so I'm not sure why the file would be
>closed. Perhaps the OP can make the fix I suggested and then let us
>know what happens.
The fix helped for "efficient" version, didn't try the other one. I was
able to listen to the stream with WinAmp.
>P.P.S. Though I should also point out to the OP, an others using
>CLISP, that you will probably have a hard time running the full
>Shoutcast server example in CLISP since it requires multiple threads.
I made the appropriate fixes, such as removing the locks and using
:listeners 0 for aserve server. This makes it impossible to make any
changes at runtime, and probably it's impossible for more than one to
connect...
--
|a\o/r|,-------------.,---------- Timofei Shatrov aka Grue ------------.
| m"a ||FC AMKAR PERM|| mail: grue at mail.ru http://grue3.tripod.com |
| k || PWNZ J00 || Kingdom of Loathing: Grue3 lvl 18 Seal Clubber |
`-----'`-------------'`-------------------------------------------[4*72]
····@mail.ru (Timofei Shatrov) writes:
> On Sun, 10 Jul 2005 14:36:43 GMT, Peter Seibel <·····@gigamonkeys.com>
> tried to confuse everyone with this message:
>>P.P.S. Though I should also point out to the OP, an others using
>>CLISP, that you will probably have a hard time running the full
>>Shoutcast server example in CLISP since it requires multiple threads.
>
> I made the appropriate fixes, such as removing the locks and using
> :listeners 0 for aserve server. This makes it impossible to make any
> changes at runtime, and probably it's impossible for more than one to
> connect...
You'll probabyl also discover that the web UI is, er, not very
responsive, while listening to a stream. ;-)
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
On Tue, 12 Jul 2005 19:42:05 GMT, <·····@gigamonkeys.com> wrote:
>
>>>Shoutcast server example in CLISP since it requires multiple threads.
>
> You'll probabyl also discover that the web UI is, er, not very
> responsive, while listening to a stream. ;-)
I haven't tried this example yet, but it is on the list...that is if
multiple connections can be made. Your comment makes me wonder if
indeed multiple connections are possible (but perhaps slow) ?
--
LOOP :: a Domain Specific Language.
GP lisper <········@CloudDancer.com> writes:
> On Tue, 12 Jul 2005 19:42:05 GMT, <·····@gigamonkeys.com> wrote:
>>
>>>>Shoutcast server example in CLISP since it requires multiple threads.
>>
>> You'll probabyl also discover that the web UI is, er, not very
>> responsive, while listening to a stream. ;-)
>
> I haven't tried this example yet, but it is on the list...that is if
> multiple connections can be made. Your comment makes me wonder if
> indeed multiple connections are possible (but perhaps slow) ?
No, I'd expect that you can only have one connection at a time in a
non multithreaded Lisp. And since the thread that is streaming MP3s
will be busy doing that for as long as you listen, the web UI will be
unavailable.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/