couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Somov <trophyb...@googlemail.com>
Subject Re: Development environment
Date Fri, 29 Apr 2011 13:36:03 GMT
Hello Robert,
this is much closer to what I expect.
I assume I should follow the procedure described here
http://mail-archives.apache.org/mod_mbox/couchdb-dev/200811.mbox/%3CC397E43F-096F-4892-9519-383032622FCD@dionne-associates.com%3E

I will give it a try.
Thank you very much.
-
Andrey

P.S. I have already identified some redundant code (
https://issues.apache.org/jira/browse/COUCHDB-920).
I hope I can further improve the code base when I am able to debug the
running database.



On Fri, Apr 29, 2011 at 1:34 PM, Robert Dionne <dionne@dionne-associates.com
> wrote:

> Hi Andrey,
>
>  I use Distel[1] (Distributed emacs lisp for Erlang), a set of emacs
> extensions that create a full development environment for Erlang. It
> connects to a running node so one gets full access to the syntax_tools and
> source code of Erlang, all at run time. As this brief white paper points out
> it goes further than typical elisp hacks as it imports the Erlang
> distributed model into emacs. I keep hoping to find some time to push it a
> little further and provide better support for working with BigCouch, our
> clustered CouchDB at Cloudant.
>
>  I keep up my own fork of it as there aren't too many of us out there and I
> needed to fix a few things. I also include in that project some tweaks to
> the Erlang mode that ships with Erlang to accommodate the CouchDB format
> conventions. It provides a full symbolic debugging environment. Though it's
> useful and I think I've found a few CouchDB bugs with it, given the nature
> of OTP programming it's a little harder when you have breakpoints that hit
> 50 processes. It was great for stepping thru the btree code.
>
>  The most useful features are the navigation (M-. M-,) and who_calls (C-c
> C-d w) The lack of use of who_calls I believe is the major reason we often
> discover dead code that's been there forever. As an aside the use of type
> specs and dialyzer go a long way towards finding errors at compile time.
>
> Regards,
>
> Bob
>
> [1] https://github.com/bdionne/distel/raw/master/doc/gorrie02distel.pdf
> [2] https://github.com/bdionne/distel
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message