gmane.lisp.babel.devel

Re: [asdf-devel] Tool for transcoding lisp source files and adding coding file options.

Antony — 2012-04-25T14:56:02

Thanks for sharing.
Would be nice if someone puts relevant pieces in a library since this 
has quite a bit of generally (outside of lisp source file encoding 
conversion) useful stuff.

-Antony

Re: error downloading babel

2012-03-23T16:27:15


----- Mail original -----
De: "Stelian Ionescu" <sionescu< at >cddr.org>
À: harven< at >free.fr
Cc: babel-devel< at >common-lisp.net
Envoyé: Vendredi 23 Mars 2012 17:08:44
Objet: Re: [babel-devel] error downloading babel

On Fri, 2012-03-23 at 16:35 +0100, harven< at >free.fr wrote:
[...]

First update quicklisp to dist 2012-03-07, then try again

Thanks, it worked.
I thought my version of quicklisp was up to date, but apparently I was wrong.

Best wishes,

Re: error downloading babel

Stelian Ionescu — 2012-03-23T16:08:44

[...]

First update quicklisp to dist 2012-03-07, then try again

error downloading babel

2012-03-23T15:35:09

Hello,

I encounter a problem trying to download babel using quicklisp. 

I am on debian squeeze and I use the last version of sbcl 1.0.55 that I
downloaded 5mns ago from the website, together with a fresh install of
quicklisp. I can reproduce the error using the version of sbcl 1.0.40
in the debian repositories. 


The relevant part of the log which is attached to this message seems to be
* (ql:quickload "babel")
To load "babel":
  Load 1 ASDF system:
    babel
; Loading "babel"

; file: /home/harven/.quicklisp/dists/quicklisp/software/babel-20120208-git/src/enc-unicode.lisp
; in: DEFINE-UTF-16 :UTF-16
;     (BABEL-ENCODINGS::DEFINE-UTF-16 :UTF-16)
; 
; caught ERROR:
;   (during macroexpansion of (DEFINE-UTF-16 :UTF-16))
;   #:~A-CODE-POINT-COUNTER fell through ETYPECASE expression.
;   Wanted one of (STRING SIMPLE-STRING).


