Re: ASDF version

On 1/31/08, Victor Kryukov <victor.kryukov <at> gmail.com> wrote:
> I'm currently using SBCL 1.0.13, and it ships with asdf version 1.102
> [1], and the same is true for the development version of SBCL, while
> the most recent version is 1.111[2]. Is it by design? I'm asking
> because 1.107, which is 10 months old, introduced
> system-relative-pathname functionality, which is quite useful.

No, not by any particular design that I am aware of. I'll update the
SBCL copy.

Cheers,

 -- Nikodemus

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

SB-INT:FLUSH-STANDARD-OUTPUT-STREAMS problem

It seems SB-INT:FLUSH-STANDARD-OUTPUT-STREAMS is called early enough in
the debug handling code to be really annoying when your problem is that
you can't write to a standard output stream. For example:

******************************************

mprice <at> brownsmill ~/tmp> sbcl
; loading preferences for asdf-binary-locations/load-op from
; /home/mprice/.asdf/asdf-binary-locations.lisp

CL-USER> (defun main()
           (dotimes (i 2000)
            (format t "~a~%" i))
           (quit))

MAIN
CL-USER> (sb-ext:save-lisp-and-die "test" :toplevel #'main :executable t)
[undoing binding stack and other enclosing state... done]
[saving current Lisp image into /home/mprice/tmp/test:
writing 2824 bytes from the read-only space at 0x01000000
writing 1616 bytes from the static space at 0x01100000
writing 24023040 bytes from the dynamic space at 0x09000000
done]
mprice <at> brownsmill ~/tmp> ./test | tail -n 1
1999
mprice <at> brownsmill ~/tmp> ./test | head -n 1
0
Help! 11 nested errors. SB-KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.

  [huge stack trace deleted]

Re: SB-INT:FLUSH-STANDARD-OUTPUT-STREAMS problem

On 2/1/08, Michael Price <mprice <at> atl.lmco.com> wrote:

> It seems SB-INT:FLUSH-STANDARD-OUTPUT-STREAMS is called early enough in
> the debug handling code to be really annoying when your problem is that
> you can't write to a standard output stream. For example:

Yeah. Though I think it comes largely down to any error involving
output being annoying to debug -- not that things could not be improved.

> Is there a simple work-around for this problem that I'm missing?

HANDLER-CASE:

(defun main ()
  (handler-case
      (dotimes (i 20000)
        (format t "~a~%" i))
    (stream-error ()
      (quit :unix-status 1)))
  (quit))

SBCL itself wants to be smarter about EPIPE -- but I'm not sure just what TRT
is there.

Cheers,

 -- Nikodemus

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft

Re: SB-INT:FLUSH-STANDARD-OUTPUT-STREAMS problem

On 2/2/08, Nikodemus Siivola <nikodemus <at> random-state.net> wrote:

> SBCL itself wants to be smarter about EPIPE -- but I'm not sure just what TRT
> is there.

The attached patch implements one way of being smarter about things like that.

Result:

* (defun main ()
    (dotimes (i 20000)
      (format t "~a~%" i))
    (quit))

MAIN
* (save-lisp-and-die "test.core" :toplevel #'main)
[undoing binding stack and other enclosing state... done]
[saving current Lisp image into /Users/nikodemus/src/sbcl-git/test.core:
writing 2848 bytes from the read-only space at 0x04000000
writing 1616 bytes from the static space at 0x04100000
writing 24023040 bytes from the dynamic space at 0x10000000
done]
$ src/runtime/sbcl --core test.core --noinform | head -n 1
0

debugger invoked on a SB-INT:SIMPLE-STREAM-ERROR:
  Could not write to #<SB-SYS:FD-STREAM for "standard output"
{116E98E9}>: Broken pipe

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

Re: added support for mkdtemp in sb-posix

Here's a slightly more correct take on the same subject.

What I'm not sure of is what these functions should return:
strings or pathnames? In this version they return pathnames,
but quite possibly we should stick to strings.

Summary:

export SB-POSIX:MKSTEMP, add SB-POSIX:MKTEMP and SB-POSIX:MKDTEMP

 * Remove the alien struct consing from the calls -- just use the SAP
   directly.

 * Automagic unsupportedness handling for platforms that miss any of
   these.

 * All three new return pathnames instead of strings.

 * Rudimentary tests.

 * #-win32 for now.

Cheers,

 -- Nikodemus

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft

Re: added support for mkdtemp in sb-posix

"Nikodemus Siivola" writes:

> Here's a slightly more correct take on the same subject.
> 
> What I'm not sure of is what these functions should return:
> strings or pathnames? In this version they return pathnames,
> but quite possibly we should stick to strings.

Other functions in SB-POSIX that return filenames (readlink, getcwd,
etc.) return them as strings in filename syntax.  IMO, this is a flaw in
SB-POSIX [1], but it's important to be consistent with the rest of the
interface.

Also, people might already be using SB-POSIX:MKSTEMP, and if they are
parsing the second return value manually, their programs will break.

--
Richard

[1] Filename syntax is not the same as namestring syntax, and so the
only correct way to use SB-POSIX functions that return filenames
alongside ANSI CL to use PARSE-NATIVE-NAMESTRING at the call site.  That
"most" filenames are STRING= to a namestring that (indirectly) denotes
that filename makes need to use PARSE-NATIVE-NAMESTRING less obvious,
but it's still there.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: added support for mkdtemp in sb-posix

On 2/2/08, Richard M Kreuter <kreuter <at> progn.net> wrote:
> "Nikodemus Siivola" writes:
>
> > Here's a slightly more correct take on the same subject.
> >
> > What I'm not sure of is what these functions should return:
> > strings or pathnames? In this version they return pathnames,
> > but quite possibly we should stick to strings.
>
> Other functions in SB-POSIX that return filenames (readlink, getcwd,
> etc.) return them as strings in filename syntax.  IMO, this is a flaw in
> SB-POSIX [1], but it's important to be consistent with the rest of the
> interface.
>
> Also, people might already be using SB-POSIX:MKSTEMP, and if they are
> parsing the second return value manually, their programs will break.

Yep. The question is, if we want to switch to the better interface, how
do we do it?

This is a more general question then just SB-POSIX: if we wanted to say,
seriously refactor the SB-ALIEN interfaces, how should we do that?

(Make a new package with the new interface? Move the old interface to
a new package? Increment the second digit of our version number of each
such major change? Just Let Users Live With The Pain?)

Cheers,

 -- Nikodemus

Re: added support for mkdtemp in sb-posix

> Yep. The question is, if we want to switch to the better interface, how
> do we do it?
>
> This is a more general question then just SB-POSIX: if we wanted to say,
> seriously refactor the SB-ALIEN interfaces, how should we do that?
>
> (Make a new package with the new interface? Move the old interface to
> a new package? Increment the second digit of our version number of each
> such major change? Just Let Users Live With The Pain?)

from a mostly user's point of view:

- a mail to the list with a big fat warning in the subject (maybe with
an easy to search word like "INCOMPATIBLE CHANGE")
- increment the second digit in the version number
- if the change is a potential headache generator for many users _and_
also it's easy to do, then rename the old package and keep it for a
while (for example SB-ALIEN would be a good candidate for this
category, at least from the headache point of view).
- people who are concerned with backwards compatibility should not
update sbcl or use some git fu to build their sbcl with the fixes they
need.

just my 0.02,

--

-- 
 attila

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft

Re: win32 questions/concerns

On 1/29/08, Nikodemus Siivola <nikodemus <at> random-state.net> wrote:
> On 1/27/08, John Connors <johnc <at> yagc.ndo.co.uk> wrote:
>
> > For what it's worth, (I'm not sure how much) on win64 boxen I changed
> > src/compiler/x86/parms.lisp to the attached patch. I'm not sure what
> > actually lives in the dynamic space, but I'm inclined to guess it's
> > WoW32, hence the high failure rate on win64 boxen. HTH
>
> So these setting are at least somewhat good for 64bit Windows? Can
> someone confirm if they are good for 32bit Windows as well?

Apropos: what does uname -m return on 64 bit Windows? Or rather, which
command-line tool can tell us that the host is a 64 bit Windows?

Cheers,

 -- Nikodemus

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: win32 questions/concerns

"Nikodemus Siivola" <nikodemus <at> random-state.net> writes:

> Apropos: what does uname -m return on 64 bit Windows? Or rather, which
> command-line tool can tell us that the host is a 64 bit Windows?

the PROCESSOR_ARCHITECTURE environment variable has the value "AMD64"
on 64-bit Windows (probably something else on Itanium, but who cares).

(and shouldn't the relocation patch fix this all for good?)

cheers,
--m

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/