Raimo,<br><br>I get what you are saying; thanks for the enlightenment. Still, I think if I had a list of available data points (and you could create the process_info_items() call only to return the interesting ones, possibly), I could display them to the user, who could decide, no, that one is ugly and I won't select it for display. Isn't it better to give a choice and have someone refuse it, that to deny it to them? I don't know. It's just a thought.<br>
<br><div class="gmail_quote">On Fri, May 16, 2008 at 3:35 AM, Raimo Niskanen <<a href="mailto:raimo%2Berlang-questions@erix.ericsson.se">raimo+erlang-questions@erix.ericsson.se</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Thu, May 15, 2008 at 01:13:38PM -0400, Edwin Fine wrote:<br>
> LOL. I probably deserved that. Thanks for the replies - SOMEONE is out<br>
> there!<br>
><br>
> Matt, the solution is workable, and I avoid pain as much as the next guy,<br>
> but I really want to have something that will TELL me what all the valid<br>
> process_info items are. process_info/1 only gives me SOME of them and is for<br>
> debugging only.<br>
><br>
> Ok, then; here's a suggestion:<br>
><br>
> Erlang team, How about adding an info item of "all" for process_info/2? It<br>
> won't break the interface, and it will allow people like me to "query"<br>
> process_info for which items are valid.<br>
<br>
</div>We have thought of an 'all' item for process_info/2, but<br>
all items includes very strange and specialized ones,<br>
we are not proud of all of them, plus some are heavy<br>
to produce and some give duplicate information.<br>
<br>
Therefore we have more or less concluded that anyone<br>
who wants all items does not want all items, just<br>
all the ones that are interesting, and beleive me<br>
you are not interested in getting all of the<br>
items process_info/2 can produce, especially not<br>
all it will be able to produce in the future.<br>
<br>
Use your handcoded list, the chance an item will be removed<br>
is small, but to be prepared for that you can call process_info/2<br>
in a loop and shield it with a try .. catch block.<br>
<div class="Ih2E3d"><br>
><br>
> Regards,<br>
> Edwin Fine<br>
><br>
> On Thu, May 15, 2008 at 5:01 AM, Matthias Lang <<a href="mailto:matthias@corelatus.se">matthias@corelatus.se</a>><br>
> wrote:<br>
><br>
> > Edwin Fine writes:<br>
> ><br>
> >  > I don't know if my first post just didn't make it, or got ignored<br>
> > because I<br>
> >  > inadvertently offended someone, or perhaps it asked too boring a<br>
> >  > question.<br>
> ><br>
> > I thought "the guy's figured out a perfectly workable solution but is<br>
> > tying himself in knots to avoid using it because it doesn't seem<br>
> > painful enough." Either that, or he hasn't managed to explain what he<br>
> > really wants to do.<br>
> ><br>
> > Matt<br>
> ><br>
> ><br>
<br>
</div><div class="Ih2E3d">> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
</div><font color="#888888">--<br>
<br>
/ Raimo Niskanen, Erlang/OTP, Ericsson AB<br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
</div></div></blockquote></div><br>