- cmucl-imp - mailman3.common-lisp.net

build.sh
by Robert Swindells 30 Nov '09

30 Nov '09

I'm building the November snapshot and found that the line that causes old fasl files to be deleted from the build directories seems to have returned. Did this come from the merge of 20a-pre1 ? Maybe we need a $Header:$ line in this and a few other files. Robert Swindells

2 2

Dec snapshot tagged
by Raymond Toy 23 Nov '09

23 Nov '09

The December snapshot has been tagged a little early for various reasons. There weren't any major changes (see release-20b.txt), but I wanted to get these binaries out now. Binaries available soon. Ray

1 0

Snapshot 2009-11
by Raymond Toy 29 Oct '09

29 Oct '09

The November snapshots have been tagged and binaries will be uploaded shortly. Please read the early message about upcoming changes. For the unicode builds, you'll have to do a cross compile from a branch and use that to build the current snapshot. The non-unicode build can just use the 2009-10-01 bootstrap file. Important changes in this snapshot: o UTF-8 is much faster now. Some others have been speeded up too. o A critical bug in SSE2 has been fixed. (complex +/- float would sometimes have random junk added to the imaginary part.) Because of the SSE2 bug, I plan on creating both 8bit and Unicode builds for this snapshot. I wasn't going to do 8bit builds too often anymore, but this bug warrants it. Ray

1 0

Upcoming changes
by Raymond Toy 18 Oct '09

18 Oct '09

In the next day or two, I will be checking in some changes for Unicode that makes the utf-8 reader much faster (2-3 times or so). The other formats don't see much change in speed. However, to bootstrap this change you will need to do a cross-compile using the unicode-string-buffer-branch. Use boot-2009-10-1-cross.lisp as the cross-compile script. (Don't forget: you need to do, eventually, an x87 and an sse2 build. Non-unicode isn't needed here.) Once you finished the cross-compile, you can use that to build the sources. You can try this with the unicode-string-buffer-impl-branch now, or wait until that branch is merged to the trunk. Ray

2 1

[cmucl-imp] testing
by Raymond Toy 17 Oct '09

17 Oct '09

testing

1 0

Testing
by Raymond Toy 17 Oct '09

17 Oct '09

testing

1 0

[cmucl-imp] Testing
by Raymond Toy 17 Oct '09

17 Oct '09

Testing cmucl-imp(a)common-lisp.net

1 0

Re: [cmucl-imp] Re: setenv, unsetenv
by Raymond Toy 16 Oct '09

16 Oct '09

Madhu wrote: > My confusion appears to be because I was calling functions (via ffi) > which in turn used getenv(3) to query the environment to decide on > behaviour. > This, however, is enough reason to have setenv/putenv to keep *environment-list* and the C environment synchronized. If the user manipulated *environment-list* directly, the changes wouldn't be seen by ffi. This doesn't solve the issue if some function modifies the environment, though. Ray

1 0

Re: setenv, unsetenv (Was Re: Re: EXT:GETENV Re: [cmucl-commit] CMUCL commit: src/code (save.lisp))
by Madhu 16 Oct '09

16 Oct '09

* Raymond Toy <4AD71250.90204(a)stericsson.com> : Wrote on Thu, 15 Oct 2009 08:15:12 -0400: | Note that Solaris 8 (yes, it's ancient) does not have unsetenv and | setenv, so if we do this, can we try to just use putenv? I guess that | precludes us from removing something from the environment. If you cannot remove anything from the environment, I imagine you could just conditionalize out the unsetenv call branch without loss, maybe set it the value to "". There are no current callers anyway. | Solaris 10 does have unsetenv and setenv, though. | | And I think it is important to keep *environment-list* synchronized. | Either that or change load-foreign, execve, run-program and others | that use *environment-list* to set the environment. The idea behind what I suggested was to have minimal impact on existing code --- so the *environment-list* would continue to be used as before by these functions; it would continue to reflect the unix environment list at startup and have all changes made by the user via SETENV and (SETF GETENV). -- Madhu

3 2