headers
David Creelman | 2 Feb 2009 22:50
Picon
Gravatar

cl-typesetting strangeness

Hi,

I'm trying to write a utility to print calendars using cl-typesetting.

I'm using SBCL and I get this error when I try to create a paragraph in my code

* (calendar-print::hello)  

debugger invoked on a UNDEFINED-FUNCTION in thread #<THREAD "initial thread" RUNNING {A834711}>: The
function :H-ALIGN is undefined.

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

("bogus stack frame")

I've done (require 'cl-typesetting) before calling hello. hello is simply a
copy of hello from cl-typesettings demo file test.lisp. I have a (use-package
typeset) above the hello code.

I'm guessing the problem is something to do with the accessor for the style.
Why can't this be seen by SBCL in my module when it can be seen in the test
module of cl-typesetting?

My apologies if this is a bit off topic for questions on SBCL.

Any ideas what I'm doing wrong?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Chun Tian (binghe | 3 Feb 2009 11:45
Picon

Re: Best method of working around bug 314939

Hi, Tapio Saarinen

All EUC-JP related SBCL code is in #p"src/code/external-formats/enc- 
jpn.lisp" and #p"src/code/external-formats/enc-jpn-tbl.lisp". The  
character map between EUC-JP and Unicode are defined by SB-IMPL::*UCS- 
TO-EUCJP-TABLE* and SB-IMPL::*EUCJP-TO-UCS-TABLE*. However, I don't  
think there're mistakes in them.

On 2009-1-31, at 19:30, Tapio Saarinen wrote:

> https://bugs.launchpad.net/sbcl/+bug/314939
>
> Does anyone have any suggestions for working around this bug? I need  
> to fetch
> EUC-JP encoded webpages which have invalid characters in them and  
> convert them
> to readable strings for use in an application. I'm extremely new to
> programming in lisp and would be grateful for any ideas as to the  
> best method
> of doing so.
>
> Thanks,
> Tapio
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
(Continue reading)

Permalink | Reply | 2 comments |
headers
Gary King | 3 Feb 2009 13:36
Favicon
Gravatar

Re: cl-typesetting strangeness

Hi David,

