distel-hackers — Mailing list for all things Distel

Re: [Distel-hackers] Patch for emacs-unicode-2

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

Hi guys,

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

> Thank you Matthias. Is the revised patch compatible with xemacs?
>
> O/H Matthias Radestock έγραψε:
>>
>> Unfortunately these functions are Gnu Emacs specific, so your patch
>> would break XEmacs compatibility.
>>
>> Regards,
>>
>> Matthias

I haven't seen any followups from anyone on the list. This patch would
appear to address the Emacs 23 (unicode branch) issues that have
cropped up in various posts to the list in the past:

http://sourceforge.net/mailarchive/forum.php?thread_name=pan.2007.06.03.15.58.55.157254%40gmail.com&forum_name=distel-hackers
http://sourceforge.net/mailarchive/forum.php?thread_name=45FC4033.8070800%40charter.net&forum_name=distel-hackers

Unfortunately, I don't have a copy of Emacs 23 to test this
on. Matthias, could you confirm that the patch doesn't cause any
problems on XEmacs? Also, could some of the earlier Emacs 23 posters
indicate whether this patch fixes the problems they had been
experiencing? If so, I'll commit this patch.

Thanks,
Bill

Re: [Distel-hackers] Patch for emacs-unicode-2

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

Thank you Matthias. Is the revised patch compatible with xemacs?

O/H Matthias Radestock έγραψε:
> 
> Unfortunately these functions are Gnu Emacs specific, so your patch 
> would break XEmacs compatibility.
> 
> Regards,
> 
> Matthias
> 

Re: [Distel-hackers] Patch for emacs-unicode-2

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

Dimitris,

Dimitris Dinodimos wrote:
> The problem with the emacs-unicode-2 branch is the decoding of the
> socket output.
> 
> The solution is documented in "decoding process output" in elisp
> reference manual.
> http://www.gnu.org/software/emacs/elisp/html_node/Decoding-Output.html

Unfortunately these functions are Gnu Emacs specific, so your patch 
would break XEmacs compatibility.

Regards,

Matthias

[Distel-hackers] Patch for emacs-unicode-2

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

The problem with the emacs-unicode-2 branch is the decoding of the
socket output.

The solution is documented in "decoding process output" in elisp
reference manual.
http://www.gnu.org/software/emacs/elisp/html_node/Decoding-Output.html

I hope this helps.

Dimitris

Re: [Distel-hackers] =?utf-8?q?*Completions*_buffer_does_not_closed?= =?utf-8?q?=09automatically?=

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

Hi Pierre,

Pierre Radermecker <pra...@ya...> writes:
>> I think I see what's happening. I normally only have one buffer
>> visible in the Emacs frame, so when I hit M-TAB I always get the
>> completions buffer shown. You must be displaying 2 buffers in an Emacs
>> frame. When I do that, I get the results that you do. Does the
>> attached patch fix the problem for you?
>
> yes, it does. Thanks so much. It is so much better not to have to use the mouse.

Ok, I've committed the change.

>> Neat! Yes, I'll be at OOPSLA, but only on Monday (the DLS sessions and
>> the MSLUG meeting) and a couple of OOPSLA sessions on Tueesday. Will
>> you be at DLS or MSLUG? 
>> 
>
> I should attend the DSL on Monday and the 50/50 conference on Tuesday. Look
> forward to meeting you there.

Great, I'll see you at the DSL then.

-Bill

Re: [Distel-hackers] =?utf-8?q?*Completions*_buffer_does_not_closed?= =?utf-8?q?=09automatically?=

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

> I think I see what's happening. I normally only have one buffer
> visible in the Emacs frame, so when I hit M-TAB I always get the
> completions buffer shown. You must be displaying 2 buffers in an Emacs
> frame. When I do that, I get the results that you do. Does the
> attached patch fix the problem for you?

yes, it does. Thanks so much. It is so much better not to have to use the mouse.


> Neat! Yes, I'll be at OOPSLA, but only on Monday (the DLS sessions and
> the MSLUG meeting) and a couple of OOPSLA sessions on Tueesday. Will
> you be at DLS or MSLUG? 
> 

I should attend the DSL on Monday and the 50/50 conference on Tuesday. Look
forward to meeting you there.

Re: [Distel-hackers] =?utf-8?q?*Completions*_buffer_does_not_closed?= =?utf-8?q?=09automatically?=

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

Hi Pierre,

