headers
Dave Roberts | 1 Mar 2004 06:50

Reader pathname issue?

So in the course of working with UFFI to write some code to deal with
external functions, I ran across what is perhaps a bug in the reader for
pathnames. I'm still new to Lisp, so please educate me if this is not a
bug:

* #p"/home/dave/lispstuff/uffi-1.4.6"

#P"/home/dave/lispstuff/uffi-1.4"

This is using SBCL 0.8.6. Basically, when entering a literal pathname,
SBCL drops the trailing ".6" for some unknown reason. I have tried it
with some other names and suffixes and can't see any pattern in the
short amount of testing.

So, bug or pilot error?

Thanks,

-- Dave

--

-- 
Dave Roberts <ldave <at> droberts.com>

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
Permalink | Reply | 1 comment |
headers
Christophe Rhodes | 1 Mar 2004 09:07
Picon
Picon
Favicon

Re: Reader pathname issue?

Dave Roberts <ldave <at> droberts.com> writes:

> * #p"/home/dave/lispstuff/uffi-1.4.6"
>
> #P"/home/dave/lispstuff/uffi-1.4"
>
> This is using SBCL 0.8.6. Basically, when entering a literal pathname,
> SBCL drops the trailing ".6" for some unknown reason. I have tried it
> with some other names and suffixes and can't see any pattern in the
> short amount of testing.
>
> So, bug or pilot error?

A bug, which should be fixed in sbcl-0.8.8.

