distel-hackers — Mailing list for all things Distel

Re: [Distel-hackers] erl-complete ...

[Bill C. <bil...@gm...>]

Matthias Radestock <mat...@so...> writes:

> Pierre Radermecker wrote:
>> I am wondering why some completions do not seem to work. For instance "math:"
>> only gives pi(). None of the functions in the erlang module seems to
>> complete(list_to, is_, ...)
>
> This is not distel's fault. There is something odd about these modules; 
> xref cannot see much in them either:
>
> (x@h)2> xref:start(foo, {xref_mode, modules}).
> {ok,<0.158.0>}
> (x@h)3> xref:add_release(foo, code:lib_dir(), {name, otp}).
> ok
> (x@h)4> xref:q(foo, 'X * math:_/_').
> {ok,[{math,pi,0}]}
> (x@h)6> xref:q(foo, 'X * erlang:"list_to.*"/_').
> {ok,[{erlang,list_to_integer,2}]}
> (x@h)7> xref:q(foo, 'X * erlang:"is_.*"/_').
> {ok,[]}

Probably because they're BIF's that are implemented in C rather than
Erlang:

(emacs@bc)7> erl_bifs:is_bif(math, pi, 0).
false
(emacs@bc)8> erl_bifs:is_bif(math, sin, 1).
true

Do a "M-." on "math:pi()" and you'll see that it's the only function
in the source file.

- Bill

Re: [Distel-hackers] erl-complete ...

[Matthias R. <mat...@so...>]

Pierre Radermecker wrote:
> I am wondering why some completions do not seem to work. For instance "math:"
> only gives pi(). None of the functions in the erlang module seems to
> complete(list_to, is_, ...)

This is not distel's fault. There is something odd about these modules; 
xref cannot see much in them either:

(x@h)2> xref:start(foo, {xref_mode, modules}).
{ok,<0.158.0>}
(x@h)3> xref:add_release(foo, code:lib_dir(), {name, otp}).
ok
(x@h)4> xref:q(foo, 'X * math:_/_').
{ok,[{math,pi,0}]}
(x@h)6> xref:q(foo, 'X * erlang:"list_to.*"/_').
{ok,[{erlang,list_to_integer,2}]}
(x@h)7> xref:q(foo, 'X * erlang:"is_.*"/_').
{ok,[]}


Matthias.

[Distel-hackers] erl-complete ...

[Pierre R. <pra...@ya...>]

I am wondering why some completions do not seem to work. For instance "math:"
only gives pi(). None of the functions in the erlang module seems to
complete(list_to, is_, ...)

The way completion works is really weak (the *Completion buffer do not close
automatically). Is there someone interested in improving the feature ?

I will try to compare the el completion code with Slime if nobody else out is
willing to do it (I have no knowledge of el). Are there obvious reasons why it
is difficult to backport ?

Thanks for your help.

Re: [Distel-hackers] svn repository ebin dir

[Pierre R. <pra...@ya...>]

Pierre Radermecker <pradermecker <at> yahoo.ca> writes:

> 
> If I do a fresh check out with
> 
> svn checkout http://distel.googlecode.com/svn/trunk/ distel
> 
> I get an empty ebin directory ?!
> 
Sorry I forgot I had to do a make again ...

[Distel-hackers] svn repository ebin dir

[Pierre R. <pra...@ya...>]

If I do a fresh check out with

svn checkout http://distel.googlecode.com/svn/trunk/ distel

I get an empty ebin directory ?!

Re: [Distel-hackers] distel and emacs unicode-2 (again)

[James C. <jam...@gm...>]

Matthew D Swank <akopa.gmane.poster <at> gmail.com> writes:

