Subscribe: Comments for CUViper
http://blog.cuviper.com/comments/feed/
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
add new  add  cast  code code  code  comment add  comment  gcc python  gcc  git  int  new warnings  python  systemtap  warnings gcc 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Comments for CUViper

Comments for Josh Stone



Ideas, opinions, and inanities



Last Build Date: Sat, 22 Feb 2014 18:35:16 +0000

 



Comment on SystemTap monitoring ptrace activity by Josh Stone

Sat, 22 Feb 2014 18:35:16 +0000

@portl4t - Since your question is not really related to this blog post, I'd rather you emailed the mailing list, systemtap@sourceware.org. Please at least include the version of systemtap, the compiler version and options you use, and a complete example script. My first guess is that you're running systemtap older than 1.7, which fixed bug 12136. Note, you can also chain dereferences like ->ds->a or ->pd->t, which should work even on an older systemtap that doesn't know how to cast :: types properly. It's always -> in systemtap scripts, even for members that would use . in C/C++.



Comment on SystemTap monitoring ptrace activity by portl4t

Sat, 22 Feb 2014 10:52:33 +0000

namespace nk { struct Pda { int t; }; }; class Dummy { public: struct State { int a; }; }; class Ep { public: Ep(): r(7) { ds.a = 169; pd.t = 200; } ~Ep(){} int mb(int n) { return n * (n - 1); } public: int r; Dummy::State ds; nk::Pda pd; }; /////////////////// Hi, I probe function Ep::mb with systemtap, and I can get Ep::r like this: r = @cast(longlong_arg(1), "Ep")->r but, how can I get Ep::ds.a and Ep::pd.t ? I try to get them like this: pd = &@cast(longlong_arg(1), "Ep")->pd t = @cast(pd, "nk::Pda")->t ds = &@cast(longlong_arg(1), "Ep")->ds a = @cast(ds, "Dummy::State")->a They don't work, I got semantic error : type definition 'Dummy::State' not found in xx operator :'@cast' at xxx.



Comment on Add new warnings to GCC with Python by Josh Stone

Fri, 24 Jan 2014 17:16:33 +0000

Nice, thanks!



Comment on Add new warnings to GCC with Python by Dave Malcolm

Fri, 24 Jan 2014 16:22:42 +0000

I've added an "in_system_header" boolean attribute to gcc.Location as https://git.fedorahosted.org/cgit/gcc-python-plugin.git/commit/?id=58968fff3b23fcca0641ce5ad5fbc0c7a19242f4



Comment on Add new warnings to GCC with Python by Tom Tromey

Fri, 24 Jan 2014 15:38:05 +0000

> # (is data like -isystem available?) It's available internally but I don't think the Python plugin exposes it. I think gcc.Location could use a few new attributes; at least "in_system_header" and perhaps some related to macro expansion information.



Comment on Add new warnings to GCC with Python by Dave Malcolm

Fri, 24 Jan 2014 15:38:00 +0000

> # I don't want notices for system headers. > # (is data like -isystem available?) gcc has that as a flag internally, on locations [1], but the plugin doesn't yet expose that on gcc.Location instances. I'll see if I can add it. [1] "in_system_header_at(LOC)" within input.h



Comment on How short can Git abbreviate? by Defining your own Git commands | CUViper

Sun, 17 Nov 2013 21:31:00 +0000

[…] its own file.  As long as you name it starting with “git-“, like git-unique-abbrev in my last post, and save it somewhere in your PATH, then you can call it as you would any other git command like […]



Comment on How short can Git abbreviate? by Josh

Mon, 11 Nov 2013 20:38:04 +0000

Frederik :

Everything is for posterity on the internet.

I suppose, but I know I don't treat everything with the same diligence. I want git commit messages to be useful as long as possible, but I care less in short discussions like, "Hey JohnDoe, your commit abcdef broke the build, please investigate."



Comment on How short can Git abbreviate? by Frederik

Mon, 11 Nov 2013 08:53:51 +0000

"Finally, when you reference a Git hash for posterity, e.g. in another commit message, I’d recommend always using the full value." Everything is for posterity on the internet.



Comment on Boot Time versus LVM Snapshots by Josh

Tue, 29 Jan 2013 19:10:17 +0000

I just discovered from the Fedora 19 feature YumFsSnapshotThinpSupport that there was already a F17 feature ThinProvisioning. This looks like it might be a better way for me to manage VM storage and snapshots. https://fedoraproject.org/wiki/Features/YumFsSnapshotThinpSupport https://fedoraproject.org/wiki/Features/ThinProvisioning It's not clear to me how easily I could convert my existing LVM configuration, but it's worth investigating.