headers
Octav Popescu | 5 Jun 2008 23:47
Picon
Favicon

Text files in MCL 5.2

MCL 5.2 seems to have a problem with text files. It assumes the input 
file is encoded in MacRoman and converts it to Unicode strings on 
reading, but it doesn't do a reverse conversion on writing. And then it 
just writes the lower bytes of the unicode codes. So for instance if you do:

(with-open-file (in "Home:In.lisp")
    (with-open-file (out "Home:Out.lisp" :direction :output :if-exists 
:supersede)
      (princ (read-line in) out)))

And if you have a line with foreign language characters in "In.lisp", 
you end up with different characters in "Out.lisp". So if you read it 
again, you get a different text than the first time. Does anybody have a 
solution for this problem? I found a workaround by calling 
ccl::convert-string-to-mac-encodings on the string before writing it, 
but I'm hoping for a better integrated solution, which I can save as a 
patch.

Thanks,
Octav
_______________________________________________
info-mcl mailing list
info-mcl@...
http://clozure.com/mailman/listinfo/info-mcl
Permalink | Reply | 1 comment |
headers
Toomas Altosaar | 6 Jun 2008 00:43
Picon
Picon

Re: Text files in MCL 5.2

IIRC, MCL 5.2 reads in text files and converts to Unicode on the fly. 
And if you save the file then there is no going back to using that 
file in an earlier MCL release.

Not the solution you are looking for, but I am still using 5.1 for 
just that reason.

Is there some switch that allows the Unicode conversion to be turned off?

>MCL 5.2 seems to have a problem with text files. It assumes the input
>file is encoded in MacRoman and converts it to Unicode strings on
>reading, but it doesn't do a reverse conversion on writing. And then it
>just writes the lower bytes of the unicode codes. So for instance if you do:
>
>(with-open-file (in "Home:In.lisp")
>     (with-open-file (out "Home:Out.lisp" :direction :output :if-exists
>:supersede)
>       (princ (read-line in) out)))
>
>And if you have a line with foreign language characters in "In.lisp",
>you end up with different characters in "Out.lisp". So if you read it
>again, you get a different text than the first time. Does anybody have a
>solution for this problem? I found a workaround by calling
>ccl::convert-string-to-mac-encodings on the string before writing it,
>but I'm hoping for a better integrated solution, which I can save as a
>patch.
>
>Thanks,
>Octav
>_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
p2.edoc | 7 Jun 2008 08:39

Re: Text files in MCL 5.2

At 5:47 PM -0400 08/06/05, Octav Popescu wrote:
>MCL 5.2 seems to have a problem with text files. It assumes the input
>file is encoded in MacRoman and converts it to Unicode strings on
>reading, but it doesn't do a reverse conversion on writing. And then it
>just writes the lower bytes of the unicode codes.

In the MCL 5.2 save file dialog is a new Format option for external-format
[MCL 5.1 Format]
[Unicode (UTF8)]
[Unicode (UTF16)]
[Unix line endings]

If a file is saved in [MCL 5.1 Format] or [Unix 
line endings] by 5.2 is should be read as 
original under MCL pre 5.2.

MCL 5.2 file saved as [Unicode (UTF8)],  under 
5.1 we see the BOM (Ôªø) file prefix.
         ditto         [Unicode (UTF16)], under 5.1 it cannot be read

the external file's format is found using 
utf-something-p (which assumes nothing, rather 
investigates the file contents and 
FSCataloginfo.FinderInfo.filetype).

for internal state, file-external-format looks 
for (view-get window :external-format).

if we save as [MCL 5.1 Format] ccl::view-alist has :EXTERNAL-FORMAT nil.
(Continue reading)

Permalink | Reply | 0 comments |
headers
p2.edoc | 7 Jun 2008 08:40

font change anomaly

