| To: | pcp@xxxxxxxxxxx |
|---|---|
| Subject: | pmprintf & pmconfirm |
| From: | fche@xxxxxxxxxx (Frank Ch. Eigler) |
| Date: | Sun, 25 May 2014 10:12:35 -0400 |
| Delivered-to: | pcp@xxxxxxxxxxx |
| In-reply-to: | <1536363482.13088867.1400822336748.JavaMail.zimbra@xxxxxxxxxx> (Nathan Scott's message of "Fri, 23 May 2014 01:18:56 -0400 (EDT)") |
| References: | <1206097450.13083278.1400820443326.JavaMail.zimbra@xxxxxxxxxx> <1536363482.13088867.1400822336748.JavaMail.zimbra@xxxxxxxxxx> |
| User-agent: | Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) |
Hi - On IRC, nathans & scox were talking about recent pmatop/pmcollectl changes now causing pmconfirm dialogs popping up, hanging qa. I took a glance at related code and got wondering. What led to the creation of pmprintf() / pmflush(), and the desire to turn some error conditions detected in the library into a suspension of the program (and interruption of the user) for some interactive dialogs? (I'm not aware of any other general purpose library that does this.) pcpintro makes the PCP_STDERR=DISPLAY setting sound like it's for startup errors only (related to how pure X/desktop apps may lack a usable stderr), but pmprintf/pmflush() are used in non-startup contexts too. By the way, why is __pmNotifyErr disconnected from pmprintf()? - FChE |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | pcpstats, Michele Baldessari |
|---|---|
| Next by Date: | Re: [pcp] Small python segfault fix when printing empty units structs, Nathan Scott |
| Previous by Thread: | pcp updates: scox merge, pmcd.services, qa, Nathan Scott |
| Next by Thread: | SECURE YOUR E-MAIL, SECURE WEBMAIL |
| Indexes: | [Date] [Thread] [Top] [All Lists] |