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

Re: [cmucl-imp] Compiling files with traditional Mac EOL in CMUCL
by Raymond Toy 12 Oct '17

12 Oct '17

On Wed, Oct 11, 2017 at 2:13 AM, Chun Tian <binghe.lisp(a)gmail.com> wrote: > > Hi Raymond, > > I’m so sorry, but somehow I've never received your previous email, that’s why I didn’t reply. > > After my initial post for this issue, I actually received a private mail from James Anderson (the author of CL-XML and many other utilities), the following reader macro, which allows the correct handling of Mac EOL in every CL implementation: > > (defun |universal-comment-reader| (stream char) > (declare (ignore char)) > (loop (case (read-char stream nil nil) > ((#\return #\linefeed nil) (return)) > (t ))) > (values)) > > (set-macro-character #\; '|universal-comment-reader|) > > But any way, I just tried (compile-file "foo.lisp" :external-format '(:utf8 :cr)), and I confirm it also works. I don’t know how to let ASDF compile files with additional parameters in COMPILE-FILE, but anyway there should be a solution (for CMUCL, maybe also SBCL?), it’s still a problem for some other CL implementations. Thanks for letting me know; glad it works for you. As for asdf, you can define your own classes and operations. I'm not an expert on this, but here is an example from f2cl (that Fare basically updated for me): https://gitlab.common-lisp.net/f2cl/f2cl/blob/master/src/f2cl-asdf.lisp. I think the relevant part is the perform method where you can specify options when compiling. > > Regards, > > Chun Tian > > > Il giorno 11 ott 2017, alle ore 05:37, Raymond Toy <toy.raymond(a)gmail.com> ha scritto: > > > >>>>>> "Raymond" == Raymond Toy <toy.raymond(a)gmail.com> writes: > > > >>>>>> "Chun" == Chun Tian <(binghe)" <binghe.lisp(a)gmail.com>> writes: > > Chun> OK, sorry, I carefully checked again. SBCL also doesn't support compiling > > Chun> files with Mac EOLs. Clozure CL, which I confirmed now, indeed support Mac > > Chun> EOLs. > > > > Chun> For the reason I can't convert the source files to UNIX line endings, > > Chun> there's a Lisp function for parsing (multi-line) literal strings defined in > > Chun> source files with MAC line endings. It seems that, #\Newline was mapped to > > Chun> "\r" in MCL, thus Lisp forms like (position #\Newline string) doesn't work > > Chun> in MCL for other line endings, especially the UNIX endings, because in this > > Chun> case there would be no #\Newline in the string at all! > > > > Raymond> I haven't tried this out in a long time, but maybe something like this > > Raymond> will work: > > > > Raymond> (compile-file "foo.lisp" :external-format '(:utf8 :cr)) > > > > Did you get a chance to try this out? > > > > -- > > Ray > > > > _______________________________________________ > > cmucl-imp mailing list > > cmucl-imp(a)cmucl.cons.org > > https://lists.zs64.net/mailman/listinfo/cmucl-imp > -- Ray

1 0

[cmucl-imp] Snapshot 2017-10
by Raymond Toy 11 Oct '17

11 Oct '17

The 2017-10 snapshot has been tagged. Binaries will be uploaded soon ot the usual place. The release notes can be found at https://gitlab.common-lisp.net/cmucl/cmucl/tags/snapshot-2017-10 and also on the wiki: https://gitlab.common-lisp.net/cmucl/cmucl/wikis/Home -- Ray

1 0

[cmucl-imp] Compiling files with traditional Mac EOL in CMUCL
by Chun Tian (binghe) 11 Oct '17

11 Oct '17

Hi, I'm surprised that CMUCL doesn't support lisp files with traditional Mac EOL, that is, lines are separated by a single '\r', there's no `\n` at all. Here is my recent story: I'm porting some old Lisp code originally developed in Macintosh Common Lisp 4.2. All files use Mac EOL. I can't convert them to Unix EOL, because that will break some Lisp functions in MCL. The problem when compiling these files in CMUCL is, if there's a line-based comment starting with semicolon ";", CMUCL compiler will consider all the rest code in the file is at the "same" line, thus they're all commented! It looks like CMUCL has correctly compiled the file (because there's no warning at all), but actually it compiled almost nothing. SBCL and LispWorks have no such issues, I can imagine Clozure CL must natively support Mac EOL. Is this a CMUCL bug that can be fixed? Regards, Chun Tian -- Chun Tian (binghe) University of Bologna (Italy)

3 4

[cmucl-imp] Issues upgrading ASDF on CMUCL
by Faré 26 Jul '17

26 Jul '17