A similar error has been reported on github 
https://github.com/cl-babel/babel/issues/9
where it was suggested to run the command
(alexandria:format-symbol t '#:~a-code-point-counter "UTF16") 
Here is what I get.

* (ql:quickload "alexandria")
To load "alexandria":
  Load 1 ASDF system:
    alexandria
; Loading "alexandria"

("alexandria")
* (alexandria:format-symbol t '#:~a-code-point-counter "UTF16") 

debugger invoked on a SB-KERNEL:CASE-FAILURE in thread
#<THREAD "initial thread" RUNNING {AB2C889}>:
  #:~A-CODE-POINT-COUNTER fell through ETYPECASE expression.
  Wanted one of (STRING SIMPLE-STRING).

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

(SB-KERNEL:CASE-FAILURE
 ETYPECASE
 #:~A-CODE-POINT-COUNTER
 (STRING SIMPLE-STRING))
0] 0

Any help ?

* (ql:quickload "babel")
To load "babel":
  Load 1 ASDF system:
    babel
; Loading "babel"

; file: /home/harven/.quicklisp/dists/quicklisp/software/babel-20120208-git/src/enc-unicode.lisp
; in: DEFINE-UTF-16 :UTF-16
;     (BABEL-ENCODINGS::DEFINE-UTF-16 :UTF-16)
; 
; caught ERROR:
;   (during macroexpansion of (DEFINE-UTF-16 :UTF-16))
;   #:~A-CODE-POINT-COUNTER fell through ETYPECASE expression.
;   Wanted one of (STRING SIMPLE-STRING).

; in: DEFINE-UTF-16 :UTF-16LE
;     (BABEL-ENCODINGS::DEFINE-UTF-16 :UTF-16LE :LE)
; 
; caught ERROR:
;   (during macroexpansion of (DEFINE-UTF-16 :UTF-16LE ...))
;   #:~A-CODE-POINT-COUNTER fell through ETYPECASE expression.
;   Wanted one of (STRING SIMPLE-STRING).

; in: DEFINE-UTF-16 :UTF-16BE
;     (BABEL-ENCODINGS::DEFINE-UTF-16 :UTF-16BE :BE)
; 
; caught ERROR:
;   (during macroexpansion of (DEFINE-UTF-16 :UTF-16BE ...))
;   #:~A-CODE-POINT-COUNTER fell through ETYPECASE expression.
;   Wanted one of (STRING SIMPLE-STRING).

; in: DEFINE-UCS :UTF-32
;     (BABEL-ENCODINGS::DEFINE-UCS :UTF-32 4)
; 
; caught ERROR:
;   (during macroexpansion of (DEFINE-UCS :UTF-32 ...))
;   #:~A-CODE-POINT-COUNTER fell through ETYPECASE expression.
;   Wanted one of (STRING SIMPLE-STRING).

; in: DEFINE-UCS :UTF-32LE
;     (BABEL-ENCODINGS::DEFINE-UCS :UTF-32LE 4 :LE)
; 
; caught ERROR:
;   (during macroexpansion of (DEFINE-UCS :UTF-32LE ...))
;   #:~A-CODE-POINT-COUNTER fell through ETYPECASE expression.
;   Wanted one of (STRING SIMPLE-STRING).

; in: DEFINE-UCS :UTF-32BE
;     (BABEL-ENCODINGS::DEFINE-UCS :UTF-32BE 4 :BE)
; 
; caught ERROR:
;   (during macroexpansion of (DEFINE-UCS :UTF-32BE ...))
;   #:~A-CODE-POINT-COUNTER fell through ETYPECASE expression.
;   Wanted one of (STRING SIMPLE-STRING).

; in: DEFINE-UCS :UCS-2
;     (BABEL-ENCODINGS::DEFINE-UCS :UCS-2 2 NIL 65536)
; 
; caught ERROR:
;   (during macroexpansion of (DEFINE-UCS :UCS-2 ...))
;   #:~A-CODE-POINT-COUNTER fell through ETYPECASE expression.
;   Wanted one of (STRING SIMPLE-STRING).

; in: DEFINE-UCS :UCS-2LE
;     (BABEL-ENCODINGS::DEFINE-UCS :UCS-2LE 2 :LE 65536)
; 
; caught ERROR:
;   (during macroexpansion of (DEFINE-UCS :UCS-2LE ...))
;   #:~A-CODE-POINT-COUNTER fell through ETYPECASE expression.
;   Wanted one of (STRING SIMPLE-STRING).

; in: DEFINE-UCS :UCS-2BE
;     (BABEL-ENCODINGS::DEFINE-UCS :UCS-2BE 2 :BE 65536)
; 
; caught ERROR:
;   (during macroexpansion of (DEFINE-UCS :UCS-2BE ...))
;   #:~A-CODE-POINT-COUNTER fell through ETYPECASE expression.
;   Wanted one of (STRING SIMPLE-STRING).

debugger invoked on a ASDF:COMPILE-ERROR in thread
#<THREAD "initial thread" RUNNING {AB2C889}>:
  Error while invoking #<COMPILE-OP (:VERBOSE NIL) {B72ECF9}> on
  #<CL-SOURCE-FILE "babel" "src" "enc-unicode">

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [RETRY ] Retry compiling #<CL-SOURCE-FILE "babel" "src" "enc-unicode">.
  1: [ACCEPT] Continue, treating
              compiling #<CL-SOURCE-FILE "babel" "src" "enc-unicode"> as having
              been successful.
  2: [ABORT ] Give up on "babel"
  3:          Exit debugger, returning to top level.

((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE))
 #<unavailable argument>
 #<unavailable argument>
 #<ASDF:COMPILE-OP (:VERBOSE NIL) {B72ECF9}>
 #<ASDF:CL-SOURCE-FILE "babel" "src" "enc-unicode">)
0] 

Sincerely,

Re: [cffi-devel] Unit tests failures on differentlisps

Anton Vodonosov — 2012-01-06T06:42:57

29.12.2011, 15:08, "Luís Oliveira" <luismbo< at >gmail.com>:

Jenkins is an interesting software (thanks for the reference BTW), but
it (and other continuous integration servers) has not so much overlap 
with what I do.

For Jenkins to run tests we need to provide a command "run tests".
Out of box it will be unable to run CL tests. So it's the first thing
I do - unify the interface of running test suites of different CL
libraries.

Also it is important to represent results so that we can see
side by side results of a particular library on different CL
implementations; or results of all the libraries on different
quicklisp distributions and so on. Continuous integration
servers will not provide such a representation.

Another goal is that people can contribute test results for
their platforms. This will save us from dependency
and maintenance of some central build farm with
all the possible combinations of OS and CL implementations.

So, while continue integration servers main function is to 
run some command - "run tests" - on some schedule
or by evens like source control commits. 

In my opinion scheduling is not the main task to solve. 
With cl-test-grid I go bottom-up by providing an easy way to 
run tests on any platform and share results. 

If we have several contributors who agree to run a simple 
command manually say once a month, it should be enough 
(for the beginning at least) to monitor the CL landscape 
and detect regressions. 

After this will work, probably someone will want to configure a cron job 
for this command and don't spend any attention on this at alll,
but on some platforms there might be limitations which will require
starting tests manually. Today it's a bit early to think about this.