Pierre Radermecker <pra...@ya...> writes:
>> I believe that distel's completion buffer behaves in a similar manner
>> to "normal" completion (at least it appears to work the same way for
>> me). If you're seeing something different, perhaps you could list the
>> specific steps you take to replicate the behaviour.
>
> Here are the steps with Distel:
>
> 1) type "io:f" in the buffer and press alt-tab:
> *Completions* buffer open
> 2) go on typing "orm" in the buffer and press alt-tab:
> Automatic completion in the buffer, the *Completions* window stays open.
>
> Here are the steps in the *Scratch* buffer
> 1) type (gl and press alt-tab:
> *Completions* buffer open
> 2) go on typing "obal-k" in the buffer and press alt-tab:
> Automatic completion in the buffer, *Completions* buffer automatically close.
>
> Do you have a similar behavior ?

I think I see what's happening. I normally only have one buffer
visible in the Emacs frame, so when I hit M-TAB I always get the
completions buffer shown. You must be displaying 2 buffers in an Emacs
frame. When I do that, I get the results that you do. Does the
attached patch fix the problem for you?

> Thanks for your help (maybe we will meet at OOPSLA in Montréal)

Neat! Yes, I'll be at OOPSLA, but only on Monday (the DLS sessions and
the MSLUG meeting) and a couple of OOPSLA sessions on Tueesday. Will
you be at DLS or MSLUG? 

- Bill

Patch:
Index: elisp/erl-service.el
===================================================================
--- elisp/erl-service.el        (revision 42)
+++ elisp/erl-service.el        (working copy)
@@ -827,6 +827,8 @@
 (defun erl-complete (node)
   "Complete the module or remote function name at point."
   (interactive (list (erl-target-node)))
+  (let ((win (get-buffer-window "*Completions*" 0)))
+    (if win (with-selected-window win (bury-buffer))))
   (let ((end (point))
   (beg (ignore-errors 
          (save-excursion (backward-sexp 1)

Re: [Distel-hackers] =?utf-8?q?*Completions*_buffer_does_not_closed?= =?utf-8?q?=09automatically?=

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

> I believe that distel's completion buffer behaves in a similar manner
> to "normal" completion (at least it appears to work the same way for
> me). If you're seeing something different, perhaps you could list the
> specific steps you take to replicate the behaviour.

Here are the steps with Distel:

1) type "io:f" in the buffer and press alt-tab:
*Completions* buffer open
2) go on typing "orm" in the buffer and press alt-tab:
Automatic completion in the buffer, the *Completions* window stays open.

Here are the steps in the *Scratch* buffer
1) type (gl and press alt-tab:
*Completions* buffer open
2) go on typing "obal-k" in the buffer and press alt-tab:
Automatic completion in the buffer, *Completions* buffer automatically close.

Do you have a similar behavior ?

Thanks for your help (maybe we will meet at OOPSLA in Montréal)

Re: [Distel-hackers] *Completions* buffer does not closed automatically

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

Hi Pierre,

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

> The *Completions* buffer does not seem to close automatically after completion.
> It seems to be a specific distel problem on my setting. For instance, the
> *Completions* buffer closes normally in a plain lisp mode (after multiple
> alt-tab in the *Scratch* buffer).
>
> Is it a known problem or it is something specific to my setting ?

I believe that distel's completion buffer behaves in a similar manner
to "normal" completion (at least it appears to work the same way for
me). If you're seeing something different, perhaps you could list the
specific steps you take to replicate the behaviour.

- Bill

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

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

Hi Pierre,

Pierre Radermecker <pra...@ya...> writes:
>> I've applied your patch (as well as the mod you sent in your later
>> message) and have committed the changes.
>> 
>
> Thanks for the fix !
>
> Would be nice to have completion for the erlang BIF that don't require the
> module prefix (like is_tuple(Term))
>
> Is it in the to-do list ;-)

It wasn't in my to-do list - is it in yours? ;-)

I'm not sure if there's any way of determining what all of the
available BIF's are at runtime. Do you know of any way to do this?

- Bill

[Distel-hackers] *Completions* buffer does not closed automatically

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

The *Completions* buffer does not seem to close automatically after completion.
It seems to be a specific distel problem on my setting. For instance, the
*Completions* buffer closes normally in a plain lisp mode (after multiple
alt-tab in the *Scratch* buffer).

Is it a known problem or it is something specific to my setting ?

Thanks for your help.

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

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

> 
> I've applied your patch (as well as the mod you sent in your later
> message) and have committed the changes.
> 