if in a pure new MCL 5.2 Listener you evaluate (code-char #xEFBB), 
the Listener font is changed

_______________________________________________
info-mcl mailing list
info-mcl@...
http://clozure.com/mailman/listinfo/info-mcl
Permalink | Reply | 0 comments |
headers
Toomas Altosaar | 7 Jun 2008 14:00
Picon
Picon

CLOS keeps on surprising me

Would have thought that the following would have been caught at compile time.
But I imagine that there is a good reason for only detecting this at run time.
This in 5.1b4.

-----

(defgeneric some-function (x)
   (:method (x) (print x) (values))
   (:method :before (x) (print :before))
   (:method :after (x) (print :after))
   (:method :around (x)
            (print :around1)
            (call-next-method)
            (print :around2)
            (values))
   (:method :BULL (x)
            (print :BULL)))

;(some-function 5)

>  Error: #<STANDARD-METHOD SOME-FUNCTION :BULL (T)> is an invalid method.
>         :BULL is not one of :BEFORE, :AFTER, and :AROUND.
>  While executing: CCL::%INVALID-METHOD-ERROR
>  Type Command-. to abort.
See the RestartsŠ menu item for further choices.
1 >

;(COMPUTE-APPLICABLE-METHODS #'some-function '(5)) ==>

(#<STANDARD-METHOD SOME-FUNCTION (T)>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pascal Costanza | 7 Jun 2008 14:12

Re: CLOS keeps on surprising me


On 7 Jun 2008, at 14:00, Toomas Altosaar wrote:

> Would have thought that the following would have been caught at  
> compile time.
> But I imagine that there is a good reason for only detecting this at  
> run time.
> This in 5.1b4.
>
> -----
>
> (defgeneric some-function (x)
>   (:method (x) (print x) (values))
>   (:method :before (x) (print :before))
>   (:method :after (x) (print :after))
>   (:method :around (x)
>            (print :around1)
>            (call-next-method)
>            (print :around2)
>            (values))
>   (:method :BULL (x)
>            (print :BULL)))
>
> ;(some-function 5)
>
>> Error: #<STANDARD-METHOD SOME-FUNCTION :BULL (T)> is an invalid  
>> method.
>>        :BULL is not one of :BEFORE, :AFTER, and :AROUND.
>> While executing: CCL::%INVALID-METHOD-ERROR
>> Type Command-. to abort.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Toomas Altosaar | 7 Jun 2008 15:39
Picon
Picon

Re: CLOS keeps on surprising me

Strange that I was just thinking of you when I posted this question. ;-)

Thanks for the reasoning!

>A compiler could theoretically detect that the standard method 
>combination is used, and thus anticipate that qualifiers other 
>than :before, :after and :around are invalid. However, in the general 
>case, method combination can be performed by some user-defined 
>algorithm, and thus it is impossible to predict in the general case 
>which qualifiers are acceptable or not. This could, for example, 
>depend on runtime state of the system.
>
>
>Pascal
>
>--
>Pascal Costanza, mailto:pc@..., http://p-cos.net
>Vrije Universiteit Brussel, Programming Technology Lab
>Pleinlaan 2, B-1050 Brussel, Belgium
>
>
>
>
>
>
>_______________________________________________
>info-mcl mailing list
>info-mcl@...
>http://clozure.com/mailman/listinfo/info-mcl
(Continue reading)

Permalink | Reply | 0 comments |
headers
Didier Verna | 23 Jun 2008 16:04
Picon
Picon
Picon
Picon
Gravatar

[ELW'08] Important news


       Hello,

here are some important news on the 5th European Lisp Workshop, July 7,
Pahpos, Cyprus, co-located with ECOOP 2008:

* The paper selection process is over; the final programme will be
  available shortly. Stay tuned for the upcoming call for participation!

* We now have the abstracts for the two keynote presentations:

  Lisp for the 21st Century (Mark Tarver)

  As Lisp reaches its 50th anniversary, the talk looks at some of the
  reasons why Lisp has not found a wider acceptance amongst the
  programming community. Part of the reasons lie in a vicious cycle
  between education and industry within which Lisp is trapped. One
  solution is the L21 project - to produce a rationalized and revised
  update of Lisp for the C21. Qi fits many of the constraints of the L21
  project. The talk concludes on what needs to be done within Qi and the
  Lisp world to bring Lisp to the center stage.

  A Detailed Look at the Lisp Nature of Clojure (Rich Hickey)

  The small essential core of Lisp makes dialects easy to define and
  implement. Most dialects are viewed skeptically by the community, as
  their features can be realized via the extensibility mechanisms of
  Scheme or Common Lisp. However, functional programming,
  interoperability, extensibility and concurrency objectives call for
  different decisions at many Lisp design points. Meeting those objectives
(Continue reading)

Permalink | Reply | 0 comments |
headers
Didier Verna | 30 Jun 2008 16:57
Picon
Picon
Picon
Picon
Gravatar

CfParticipation: ELW'08, July 7, Paphos, Cyprus


     +------------------------------------------------------------+
     |                   CALL FOR PARTICIPATION                   |
     |                 5th European Lisp Workshop                 |
     |     July 7, Paphos, Cyprus - co-located with ECOOP 2008    |
     +------------------------------------------------------------+

The 5th European Lisp Workshop will be held on July 7, in Paphos,
Cyprus, as part of this year's European Conference on Object-Oriented
Programming (ECOOP 2008). The workshop will feature two keynote
presentations: "Lisp for the 21st Century", by Mark Tarver, and "A
detailed look at the Lisp Nature of Clojure", by Rich Hickey. We have
also accepted four scientific papers about description logic systems,
data parallelism for quantum simulation, interactive code generation,
and a rant about make-method-lambda.

Get all the programme details at http://elw2008.bknr.net/programme.

Registration
************
Main registration is with ECOOP via the following page:
https://cyprusconferences.org/ecoop08/form_ecoop.htm

There is still room for attending the workshop, so if you want to
participate, please contact me by email as well (didier@...).

--

-- 
5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/

Didier Verna, didier@..., http://www.lrde.epita.fr/~didier
(Continue reading)

Permalink | Reply | 0 comments |

Gmane