> 
> I am still at a loss as to what is wrong when I try to use distel in emacs
> 23.x.  Could someone *please* give me some feed-back on what might be
> wrong.
> 
> Here is a typical trace from running a command that needs to connect to a
> node (in this case erl-process-list):
> 
> Debugger entered--Lisp error: (error "lucretia/-29892 Servname not supported 
for ai_socktype")

I'm having pretty much the same problem:  Looking around suggests that the 
problem is that there is not an entry in /etc/services (http://www.ducea.com/
2006/09/11/error-servname-not-supported-for-ai_socktype/ has a similar problem, 
but for something else).  So, if someone can figure out what service name to 
use, it should work...

James

Re: [Distel-hackers] Patch for empty buffer while debbuging

[mats c. <mat...@er...>]

On Fri, 2007-09-07 at 15:55 -0700, Bill Clementson wrote:
> Dimitris Dinodimos <di...@gm...> writes:
> 
> > Distel is displaying an empty buffer. Everything else is fine. I can
> > see the variables or I can press "c" to continue blindly.
> > The attached  patch solved the problem for me.
> 
> mats - could you see whether this patch fixes the problem for you?

  found the bug. turned out the buggy bit was written by none other than
myself :< divine justice and all that.

  it didn't occur to me that M:module_info() will behave differently
depending on whether M is interpreted or not.
   i had also assumed that filelib:wildcard("") -> [], which also turned
out to be wrong (it exits).

  i'm testing the fix now, will commit later today.

  mats

Re: [Distel-hackers] Patch for empty buffer while debbuging

[Bill C. <bil...@gm...>]

Dimitris Dinodimos <di...@gm...> writes:

> Distel is displaying an empty buffer. Everything else is fine. I can
> see the variables or I can press "c" to continue blindly.
> The attached  patch solved the problem for me.

mats - could you see whether this patch fixes the problem for you?

- Bill

[Distel-hackers] Patch for empty buffer while debbuging

[Dimitris D. <di...@gm...>]

Distel is displaying an empty buffer. Everything else is fine. I can  
see the variables or I can press "c" to continue blindly.
The attached  patch solved the problem for me.

Re: [Distel-hackers] [Fwd: empty edbproc buffer]

[Matthias R. <mat...@so...>]

mats cronqvist wrote:
>   i just ran into the problem described by some guy named vish on
> erlang-questions;
> 
> "I start a debug session with C-c C-d i and set a breakpoint C-x SPC. 
> And when I run the function in the shell, the debug process list 
> window pops up. I type return on the correct process and a debugger 
> buffer pops up. As far as I understand it to work, it should show the 
> program in a read-only buffer: with the state of execution & 
> breakpoints, and with variables at the bottom of the window. However I 
> get a blank buffer: all the commands (n, SPC, q, h, etc.) seem to work 
> fine though. I'm not sure if it's because I misunderstood how it's 
> supposed to work, so here's a screenshot: 
> 
> http://vish.in/temp/emacs-debug.png "
> 
>   i see the same thing, but seemingly only on my solaris/emacs22
> machine.
>   could there be a problem with emacs22? 

I observed the same behaviour the other day on xemacs 21.4.20 on debian 
x86. This worked fine before on the same platform, but I have updated 
xemacs, distel and many of the debian packages since then. Chances are 
the problem lies with one of the three.

The easiest to rule in/out is distel. Mats, are you running the exact 
same version of distel on both your installations?


Matthias.

Re: [Distel-hackers] [Fwd: empty edbproc buffer]

[Bill C. <bil...@gm...>]

Hi Mats,

mats cronqvist <mat...@er...> writes:

>   i just ran into the problem described by some guy named vish on
> erlang-questions;
>
> "I start a debug session with C-c C-d i and set a breakpoint C-x SPC. 
> And when I run the function in the shell, the debug process list 
> window pops up. I type return on the correct process and a debugger 
> buffer pops up. As far as I understand it to work, it should show the 
> program in a read-only buffer: with the state of execution & 
> breakpoints, and with variables at the bottom of the window. However I 
> get a blank buffer: all the commands (n, SPC, q, h, etc.) seem to work 
> fine though. I'm not sure if it's because I misunderstood how it's 
> supposed to work, so here's a screenshot: 
>
> http://vish.in/temp/emacs-debug.png "

I replied to Vishnu on the erlang-questions list; however, he sent his
replies to me via email. In short, this is what I asked him to try and
what he replied:

1. Since he was using Aquamacs Emacs, I initially thought it was a
problem related to Aquamacs (which, by default, pops up a new frame
for every buffer). I told him how to disable this; however, he
continued to get the same distel problem.

2. I asked him if he had his source files in a different location from
the .beam files. Distel looks in certain standard places; however, I
thought there might be a problem with either old .beam files or
source/beam files not being in sync or source/beam not being in
standard locations. I didn't hear back from him after this, so I don't
know whether that was the problem or not. So, for the erlang file that
you are debugging, was it recently compiled and is it in either the
same directory as the source or in the standard ebin/src directories?

>   i see the same thing, but seemingly only on my solaris/emacs22
> machine.
>   could there be a problem with emacs22? 

I'm using emacs22 and I don't have any problems. I'll send Vishnu an
email and see whether he found out what his problem was.

- Bill

[Distel-hackers] [Fwd: empty edbproc buffer]

[mats c. <mat...@er...>]

  i just ran into the problem described by some guy named vish on
erlang-questions;

"I start a debug session with C-c C-d i and set a breakpoint C-x SPC. 
And when I run the function in the shell, the debug process list 
window pops up. I type return on the correct process and a debugger 
buffer pops up. As far as I understand it to work, it should show the 
program in a read-only buffer: with the state of execution & 
breakpoints, and with variables at the bottom of the window. However I 
get a blank buffer: all the commands (n, SPC, q, h, etc.) seem to work 
fine though. I'm not sure if it's because I misunderstood how it's 
supposed to work, so here's a screenshot: 

http://vish.in/temp/emacs-debug.png "

  i see the same thing, but seemingly only on my solaris/emacs22
machine.
  could there be a problem with emacs22? 

  mats

Re: [Distel-hackers] who_calls rewrite

[<to...@to...>]

Matthias Radestock wrote:
> Tobbe,
>
> Torbjorn Tornkvist wrote:
>> it seems like when there are a large amount of callers
>> I get nothing displayed!?
>
> That's strange.
>
> Two questions:
>
> 1) can you give me an example so I can try reproducing this?
I'm afraid not, since it the code isn't open source.
Hm...but now when I tried it again, it seems to work...
So I take back my earlier statement.
It is now just excellent :-)

