Hey everyone,
New project on Comon-Lisp.net: http://common-lisp.net/project/clkd/
This is something I slapped together for efficiently memorizing the
meanings of kanji, as given in Jim Breen's kanjidic.
It's helped me memorize some 1200 characters so far.
"Kaz Kylheku" <········@gmail.com> writes:
> New project on Comon-Lisp.net: http://common-lisp.net/project/clkd/
Looks very interesting! Do you know of any dictionaries I can use with
it mapping hanzi to pinyin (not english)?
BTW, the configure script and Makefile were a bit of a pain, didn't
detect lndir, got confused with my ASDF setup and pretty much forced
CLISP on me. Why didn't you use plain ASDF?
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
On Mar 11, 3:28 pm, ·············@deadspam.com (Luís Oliveira) wrote:
> "Kaz Kylheku" <········@gmail.com> writes:
> > New project on Comon-Lisp.net:http://common-lisp.net/project/clkd/
>
> Looks very interesting! Do you know of any dictionaries I can use with
> it mapping hanzi to pinyin (not english)?
Kanjidic contains Cantonese and Mandarin readings. These are currently
not extracted when the lispified forms of the dictionary are produced.
Since this project has shiny new mailing list, it would be good to
take up this discussion there. :)
> BTW, the configure script and Makefile were a bit of a pain, didn't
> detect lndir, got confused with my ASDF setup and pretty much forced
> CLISP on me.
CLISP is the platform for this program. The other issues are just
pains of a first, admittedly alpha-ish release.
> Why didn't you use plain ASDF?
I need a hacked ASDF because of some bugs that had to be fixed.
ASDF, by itself, isn't a build and installation tool that you can use
to deploy software to people other than Lisp programmers.
It just handles the compiling and incremental rebuilds during
development.
One reason for having a standard configure script which produces a
Makefile is to conform to expectations, but another reason is that
this provides capabilities which are just not there otherwise. Custom
build steps that are expressed more easily as shell commands, plus
copying files, etc.
Incidentally, lndir wouldn't be needed if ASDF could handle the
separation of build and source directories. If I can hack that in, I
can get rid of lndir completely.
On Mar 12, 3:06 pm, "Kaz Kylheku" <········@gmail.com> wrote:
> On Mar 11, 3:28 pm, ·············@deadspam.com (Luís Oliveira) wrote:
>
> > "Kaz Kylheku" <········@gmail.com> writes:
> > > New project on Comon-Lisp.net:http://common-lisp.net/project/clkd/
>
> > Looks very interesting! Do you know of any dictionaries I can use with
> > it mapping hanzi to pinyin (not english)?
>
> Kanjidic contains Cantonese and Mandarin readings. These are currently
> not extracted when the lispified forms of the dictionary are produced.
>
> Since this project has shiny new mailing list, it would be good to
> take up this discussion there. :)
>
> > BTW, the configure script and Makefile were a bit of a pain, didn't
> > detect lndir, got confused with my ASDF setup and pretty much forced
> > CLISP on me.
>
> CLISP is the platform for this program. The other issues are just
> pains of a first, admittedly alpha-ish release.
>
> > Why didn't you use plain ASDF?
>
> I need a hacked ASDF because of some bugs that had to be fixed.
>
> ASDF, by itself, isn't a build and installation tool that you can use
> to deploy software to people other than Lisp programmers.
>
> It just handles the compiling and incremental rebuilds during
> development.
>
> One reason for having a standard configure script which produces a
> Makefile is to conform to expectations, but another reason is that
> this provides capabilities which are just not there otherwise. Custom
> build steps that are expressed more easily as shell commands, plus
> copying files, etc.
>
> Incidentally, lndir wouldn't be needed if ASDF could handle the
> separation of build and source directories. If I can hack that in, I
> can get rid of lndir completely.
btw. mapping of hanzi to pinyin, Cantonese, Korean, Japanese can be
easily done with unihan database http://unicode.org/charts/unihan.html
On Mar 11, 11:06 pm, "Kaz Kylheku" <········@gmail.com> wrote:
> On Mar 11, 3:28 pm, ·············@deadspam.com (Luís Oliveira) wrote:
> > Why didn't you use plain ASDF?
>
> I need a hacked ASDF because of some bugs that had to be fixed.
[ snip ]
> Incidentally, lndir wouldn't be needed if ASDF could handle the
> separation of build and source directories. If I can hack that in, I
> can get rid of lndir completely.
Done. My hacked ASDF can now build the tree of fasl's in a separate
build directory. Bye-bye lndir.
From: Richard M Kreuter
Subject: Re: New project: Kanji-learning program.
Date:
Message-ID: <87veh5xapm.fsf@progn.net>
"Kaz Kylheku" <········@gmail.com> writes:
> On Mar 11, 11:06 pm, "Kaz Kylheku" <········@gmail.com> wrote:
>> On Mar 11, 3:28 pm, ·············@deadspam.com (Luís Oliveira) wrote:
>> > Why didn't you use plain ASDF?
>>
>> I need a hacked ASDF because of some bugs that had to be fixed.
>
> [ snip ]
>
>> Incidentally, lndir wouldn't be needed if ASDF could handle the
>> separation of build and source directories. If I can hack that in, I
>> can get rid of lndir completely.
>
> Done. My hacked ASDF can now build the tree of fasl's in a separate
> build directory. Bye-bye lndir.
The design of asdf leaves it to the user where operations' output
files for should go, rather than being a property of the system; a
system definition is not a Makefile. Users who want this control can
add an :AROUND method on OUTPUT-FILES, or use asdf-binary-locations
(which provides such an :AROUND method), or, if their implementations'
logical pathnames are up to snuff, use logical pathname translations
to control where output files go (mostly; a few systems have files
whose names aren't syntactically valid LPN components).
However, if you really want your system not to follow asdf's
customization protocol, you still don't need to fork asdf.lisp: you
can add a mixin class, have your systems' components be generalized
instances of that mixin, and add an :AROUND method on OUTPUT-FILES
that specializes on the mixin.
If you are determined to fork asdf, it would be better for everybody
if you removed the name "asdf" from every aspect of your fork. I see
you've changed the package name in the file to ZXCV; could you also
change the file's name, and the module name in the call to PROVIDE at
the end?
FWIW, I agree that asdf's default OUTPUT-FILES method is almost
maximally bad, given the possibilities in the design space. But at
least asdf lets you fix it relatively cleanly.
--
RmK
> > BTW, the configure script and Makefile were a bit of a pain, didn't
> > detect lndir, got confused with my ASDF setup and pretty much forced
> > CLISP on me.
>
> CLISP is the platform for this program. The other issues are just
> pains of a first, admittedly alpha-ish release.
I second the adverse opinion about configure/Makefile. I made it work
on Windows, without having cygwin, and it would be much easier to do
so if I did not have to extract how to generate auxiliary files from
Makefile to a lisp file. And I see little point in configure script
for lisp stuff like this, especially if Windows are between target
platforms.
> > Why didn't you use plain ASDF?
>
> I need a hacked ASDF because of some bugs that had to be fixed.
I had to fix in
(defmethod component-pathname ((component component))
the false branch of aif from implicit nil to '(:relative) anyway -
otherwise the directory is not correct.
>
> ASDF, by itself, isn't a build and installation tool that you can use
> to deploy software to people other than Lisp programmers.
I think best way to deploy stuff like that to non-lisp programmers is
compiled to executable and packaged with necessary data files in final
form. Just my opinion.
Yes, I like the package - otherwise I would not bother with making it
work and commenting on it :)
Regards,
Tomas Zellerin