One essential feature of ASDF is being able to upgrade from a previously loaded ASDF. This feature broke recently on CMUCL. When trying to upgrade CMUCL's provided ASDF to the latest, some weird CLOS errors happen. >From 3.1.7 (using 21d), class MODULE isn't subtypep of its superclass COMPONENT. >From 3.2.1 (using the april 2017 snapshot), I fail to set a newly defined slot inside INITIALIZE-INSTANCE: Error in function "DEFMETHOD SLOT-MISSING (T T T T)": When attempting to set the slot's value to NIL (setf of slot-value), the slot ASDF/FORCING:FORCED is missing from the object #<ASDF/PLAN:SEQUENTIAL-PLAN {5A38C46D}>. There's probably something wrong in some method caching mechanism, that prevents invalidation in presence of redefinition, or that breaks the class graph, etc. I know that ASDF upgrade stresses the CLOS implementation a lot, but CMUCL is unique in being stumped by ASDF, and has been for years. I'm not going to spend too many cycles figuring out what's happening, or going to block an ASDF release. My understanding is that the policy with respect to CMUCL is that CMUCL is always very prompt to update its ASDF, and that live ASDF upgrades are therefore not as essential as it is on other implementations that linger for years without an update. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org To distinguish the real from the unreal, one must experience both. — Saul Gorn On Sun, Apr 9, 2017 at 1:11 AM, Raymond Toy <toy.raymond(a)gmail.com> wrote: > While looking at the logs, I came across this that occurred on Jan 18, 20 > years ago: > > Author: ram <ram> > Date: Sat Jan 18 14:32:04 1997 +0000 > > Werkowskis source kit 1.03.7 > > > I guess this is the birth of cmucl in the new era. > > Seems so long ago, and yet not really that long ago either. > > -- > Ray > _______________________________________________ > cmucl-imp mailing list > cmucl-imp(a)cmucl.cons.org > https://lists.zs64.net/mailman/listinfo/cmucl-imp

2 3

[cmucl-imp] An historical note
by Raymond Toy 09 Apr '17

09 Apr '17

While looking at the logs, I came across this that occurred on Jan 18, 20 years ago: Author: ram <ram> Date: Sat Jan 18 14:32:04 1997 +0000 Werkowskis source kit 1.03.7 I guess this is the birth of cmucl in the new era. Seems so long ago, and yet not really that long ago either. -- Ray

1 0

[cmucl-imp] Snapshot 2017-04
by Raymond Toy 09 Apr '17

09 Apr '17

The 2017-04 snapshot has been tagged and binaries will be uploaded soon. Not much changed this month except for updating ASDF to version 3.2.1. However, FreeBSD binaries are available once again. As of this writing, you can get binaries for 21b and snapshot-2017-03 in the usual places. Thanks to Fred Gilham for making these available. Even though I don't use FreeBSD, it's really nice to see them available once again since FreeBSD was the first supported OS for the x86 architecture. -- Ray

1 0

[cmucl-imp] Testing
by Raymond Toy 16 Mar '17

16 Mar '17

Testing -- Ray

1 0

Testing cmucl mailing list at c-l.net
by Raymond Toy 10 Mar '17

10 Mar '17

Test -- Ray

1 0

[cmucl-imp] Symbols in wrong package
by Faré 04 Feb '17

04 Feb '17

Dear CMU CL hackers, ASDF 3.2.0 moved a few symbols from asdf/action to the later asdf/plan: required-component, traverse-actions, traverse-sub-action. But when I compile asdf.lisp while asdf 3.1.7 is loaded, the fasl ends up containing the symbols in action/action, and unfbound symbols are created in asdf/plan and exported. CMUCL is the only implementation that does that, and I believe that is a recent change, because test-utilities.script didn't fail before I upgraded CMUCL from some 2016 snapshot to the latest 2017-01. If that doesn't ring a bell, I can investigate further. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Be humble, for you are made of earth. Be noble, for you are made of stars. — Serbian proverb

2 2

Re: [cmucl-imp] [cmucl-help] NaN
by Marco Antoniotti 13 Jan '17

13 Jan '17

Thank you James, thank you Stelian. The CFFI solution seems very interesting and the codec James pointed me to are also useful. Do you have any ideas about how your code(s) would impact the lower levels of the implementation? Meaning: the solutions both of you propose essentially use the FFI: any ideas about how such solutions would impact memory management? Just curious. All the best Marco > On Jan 11, 2017, at 24:25 , james anderson <james(a)dydra.com> wrote: > > good evening; > >> On 2017-01-11, at 00:17, Raymond Toy <toy.raymond(a)gmail.com> wrote: >> >> […] >> You will have to figure out how to get LW or your favorite impl to do >> something similar. > > that is what the code i pointed you at does. > > best regards, from berlin, -- Marco Antoniotti

4 7