Cheers, Tobbe

Re: [Distel-hackers] who_calls rewrite

[Bill C. <bil...@gm...>]

Hi Matthias,

Matthias Radestock <mat...@so...> writes:

> Bill Clementson wrote:
>>> There is a comment in the code saying "FIXME: Use line number for a
>>> hyperlink.". I reckon one way to implement something sensible along
>>> these lines is to construct an, in Emacs-lingo, "overlay" for the
>>> displayed m:f/a with the line number information. 
>>
>> I thought that "overlays" were more for display properties and that
>> "text-properties" would be what you would want to use for storing the
>> line# and source file of any matches.
>
> If you say so. I am not an emacs hacker.
>
>> Are you suggesting that "M-." be used to go to the "call"? Normally,
>> "M-." is used to go to the definition, not a reference. Why not just
>> use "RET"? You could have a separate RET key binding for the who-calls
>> results buffer.
>
> That would be better indeed. It still has to do much of the same work
> as "M-.", so I was just trying to cut some corners.
>
> Any chance you could have a go at implementing this?

Not in the short term. I've taken a bit of a break from Erlang due to
other commitments. It shouldn't be a difficult hack though, so maybe
someone else would like to take it on?

- Bill

Re: [Distel-hackers] who_calls rewrite

[Matthias R. <mat...@so...>]

Tobbe,

Torbjorn Tornkvist wrote:
> it seems like when there are a large amount of callers
> I get nothing displayed!?

That's strange.

Two questions:

1) can you give me an example so I can try reproducing this?

2) what is the behaviour of the previous version?


Matthias.

Re: [Distel-hackers] who_calls rewrite

