distel-hackers Mailing List for Distel (Page 4)
Status: Beta
Brought to you by:
lukeg
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(19) |
Nov
(23) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(1) |
Feb
(2) |
Mar
(16) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(16) |
Dec
(6) |
2004 |
Jan
(7) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(11) |
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2006 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
(1) |
2007 |
Jan
(1) |
Feb
(10) |
Mar
(9) |
Apr
(3) |
May
(2) |
Jun
(46) |
Jul
(25) |
Aug
(1) |
Sep
(50) |
Oct
(4) |
Nov
(3) |
Dec
|
2008 |
Jan
|
Feb
|
Mar
(6) |
Apr
(4) |
May
(3) |
Jun
(6) |
Jul
(3) |
Aug
(9) |
Sep
(5) |
Oct
(10) |
Nov
(26) |
Dec
(30) |
2009 |
Jan
(10) |
Feb
(11) |
Mar
(20) |
Apr
(37) |
May
(45) |
Jun
(24) |
Jul
(37) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
|
Dec
(13) |
2010 |
Jan
(4) |
Feb
(6) |
Mar
(2) |
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
(2) |
Sep
|
Oct
(3) |
Nov
|
Dec
(1) |
2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: Bill C. <bil...@gm...> - 2007-10-16 23:00:59
|
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 |
From: Dimitris D. <di...@gm...> - 2007-10-12 22:53:06
|
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 > |
From: Matthias R. <mat...@so...> - 2007-10-12 21:25:23
|
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 |
From: Dimitris D. <di...@gm...> - 2007-10-12 20:03:33
|
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 |
From: Bill C. <bil...@gm...> - 2007-09-27 22:44:31
|
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 |
From: Pierre R. <pra...@ya...> - 2007-09-27 21:41:47
|
> 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. |
From: Bill C. <bil...@gm...> - 2007-09-26 15:49:28
|
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) |
From: Pierre R. <pra...@ya...> - 2007-09-25 23:33:21
|
> 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) |
From: Bill C. <bil...@gm...> - 2007-09-25 21:43:26
|
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 |
From: Bill C. <bil...@gm...> - 2007-09-25 20:58:45
|
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 |
From: Pierre R. <pra...@ya...> - 2007-09-22 00:10:25
|
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. |
From: Pierre R. <pra...@ya...> - 2007-09-22 00:05:34
|
> > 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 ;-) |
From: Bill C. <bil...@gm...> - 2007-09-18 13:44:34
|
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 |
From: Matthias R. <mat...@so...> - 2007-09-18 08:00:30
|
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. |
From: Bill C. <bil...@gm...> - 2007-09-18 05:09:42
|
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 |
From: Matthias R. <mat...@so...> - 2007-09-18 04:02:50
|
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. |
From: krzycube <yu...@gm...> - 2007-09-15 13:20:13
|
> 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 ------------------------------------------------------- |
From: Bill C. <bil...@gm...> - 2007-09-15 06:11:21
|
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 |
From: Matthias R. <mat...@so...> - 2007-09-15 05:00:05
|
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 |
From: <mat...@so...> - 2007-09-15 04:49:55
|
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. |
From: Matthias R. <mat...@so...> - 2007-09-14 20:34:10
|
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 |
From: Bill C. <bil...@gm...> - 2007-09-14 20:33:40
|
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 |
From: Bill C. <bil...@gm...> - 2007-09-14 20:06:55
|
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 |
From: Bill C. <bil...@gm...> - 2007-09-14 19:17:34
|
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 |
From: Matthias R. <mat...@so...> - 2007-09-12 21:45:15
|
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. |