Thanks for the fix !

Would be nice to have completion for the erlang BIF that don't require the
module prefix (like is_tuple(Term))

Is it in the to-do list ;-)

Re: [Distel-hackers] who_calls rewrite

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

Hi Matthias,

Matthias Radestock <mat...@so...> writes:
> Bill Clementson wrote:
>> Yep, that did it - thanks!
>
> Works for me too. Thanks for implementing this change.
>
>> Incidentally, I probably mucked around trying to figure out the xref
>> query string to use for longer than it took me to write the elisp
>> code. Is there any better documentation or examples of xref other
>> than the tools xref document? e.g. - better than:
>> http://www.erlang.org/doc/man/xref.html
>
> There is the User Guide at
> http://www.erlang.org/doc/apps/tools/xref_chapter.html#5, but it's not
> all that much more helpful.

Yes, I saw that one too (it's linked to from the above page).

> I am not aware of any other documentation / tutorials / examples.
>
> I found that carefully reading the above two documents from start to
> finish, and trying a few self-constructed examples along the way,
> helped quite a bit.
>
> I suspect the inaccessibility of the xref documentation is one of the
> reasons it isn't known and used more widely. 

I did google around a bit yesterday trying to find examples as I
thought someone had surely been banging their head against the wall
with xref before. Surprisingly, I didn't find much. I suspect you're
right - the documentation probably puts most people off.

> Somebody should write a
> few introductory blog posts ...

Hmm, actually, that's a really good idea and I know the ideal person
for the job!  LShift has a blog with a growing collection of
erlang-related posts - a great forum for you to share your xref
knowledge! ;-)

Thanks again for your work in getting xref into distel.

- Bill

Re: [Distel-hackers] who_calls rewrite

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

Bill,

Bill Clementson wrote:
> Yep, that did it - thanks!

Works for me too. Thanks for implementing this change.

> Incidentally, I probably mucked around trying to figure out the xref
> query string to use for longer than it took me to write the elisp
> code. Is there any better documentation or examples of xref other
> than the tools xref document? e.g. - better than:
> http://www.erlang.org/doc/man/xref.html

There is the User Guide at 
http://www.erlang.org/doc/apps/tools/xref_chapter.html#5, but it's not 
all that much more helpful.

I am not aware of any other documentation / tutorials / examples.

I found that carefully reading the above two documents from start to 
finish, and trying a few self-constructed examples along the way, helped 
quite a bit.

I suspect the inaccessibility of the xref documentation is one of the 
reasons it isn't known and used more widely. Somebody should write a few 
introductory blog posts ...


Matthias.

Re: [Distel-hackers] who_calls rewrite

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

Hi Matthias,