[Matthias R. <mat...@so...>]

Bill Clementson wrote:
>> There is a comment in the code saying "FIXME: Use line number for a
>> hyperlink.". I reckon one way to implement something sensible along
>> these lines is to construct an, in Emacs-lingo, "overlay" for the
>> displayed m:f/a with the line number information. 
> 
> I thought that "overlays" were more for display properties and that
> "text-properties" would be what you would want to use for storing the
> line# and source file of any matches.

If you say so. I am not an emacs hacker.

> Are you suggesting that "M-." be used to go to the "call"? Normally,
> "M-." is used to go to the definition, not a reference. Why not just
> use "RET"? You could have a separate RET key binding for the who-calls
> results buffer.

That would be better indeed. It still has to do much of the same work as 
"M-.", so I was just trying to cut some corners.

Any chance you could have a go at implementing this?


Matthias.

Re: [Distel-hackers] who_calls rewrite

[Torbjorn T. <to...@to...>]

Matthias Radestock wrote:
> Hi,
> 
> I found distel's "who calls" (C-c C-d w) feature rather cumbersome to
> use. It takes ages to start the first time and then doesn't update when
> the code changes. Plus the code for it is quite horrible and brittle.
> 
> So I replaced all ~250 lines of it with a single call to xref:q/2. See
> the attached patch.
> 
> Invoking "who calls" for the first time still takes a while, but less
> than previously. And code changes are tracked properly.

Excellent!

However, it seems like when there are a large amount of callers
I get nothing displayed!?

Cheers, Tobbe

Re: [Distel-hackers] who_calls rewrite

[Bill C. <bil...@gm...>]

Hi Matthias,

Matthias Radestock <mat...@so...> writes:
> Bill Clementson wrote:
>
>> Very nice. This is much faster and (with my limited testing) seems to
>> produce the same results. I've committed your patch.
>
> Cheers.
>
> On a related note, who_calls actually returns the line number of the
> call sites but this currently isn't displayed/used. This was the case
> in the previous version too.
>
> There is a comment in the code saying "FIXME: Use line number for a
> hyperlink.". I reckon one way to implement something sensible along
> these lines is to construct an, in Emacs-lingo, "overlay" for the
> displayed m:f/a with the line number information. 

I thought that "overlays" were more for display properties and that
"text-properties" would be what you would want to use for storing the
line# and source file of any matches.

> We can then look for
> this invisible piece of information in "M-." (aka
> erl-find-source-under-point) and, if present, navigate to it.
>
> Any other suggestions?

Are you suggesting that "M-." be used to go to the "call"? Normally,
"M-." is used to go to the definition, not a reference. Why not just
use "RET"? You could have a separate RET key binding for the who-calls
results buffer.

- Bill

Re: [Distel-hackers] who_calls rewrite

[Bill C. <bil...@gm...>]

Hi Matthias,

Matthias Radestock <mat...@so...> writes:
> Bill Clementson wrote:
>
>> Very nice. This is much faster and (with my limited testing) seems to
>> produce the same results. I've committed your patch.
>
> Cheers.
>
> On a related note, who_calls actually returns the line number of the
> call sites but this currently isn't displayed/used. This was the case
> in the previous version too.
>
> There is a comment in the code saying "FIXME: Use line number for a
> hyperlink.". I reckon one way to implement something sensible along
> these lines is to construct an, in Emacs-lingo, "overlay" for the
> displayed m:f/a with the line number information. 

I thought that "overlays" were more for display properties and that
"text-properties" would be what you would want to use for storing the
line# and source file of any matches.

> We can then look for
> this invisible piece of information in "M-." (aka
> erl-find-source-under-point) and, if present, navigate to it.
>
> Any other suggestions?

Are you suggesting that "M-." be used to go to the "call"? Normally,
"M-." is used to go to the definition, not a reference. Why not just
use "RET"? You could have a separate RET key binding for the who-calls
results buffer.

- Bill

Re: [Distel-hackers] who_calls rewrite

[Matthias R. <mat...@so...>]