The problem lay in a confusion in parsing for the version component of
pathnames (it would lose when the final part of the pathname was
".<int>".

One comment: are you sure you don't mean the pathname
#p"/home/dave/lispstuff/uffi-1.4.6/"?  The trailing slash can make
quite a significant difference.

Cheers,

Christophe
--

-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paolo Amoroso | 6 Mar 2004 17:15
Picon
Favicon

Location of .asd files for REQUIRE

On my Debian Woody system I keep most of my Lisp sources in
subdirectories of ~/src/, such as ~/src/clx/ for SBCL's CLX sources. I
also have directory ~/src/systems/, in which I place symbolic links to
.asd files, including:

  ~/src/systems/clx.asd -> ~/src/clx/clx.asd

If I create directory ~/.sbcl/systems and the symbolic link:

  ~/.sbcl/systems/clx.asd -> ~/src/clx/clx.asd

I can correctly build and compile CLX by hand as explained in the
README file. But if ~/.sbcl/systems is not a regular directory but a
symbolic link:

  ~/.sbcl/systems -> ~/src/systems/

I get an error when building or loading CLX (see the transcript
included below). Why? Is this because of too much file system
indirection?

I use SBCL compiled from CVS sources updated no more than a couple of
days ago, and the latest CLX CVS sources from cvs.telent.net.

Paolo

--------------------------------------------------------------------
This is SBCL 0.8.8.14, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christophe Rhodes | 6 Mar 2004 18:51
Picon
Picon
Favicon

Re: Location of .asd files for REQUIRE

Paolo Amoroso <amoroso <at> mclink.it> writes:

> I get an error when building or loading CLX (see the transcript
> included below). Why? Is this because of too much file system
> indirection?

There is at least an inconsistency in SBCL's TRUENAME: it only
resolves the "topmost" symbolic link.  So, given
  /tmp/foo (directory)
  /tmp/foo/zot (file)
  /tmp/bar (symbolic link to /tmp/foo)
(truename "/tmp/bar/zot") returns #p"/tmp/bar/zot", not
#p"/tmp/foo/zot".  Whether this is an outright bug in TRUENAME
(unlikely, given the flexibility the CL pathname standard affords
implementors ;-), a suboptimality that we want to correct, or a
bad implicit assumption that ASDF has erroneously made, I don't know.

> 0: (TRUENAME 1 #P"/home/paolo/.sbcl/systems/package.lisp")[:EXTERNAL]

From here, we see that it has failed to fully resolve the path for
clx.asd.

Cheers,

Christophe
--

-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Roberts | 16 Mar 2004 07:29

Very slow and consy sb-alien:deref

So I'm working with UFFI and trying to interface with an outside
library. I have a small function that calls uffi:deref-array to read a
byte from an external buffer. This seems to be a macro that calls
sb-alien:deref. When I time this under SBCL 0.8.8, it takes 6 ms and
conses > 90 KB per call. Needless to say, this seems both very slow and
wasteful of memory. Here is the transcript from an emacs buffer (though
I have verified that it has nothing to do with either emacs or slime
using a standalone session in a term window).

Any thoughts?

* buffer

#<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X08274C20 :TYPE (* (UNSIGNED 8))>
* (time (deref buffer 12))

Evaluation took:
  		 0.006 seconds of real time
  		 0.0 seconds of user run time
  		 0.0 seconds of system run time
  		 0 page faults and
  		 94224 bytes consed.

--

-- 
Dave Roberts <ldave <at> droberts.com>

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christophe Rhodes | 16 Mar 2004 13:03
Picon
Picon
Favicon

Re: Very slow and consy sb-alien:deref

Dave Roberts <ldave <at> droberts.com> writes:

> * buffer
>
> #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X08274C20 :TYPE (* (UNSIGNED 8))>
> * (time (deref buffer 12))
>
> Evaluation took:
>   		 0.006 seconds of real time
>   		 0.0 seconds of user run time
>   		 0.0 seconds of system run time
>   		 0 page faults and
>   		 94224 bytes consed.

As a general rule, measuring something with just one call is a poor
way of getting accurate readings.  Also, you should take care to
measure what you actually want to know about -- not included in your
timings above are the amount of time it took you to type that form
into the REPL.  (If you think that's needlessly pedantic, consider the
possibility that the compiler can do work behind-the-scenes that it
can't if you just interact with top-level forms in the REPL -- and
that typically your program is compiled.)

Without knowing the details, it's hard to tell exactly what is going
on.  Could you post a more complete transcript, including your
definition of buffer?

Cheers,

Christophe
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Roberts | 23 Mar 2004 10:20

Help with type declarations

SBCL gurus,

I'm trying to optimize some calls and fighting a bit with SBCL on some
type declarations. In particular, it looks like INLINE and FTYPE
declarations don't want to mix very well. I have a couple of functions
at the bottom of my call graph:

(defun get-byte (buffer size index)
  "Get a byte from the foreign object array at the specified index."
  (declare (optimize (speed 3) (safety 0) (space 0))
 	   (byte-ptr buffer)
 	   (fixnum size)
 	   (fixnum index))
  (assert (and (<= 0 index) (< index size)))
  (uffi:deref-array buffer :unsigned-byte index))

(defun get16 (buffer size index)
  "Get a 16-bit quantity from the foreign object array, starting at
the specified index, in big-endian byte order."
  (declare (optimize (speed 3) (safety 0) (space 0))
	   (byte-ptr buffer)
	   (fixnum size)
	   (fixnum index)
	   (inline get-byte)
	   (ftype (function (byte-ptr fixnum fixnum) fixnum) get-byte))
  (logior (the fixnum (ash (get-byte buffer size index) 8))
	  (get-byte buffer size (1+ index))))

I want GET16 to inline GET-BYTE. At first, I had originally added the
FTYPE declaration in GET16 without the INLINE, to make the LOGIOR and
(Continue reading)

Permalink | Reply | 4 comments |
headers
Christophe Rhodes | 23 Mar 2004 11:36
Picon
Picon
Favicon

Re: Help with type declarations

Dave Roberts <ldave <at> droberts.com> writes:

> Now, I could insert (the fixnum ...) everywhere in the code. But
> shouldn't this work as I have written it, with both the INLINE and FTYPE
> declarations in force at the same time, or am I doing something wrong
> here?

It's a bit hard to tell, but there is something that is at least
suspicious.  The system needs to know that you will want to inline
functions in the future; otherwise the function will in fact be
non-inlineable.  To make a function inlineable, the compiler needs to
see 
  (declaim (inline foo))
before
  (defun foo () ...)
and since you didn't include one of those, it's possible that you've
left it out from your own code?  If you don't want FOO inline
everywhere, then you can put
  (declaim (notinline foo))
after the definition of foo, and then declare it inline locally as you
did in your second function.

As for respecting both the INLINE and FTYPE declarations at the same
time, I'm not sure whether that happens when the inlining is actually
performed.  For most cases it doesn't matter, because sbcl is quite
capable of deriving result types itself.

Cheers,

Christophe
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nikodemus Siivola | 23 Mar 2004 12:06
Picon
Picon

Re: Help with type declarations

On Tue, 23 Mar 2004, Dave Roberts wrote:

This caught my eye:

> (defun get16 (buffer size index)
>   "Get a 16-bit quantity from the foreign object array, starting at
> the specified index, in big-endian byte order."
>   (declare (optimize (speed 3) (safety 0) (space 0))
> 	   (byte-ptr buffer)
> 	   (fixnum size)
> 	   (fixnum index)
                  ^here

> 	   (inline get-byte)
> 	   (ftype (function (byte-ptr fixnum fixnum) fixnum) get-byte))
>   (logior (the fixnum (ash (get-byte buffer size index) 8))
> 	  (get-byte buffer size (1+ index))))
                                   ^and here

So, actually you aren't guaranteeing a fixnum after all.

Maybe:

 (declare (type (integer 0 #.(1- most-positive-fixnum)) index))

would help?

Cheers,

 -- Nikodemus
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dave Roberts | 24 Mar 2004 06:13

Re: Help with type declarations

On Tue, 2004-03-23 at 02:36, Christophe Rhodes wrote:
> It's a bit hard to tell, but there is something that is at least
> suspicious.  The system needs to know that you will want to inline
> functions in the future; otherwise the function will in fact be
> non-inlineable.  To make a function inlineable, the compiler needs to
> see 
>   (declaim (inline foo))
> before
>   (defun foo () ...)
> and since you didn't include one of those, it's possible that you've
> left it out from your own code?  If you don't want FOO inline
> everywhere, then you can put
>   (declaim (notinline foo))
> after the definition of foo, and then declare it inline locally as you
> did in your second function.

Doh! Right. I had read the page in the hyperspec that described all this
and had misunderstood what it was trying to achieve with that. I added
the DECLAIM and it worked great. Thank you.

> 
> As for respecting both the INLINE and FTYPE declarations at the same
> time, I'm not sure whether that happens when the inlining is actually
> performed.  For most cases it doesn't matter, because sbcl is quite
> capable of deriving result types itself.

Actually, that seems to work fine now. I have this feeling that by not
declaiming the inline, SBCL was not able to derive the type info for
some reason. Not sure why, but you might want to check on it. It
probably should not have complained at me about type info, just instead
(Continue reading)

Permalink | Reply | 0 comments |

Gmane