distel-hackers — Mailing list for all things Distel

[Distel-hackers] small or big?

[Mats C. <et...@cb...>]

  anybody happens to know what this means?

error in process filter: erlext-read-obj: Unknown tag: smallBig
error in process filter: Unknown tag: smallBig


  mats

[Distel-hackers] Pattern matching syntax poll

[Luke G. <lu...@bl...>]

Ahoy,

Several people have suggested that Distel's pattern matching syntax is
a bit too "unlispy", so I'm thinking about changing it.

For the Erlang pattern {foo, Bar, Baz} (where Baz is already bound),
we could have one of:

a) [foo Bar ,baz]   (same as today)
b) ['foo bar ,baz]  ('x is literal, x is unbound, ,x is bound)
c) ['foo ,bar baz]  ('x is literal, ,x is unbound, x is bound)
d) something else

Anyone have any strong feelings?

PS, if anyone has any other not-backwards-compatible feature requests,
now's a good time for them.

Cheers,
Luke

Re: [Distel-hackers] Refactoring ?

[Mickael R. <mic...@er...>]

Selon Luke Gorrie <lu...@bl...>: 
 
> G'day Mickael, 
>  
> > Is anyone working on a distel refactoring set of functions ? 
>  
> I don't think so, though the idea has been kicked around a bit. It 
> would be interesting to look at Richard Carlsson's syntax-tools 
> package (and similar things) and see what they have to offer in this 
> direction. 
 
I think this would be usefull to quickly maintain a base of code with test 
suite and code. It is important to have refactoring to be able for example to 
rename function without having to go in every module to change them for 
example. I think this would be the most usefull function. 
 
> You got something in mind? :-) 
 
No nothing in mind, yet. I think we should proceed step by step and start with 
small and limited functionnality (like example function rename and propagation 
in every module that use it). 
You are right, more advanced refactoring functions implies that we need to 
have the source tree in memory. 
 
--  
Mickaël Rémond

Re: [Distel-hackers] Refactoring ?

[Luke G. <lu...@bl...>]

G'day Mickael,

> Is anyone working on a distel refactoring set of functions ? 

I don't think so, though the idea has been kicked around a bit. It
would be interesting to look at Richard Carlsson's syntax-tools
package (and similar things) and see what they have to offer in this
direction.

You got something in mind? :-)

Cheers,
Luke

[Distel-hackers] Refactoring ?

[Mickael R. <mic...@er...>]

Hello, 
 
Is anyone working on a distel refactoring set of functions ? 
 
--  
Mickaël Rémond

Re: [Distel-hackers] PROBLEM: Test

[Luke G. <lu...@bl...>]

Luke Gorrie <lu...@bl...> writes:

> ;; Distel bug report form.
> ;;
> ;; This is an email message buffer for you to fill in information
> ;; about your problem. When finished, you can enter "C-c C-c" to
> ;; send the report to the distel-hackers mailing list - or updated the
> ;; 'To: ' header line to send it somewhere else.
> ;;
> ;; Please describe the problem in detail in this blank space:

Okay, I checked in a small hack to CVS, which is the
`report-distel-problem' command. It just creates a message buffer
addressed to the list, with a bug report template and some
automatically gathered trace information. Hopefully it's a convenient
way to report bugs without having to manually include all the details.

The next step is a diagnostic command that can catch FAQ-type
problems, like naming an erlang node 'distel' or not having the
'dec32' in the path, etc etc.

Cheers,
Luke

[Distel-hackers] PROBLEM: Test

[Luke G. <lu...@bl...>]

;; Distel bug report form.
;;
;; This is an email message buffer for you to fill in information
;; about your problem. When finished, you can enter "C-c C-c" to
;; send the report to the distel-hackers mailing list - or updated the
;; 'To: ' header line to send it somewhere else.
;;
;; Please describe the problem in detail in this blank space:

Testing a new `report-distel-bug' function.

;; Below is some automatically-gathered debug information. Please make
;; sure it doesn't contain any secrets that you don't want to send. If
;; you decide to censor it or have any other special notes, please
;; describe them here:



[ ---- Automatically gathered trace information ---- ]

Emacs node name: distel@cockatoo

Node of most recent command: x@cockatoo

