risky_shell

[Ulf Wiger (AL/EAB)]

> -----Original Message-----
> From: peppe@REDACTED [mailto:peppe@REDACTED]

> We have not documented the details because we don't want 
> people to use this flag and, like you, become dependent on
> the old shell startup behaviour. So don't push me or I'll
> take away this flag of yours! :-)

I thought my suggestion to mention the name of the flag in the 
release notes only was quite reasonable.  (-:


> The old parallell startup behaviour *could* be useful to
> start tracing early.

*Is* useful.
Feel free to provide a list of *more* useful ways to 
accomplish the same thing.  ;-)
(I believe this was the main reason why you agreed to 
put it back in...)


> But since it is indeed parallell and the time to start 
> the shell process depends on e.g. io speed, it must be an
> unpredictable way to start tracing an application start
> sequence.

Indeed. Depending on how quickly the situation occurs that 
you want to trace, it can be difficult to get the commands
entered quickly enough. People here have learned to keep 
such commands in a text editor window, and then select 
a bunch of lines at a time, and copy and paste into the 
erlang shell. Also, a system the size of the AXD 301 doesn't
start *that* quickly. Code loading alone takes nearly one
minute (actually, this happens before even the old shell
appears, when embedded loading is used), and loading the 
Mnesia database from disk takes another minute (and we have
code that makes sure that no "interesting" applications 
start before Mnesia is done loading). For many of the 
sequences that one might want to trace on, there's plenty 
of time.

OK, I didn't really mean to push you to make the feature 
"documented" in the sense that it would encourage people
to depend on it. 

Tracing early on a system *is* difficult, and there is
no single good way to do it. I welcome initiatives to 
relieve people of the challenge of pasting in shell
commands quickly enough to catch the bug, but not 
so quickly that they break something. (-:
In the meantime, one might even want to have a 
"tricky fault finding" tutorial, where anything goes,
of course with all the appropriate disclaimers.

If I may, there are some documented functions where 
users are *strongly discouraged* from even using them 
at all. I think this is appropriate. Some examples perhaps:

"erlang:bump_reductions(Reductions)
[...]This BIF might be removed in a future version of the 
Beam machine without prior warning. It is unlikely to be 
implemented in other Erlang implementations. If you think 
that you must use it, encapsulate it your own wrapper module, 
and/or wrap it in a catch."

"erlang:suspend_process(Pid)
Suspends the process Pid. 

 <WARNING/> This BIF is intended for debugging only."


"[application:]set_env(Application, Par, Val) -> ok
[...] <WARNING/> Use this function only if you know what 
you are doing, that is, on your own applications. It is 
very application and configuration parameter dependent when 
and how often the value is read by the application, and 
careless use of this function may put the application in 
a weird, inconsistent, and malfunctioning state. "


/Uffe