Best regards,
- Anton


_______________________________________________
babel-devel mailing list
babel-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/babel-devel

Re: [cffi-devel] Unit tests failures on differentlisps

Anton Vodonosov — 2012-01-06T06:42:57

29.12.2011, 15:08, "Luís Oliveira" <luismbo< at >gmail.com>:

Jenkins is an interesting software (thanks for the reference BTW), but
it (and other continuous integration servers) has not so much overlap 
with what I do.

For Jenkins to run tests we need to provide a command "run tests".
Out of box it will be unable to run CL tests. So it's the first thing
I do - unify the interface of running test suites of different CL
libraries.

Also it is important to represent results so that we can see
side by side results of a particular library on different CL
implementations; or results of all the libraries on different
quicklisp distributions and so on. Continuous integration
servers will not provide such a representation.

Another goal is that people can contribute test results for
their platforms. This will save us from dependency
and maintenance of some central build farm with
all the possible combinations of OS and CL implementations.

So, while continue integration servers main function is to 
run some command - "run tests" - on some schedule
or by evens like source control commits. 

In my opinion scheduling is not the main task to solve. 
With cl-test-grid I go bottom-up by providing an easy way to 
run tests on any platform and share results. 

If we have several contributors who agree to run a simple 
command manually say once a month, it should be enough 
(for the beginning at least) to monitor the CL landscape 
and detect regressions. 

After this will work, probably someone will want to configure a cron job 
for this command and don't spend any attention on this at alll,
but on some platforms there might be limitations which will require
starting tests manually. Today it's a bit early to think about this.

Best regards,
- Anton


_______________________________________________
babel-devel mailing list
babel-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/babel-devel

Re: [cffi-devel] Unit tests failures on differentlisps

Anton Vodonosov — 2012-01-06T06:42:57

29.12.2011, 15:08, "Luís Oliveira" <luismbo< at >gmail.com>:

Jenkins is an interesting software (thanks for the reference BTW), but
it (and other continuous integration servers) has not so much overlap 
with what I do.

For Jenkins to run tests we need to provide a command "run tests".
Out of box it will be unable to run CL tests. So it's the first thing
I do - unify the interface of running test suites of different CL
libraries.

Also it is important to represent results so that we can see
side by side results of a particular library on different CL
implementations; or results of all the libraries on different
quicklisp distributions and so on. Continuous integration
servers will not provide such a representation.

Another goal is that people can contribute test results for
their platforms. This will save us from dependency
and maintenance of some central build farm with
all the possible combinations of OS and CL implementations.

So, while continue integration servers main function is to 
run some command - "run tests" - on some schedule
or by evens like source control commits. 

In my opinion scheduling is not the main task to solve. 
With cl-test-grid I go bottom-up by providing an easy way to 
run tests on any platform and share results. 

If we have several contributors who agree to run a simple 
command manually say once a month, it should be enough 
(for the beginning at least) to monitor the CL landscape 
and detect regressions. 

After this will work, probably someone will want to configure a cron job 
for this command and don't spend any attention on this at alll,
but on some platforms there might be limitations which will require
starting tests manually. Today it's a bit early to think about this.

Best regards,
- Anton


_______________________________________________
babel-devel mailing list
babel-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/babel-devel

Re: Problem with gbk-map.lisp

levin — 2012-01-03T07:38:12

Hi,Luís Oliveira

Thanks for telling me this problem, and I'm also glad that you fixed it,
sorry for the problem, I didn't take much consideration into this problem
when I was writing, BTW, ASCII representation is pretty enough.

Another problem you mentioned in the github issue list, I'd try to learn
how to write the ASDF tests suite.

Wenpeng Li

On Tue, Jan 3, 2012 at 6:05 AM, Luís Oliveira <luismbo< at >gmail.com> wrote:

Problem with gbk-map.lisp

Luís Oliveira — 2012-01-02T22:05:53

Hello Wenpeng,

I missed an obvious problem with your patch, it depends on Lisps
loading gbk-map.lisp using the UTF-8 encoding. AFAIK, there's no good
way to portably enforce that via ASDF, so I've converted the file to
an ASCII representation. It's not as pretty as the previous version,
but it seems to work.

Cheers,

Re: [cffi-devel] Unit tests failures on differentlisps

Luís Oliveira — 2011-12-29T11:08:03

OK, cool stuff. Have you considered using something like Jenkins?

Re: [cffi-devel] Unit tests failures on differentlisps

Anton Vodonosov — 2011-12-29T03:23:44


29.12.2011, 04:29, "Luís Oliveira" <luismbo< at >gmail.com>:

Not yet, because I am in the beginning of the project and only
starting to see the first results (it's not really a buildfarm, but
a small system where anyone may run a simple command, like
(load "agent.lisp"), and it runs the tests and submits the results
to the central server; so that we will be able to accumulate 
the statictics; currently this command just runs tests on 
whatever is the current quicklisp distribution is installed 
on the system, and I am the only person who runs this command 
- I am testing how it works and polishing the corner cases). 

The ability for library authors to express a wish to run tests on the 
recent (not released) version is one of the important future goals. 
There is no decision yet on how it will be specified, we may discuss it.
 I will contact you when (hopefully) I ready for this.

Best regards,
- Anton

_______________________________________________
babel-devel mailing list
babel-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/babel-devel

Re: Submit a GBK patch

Luís Oliveira — 2011-12-29T01:07:31

Yang and Wenpeng,

On Thu, Dec 22, 2011 at 2:55 PM, Xiaofeng Yang <n.akr.akiiya< at >gmail.com> wrote:

I've pushed Wenpeng's patch to the main repository. Some of the bits
in CCL's code do seem cleaner. It'd be nice to simplify Babel's
version if any of you has the time.

Thanks!

Re: [cffi-devel] Unit tests failures on differentlisps

Luís Oliveira — 2011-12-29T00:29:17

Thanks, this is rather helpful since these days I don't convenient
access to all the Lisps/platforms supported by CFFI. Those failures
are mostly harmless, although the BFF ones are probably
implementation-specific bugs.

Is there a way to take advantage of your buildfarm such that I can
test CFFI versions before doing a release or before even pushing to
the main repository?

Cheers,

Unit tests failures on different lisps

Anton Vodonosov — 2011-12-28T21:21:34

Hello.

I am running tests of some most often Quicklisp-downloaded libraries, including babel.

Babel tests have different number of failures/errors on different Lisps (about 8, 9 or 5).

You may find the results here: http://common-lisp.net/project/cl-test-grid/pivot_ql-lib_lisp.html

Clicking the ok/fail status refer to the library test logs where you may find what failures
occurred.

Best regards,
- Anton

Re: Submit a GBK patch

Xiaofeng Yang — 2011-12-22T14:55:37

I suggest this for both GB2312 and GBK encoding (this 2 encodings are very
important for Chinese users):
http://trac.clozure.com/ccl/changeset/14911
I've tested this for CCL using the encoding tables and tests from GNU's
iconv.

Most babel code came from CCL. I think to integrated this for babel is
easily and more suitable though it just only for CCL now.

     Best regards,
Xiaofeng Yang


2011/12/21 levin <levin108< at >gmail.com>

_______________________________________________
babel-devel mailing list
babel-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/babel-devel

Submit a GBK patch

levin — 2011-12-21T11:21:33

HI,all

Days ago, I found this project babel, and tried to use it in my project, as
I'm Chinese,
I found it doesn't support GBK encoding in babel, so I wrote a patch for
babel to make
it support GBK.

I just used common lisp for not a long time, so if there was something not
good enough, please let me know, I also hope you can accept this patch or
help me
modify it to make babel support GBK, so we can use it freely to process
Chinese text.

Thanks.

Re: Few fixes for ucs-2 and utf-32

Luís Oliveira — 2011-11-14T00:45:07

Heh. I, erm, insist. ;-)

Re: Few fixes for ucs-2 and utf-32

Dmitry Ignatiev — 2011-11-13T20:25:46

Hello.


Not yet, but i can write a few, if you insist.
_______________________________________________
babel-devel mailing list
babel-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/babel-devel

Re: Few fixes for ucs-2 and utf-32

Luís Oliveira — 2011-11-10T21:05:10

Hello,

On Thu, Oct 27, 2011 at 2:46 PM, Dmitry Ignatiev <lovesan.ru< at >gmail.com> wrote:

Do you have any tests to go with the patch? That'd be great.

Thanks,

Few fixes for ucs-2 and utf-32

Dmitry Ignatiev — 2011-10-27T13:46:25

Hi there.

There were some BOM-related bugs in unicode decoders.

patch attached
_______________________________________________
babel-devel mailing list
babel-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/babel-devel

Re: octets-to-string with UTF8 and Byte Order Marker

Luís Oliveira — 2011-05-11T07:32:33

Hello,

Sorry for the late reply.

On Thu, Apr 21, 2011 at 10:36 PM, Rob Blackwell <rob.blackwell< at >aws.net> wrote:

I'm not sure. I couldn't find any clear indications on how leading
BOMs should be handled for UTF-8. The BOM FAQ seems to indicate they
should be converted to ZERO WIDTH NON-BREAKING SPACEs, maybe. Any
comments? It would perhaps be interesting to check what well
established libraries such as ICU do.

Cheers,