Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Local\s+context\s+vs\s+dynamic\s+namespace\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Local\s+context\s+vs\s+dynamic\s+namespace\s*$/: 9 ]

Total 9 documents matching your query.

1. Local context vs dynamic namespace (score: 1): Author: nathans@xxxxxxxxxx; Date: Mon, 12 Apr 2010 11:56:50 +1000 (EST); Hi Ken, We're a long way down the path of converting all of our production environment over to using MMV and the dynamic namespace extensions. All going swimmingly so far. Just this morning we came a; /archives/pcp/2010-04/msg00016.html (7,817 bytes)
2. Re: Local context vs dynamic namespace (score: 1): Author: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>; Date: Mon, 12 Apr 2010 13:52:54 +1000; This is pretty much outside the scope of what I was aiming for with the dynamic metrics, although it is not unreasonable. It will mean even more code being copied and changed from pmcd to libpcp as t; /archives/pcp/2010-04/msg00021.html (8,423 bytes)
3. Re: Local context vs dynamic namespace (score: 1): Author: nathans@xxxxxxxxxx; Date: Mon, 12 Apr 2010 15:31:29 +1000 (EST); Good point. I'll go with dropping -L in the bash completion, I think. Guess we could do something like the /etc/ld.so.conf.d/ approach with local context pmdas, to specify all that should be open whe; /archives/pcp/2010-04/msg00022.html (7,827 bytes)
4. Re: Local context vs dynamic namespace (score: 1): Author: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>; Date: Wed, 14 Apr 2010 06:47:08 +1000; Nathan, I know you don't particularly like the environment variable approach, but following the $PCP_DERIVED_CONFIG example, we could introduce $PCP_LOCAL_CONFIG that might specify the name of a file; /archives/pcp/2010-04/msg00027.html (10,565 bytes)
5. Re: Local context vs dynamic namespace (score: 1): Author: Nathan Scott <nathans@xxxxxxxxxx>; Date: Wed, 14 Apr 2010 08:02:22 +1000 (EST); I was thinking something along those lines, but more system-wide than user specific. If we had a /etc/pcp.local.d/ directory, we could have the agent Install scripts drop a file in there in __pmSpecL; /archives/pcp/2010-04/msg00028.html (9,360 bytes)
6. Re: Local context vs dynamic namespace (score: 1): Author: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>; Date: Wed, 14 Apr 2010 08:55:38 +1000; No real issue with this, but a few comments. 1. By "drop a file" I presume you're thinking one file per pmda that wants to play, and then "somewhere" in libpcp I process all of the files in the magic; /archives/pcp/2010-04/msg00029.html (10,705 bytes)
7. Re: Local context vs dynamic namespace (score: 1): Author: Nathan Scott <nathans@xxxxxxxxxx>; Date: Wed, 14 Apr 2010 09:23:58 +1000 (EST); Right, that was what I was thinking. Right. Someday, pmcd could perhaps take a leaf out of this book, but way beyond scope here. I'd be happy with that too, yep. Mmm, yes, nice idea - do we even need; /archives/pcp/2010-04/msg00030.html (9,571 bytes)
8. Re: Local context vs dynamic namespace (score: 1): Author: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>; Date: Thu, 15 Apr 2010 08:44:07 +1000; The parsing is pretty simple ... I opted to not do a heap of error checking because (a) pmcd is already doing that at the time pmcd.conf is updated and reread, and (b) the parsing happens during the; /archives/pcp/2010-04/msg00038.html (9,441 bytes)
9. Re: Local context vs dynamic namespace (score: 1): Author: Nathan Scott <nathans@xxxxxxxxxx>; Date: Thu, 15 Apr 2010 09:44:43 +1000 (EST); All sounds fine to me. I came across what looks like a day-1 bug in local context mode when dealing with help text this morning (so if you hit a free-of-non-malloc memory in there, I've got a fix for; /archives/pcp/2010-04/msg00040.html (8,767 bytes)

Current List: 1 - 9
Page: [1]