Bill,

Bill Clementson wrote:

> Very nice. This is much faster and (with my limited testing) seems to
> produce the same results. I've committed your patch.

Cheers.

On a related note, who_calls actually returns the line number of the 
call sites but this currently isn't displayed/used. This was the case in 
the previous version too.

There is a comment in the code saying "FIXME: Use line number for a 
hyperlink.". I reckon one way to implement something sensible along 
these lines is to construct an, in Emacs-lingo, "overlay" for the 
displayed m:f/a with the line number information. We can then look for 
this invisible piece of information in "M-." (aka 
erl-find-source-under-point) and, if present, navigate to it.

Any other suggestions?


Matthias.

Re: [Distel-hackers] Emacs completion improvement

[Bill C. <bil...@gm...>]

Pierre Radermecker <pra...@ya...> writes:

>> Yes, SLIME-like completion would definitely be a nice enhancement for
>> distel. It wasn't clear from your post whether this was something you
>> were working on or just a suggested enhancement.
>
> I am not working on it ... I could consider trying to improve the way completion
> work in Distel but first I'd like to be sure it is indeed a good idea ... I have
> no real knowledge of elisp so it could take me a while to figure it out.
>
> Maybe this kind of improvement has been considered before ? Maybe there are good
> reasons why it is so basic ... 
>
> Because Luke wrote both Slime and Distel, I was wondering why it doesn't work in
> Distel the way it works in Slime ...

There are multiple completion mechanisms in SLIME and Luke didn't
write them all. I presume he was either happy with the way completion
worked in distel or was waiting for a volunteer who would do something
about it. ;-)

- Bill

Re: [Distel-hackers] who_calls rewrite

[Bill C. <bil...@gm...>]

Hi Matthias,

Matthias Radestock <mat...@so...> writes:

> I found distel's "who calls" (C-c C-d w) feature rather cumbersome to
> use. It takes ages to start the first time and then doesn't update when
> the code changes. Plus the code for it is quite horrible and brittle.
>
> So I replaced all ~250 lines of it with a single call to xref:q/2. See
> the attached patch.
>
> Invoking "who calls" for the first time still takes a while, but less
> than previously. And code changes are tracked properly.

Very nice. This is much faster and (with my limited testing) seems to
produce the same results. I've committed your patch.

- Bill

Re: [Distel-hackers] Emacs completion improvement

[mats c. <mat...@er...>]

On Fri, 2007-08-31 at 23:41 +0000, Pierre Radermecker wrote:
> On completion, Distel opens up a *Completions* buffer. 
...
> I would love to have something a bit more intuitive. Something along the line
> with the Predictive Emacs extension (or other editors such as IntelliJ,
> Netbeans, Eclipse, ...), a kind of tooltip completion of some sort.

  there is a very nice tool http://esense.sourceforge.net that does
this. distel and esense together is the shit.

  mats

Re: [Distel-hackers] Emacs completion improvement

[Pierre R. <pra...@ya...>]

Yep while reading previous posts, I understood that Luke doesn't maintain Distel
anymore.

Would be nice if Distel could benefit from Slime improvements ... Is the fact
that Distel populates only the *Completions* buffer (without activating the
mini-buffer for instance) a kind of misbehavior ? 

In Emacs in general the *Completions* buffer is supposed to work in conjunction
with the mini-buffer, isn't ?

Re: [Distel-hackers] Emacs completion improvement

[Pierre R. <pra...@ya...>]

> Yes, SLIME-like completion would definitely be a nice enhancement for
> distel. It wasn't clear from your post whether this was something you
> were working on or just a suggested enhancement.

I am not working on it ... I could consider trying to improve the way completion
work in Distel but first I'd like to be sure it is indeed a good idea ... I have
no real knowledge of elisp so it could take me a while to figure it out.

Maybe this kind of improvement has been considered before ? Maybe there are good
reasons why it is so basic ... 

Because Luke wrote both Slime and Distel, I was wondering why it doesn't work in
Distel the way it works in Slime ...