Recent *Messages*:
  Wrote /home/luke/hacking/distel/elisp/distel.el
  Undo!
  (No changes need to be saved)
  Auto-saving...done
  Done
  Undo! [2 times]
  Done
  report-distel-problem
  Wrote /home/luke/hacking/distel/elisp/distel.el
  Auto-saving...done
  Mark saved where search started
  Done
  Wrote /home/luke/hacking/distel/elisp/distel.el
  report-distel-problem
  (No changes need to be saved)


Recent interactions with x@cockatoo:
  "] [[TYPE erl-pid x@cockatoo 26 0 3] "<0.26.0> user              3555       0
  "] [[TYPE erl-pid x@cockatoo 27 0 3] "<0.27.0> <none>            4575       0
  "] [[TYPE erl-pid x@cockatoo 28 0 3] "<0.28.0> <none>            363        0
  "] [[TYPE erl-pid x@cockatoo 29 0 3] "<0.29.0> <none>            1202       0
  "] [[TYPE erl-pid x@cockatoo 31 0 3] "<0.31.0> <none>            45         0
  "] [[TYPE erl-pid x@cockatoo 32 0 3] "<0.32.0> kernel_safe_sup   59         0
  "] [[TYPE erl-pid x@cockatoo 36 0 3] "<0.36.0> <none>            9364       0
  "] [[TYPE erl-pid x@cockatoo 40 0 3] "<0.40.0> 'distel_gl_for_<1 1          0
  "] [[TYPE erl-pid x@cockatoo 48 0 3] "<0.48.0> <none>            15         0
  "] [[TYPE erl-pid x@cockatoo 49 0 3] "<0.49.0> <none>            6          0
  "] [[TYPE erl-pid x@cockatoo 50 0 3] "<0.50.0> <none>            10985      0
  "])]]
  >> REG_SEND: [TYPE erl-pid distel@cockatoo 88 0 0] rex [[TYPE erl-pid distel@cockatoo 88 0 0] [call distel rpc_entry (erlang process_info ([TYPE erl-pid x@cockatoo 10 0 3] backtrace)) [TYPE erl-pid distel@cockatoo 1 0 0]]]
  << SEND: [TYPE erl-pid distel@cockatoo 88 0 0] [rex [backtrace "program counter = 0x838df18 (gen_server:loop/6 + 52)
  cp = 0x838995c (proc_lib:init_p/5 + 164)
  arity = 0

  0x84c930c Return addr 0x838995C (proc_lib:init_p/5 + 164)
  y(0)     []
  y(1)     infinity
  y(2)     rpc
  y(3)     []
  y(4)     rex
  y(5)     <0.9.0>

  0x84c9328 Return addr 0x8132868 (<terminate process normally>)
  y(0)     Catch 0x838995C (proc_lib:init_p/5 + 164)
  y(1)     gen
  y(2)     init_it
  y(3)     [gen_server,<0.9.0>,<0.9.0>,{local,rex},rpc,[],[]]
  "]]
  >> REG_SEND: [TYPE erl-pid distel@cockatoo 89 0 0] rex [[TYPE erl-pid distel@cockatoo 89 0 0] [call distel rpc_entry (erlang process_info ([TYPE erl-pid x@cockatoo 10 0 3] backtrace)) [TYPE erl-pid distel@cockatoo 1 0 0]]]
  << SEND: [TYPE erl-pid distel@cockatoo 89 0 0] [rex [backtrace "program counter = 0x838df18 (gen_server:loop/6 + 52)
  cp = 0x838995c (proc_lib:init_p/5 + 164)
  arity = 0

  0x84c930c Return addr 0x838995C (proc_lib:init_p/5 + 164)
  y(0)     []
  y(1)     infinity
  y(2)     rpc
  y(3)     []
  y(4)     rex
  y(5)     <0.9.0>

  0x84c9328 Return addr 0x8132868 (<terminate process normally>)
  y(0)     Catch 0x838995C (proc_lib:init_p/5 + 164)
  y(1)     gen
  y(2)     init_it
  y(3)     [gen_server,<0.9.0>,<0.9.0>,{local,rex},rpc,[],[]]
  "]]


The End.

Re: [Distel-hackers] (no subject)

[Luke G. <lu...@bl...>]

Mats Cronqvist <et...@cb...> writes:

>   can't connect my emacs (21.1) to my erlang node (R8B-2) any more...
>   any ideas?
> 
>   mats
> 
>   in the erlang node
> ** Connection attempt from disallowed node distel@cbe1030 ** 
> 
> fsm-debug buffer  

[...]

> STATE: derl-recv-challenge -> derl-recv-challenge-ack
> EVENT: closed - "exited abnormally with code..."
> FAIL : "Error on event closed in st..." (buffer: #<buffer *derl foo@cbe1030*>)

Looks like the Erlang node didn't like our authentication: we enter
the "receive-challenge-ack" state but get the socket closed on us.

I think the initial "checklist" is (preparing for FAQ):

  Running short names (sname) node, not called 'distel'

  In Emacs running (erl-cookie) should give the same as
  erlang:get_cookie() in Erlang.

  To make sure the 'dec32' helper program is installed okay, running
  (int32-to-decimal "0000") should print "808464432"

  The Emacs variable `erl-node-name' should contain the right
  hostname.

Beyond that, the best way is to recompile the Erlang 'kernel'
application with dist_debug and dist_trace defined - then it will
print information about handshake process and so on, and we can take
it from there.

(Actually, it's probably enough to just recompile the dist_util module
I think).

Cheers,
Luke

[Distel-hackers] (no subject)

[Mats C. <et...@cb...>]

  can't connect my emacs (21.1) to my erlang node (R8B-2) any more...
  any ideas?

  mats

  in the erlang node
** Connection attempt from disallowed node distel@cbe1030 ** =


fsm-debug buffer  =


EVENT: init - "pfoo"
SEND : "=00=04pfoo"
STATE: epmd-process -> epmd-recv-port-resp
EVENT: data - "=FAD"
TERM : 64068
EVENT: init - foo@cbe1030
SEND : "=00=15n=00=05=00=00=00=00distel@cbe1030"
STATE: derl-state0 -> derl-recv-status
EVENT: data - "=00=03sok=00=16n=00=05=00=00=00=FEZ=D3D=A8foo@cbe1030"
STATE: derl-recv-status -> derl-recv-challenge
EVENT: data - ""
SEND : "=00=15r=00=00=00*=A3=C0=AC=0C=C9=3Dt\"=BB\211\203=AF\\I=1E=18"
STATE: derl-recv-challenge -> derl-recv-challenge-ack
EVENT: closed - "exited abnormally with code..."
FAIL : "Error on event closed in st..." (buffer: #<buffer *derl foo@cbe10=
30*>)

 Messages buffer

nodedown: foo@cbe1030
error in process sentinel: if: Can't handle event closed in state =

derl-recv-challenge-ack
error in process sentinel: Can't handle event closed in state =

derl-recv-challenge-ack


  the cookie in the erlang node is the one from ~/.erlang.cookie

Re: [Distel-hackers] Did not manage to make distel run

[Mickael R. <mic...@er...>]

Mats Cronqvist found the solution. I did call my Erlang node distel, which is 
the name of the elisp node. 
 
This is now working very well :-) 
 
Thank you. 
 
--  
Mickaël Rémond

Re: [Distel-hackers] Did not manage to make distel run

[Mickael R. <mic...@er...>]

Mickael Remond <mic...@er...>:  
  
> Hello all,  
>   
> I am probably missing something obvious but I am stuck here.  
>   
> Any advices ?  
 
Some more relevant information. I am using Gnu Emacs 21.2.1 (Linux Mandrake 
9.0 version) and Erlang/OTP R8B-2 
 
--   
Mickaël Rémond

[Distel-hackers] Did not manage to make distel run

[Mickael R. <mic...@er...>]

Hello all, 
 
Sorry to bother you with that. I did not manage to make distel run on my 
system. When Emacs tries to contact the node, it think that the node is down. 
I have a node running on the same machine, but the system does not seem to be 
able to contact it. It does not even try to contact the EPMD (I see no contact 
when run in debug mode). 
I am probably missing something obvious but I am stuck here. 
 
Any advices ? 
 
--  
Mickaël Rémond

RE: [Distel-hackers] Tracing (Was: Re: Distel 3.0)

[Mats C. (EAB) <mat...@et...>]

> -----Original Message-----
> From: Luke Gorrie [mailto:lu...@bl...]
> Sent: Thursday, October 10, 2002 5:55 PM
> To: Mats Cronqvist (EAB)
> Cc: 'dis...@li...'
> Subject: Re: [Distel-hackers] Tracing (Was: Re: Distel 3.0)
> 
> 
> "Mats Cronqvist (EAB)" <mat...@et...> writes:
> 
> >   we have pretty hefty application (written by me) that allows you
> >   to take traces to file, move the file off-target and massage the
> >   data in many useful ways. it includes most of the functionality
> >   offered by dbg and fprof + a fair bit (such as presenting cpu time
> >   per erlang process). <end self-promotion>
> 
> That sounds very nice indeed :-). Is that going to be in R9, or
> Ericsson-internal?

  our project (the AXD) only. i could put it on "contributions" i guess. i think otp is working on something similar for R9, maybe that'll be really good...

> >   i'm not sure how much of this could be used in an distel context
> >   (we trace to file to minimize the impact on the system).
> 
> One thing I'd _really_ like in Distel is to to say "Give me a
> real-time trace of the next process that starts in {M,F,A}", and then
> see everything the process does (and everything that other processes
> do for it) until it terminates. Do you know how to do that with
> trace? The tricky bit seems to be actually starting the trace on the
> right process at the right time..

  yeah, that's right (about the tricky bit). i do know how to do that (you trace on spawn for all processes and turn on the real trace when the correct mfa shows up). unfortunately, you'll probably miss a bit in the beginning that way. the other tricky bit is to keep the volume of data down ("everything the process does" can be quite a lot).
  <self-promotion> my app does allow you to see "everything the process does", either to a file, in the erlang shell or in the erlang shell of a different node (to offload the (expensive) io).</self-promotion> of course, dbg can do similar things. maybe even exactly the same things. (i don't use dbg much since it broke something important a long time ago)
  btw, what would be the win of getting this into emacs?

    mats
    

Re: [Distel-hackers] Tracing (Was: Re: Distel 3.0)

[Luke G. <lu...@bl...>]

"Mats Cronqvist (EAB)" <mat...@et...> writes:

>   we have pretty hefty application (written by me) that allows you
>   to take traces to file, move the file off-target and massage the
>   data in many useful ways. it includes most of the functionality
>   offered by dbg and fprof + a fair bit (such as presenting cpu time
>   per erlang process). <end self-promotion>

That sounds very nice indeed :-). Is that going to be in R9, or
Ericsson-internal?

>   i'm not sure how much of this could be used in an distel context
>   (we trace to file to minimize the impact on the system).

One thing I'd _really_ like in Distel is to to say "Give me a
real-time trace of the next process that starts in {M,F,A}", and then
see everything the process does (and everything that other processes
do for it) until it terminates. Do you know how to do that with
trace? The tricky bit seems to be actually starting the trace on the
right process at the right time..

Cheers,
Luke

RE: [Distel-hackers] Tracing (Was: Re: Distel 3.0)

[Mats C. (EAB) <mat...@et...>]

    luke,
  we have pretty hefty application (written by me) that allows you to take traces to file, move the file off-target and massage the data in many useful ways. it includes most of the functionality offered by dbg and fprof + a fair bit (such as presenting cpu time per erlang process). <end self-promotion> 
  i'm not sure how much of this could be used in an distel context (we trace to file to minimize the impact on the system). 

  mats

> -----Original Message-----
> From: Luke Gorrie [mailto:lu...@bl...]
> Sent: Tuesday, October 08, 2002 5:16 PM
> To: Mats Cronqvist
> Cc: dis...@li...
> Subject: [Distel-hackers] Tracing (Was: Re: Distel 3.0)
> 
> 
> Mats Cronqvist <et...@cb...> writes:
> 
> > > Are you debugging code on remote machines?
> > 
> >   not yet. i.e. we are debugging, but can't use/trust the 
> debugging support 
> > (we use the trace bif instead). but our lab sites don't 
> have the source 
> > either...
> 
> Tracing with the trace bif is very interesting. I don't have the hang
> of it, and suspect it's not used very widely outside Ericsson. It does
> look very useful.
> 
> Can you think of some nice tracing features that could be added to
> Distel, based on the way you guys use the trace bif?
> 
> I've only actually used the tracing from the process manager (either
> the Tk one or the Distel one), and what's really missing there is a
> way to trace short-lived processes that you can't just click on.
> 
> Cheers,
> Luke
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Distel-hackers mailing list
> Dis...@li...
> https://lists.sourceforge.net/lists/listinfo/distel-hackers
> 

[Distel-hackers] Tracing (Was: Re: Distel 3.0)

[Luke G. <lu...@bl...>]

Mats Cronqvist <et...@cb...> writes:

> > Are you debugging code on remote machines?
> 
>   not yet. i.e. we are debugging, but can't use/trust the debugging support 
> (we use the trace bif instead). but our lab sites don't have the source 
> either...

Tracing with the trace bif is very interesting. I don't have the hang
of it, and suspect it's not used very widely outside Ericsson. It does
look very useful.

Can you think of some nice tracing features that could be added to
Distel, based on the way you guys use the trace bif?

I've only actually used the tracing from the process manager (either
the Tk one or the Distel one), and what's really missing there is a
way to trace short-lived processes that you can't just click on.

Cheers,
Luke

Re: [Distel-hackers] Distel 3.0

[Mats C. <et...@cb...>]

> G'day Mats,
> 
> I've committed your patch for using the absolute filename from the
> Emacs buffer as the source file to interpret in the Erlang node. This
> assumes a common filesystem between the Emacs and the node being
> debugged, but that's fine for me - I only debug on my local machine in
> practice, and was finding int:i unrealiable too.
> 

  if the file systems are not common, i guess you'd have to ship the file 
(local -> target in my case).

> >   guessing the source is all well and good, but i would imagine that
> > most commercial projects uses a repository with version-tagged
> > source files. if the compiler sticks the absolute file name and the
> > version tag in the beam file (the version tag is always present in
> > the beam file even now, see below) you should be able to find the
> > right source code quite easily (as long as you can access the
> > repository, at least).
> >   e.g. what i would like to see in the edbproc buffer is the file
> > $CLEARCASEPATH/mod.erl$CLEARCASEVSN which is guararanteed to be the
> > correct one.
> 
> Yes, that would be nice. We could also have the option of the target
> node finding the source itself (if it's on its filesystem), or Emacs
> shipping the whole file over for the matching version.
> 

  yeah.

> >   since we don't ship the source (do you?) i think this is the only
> > way to go for us.
> 
> We don't ship the source, but do most of our debugging on local
> installations on our unix boxes which do have the source. It would be
> handy to be able to debug on the target boxes that don't have the
> source code, though I haven't needed it yet.
> 
> Are you debugging code on remote machines?
> 

  not yet. i.e. we are debugging, but can't use/trust the debugging support 
(we use the trace bif instead). but our lab sites don't have the source 
either...

> > from beam_asm.erl
> > %%
> > %% If the attributes contains no 'vsn' attribute, we'll insert one
> > %% with an MD5 "checksum" calculated on the code as its value.
> > %% We'll not change an existing 'vsn' attribute.
> > %%
> 
> Nice. Emacs' version-control mode probably makes the version
> information conveniently available in the buffers, so we could do some
> consistency checks, e.g. when setting breakpoints.
> 
> Though one tricky bit would be if the version is set by the version
> control software, like -vsn('$Revision$') in CVS (which we use). Then
> it would be the same in fresh checkouts and locally hacked copies that
> haven't been committed yet (since it only updates on commit). How's
> it work in Clearcase?

  cc changes the vsn tag on checkout to read something like 
-vsn('/main/R3A/R3C/R4A/1, checkout by etxmacr in etxmacr_view').

  mats

Re: [Distel-hackers] Distel 3.0

[Luke G. <lu...@bl...>]

G'day Mats,

I've committed your patch for using the absolute filename from the
Emacs buffer as the source file to interpret in the Erlang node. This
assumes a common filesystem between the Emacs and the node being
debugged, but that's fine for me - I only debug on my local machine in
practice, and was finding int:i unrealiable too.

>   guessing the source is all well and good, but i would imagine that
> most commercial projects uses a repository with version-tagged
> source files. if the compiler sticks the absolute file name and the
> version tag in the beam file (the version tag is always present in
> the beam file even now, see below) you should be able to find the
> right source code quite easily (as long as you can access the
> repository, at least).
>   e.g. what i would like to see in the edbproc buffer is the file
> $CLEARCASEPATH/mod.erl$CLEARCASEVSN which is guararanteed to be the
> correct one.

Yes, that would be nice. We could also have the option of the target
node finding the source itself (if it's on its filesystem), or Emacs
shipping the whole file over for the matching version.

>   since we don't ship the source (do you?) i think this is the only
> way to go for us.

We don't ship the source, but do most of our debugging on local
installations on our unix boxes which do have the source. It would be
handy to be able to debug on the target boxes that don't have the
source code, though I haven't needed it yet.

Are you debugging code on remote machines?

> from beam_asm.erl
> %%
> %% If the attributes contains no 'vsn' attribute, we'll insert one
> %% with an MD5 "checksum" calculated on the code as its value.
> %% We'll not change an existing 'vsn' attribute.
> %%

Nice. Emacs' version-control mode probably makes the version
information conveniently available in the buffers, so we could do some
consistency checks, e.g. when setting breakpoints.

Though one tricky bit would be if the version is set by the version
control software, like -vsn('$Revision$') in CVS (which we use). Then
it would be the same in fresh checkouts and locally hacked copies that
haven't been committed yet (since it only updates on commit). How's
it work in Clearcase?

Cheers,
Luke

[Distel-hackers] Re: Distel 3.0

[Mats C. <et...@cb...>]

> Mats Cronqvist <et...@cb...> writes:
> 
> >   also, in distel:debug_toggle you call int:i(Mod), which makes int
> > try to guess the source file name... which makes me sad since it
> > bypasses my guess_source_file_from_modinfo hack. i changed
> > debug_toggle to call int:i(FileName) instead (that ought to be the
> > right thing, since presumably the source in emacs is the one
> > guess_source_file gave you in the first place).  this implied a
> > change in edb.el :<
> 
> I just noticed something very interesting: filename:find_src/2.
> 
> This seems to already implement the basic guess-the-source-file
> functionality in distel.erl, so maybe that plus your int:file feature
> is the Right way to go.
> 
> It also has configurable rules, and we could configure those in Emacs
> variables to add site-specific directory searching.
> 
> I'll have a play around with that and hopefully tidy up the code
> accordingly.
> 
> Cheers,
> Luke
> 

  guessing the source is all well and good, but i would imagine that most 
commercial projects uses a repository with version-tagged source files. if the 
compiler sticks the absolute file name and the version tag in the beam file 
(the version tag is always present in the beam file even now, see below) you 
should be able to find the right source code quite easily (as long as you can 
access the repository, at least).
  e.g. what i would like to see in the edbproc buffer is the file 
$CLEARCASEPATH/mod.erl$CLEARCASEVSN which is guararanteed to be the correct 
one.
  since we don't ship the source (do you?) i think this is the only way to go 
for us.

from beam_asm.erl
%%
%% If the attributes contains no 'vsn' attribute, we'll insert one
%% with an MD5 "checksum" calculated on the code as its value.
%% We'll not change an existing 'vsn' attribute.
%%

[Distel-hackers] Re: Distel 3.0

[Luke G. <lu...@bl...>]

Mats Cronqvist <et...@cb...> writes:

>   also, in distel:debug_toggle you call int:i(Mod), which makes int
> try to guess the source file name... which makes me sad since it
> bypasses my guess_source_file_from_modinfo hack. i changed
> debug_toggle to call int:i(FileName) instead (that ought to be the
> right thing, since presumably the source in emacs is the one
> guess_source_file gave you in the first place).  this implied a
> change in edb.el :<

I just noticed something very interesting: filename:find_src/2.

This seems to already implement the basic guess-the-source-file
functionality in distel.erl, so maybe that plus your int:file feature
is the Right way to go.

It also has configurable rules, and we could configure those in Emacs
variables to add site-specific directory searching.

I'll have a play around with that and hopefully tidy up the code
accordingly.

Cheers,
Luke

[Distel-hackers] Test message from unsubscribed address

[Luke G. <luk...@bl...>]