In the previous thread, I wondered whether to merge asdf-encodings into asdf. Any feedback on the proposal?
SCL plans to essentially do this in their upcoming release (1.4?).
It's again about 20KB, to add to the current 223KB (feature and size inflation).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The major advances in civilization are processes that all but wreck the societies in which they occur. — A.N. Whitehead
Sorry if there was some confusion. There are no plans to bundle asdf-encodings in with asdf in the next release of the SCL. The bundled version of asdf is expected to be the same as the normal release, except for any minor SCL specific fixes.
The next release of the SCL integrates comprehensive support for reading a text file character encoding from an Emacs style coding attribute. The support was contributed to public domain CMUCL if you wish to examine it. This allows 'load and 'compiler, and the debugger, and many editors, to also use the correct encoding. The new external-format has been named :file-attribute. It has not been decided if this will be the :default, but a separate default will be provided for lisp source files. I am open to working with other vendors on standardising the support, but there has been little interest.
Note that support for auto-detection is not included and there are no plans to do so. The reading of source code to interpret or compile and needs to be deterministic and not just a guess (which might be acceptable for an editor).
There is also support for reading the line termination encoding, and for handling a good range of Emacs specific encodings.
I would not suggest bundling asdf-encodings in with ASDF, but suggest CL implementations integrate the support so that it works with 'load and 'compile' and editors.
It should not interfere with the ASDF :encoding support or with asdf-encodings. Users will be able to reliably use a range of source code character encodings by just making :file-attribute the default on the SCL and adding an Emacs style coding attribute to source files. Code was contributed earlier in the year to insert the file attribute and/or transcode all of the quicklisp source distributions so there are lots of options for users and library authors.
Perhaps the asdf-encodings could be made an implementation specific support library that is only loaded for CL implementations without integrated support.
Regards Douglas Crosher
On 12/07/2012 11:50 AM, Faré wrote:
In the previous thread, I wondered whether to merge asdf-encodings into asdf. Any feedback on the proposal?
SCL plans to essentially do this in their upcoming release (1.4?).
It's again about 20KB, to add to the current 223KB (feature and size inflation).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The major advances in civilization are processes that all but wreck the societies in which they occur. — A.N. Whitehead
asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Sorry if there was some confusion. There are no plans to bundle asdf-encodings in with asdf in the next release of the SCL. The bundled version of asdf is expected to be the same as the normal release, except for any minor SCL specific fixes.
Oh, OK. Good. My apologies for not getting it. Your plan looks good.
The next release of the SCL integrates comprehensive support for reading a text file character encoding from an Emacs style coding attribute. The support was contributed to public domain CMUCL if you wish to examine it. This allows 'load and 'compiler, and the debugger, and many editors, to also use the correct encoding. The new external-format has been named :file-attribute. It has not been decided if this will be the :default, but a separate default will be provided for lisp source files. I am open to working with other vendors on standardising the support, but there has been little interest.
I believe I saw an earlier version of it. Is it in the current version of CMUCL from CVS? asdf::default-encoding-external-format could use :file-attribute instead of :default on SCL.
I would not suggest bundling asdf-encodings in with ASDF, but suggest CL implementations integrate the support so that it works with 'load and 'compile' and editors.
That sounds like an interesting plan.
Code was contributed earlier in the year to insert the file attribute and/or transcode all of the quicklisp source distributions so there are lots of options for users and library authors.
Is that the code we saw on that list? Did you get any feedback since then? IIRC, there were ~7 problematic systems that needed to be updated for UTF-8.
Perhaps the asdf-encodings could be made an implementation specific support library that is only loaded for CL implementations without integrated support.
That's a can of worm I'm trying to move away from.
Some time next month, we should go over quicklisp again and see if we can resolve those ~7 remaining systems, and maybe change the defaults for ASDF.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The greatest productive force is human selfishness. — Robert Heinlein, "Time Enough For Love"
"Far" == Far <Far> writes:
>> The next release of the SCL integrates comprehensive support for >> reading a text file character encoding from an Emacs style coding >> attribute. The support was contributed to public domain CMUCL if >> you wish to examine it. This allows 'load and 'compiler, and the >> debugger, and many editors, to also use the correct encoding. >> The new external-format has been named :file-attribute. It has >> not been decided if this will be the :default, but a separate default >> will be provided for lisp source files. I am open to working with >> other vendors on standardising the support, but there has been >> little interest. >> Far> I believe I saw an earlier version of it. Is it in the current version Far> of CMUCL from CVS?
No. The code was checked into git, but backed before the release and hasn't been re-enabled. While it's pretty cool, we wonder if it would not be better handled as an external library.
Ray
On Fri, Dec 7, 2012 at 11:57 AM, Raymond Toy toy.raymond@gmail.com wrote:
>> The next release of the SCL integrates comprehensive support for >> reading a text file character encoding from an Emacs style coding >> attribute. The support was contributed to public domain CMUCL if >> you wish to examine it. This allows 'load and 'compiler, and the >> debugger, and many editors, to also use the correct encoding. >> The new external-format has been named :file-attribute. It has >> not been decided if this will be the :default, but a separate default >> will be provided for lisp source files. I am open to working with >> other vendors on standardising the support, but there has been >> little interest. >> Far> I believe I saw an earlier version of it. Is it in the current version Far> of CMUCL from CVS?No. The code was checked into git, but backed before the release and hasn't been re-enabled. While it's pretty cool, we wonder if it would not be better handled as an external library.
Well, asdf-encodings does kind of the same thing in a semi-portable way, initially based on some of the same code. I'm sure its API could be improved.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org In the beginning there was nothing. And the Lord said "Let There Be Light!" And still there was nothing, but at least now you could see it.
On 12/08/2012 03:57 AM, Raymond Toy wrote:
"Far" == Far <Far> writes:
>> The next release of the SCL integrates comprehensive support for >> reading a text file character encoding from an Emacs style coding >> attribute. The support was contributed to public domain CMUCL if >> you wish to examine it. This allows 'load and 'compiler, and the >> debugger, and many editors, to also use the correct encoding. >> The new external-format has been named :file-attribute. It has >> not been decided if this will be the :default, but a separate default >> will be provided for lisp source files. I am open to working with >> other vendors on standardising the support, but there has been >> little interest. >> Far> I believe I saw an earlier version of it. Is it in the current version Far> of CMUCL from CVS?No. The code was checked into git, but backed before the release and hasn't been re-enabled. While it's pretty cool, we wonder if it would not be better handled as an external library.
If a CL implementation does not want the burden of implementing the reading of the file attribute then it also has the relatively good option of supporting just UTF-8 and asking users to use this and asking users to transcode lisp source files to UTF-8. If library authors include a coding file attribute in their source then this conversion can be easily automated, and it should be easy for quicklisp to do this transcoding when unpacking a library. Quicklisp could also include some auto-detection and hints to help with legacy code that does not have the coding file attribute - last time I checked a few hints were needed.
Regards Douglas Crosher
-
Douglas Crosher -
Faré -
Raymond Toy