(I've cross posted this to c-lypesetting-devel).

 From the error, I'm guessing it's a package thing. If you have code  
like

(in-package <my-package)

...

(<some cl-typesetting macro>>... (:h-align ...) ...)

and <some cl-typesetting macro> isn't accessible in my-package, then  
the compiler will think that <some cl-typesetting macro> is a function  
and evaluate its arguments _before_ it checks that <some cl- 
typesetting macro> is even defined. When it gets to (:h-align ...), it  
will think that it is also a function and try to do something with it.  
Sadly, :h-align isn't a function and so you get the error.

The first thing to do is to check if <some cl-typesetting macro> is  
accessible.

HTH,

On Feb 2, 2009, at 4:50 PM, David Creelman wrote:

> Hi,
>
> I'm trying to write a utility to print calendars using cl-typesetting.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carlos Konstanski | 4 Feb 2009 16:42

why change sb-bsd-sockets:socket-make-stream?

`sb-bsd-sockets:socket-make-stream' recently has had its :name keyword
removed from the argument list.  This is causing problems with
existing code.  What was the purpose behind this change?
--

-- 
Carlos Konstanski

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
Permalink | Reply | 4 comments |
headers
Richard M Kreuter | 4 Feb 2009 17:45

Re: why change sb-bsd-sockets:socket-make-stream?

Carlos Konstanski writes:
> `sb-bsd-sockets:socket-make-stream' recently has had its :name keyword
> removed from the argument list.  This is causing problems with
> existing code.  What was the purpose behind this change?

Wishful thinking.  Out of curiosity, what are you using that argument for?

--
Richard

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
Permalink | Reply | 3 comments |
headers
Carlos Konstanski | 4 Feb 2009 18:53

Re: why change sb-bsd-sockets:socket-make-stream?

Richard M Kreuter writes:
 > Carlos Konstanski writes:
 > > `sb-bsd-sockets:socket-make-stream' recently has had its :name keyword
 > > removed from the argument list.  This is causing problems with
 > > existing code.  What was the purpose behind this change?
 > 
 > Wishful thinking.  Out of curiosity, what are you using that argument for?
 > 
 > --
 > Richard

Araneida uses it.  It was easy enough for me to fix.  But I worry that
this kind of non-backward-compatible change fuels the single biggest
argument against Common Lisp: that even though it has a rigid ANSI
standard, the language is a moving target due to those parts of the
language that are not covered by the standard.  Anything that starts
with "sb-" is subject to breakage from one version to the next.  This
makes it more difficult to get my pointy haired bosses to accept sbcl
in the corporate environment.  As much as I hate to say it, they have
a point.  As much as I dislike Java and .NET, they are more reliable
from the standpoint of updateability because they take backwards
compatibility into account.  When most languages need to move away
from compatibility, they release new major versions.  I am losing
ground in my fight for lisp because of your decision to break
backwards compatibility in a minor release.  It gives the enemy a
silver bullet.

I am a rabid Common Lisp fan.  I am on your side.  The argument I
state here is one that I have had to personally defend against real
people.  I have introduced sbcl to the workplace, much to the chagrin
(Continue reading)

Permalink | Reply | 2 comments |
headers
Richard M Kreuter | 4 Feb 2009 18:37

Re: Best method of working around bug 314939

"Chun Tian (binghe)" writes:
> Hi, Tapio Saarinen
> 
> All EUC-JP related SBCL code is in #p"src/code/external-formats/enc- 
> jpn.lisp" and #p"src/code/external-formats/enc-jpn-tbl.lisp". The  
> character map between EUC-JP and Unicode are defined by SB-IMPL::*UCS- 
> TO-EUCJP-TABLE* and SB-IMPL::*EUCJP-TO-UCS-TABLE*. However, I don't  
> think there're mistakes in them.

The external format code isn't the problem (at least, it's not the
problem at hand); the data Tapio wants to process isn't validly encoded
EUC-JP character data.  (It's also not validly marked up HTML, according
to the W3C validator.)

Tapio: there may not be any single best practice for handling improperly
encoded character data.  Here are some approaches I've used or heard
about in the past:

(1) treat the content as sequences of bytes.  If you're mostly only
    moving the content around from one place to another, this approach
    might suffice, and a few easy-to-implement helper routines can make
    this less inconvenient than it might sound.  (A couple of examples
    are appended below.)

(2) Like the previous suggestion, but occasionally selectively decode to
    strings "manually" with SB-EXT:OCTETS-TO-STRING (which offers more
    control over decoding than character streams do).  This approach can
    be handy when you're dealing with file formats that are "mostly"
    binary with some embedded encoded character data.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christophe Rhodes | 4 Feb 2009 21:22
Favicon

Re: why change sb-bsd-sockets:socket-make-stream?

Carlos Konstanski <ckonstanski <at> pippiandcarlos.com> writes:

> This is the problem that keeps lisp from gaining a foothold in
> the business world.

If I had a nickel for every time I heard something as "the problem"
that keeps "lisp" from doing something, I would have a lot of nickels.

I don't mean to sound unsympathetic, but nor do I wish to give false
hopes.  If you want something (backwards compatibility) that takes a
lot of work to achieve, someone (in this case, you or your employer)
is going to have to either do that work or fund that work.  Sun and
Microsoft may well have solid business reasons to fund their Java and
.NET backward compatibility guarantees themselves; it's also possible
that you can buy a support contract from a Lisp vendor that will give
you someone to shout at when backwards compatibility doesn't happen.
But I'm afraid that a small motley crew of interested parties cannot
give you those guarantees, so if you've come here looking for them,
you will leave empty-handed.

One thought for you: if stability is what you want, why are you
constantly upgrading your software?

> I don't have access to the sbcl CVS repo

Why not?  It is publically visible; if CVS itself is the problem, then
there are various mirrors around in other version control formats.

Best,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard M Kreuter | 4 Feb 2009 21:53

Re: why change sb-bsd-sockets:socket-make-stream?

Carlos Konstanski writes:
> Richard M Kreuter writes:
>  > Carlos Konstanski writes:
>  > > `sb-bsd-sockets:socket-make-stream' recently has had its :name keyword
>  > > removed from the argument list.  This is causing problems with
>  > > existing code.  What was the purpose behind this change?
>  > 
>  > Wishful thinking.  Out of curiosity, what are you using that
>  > argument for?
> 
> Araneida uses it...

The decision to remove the keyword was more of an innocent act than a
plot to infuriate.  The two or three of us who cared about the patch
that removed the argument looked around and didn't think we saw anything
using it.  The keyword can be reinstated.

> This is not the first non-backward-compatible change I have had to
> contend with.  I have to maintain a list of patches for araneida and
> clsql because both have current compatibility issues that did not
> exist at one time.  Put yourself in my place: my boss expresses
> disdain that we have to patch 3rd party lisp libraries, when such
> patching is not necessary for .NET libraries...

For my part, I have never worked on any nontrivial software project,
with any languages or technologies, that didn't have its own tools and
practices for maintaining local patches, compatibility interfaces, and
regression testing machinery for dealing with third-party software.
Perhaps I've lived a peculiarly uncharmed life.  In any event, such
tools and practices are particularly useful for investigating the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Goldman | 5 Feb 2009 17:30

why change sb-bsd-sockets:socket-make-stream?

I believe I was actually responsible for changing this, somewhat
inadvertently.

For the record, we didn't take :name off the list of supported keyword
arguments, per se.  Originally, socket-make-stream just pushed through
all its arguments to sb-sys:make-fd-stream, with no checking.

I can't see an objection to adding :name to the interface to provide a
better display.  Note, however, that one would want to think about doing
this a little.  There would be a benefit to having a client application
be able to set a helpful print name, but the downside is losing the
ability to tell at a glance whether a stream is a socket stream or not.
 Perhaps this :name support should be coupled with some enhancement of
the print-object method for fd-streams....

Best,
r

PS I'm hoping a moderator will push this through to the sbcl-help
mailing list, which I don't (and will not) subscribe to.

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
Permalink | Reply | 0 comments |

Gmane