Matthias Radestock <mat...@so...> writes:
> Bill Clementson wrote:
>> I had a bit of free time today, so I implemented this (patch
>> attached). The who-calls buffer will now let you press RET on a line
>> and it will open the source member of the module containing the
>> caller and jump to the line number of the function definition of the
>> caller (which is what is returned by your "(Lin)(domain (E || ~p))"
>> who-calls xref query.
>
> Great.
>
>> I think it would be preferable to jump to the place in the function
>> where the call was made; however, I don't know what the correct xref
>> string should be. It looks like changing the "(Lin)" to something
>> like "(LLin + XLin)" is what is needed (so that xref returns the line
>> numbers for both local and external calls). However, I played around
>> with some variations and couldn't figure out the right one. And, the
>> xref documentation didn't provide any enlightenment. Do you know what
>> the xref query should be changed to?
>
> Try something like
>   {ok, Calls} = xref_q(...,"(XXL)(Lin)(E || ~p)", [MFA]),
>   lists:flatten([[{Caller, Line} || Line <- Lines]
>                  || {{{Caller,_},_}, Lines} <- Calls]).
>
> Lines is a list since there can be several call sites per function. In
> the above I am just flatting that info, but depending on how you want
> to represent this in the UI you may want to do something different.

Yep, that did it - thanks! Incidentally, I probably mucked around
trying to figure out the xref query string to use for longer than it
took me to write the elisp code. Is there any better documentation or
examples of xref other than the tools xref document? e.g. - better
than: http://www.erlang.org/doc/man/xref.html

I've committed the changes.

- Bill

Re: [Distel-hackers] who_calls rewrite

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

Bill,

Bill Clementson wrote:
> I had a bit of free time today, so I implemented this (patch 
> attached). The who-calls buffer will now let you press RET on a line 
> and it will open the source member of the module containing the
> caller and jump to the line number of the function definition of the
> caller (which is what is returned by your "(Lin)(domain (E || ~p))"
> who-calls xref query.

Great.

> I think it would be preferable to jump to the place in the function
> where the call was made; however, I don't know what the correct xref
> string should be. It looks like changing the "(Lin)" to something
> like "(LLin + XLin)" is what is needed (so that xref returns the line
> numbers for both local and external calls). However, I played around
> with some variations and couldn't figure out the right one. And, the
> xref documentation didn't provide any enlightenment. Do you know what
> the xref query should be changed to?

Try something like
   {ok, Calls} = xref_q(...,"(XXL)(Lin)(E || ~p)", [MFA]),
   lists:flatten([[{Caller, Line} || Line <- Lines]
                  || {{{Caller,_},_}, Lines} <- Calls]).

Lines is a list since there can be several call sites per function. In 
the above I am just flatting that info, but depending on how you want to 
represent this in the UI you may want to do something different.

Matthias.

[Distel-hackers] distel doesn't work on my windows xp

[krzycube <yu...@gm...>]

> i copy my issue from distel wiki in googlecode. 
> 
> What steps will reproduce the problem? 
> 0. set up distel: with below code: 
> ------------------------------------------- 
> (add-to-list 'load-path "D:\\HOME\\distel\\elisp") 
> (when (locate-library "distel") 
> (require 'distel) 
> (distel-setup) 
> ;; (add-hook 'erlang-mode-hook 'distel-erlang-mode-hook) ; 
> (add-hook 'erlang-mode-hook 
> '(lambda () 
> (unless erl-nodename-cache 
> (distel-load-shell)))) 
> (defun distel-load-shell () 
> "Load/reload the erlang shell connection to a distel node" 
> (interactive) 
> ;; Set default distel node name 
> (setq erl-nodename-cache 'emacs@krzycube-laptop) 
> (setq distel-modeline-node "emacs") 
> (force-mode-line-update) 
> ;; Start up an inferior erlang with node name `distel' 
> (let ((file-buffer (current-buffer)) 
> (file-window (selected-window))) 
> (setq inferior-erlang-machine-options '("-sname" "emacs")) 
> (switch-to-buffer-other-window file-buffer) 
> (inferior-erlang) 
> (select-window file-window) 
> (switch-to-buffer file-buffer)))) 
> ------------------------------------------- 
> 
> 1. run emacs 22.1 on windows xp pro 
> 2. M-x erlang-mode 
> 3. C-c C-z to run erlang-shell . 
> 4.C-x C-f open some erlang source 
> 5.c(xx.erl,[debug_info]). 
> 5.C-c C-d n , connet to node named emacs@krzycube as configured
> 6.C-c C-d L , try to reload code. then here failed. 
> 
> here servral steps: 
> first , can not find ~/.erlang.cookie , then i create it. 
> why didn't this create itself ? 
> after this , i face the message below: 
> 
> What is the expected output? What do you see instead? 
> 
> if: Can't handle event closed in state 
> derl-recv-challenge-ack 
> Can't handle event closed in state 
> derl-recv-challenge-ack 
> 
> What version of the product are you using? On what operating system? 
> Erlang (BEAM) emulator version 5.5.5 [async-threads:0] 
> 
> Eshell V5.5.5 (abort with ^G) 
> 
> on windows xp. 
> 
> Please provide any additional information below. 
> 
> i have tried distel before on my Ubuntu 7.04 with Emacs 21.3 , it works well. 
> but on windows , it doesn't. 
> 
> and i also try to google this error message , found something ,said: 
> there's newline in the cookie file , also i try to fix derl.el , but failed . 
> 
> -- 
> "Yu Xihe" as Chinese Name 
> "Martin" as English Name 
> "KrzyCube" as Nickname 

I don't normally use Windows; however, I did recently setup distel on 
a Windows box. I encountered similar problems when I used a copy of 
ntemacs which was based on the unicode branch of cvs emacs. However, 
after switching to the released Emacs 22.1 (not cvs emacs), distel 
worked fine. You indicated that you were using emacs 22.1, so maybe 
this isn't your problem. However, if you are using the unicode branch 
of cvs emacs, you might want to try installing the released emacs 22.1 
instead. 

Alternatively, if you're getting an error message that says something 
about there being a newline in the cookie file, you could use hexl 
mode to find and remove the newline (or recreate the cookie). 

If you continue to encounter problems, you should post details on the 
distel mailing list 
(http://news.gmane.org/gmane.comp.lang.erlang.distel.devel). 

- Bill

--------------------------------
My original problem description and Bill Clementson's answer are above the
dotted line.

and thanks , Bill , 

Yes , i am using the emacs 22.1 with the binary intall .
the version info is :

GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600)
 of 2007-06-02 on RELEASE

Then follow Bill's direct , i tried to view the ".erlang.cookie" file in 
hexl-mode in emacs , and also in ultraedit , both nothing in the file .

so , problem is still there.

- krzycube

-------------------------------------------------------

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

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

Hi Matthias,

mat...@so... writes:
> Bill Clementson <bil...@gm...> writes:
>
>> I was asking about a patch for the Call Graph code that you wrote
>> previously. At the moment, the "who calls" support doesn't work for
>> BIF's.
>
> Oh I see. Is it really that useful to have that? I don't often find
> myself wondering who calls a particular BIF.

I would imagine that it might be useful if one were refactoring code
and wanted to eliminate/replace/change calls to specific BIF's.

> I added builtins to the call graph xref server - see attached patch -
> but it doesn't seem to make a difference. I suspect BIFs are only added
> as unconnected vertices.

Perhaps.

>>>>> (except distel's completion currently isn't using xref, but it should)
>> Does the attached patch do what you wanted?
>
> Thanks for the patch. I've made the following changes:
>
> - don't add otp release - the otp modules are part of the code path and
> hence get loaded anyway
>
> - filter duplicates (due to different arity) from function completion
>
> - avoid duplication of code between who_calls and completion
>
> - add rebuild_{completions, call_graph} functions - there is nothing on
> the emacs side that calls them, but you can call them manually
>
> - minor cosmetic changes
>
> See attachment for the revised patch.

Much tidier than my patch. 

> One remaining problem with this code is that it doesn't automatically
> handle the addition/removal of modules or changes to the code load
> path - you have to invoke the aforementioned rebuild functions manually
> for this.

I don't think that's much of a problem. At least it's consistent for
both the completions and the call graph servers and it's easy enough
to invoke the rebuilds.

I've applied your patch (as well as the mod you sent in your later
message) and have committed the changes.

Thanks,
Bill

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

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

mat...@so... wrote:
> I've made the following changes:  [...]

There is one other thing you may want to change.

Currently the functions completion code doesn't actually use the 
function name prefix. Yet it works, presumably because the filtering 
happens on the emacs side (though I still have to figure out how).

Anyway, I reckon it would be cleaner to do the filtering on the erlang 
side. For that just change

     case  xref_q(?COMPLETION_SERVER, ?COMPLETION_SERVER_OPTS,
                  "(X+B) * ~p:_/_", [Mod]) of

to

     case  xref_q(?COMPLETION_SERVER, ?COMPLETION_SERVER_OPTS,
                  '(X+B) * ~p:"~s.*"/_', [Mod, Prefix]) of


Matthias

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

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

Bill,

Bill Clementson <bil...@gm...> writes:

> I was asking about a patch for the Call Graph code that you wrote
> previously. At the moment, the "who calls" support doesn't work for
> BIF's.

Oh I see. Is it really that useful to have that? I don't often find
myself wondering who calls a particular BIF.

I added builtins to the call graph xref server - see attached patch -
but it doesn't seem to make a difference. I suspect BIFs are only added
as unconnected vertices.

>>>> (except distel's completion currently isn't using xref, but it should)
> Does the attached patch do what you wanted?

Thanks for the patch. I've made the following changes:

- don't add otp release - the otp modules are part of the code path and
hence get loaded anyway

- filter duplicates (due to different arity) from function completion

- avoid duplication of code between who_calls and completion

- add rebuild_{completions, call_graph} functions - there is nothing on
the emacs side that calls them, but you can call them manually

- minor cosmetic changes

See attachment for the revised patch.

One remaining problem with this code is that it doesn't automatically
handle the addition/removal of modules or changes to the code load
path - you have to invoke the aforementioned rebuild functions manually
for this.


Matthias.

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

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

Bill,

Bill Clementson wrote:
> Matthias Radestock <mat...@so...> writes:
> 
>> Bill Clementson wrote:
>>> Do a "M-." on "math:pi()" and you'll see that it's the only function
>>> in the source file.
>> In which case I know how to fix this:
> [snip examples]
> 
> Great - will you be preparing a patch to the Call Graph code so that
> who_calls will also return info on BIF's?

Changing the completion code to use xref, and include BIFs, is on my 
todo list. Don't know when I will get round to doing it though. The code 
I posted, together with the existing who_calls code and the explanation 
below should be enough for anybody to be able implement it.

>> (except distel's completion currently isn't using xref, but it should)
> 
> I guess the main problem with using xref for completion is speed. The
> xref who_calls build process is fairly slow and (if a lot of new
> functions are being added) could result in lengthy wait times when you
> want to get a completion. I guess you could use a separate (different
> from the who_calls server) xref server that always rebuilds and only
> gets functions for the specified module though. Was that what you had
> in mind?

The current_who calls only builds the graph the first time you invoke it 
  - which takes a while but is faster than what we had before - and then 
updates it incrementally for every subsequent invocation, which is very 
quick.

For completion I would use a different xref instance, configured to 
operate in "modules" mode, which is sufficient in this case. See the 
code I posted in my previous email. The modules mode of xref is *much* 
faster to initialise - less than 2 seconds on my machine, so even the 
first invocation of completion will work at tolerable speed. As with 
who_calls, subsequent invocations will be set up to update the call 
graph with any changed modules.


Matthias

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

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

Bill Clementson <bil...@gm...> writes:

> Hi mats,
>
> mats cronqvist <mat...@er...> writes:
>
>> 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.
>
> I haven't seen this fix come through yet. Are you still working on it
> or did you just forget to commit it?

Hmm, somethings a bit weird here. If I do an "svn status", I don't see
any record of your changes. However, if I download a fresh copy of
distel from svn, I do see your changes of September 12. Does anyone
else have this problem?

- Bill

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

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

Hi Matthias,

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

> Bill Clementson wrote:
>> Matthias Radestock <mat...@so...> writes:
>>> This is not distel's fault. There is something odd about these
>>> modules; xref cannot see much in them either:
>
>> 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.
>
> In which case I know how to fix this:
[snip examples]

Great - will you be preparing a patch to the Call Graph code so that
who_calls will also return info on BIF's?

> (except distel's completion currently isn't using xref, but it should)

I guess the main problem with using xref for completion is speed. The
xref who_calls build process is fairly slow and (if a lot of new
functions are being added) could result in lengthy wait times when you
want to get a completion. I guess you could use a separate (different
from the who_calls server) xref server that always rebuilds and only
gets functions for the specified module though. Was that what you had
in mind?

- Bill

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

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

Hi mats,

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

> 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.

I haven't seen this fix come through yet. Are you still working on it
or did you just forget to commit it?

- Bill

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

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

Bill Clementson wrote:
> Matthias Radestock <mat...@so...> writes:
>> This is not distel's fault. There is something odd about these modules; 
>> xref cannot see much in them either:

> 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.

In which case I know how to fix this:

(x@h)30> xref:start(foo, {xref_mode, modules}).
{ok,<0.7716.0>}
(x@h)31> xref:set_default(foo, builtins, true).
{ok,false}
(x@h)32> xref:add_release(foo, code:lib_dir(), {name, otp}).
{ok,otp}
(x@h)39> xref:q(foo, '(X+B) * math:_/_').
{ok,[{math,exp,1},{math,log,1},{math,pi,0},{math,pow,2},{math,sqrt,1}]}
(x@h)40> xref:q(foo, '(X+B) * erlang:"is_.*"/_').
{ok,[{erlang,is_alive,0},
      {erlang,is_atom,1},
      {erlang,is_binary,1},
      {erlang,is_boolean,1},
      {erlang,is_builtin,3},
      {erlang,is_constant,1},
      {erlang,is_float,1},
      {erlang,is_function,1},
      {erlang,is_function,2},
      {erlang,is_integer,1},
      {erlang,is_list,1},
      {erlang,is_number,1},
      {erlang,is_pid,1},
      {erlang,is_process_alive,1},
      {erlang,is_reference,1},
      {erlang,is_tuple,1}]}


(except distel's completion currently isn't using xref, but it should)


Matthias.