[cl-dwim-devel] cl-dwim questions

[Kambiz Darabi]

Hello,

Attila Lendvai <attila.lendvai at gmail.com> wrote:
> 
> hello Rommel,
>
> (i cc the list because it contains some useful info. others reading
> this should ignore the stuff related to ebr42...)
>
>> * What is the most natural and/or ideal way to start up cl-dwim? Is
>>  there more than one way of starting up cl-dwim?
>
>
> [...]
> ebr42-nafi and ebr42-honti are basically two applications running from
> the same repository. they are very similar apps for two ministries
> sharing much of the code.

when I started to look into dwim, I tried to start the different
applications, eseho was the easiest, so I went with that one.

>> * Istm, that there some stuff are hardcoded in cl-dwim's source files
>>  that is somehow related to your environment (for example,
>>  dwim-system:*developer-machine-names*). Are such things in the code
>>  negligible if one wants to run cl-dwim outside your environment or
>>  some modifications must be made to the code (Kambiz?)
>
>
> we have a repo called "environment" under cl-dwim, but it's mostly
> unrelated and can be ignored.
>
> dwim-system:*developer-machine-names* is used for various decisions,
> mostly the ones that help debugging/developing when started on our own
> machines (e.g. fake login buttons, even when running in test mode, are
> only shown on dev machines).

I manage a set of patches with mercurial queues on top of the cl-dwim
repository and I have checked out most of the dependencies from their
respective scm repositories.

I could make the patches available to you, if you are interested. They
contain indeed changes to *developer-machine-names*, additionally,
some changes to the emacs startup files (init.el in environment), a
dojo distribution, the cldr files for cl-l10n, etc.

>> * Since there are no formal documentation written for cl-dwim (afaik),
>>  can you give me some pointers on how to proceed next or if I ever
>>  have questions like these, so I can try to figure out things myself
>>  before asking questions.
>
> the ideal solution would be an application that can be started up and
> played with. unfortunately ebr42 is not a good candidate, because it's
> big'n'convoluted, and contains stuff that is kinda private.

Yes, I would recommend testing with an app.

> Kami, can you maybe help in this regard? how secret is your project,
> could it be shared as a less convoluted example maybe?

I cannot publish the customer project itself, but I could publish a
simplified eseho, which serves us as a test bed to try out different
things.

It would be very helpful, Attila, if you could enable the trac hosting
for cl-dwim on common-lisp.net. With trac in place, we could start
writing down our insights, and gather and share some information to
lower the barrier for the next people interested in dwim.


Bye


Kambiz