(patch) replace perror() calls with GetLastError(), comment out spurious os_map debug output

The attached patch modifies src/runtime/win32-os.c as
follows:

* replace remaining calls to perror() with fprintf(stderr, ..., GetLastError())
   since errno is not set by Win32 API calls

* disable debug output from os_map()

--

-- 
Jack Unrue

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

_______________________________________________
Sbcl-devel mailing list
Sbcl-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Ping: adjust-array bug?

Possible bug in ADJUST-ARRAY and suggested (but possibly suboptimal)
bug fix has been unreviewed since 2006-08-17:

http://sourceforge.net/mailarchive/message.php?msg_id=36409808

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

win32 memory error

Hi all,

When running sbcl/win32 from within xemacs/slime, i got this error:

ensure_space: failed to validate 41938944 bytes at 0x02000000
VirtualAlloc fails with error code 487 (i.e invalid address)

>From genesis/constants.h, I found that address 0x2000000 is
READ_ONLY_SPACE_START, and upon further investigation i found the
following structure of the memory (using VirtualQuery):

starting address 0x2000000 :
size 0x3d0000 -> status: MEM_FREE
size 0x2000 -> status: MEM_COMMIT
remainder of the READ_ONLY region is MEM_FREE

So basically, we have a 8k block in the middle of the read-only region
which is already committed. That is the reason that VirtualAlloc is
failing. Note that this error occurs only sometimes (i.e when running
sbcl from within xemacs). When running sbcl standalone or when running
with gnu-emacs, the entire read-only region is MEM_FREE.

So the question is who allocated that 8k block? My guess is the C
runtime memory allocator. Could these kinds of interactions with other
allocators be the cause for the GC bugs too? How is sbcl ensuring that
its memory manager and the C runtime's memory manager don't stomp all
over each other?

regards
[sreeram;]

win32 memory error

Hi all,

When running sbcl/win32 from within xemacs/slime, i got this error:

ensure_space: failed to validate 41938944 bytes at 0x02000000
VirtualAlloc fails with error code 487 (i.e invalid address)

From genesis/constants.h, I found that address 0x2000000 is
READ_ONLY_SPACE_START, and upon further investigation i found the
following structure of the memory (using VirtualQuery):

starting address 0x2000000 :
size 0x3d0000 -> status: MEM_FREE
size 0x2000 -> status: MEM_COMMIT
remainder of the READ_ONLY region is MEM_FREE

So basically, we have a 8k block in the middle of the read-only region
which is already committed. That is the reason that VirtualAlloc is
failing. Note that this error occurs only sometimes (i.e when running
sbcl from within xemacs). When running sbcl standalone or when running
with gnu-emacs, the entire read-only region is MEM_FREE.

So the question is who allocated that 8k block? My guess is the C
runtime memory allocator. Could these kinds of interactions with other
allocators be the cause for the GC bugs too? How is sbcl ensuring that
its memory manager and the C runtime's memory manager don't stomp all
over each other?

regards
[sreeram;]

Re: patches: non-ascii c-string & pathnames and other

Yaroslav Kavenchuk <kavenchuk <at> tut.by> writes:
> Last version for non-ascii c-string's & pathnames (join in one patch)

Thanks, that looks great! (And sorry for keeping you waiting on this
for so long).

I discussed this with Christophe on #lisp earlier today, and came to
the conclusion that:

  * c-strings with external-formats should also be supported on non-unicode
    builds (as is done for streams)
  * it should be possible to specify the element-type of the Lisp
    string that results from naturalizing a foreign string, so that it's
    still possible to get the same behaviour as with the old
    definition of c-string

The following patch does this, cleans up the code a bit, and adds some
tests and documentation.

  <http://jsnell.iki.fi/tmp/alien-external-format.diff>

Assuming nobody has problems with the this, I'll commit it next week.

> and couple derivative pathces: some changes for win32 and some offers
> for tests (for larger compatibility with win32).
> 
> non-ascii & pathnames patch adapt  for linux (need test on other platforms).

(I'll let somebody with access to a Windows machine look at these).

Re: sb-executable mingw patch

"Marko Kocić" <marko.kocic <at> gmail.com> writes:
> Here's the patch that enables sb-executable to be used under mingw. I
> couldn't get it to work from DOS prompt, but at least it works under
> mingw and (I suppose) cygwin.

Thanks.

A few months ago there was talk of removing SB-EXECUTABLE from
contrib, since it's a rather ugly hack that nobody ever seemed to
use. These days the same niche is usually better served by
SAVE-LISP-AND-DIE :EXECUTABLE T or (if one really needs to avoid
cores) cl-launch.

So it might be good to make a decision on whether we keep it or not
before applying any patches to it. Opinions, anyone? 

--

-- 
Juho Snellman

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: sb-executable mingw patch

On 02 Sep 2006 02:16:20 +0300, Juho Snellman <jsnell <at> iki.fi> wrote:
> "Marko Kocić" <marko.kocic <at> gmail.com> writes:
> > Here's the patch that enables sb-executable to be used under mingw. I
> > couldn't get it to work from DOS prompt, but at least it works under
> > mingw and (I suppose) cygwin.
>
> Thanks.
>
> A few months ago there was talk of removing SB-EXECUTABLE from
> contrib, since it's a rather ugly hack that nobody ever seemed to
> use. These days the same niche is usually better served by
> SAVE-LISP-AND-DIE :EXECUTABLE T or (if one really needs to avoid
> cores) cl-launch.
>
Note that cl-launch has supported cores with SBCL since April. It will
possibly run under cygwin and probably not without (since it depends
on a posix shell).

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
The problem with most conspiracy theories is that they seem to believe that
for a group of people to behave in a way detrimental to the common good
requires intent.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Sbcl-devel mailing list
Sbcl-devel <at> lists.sourceforge.net

Re: Patch for run-program problem in Intel Mac OS 10.4

Sidney Markowitz <sidney <at> sidney.com> writes:

> Juho Snellman wrote, On 18/8/06 6:58 PM:
> > Note that :PTY T won't currently work on systems that use unix98 ptys
> > (for example many Linux distributions). There SB-IMPL:FIND-A-PTY needs
> > to look something like this:
> 
> Is a right way to tell whether unix98 ptys is built into the kernel by testing
> if /dev/ptmx can be opened?

I'm pretty sure it is.

> If so, the following combined code should work in either
> environment. I tested it under Mac OS 10.4.7 and Ubuntu linux 6.06,
> neither with unix98 ptys and it worked fine.

Thanks for testing it, committed as 0.9.16.14.

--

-- 
Juho Snellman

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: patches: non-ascii c-string & pathnames and other

Juho Snellman wrote:
> Assuming nobody has problems with the this, I'll commit it next week.

Many-many thanks!
Do not forget about changes from 0.9.16.2 (they are not considered).

I Look forward! :)

--

-- 
WBR, Yaroslav Kavenchuk.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Patch for run-program problem in Intel Mac OS 10.4

Juho Snellman wrote, On 2/9/06 12:30 PM:
> Thanks for testing it, committed as 0.9.16.14.

You're welcome. Note that tests/run-program.impure.lisp will still fail under
Mac OS X until Nikodemus checks in his version of the patch I suggested for
the test about two weeks ago, which he can do now that you have committed this
patch that it needed to work on UNIX98 PTY platforms.

 Sidney Markowitz
 http://www.sidney.com

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642