I have recently tried my hand at learning GTK using Andrew Krause's "Foundations of GTK+ Development" (this is the most recent - 2007 - book on GTK I could find). Thus far, about half of the programs compile & run outright and the other half have deprecated functions which I can find replacements for with a little googling. I do use some online tutorials but they don't have the detail of explanation that Mr. Krause's book has.
In a perfect world, I would like to have an up to date book to learn from but that is not available. Thus I have to go back and forth between the book (GTK2) and online sources (GTK3).
My question, when I try to compile the source code from the book, I get several errors. I have been able to update all of the code except for the issue I name in the title that I cannot get past.
From the book, chapter 3 event boxes, this line is the one I am having trouble with:
gdk_window_set_cursor (eventbox->window, gdk_cursor_new (GDK_HAND1));
I have been able to modify it to work to this point but still get the error when I compile:
gdk_window_set_cursor (eventbox->window, gdk_cursor_new_for_display (gdk_display_get_default(), GDK_HAND1));
When I compile I get:
eventboxes.c:37:33: error: ‘GtkWidget {aka struct _GtkWidget}’ has no member named ‘window’
gdk_window_set_cursor (eventbox->window, gdk_cursor_new_for_display (gdk_display_get_default(), GDK_HAND1));
Having read some other items online such as this one "using cairo with gtk3"
I have found that changes between GTK2 and GTK3 have made members, such as window, inaccessible.
Sorry for the longwinded post by my question is:
Is there a way in GTK3 to make the line of code work or I am just pursuing a fool's errand and should let this one die?
This exact code can be fixed the following way:
GdkWindow * gdk_window = gtk_widget_get_window (eventbox);
gdk_window_set_cursor (gdk_window, gdk_cursor_new (GDK_HAND1));
However, I don't think it's a good idea to learn Gtk3 with Gtk2 books. You can read them to get overall view, but then switch to gtk documentation, gtk3-demo app for some recipes, gtk3-widget-factory source code and, of course, SO.
Related
If I'm running my model in Winbugs14 via a script, what's the command for thinning, or drawing box-plots? I know some of the basic commands, for example:
set(x)
update(1000)
density(alpha)
but I couldn't find the commands for thinning, or drawing model-fit, or drawing box-plots on Winbugs14 documentation. Any ideas?
The complete list of commands is on pages 34-35 of the user manual:
https://faculty.washington.edu/jmiyamot/p548/spiegelhalter%20winbugs%20user%20manual.pdf
In particular I think you want:
thin.updater(thin)
dic.set()
dic.stats()
I'm not sure there is a command to draw boxplots but that can be done in other software e.g. R.
I guess you already know this, but development of WinBUGS stopped years ago, so you really should switch to either OpenBUGS or JAGS at some point soon. I am admittedly biased, but I think that the runjags R package is a good route for people that are familiar with WinBUGS but not as much with R - you could take a look at the first section of:
http://runjags.sourceforge.net/quickjags.html
I am using VS2012 for a course project that we started from scratch, We are to use C++ to create something like this (I think the aggregation part is reversed):
https://www.dropbox.com/s/w2zh7yltbups6cm/class.png
Well , we had that on paper , wrote the code for each class with no problems, except we can't test because each class depends on another that was not finished at the time.
Long story short : each class has its own untested code and VS does not detect any errors whatsoever and based on our previous experience we know that the code is correct, no syntax errors anyway.
When I start compiling some 500 errors come out of nowhere , some of them it says in "time.h" , I thought it was something wrong with the compiler , tried switching to C::B and see if it work but i needed a different compiler and I don't have the time to download any large files ,seriously , deadline in 2 days and internet speed sucks.
doing some research here (and googling around) I narrowed it down to cyclic dependencies and I learned that I can draw the diagram in VS and get code files , unfortunately it does it in C# while I have a C++ code (it has to be C++) .
How can I realize this diagram in C++ ? Which class should include which headers ?
How can I avoid this in the future ?
EDIT:
Solved it by removing all dependencies and disabling pre-compiled headers (Don't really know if I had to) , then I included each .h in its corresponding .cpp , then I included in each .h every header it needs to use.
All that did not really solve my problem , it was the declarations !!!
I did #ifndef myclass , #define myclass to each header and declared the used classes , I think it's what's called "Forward Declaration" (correct me if I'm wrong)
Anyway it finally compiled and I will start testing .
If you have any remarks then by all means , you can add them.
Cyclic "dependency" can be. Why not? Because they are not dependencies, but associations with visible navigability. But you have some problems here.
Reservation should better have navigation to Member. Backward it could be, too. But Reservation should have Member instance as attribute. It is more simple way.
Also Rental is a class representation of association between DVD and Customer. And should have their instances as attributes. Again, back navigation IS possible, but do you need it? Maybe.
Another problem:
Title-DVD aggregation has correct direction, but it should be Composite, for there are no DVD without Title.
Testing: You can do unit tests, isolating classes from other ones by mocking first. After debugging that start to replace mocks with real classes. After that try unit tests without mocking, then normal auto tests, with automatic input/output/comparing.
As for code engineering, download VP UML enterprise "for testing version" and/or Enterprise Architect of Sparx, eval professional version. They both can do code engineering in C++.
I have an OpenCL kernel that runs well but I want to look at the intermediate code. I use getprograminfo to pull out the binary and save it to a text file. I've tried this with nVidia, AMD, an i7 and a Xeon.
In all of these cases the binary is unreadable.
I understand that on OS X the chunk of data returned is actually a binary plist. I've found instructions for using plutil to convert it to xml, and they work.
It's still unreadable ... though I've seen instructions online that this is where you find the PTX code (in the case of my AMD 5870). There's the expected clBinaryData key but the data under that key is still one big chunk of stuff, not readable IL instructions in text form.
I'd really like to examine the intermediate language to assess inefficiencies in my use of the gpu. Is this simply not possible under Xcode? Or, what am I doing wrong?
Thanks for any information!...
If you run your program with following environmental variable set you should see .IL and .ISA files in your directory.
$ GPU_DUMP_DEVICE_KERNEL=3 ./my-program
Another way is to use AMD APP Kernel Analyzer (which comes along with AMD APP SDK) to look at the Intermediate file i.e IL and ISA.
(I am not sure whether AMD APP SDK available for MAC or not).
One more option according to APP SDK documentation, put the below in your host code.
putenv("GPU_DUMP_DEVICE_KERNEL=3");
References
AMD OpenCL Programming Guide
AMD Devgurus forum
(Making this a top-level answer so I can do some formatting.)
ocluser's answer was very helpful, in that it was enlightening and caused great learning, though it did not, alas, solve the problem.
I've verified that the environment variable described is being set, and is available to my application when run from within xcode. However, it does not have (under OSX) the highly desirable effect it has under Linux.
But, I now know how to set environment variables in 7 of 8 different ways. I also set "tracer" envars to tell me which methods are effective within the scope of my application. From the below, you can see that both the method of "edit scheme" to add arguments works, as does the "putenv" suggested by ocluser. What didn't set it in that scope: ~/.MACOS/environment.plist, app-specific plist, .profile, and adding a build phase to run a custom script (I found at least one other way within xcode to set one but forgot what I called the tracer and can't find it now; maybe it's on another machine....)
GPU_DUMP_DEVICE_KERNEL is 3
GPU_DUMP_TRK_ENVPLIST is (null)
GPU_DUMP_TRK_APPPLIST is (null)
GPU_DUMP_TRK_DOTPROFILE is (null)
GPU_DUMP_TRK_RUNSCRIPT is (null)
GPU_DUMP_TRK_SCHARGS is 1
GPU_DUMP_TRK_PUTENV is 1
... so, no this doesn't really answer the question, but expands on it a bit. Sorry if poor form. Thanks!
Have not given up and shall provide an actual problem-solver if I find one.
I've been assigned to pick up a webapplication written in some old Perl Legacy code, get it working on our server to later extend it. The code was written 10 years ago by a solitary self-taught developer...
The code has weird stuff going on - they are not afraid to do lib-param.pl on line one, and later in the file do /lib-pl/lib-param.pl - which is offcourse a different file.
Including a.pl with methods b() and c() and later including d.pl with methods c() and e() seems to be quite popular too... Packages appear to be unknown, so you'll just find &c() somewhere in the code later.
Interesting questions:
Is there a tool that can draw relations between perl-files? Show a list of files used by each other file?
The same for MySQL databases and tables? Can it show which schema's/tables are used by which files?
Is there an IDE that knows which c() is called - the one in a.pl or the one in d.pl?
How would you start to try to understand the code?
I'm inclined to go through each file and refactor it, but am not allowed to do that - only the strict minimum to get the code working. (But since the code never uses strict, I don't know if I'm gonna...)
Not using strict is a mistake -- don't continue it. Move the stuff in d.pl to D.pm (or perhaps a better name alltogether), and if the code is procedural use Sub::Exporter to get those subs back into the calling package. strict is lexical, you can turn it on for just one package. Such as your new package D;. To find out which code is being called, use Devel::SimpleTrace.
perl -MDevel::SimpleTrace ./foo.pl
Now any warnings will be accompanied by a full back-log -- sprinkle warnings around the code and run it.
I think the MySQL question should be removed, from this. Schema Table mappings have nothing to do with perl, it seems an out of place distraction on this question.
I would write a utility to scan a complete list of all subs and which file they live in; then I would write a utility to give me a list of all function calls and which file they come from.
By the way - it is not terribly hard to write a fairly mindless static analysis tool to generate a call graph.
For many cases, in well-written code, that will be enough to help me out...
Some of the developers on the project I work on have a habit of commenting their code to show which version of the product it was added for, e.g.
// added for superEnterpriseyWonder v2.5
string superMappingTag = MakeTag(extras);
if (superMappingTag.empty())
{
autoMapping = false;
}
// end added for superEnterpriseyWonder v2.5
Whenever I see this my blood pressure rises, and I have to spend 5 minutes browsing SO to cool off. It seems to me that they don't understand version control and if I were to use this practice too every other line in the source files would be a comment about when things were added. I'm considering removing all such comments from files that I work on, but am wondering is it just me being picky and is there actually some value to these comments?
If you're using Source Control then I would advocate adding a build label to Source Control after every build. That way you can search for all source modified for a specific build, with no nasty comments clogging your code.
This from Clean Code, a book by Bob Martin:
"The proper use of comments is to
compensate for our failure to express
ourself in code. Note that I used the
word failure. I meant it. Comments are
always failures."
I always think of that quote when I see a comment so I'm not suprised your blood boils.
No value whatsoever. If you have a blame tool in your version control this will achieve this, they just add noise.
Whats worse is they will attract further comments to your code to make it completely unreadable
// added for superEnterpriseyWonder v2.5
string superMappingTag = MakeTag(extras);
if (superMappingTag.empty())
{
// bug fix #12345674 shuld have been true
autoMapping = true;
// bug fix #12345674 should have been true
i++; // v2.6 now need to up the counter DO NOT DELETE
}
// end added for superEnterpriseyWonder v2.5
and then someone will delete the method but leave the code comment in
// added for superEnterpriseyWonder v2.5
// bug fix #12345674 should have been true
// v2.6 now need to up the counter DO NOT DELETE
// end added for superEnterpriseyWonder v2.5
Just say no to crappy comments
I'd say there's no value: This info can also be retrieved with your SCM's annotate/blame functionality. Also, anyone can add text between these comments, which make the comments dated (since you might add something for v2.6 while the comments say v2.5)
Another thing to note is that these comments are essentially hidden: You only see them when you are looking at the source code in question, so you can't use it to generate a changelog or something.
The comment as shown, is probably not to useful. However, there may be times that adding a feature may cause the addition of not so obvious code. In which case, a comment describing the change and/or why it the code is not obvious would be appropriate.
Not only is there no value here...there's negative value. Maintenance of comments is already sketchy in most places, this just adds another thing for people to screw with. These comments have no value to the reader and are therefore clogging their brain up with useless version information when they could have another line of code in their memory. It's also another line to have a merge conflict on (totally not joking here..I've seen merge conflicts on comments).
Could be useful in some cases (e.g. if this helps to understand why some function works differently in V3 than in V2) but in general, it's the job of the SCM to know what has been added when.
You are not picky IMHO. There are at least three good reasons not to add this type of comment in source code:
their place is actually in a Version Control System, where you can have a global view of everything that has changed to accommodate a new version of a library or a new feature. Provided it is done correctly and the logs are used.
if the source code is part of the deliverables to clients, maybe they don't need to know the history of what happened. Imagine you have done a modification for another client, and put that in comments!
too many comments are no better than too few.
The line is not clear though, what would be the difference between
// Compliance with specs abc (additional xyz feature)
...
... // some code
and:
// xyz feature:
...
... // some code
In general terms, I would not put anything that is related to the history in the source code, but stick to commenting what is done, how it is done, so that someone else can easily browse through the code and understand it.
My advice: have a methodology document written, or an informal discussion.
If seeing a superfluos comment makes your blood pressure rise, you need to take up drinking or something.
That said, I agree that such comments are mostly useless. If used consistently, the program would quickly become a maze of such comments. What if a line is changed once for version 2.5 and then a year later changed again for bug 3294? Do you put two "version" comments on the same line, or just keep the latest? If you only keep the latest, then you've lost the fact that this was originally added for 2.5. If you keep them both, what happens when there's a third change or a fourth? How do we know what the state was at each change? What happens when you add a block of code in version 2.5, and then for version 2.6 you add another block of code embedded within the 2.5 block? Etc etc. The program could easily end up having more version comments than lines of code.
If not done consistently, the comments would quickly become misleading. Someone could put a comment saying this block was added for 2.5, someone else could insert code inside that block for version 2.6 and not comment it, and now we have a comment that seems to say that the second block was added for 2.5.
And do we care that much? It's pretty rare that I care when a change was made. Oh, okay a couple of weeks ago I cared because I wanted to know who to blame for a major screw up.
As others have pointed out, version control systems do this for you on the rare occasions when you need it. I guess if you didn't have any sort of VCS, a case could be made for doing this. But you can get some very nice VCSs for free. If you need one, get one. Otherwise you're like the people who say that you should practice doing arithmetic in your head because otherwise what would you do if your calculator quit working. The assumption apparently being that at any moment, all the calculators in the world might simultaneously break.
You might say that it can help to be able to say, "Ohhhh, this was added to order entry to support the new salesman timecard function" or some such. But then the important this is not "This code was changed by Bob for version 3.2.4", but rather, "This code produces this data which isn't used here but is needed by another module over there".
I am a firm believer in writing comments that introduce sections of code and describe the general idea behind complex or otherwise non-obvious code. But that's an entirely different thing.
Consider that some may have to grab snapshots from the VCS. In that case, they don't have history to fall back on .. and such comments become useful.
I saw that a lot in code written by people that didn't use version control until recently. I guess they just took the habit and now it's hard to stop.
Another reason I found was that sometime it is important to know what piece of code is associated with what version. Of course you can always check the version log, but you don't always have time for that, and it's annoying. In some cases saying "code for v3.2" speaks more to other developers than "code to do x, y and z"... it all depends on the conventions established by the team.
Another answer is that in some projects I worked with some code was commented like that, but it was before the project actually started using version control. In that case it also made sense to keep it that way.
I find them useful, it saves chasing through the VCS to find out why a change was made to the code, or to find the BugId for a defect, given I remember what the code change was.
Although in theory the VCS contains the information, in practice it can get buried, particularly by integrations.
In other works which is easier:
// DEF43562 - changed default value
foobar = true
Or
blame(or equiv)
chase through
history to find the correct change.
Follow integration to source, and
repeat 1&2.
Find bug id attached
to original change, if you are
lucky.
Basically the comment is a short-cut around the VCS, and flaky VCS/BugTracking integration.
I find that the comments are also useful as a marker for: "This decision has been reviewed by customers/users/review committee, and this is the selected answer, be careful about changing the behaviour".