I just read some reviews of Fedora 10 compared to Ubuntu 8.10. Because I am an Ubuntu fan boy I need to justify my reasoning of saying it is better. The reason I like Ubuntu more is not OS to OS but the people behind them. Canonical says Ubuntu will always be free not matter the version. Fedora is just the test bed for Redhat. Not to dis redhat. Redhat puts a lot of code back into a lot of good open source projects. It is just they still have to sell there server stuff. I like the Ubuntu idea of free for everyone and pay for just support. It does remain to be seen if Canonical can make money this way for the long term. So I guess that is about it. I think both OSs are good and very close to the same. I just like Ubuntu more (for the moment). I also like that fact they have something to complete for.
Ubuntu does have a large amount of online forum stuff.
Ubuntu uses .deb which are easy to look inside and I think work nice
Ubuntu is working on bazaar to have all there packages in
Saturday, November 29, 2008
Saturday, November 22, 2008
Google fan boy?
So at work yesterday a coworker said I was a "Google fan boy". Having written a post about Google C++ software the night before I would have to agree that I am. This also made be think are we not all fan boys/girls of something? Every developer has to pick a baunch of tools to do anything. You need an OS, a language, an editor, a compiler, a version control system, and more. With all of these things comes a lot of chooses. It seems to me that I get one and in my mind decide it is better then the others. I would say Linux is the best OS and so on. To be happy with my chooic I find myself being like well Linux is best because of X, Y, and Z. It is not that I don't find some bad parts to all the things I use, but I have to tell myself at some level the one I am using is the best or else I would just send all my time looking for the best. When I do find one that is better I move to it and become its fan boy. If you not a fan boy of something you what are you?
Thursday, November 20, 2008
Google goodness
If you write much code in c++ you might find the standard library a bit lacking compared to other languages. I know for example python and java both have a lot more stuff in the standard library. The C language has a lot of good stuff in libraries like glibc that can be used in C++, but it has always felt to me C++ lacks tools. Because of this lot of different third party library are out there. The thing I don't like about this is they are not standard and you end up with five libraries doing the same thing have way. Anyway enought ranting if I don't like it I should start using python. What I am trying to get to is lately I have found a lot of handly simple libraries coming out of Google. So I will list some and what they do and why I think they are nice.
Memory allocation with tcmalloc (google-perftools)
I have post about this before a little and how in linux at least it is very easy to change the libc memory allocator with others like jemalloc or tcmalloc. So far I have not used tcmalloc much but it is a nice tool to have around because it is suspose to be fast and not frament the memory as bad. It also has a lot of stuff to debug memory leaks and so on. The coolest thing is it is very easy to test you don't every have to recompile your code to see it in action just preload the library.
Command line parsing with gflags
In libc there is get-opt which is not a bad way of parsing the command line but it is C and very bare bones. The gflags library is a nice step up. I make a help flag for you and you can add flags in different parts of the code. I find that nice if I just need to make a setting I put the flag code there and move on. I sure some people who say it is bad for some reason, but to me in a small project it is easy and fast.
Logging with glog
I have looked into logging library a lot over the last few year. Now of them have every looked great to me. Log4cxx I discovered is powerfully and the best I have seen but it depends on a lot of stuff and is almost to complex. That is why when I turned up glog I was very happy today. I thought google would have a logging library but could not find it. I looks like the open source release of glog was very recent. I have not dug very deep but it looks like a good project done google style. It can also use gflags if you already have that which is nice. As it goes to a 1.0 release I think it might just become my logging library of choose.
Serialization with protocol buffer
Now this one is not just for C++ and has Google support for Java and Python with many other langages getting supported by the open source comunity. It appears this is one of Google's core technologies and I am betting must people have used them if they used the internet in a round about way. Anyway for C++ this is nice because again there is not standard serialization stuff. With C++ running closer to the metal serialization is not a fun cross platform thing to handle. Protocol buffer's has some nice ideas and seem easy to use for simple stuff. You just make a message in Google made up way and then it ran a compiler type thing that truns that into C++ and you are ready to put stuff on the disk or send it to Mars. It has nice stuff to add thing latter which is important.
Testing with gtest
Now that you have all these nice libraries to write code with you need to test that code. That is where gtest comes in. Again it seems simple, clean, and easy to use. It can even create colored output. If you are into unit test it seems a good as choice as any. I still don't know how to write good test and in some types of code it seems hard to test. But if I do I would look here first.
Compiling with distcc
Now that you writing all that code want compile it in a fast way. Well if you have a few computers setting around try distcc to speed up that compile time. While not created by Google it is now being develop by Google.
Well I am sure I forgot something but that is my list of Google goodness. Here at pezad games I see the tcmalloc, protocol buffers, gflags, and perhaps glog being the usefully. But until I quit stalking Google and start writing more code we will never know :).
Memory allocation with tcmalloc (google-perftools)
I have post about this before a little and how in linux at least it is very easy to change the libc memory allocator with others like jemalloc or tcmalloc. So far I have not used tcmalloc much but it is a nice tool to have around because it is suspose to be fast and not frament the memory as bad. It also has a lot of stuff to debug memory leaks and so on. The coolest thing is it is very easy to test you don't every have to recompile your code to see it in action just preload the library.
Command line parsing with gflags
In libc there is get-opt which is not a bad way of parsing the command line but it is C and very bare bones. The gflags library is a nice step up. I make a help flag for you and you can add flags in different parts of the code. I find that nice if I just need to make a setting I put the flag code there and move on. I sure some people who say it is bad for some reason, but to me in a small project it is easy and fast.
Logging with glog
I have looked into logging library a lot over the last few year. Now of them have every looked great to me. Log4cxx I discovered is powerfully and the best I have seen but it depends on a lot of stuff and is almost to complex. That is why when I turned up glog I was very happy today. I thought google would have a logging library but could not find it. I looks like the open source release of glog was very recent. I have not dug very deep but it looks like a good project done google style. It can also use gflags if you already have that which is nice. As it goes to a 1.0 release I think it might just become my logging library of choose.
Serialization with protocol buffer
Now this one is not just for C++ and has Google support for Java and Python with many other langages getting supported by the open source comunity. It appears this is one of Google's core technologies and I am betting must people have used them if they used the internet in a round about way. Anyway for C++ this is nice because again there is not standard serialization stuff. With C++ running closer to the metal serialization is not a fun cross platform thing to handle. Protocol buffer's has some nice ideas and seem easy to use for simple stuff. You just make a message in Google made up way and then it ran a compiler type thing that truns that into C++ and you are ready to put stuff on the disk or send it to Mars. It has nice stuff to add thing latter which is important.
Testing with gtest
Now that you have all these nice libraries to write code with you need to test that code. That is where gtest comes in. Again it seems simple, clean, and easy to use. It can even create colored output. If you are into unit test it seems a good as choice as any. I still don't know how to write good test and in some types of code it seems hard to test. But if I do I would look here first.
Compiling with distcc
Now that you writing all that code want compile it in a fast way. Well if you have a few computers setting around try distcc to speed up that compile time. While not created by Google it is now being develop by Google.
Well I am sure I forgot something but that is my list of Google goodness. Here at pezad games I see the tcmalloc, protocol buffers, gflags, and perhaps glog being the usefully. But until I quit stalking Google and start writing more code we will never know :).
Saturday, November 15, 2008
Eclipse CDT: Clean out old lib references to remove invalid project path warnings.
I was removing some warnings before I committed some code, but there were two warnings that I could not remove. It happened to deal with "Invalid project path: Include path not found" not found, which is odd because the code compiled and ran just fine. As it turns out, there is a bug for it:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=206372
And in that post there is a fix for it as well under the second comment:
"To manually fix the file you need to move/delete the ${projectname}.sc file found under ${workspace}/.metadata/.plugins/org.eclipse.cdt.make.core"
https://bugs.eclipse.org/bugs/show_bug.cgi?id=206372
And in that post there is a fix for it as well under the second comment:
"To manually fix the file you need to move/delete the ${projectname}.sc file found under ${workspace}/.metadata/.plugins/org.eclipse.cdt.make.core"
Sunday, November 9, 2008
Weekly Pezad Game Update?
So I was think we should start some kind of weekly status report here at pezad games. This is just my idea so it might not keep happing, but this will be a trail run.
bzr:
First off I have been all about Distributed Version Control (dvc) as of late. The three big ones I know about are bzr, git and hg. I have not done a complete comparison but I have looked at them and read about this some. I know git is suppose to be the fastest but it takes very large projects to make this important. I know the least about hg and I don't really have a good reason for that. I have the most knowlegde of bzr. I have used bzr and beleive it copys svn for the most part more then the other two. Having started using version control with svn I like this. bzr is also used by Ubuntu my distro of choice as of late. So without a lot of carefully study I have choose bzr as my next version control system. I found the documentation was also good.
So I used it some as a locate repostory (a cool feature I think for small projects) and it was easy to just worked. Next I was saw with had and svn plugin so it could branch and svn repos and I tried that. Sadly a year or so ago when I first tried this I could not get it to work. As of ubuntu 8.10 the default bzr and bzr-svn plugin seem to work much better. I have branch svn repos and it seems nice. Now I have not tried making a commit back and need to do that. I have high hopes this will work some way or enough.
The other important thing I wanted is eclipse plugin support. Once again I could not get this to work until Ubuntu 8.10 and using eclipse 3.4. I did not try very hard before, but now it seems to just work. I have a lot more testing but things are looking up. All the project bzr, bzr-svn and the eclipse plugin look like they are under active development so they should only be getting better as time goes by, but it looks like they have reach a point that feel I can start using them. That is if I don't hit some unknown road block.
So the point of all that is I would like to see the pezad team move to using bzr over svn in the future. For now svn has all the power we need but I just think bzr has everything svn has plus move and I think it is easy to use in genreal. I will need to do some more testing but that is the plan as I see it.
OpenGL:
I have been reading more of the OpenGL red book and trying to get my know and skills up on that so I can at least read code with OpenGL and start to understand what is going on. Hopefully I was start writing more OpenGL code soon. I feel if I do any thing reading that book is a good place for to keep working.
TicTacToe:
So the two pezad developer (are there just two?) have decide to start on some simple games and work from there. After that I read a good peice on this very same idea. We dicided to start with TicTacToe. It turns out that was one of the first computer games every so a good place for us to start I think. So far I have done little be Redsaz has done a lot. The hope has been to have it working soon, but that keeps not happing. As soon as there is a work code we will blog about it I am betting.
Ending up:
Hopefully I start writing more code and stop looking into every new and cool tool (but tools are cool) and perhaps we will keep a weekly update on the status of things. If anyone does happen to read this and want to join are learning trip of gaming making just let us know and we will be happy to have you.
-penguin
bzr:
First off I have been all about Distributed Version Control (dvc) as of late. The three big ones I know about are bzr, git and hg. I have not done a complete comparison but I have looked at them and read about this some. I know git is suppose to be the fastest but it takes very large projects to make this important. I know the least about hg and I don't really have a good reason for that. I have the most knowlegde of bzr. I have used bzr and beleive it copys svn for the most part more then the other two. Having started using version control with svn I like this. bzr is also used by Ubuntu my distro of choice as of late. So without a lot of carefully study I have choose bzr as my next version control system. I found the documentation was also good.
So I used it some as a locate repostory (a cool feature I think for small projects) and it was easy to just worked. Next I was saw with had and svn plugin so it could branch and svn repos and I tried that. Sadly a year or so ago when I first tried this I could not get it to work. As of ubuntu 8.10 the default bzr and bzr-svn plugin seem to work much better. I have branch svn repos and it seems nice. Now I have not tried making a commit back and need to do that. I have high hopes this will work some way or enough.
The other important thing I wanted is eclipse plugin support. Once again I could not get this to work until Ubuntu 8.10 and using eclipse 3.4. I did not try very hard before, but now it seems to just work. I have a lot more testing but things are looking up. All the project bzr, bzr-svn and the eclipse plugin look like they are under active development so they should only be getting better as time goes by, but it looks like they have reach a point that feel I can start using them. That is if I don't hit some unknown road block.
So the point of all that is I would like to see the pezad team move to using bzr over svn in the future. For now svn has all the power we need but I just think bzr has everything svn has plus move and I think it is easy to use in genreal. I will need to do some more testing but that is the plan as I see it.
OpenGL:
I have been reading more of the OpenGL red book and trying to get my know and skills up on that so I can at least read code with OpenGL and start to understand what is going on. Hopefully I was start writing more OpenGL code soon. I feel if I do any thing reading that book is a good place for to keep working.
TicTacToe:
So the two pezad developer (are there just two?) have decide to start on some simple games and work from there. After that I read a good peice on this very same idea. We dicided to start with TicTacToe. It turns out that was one of the first computer games every so a good place for us to start I think. So far I have done little be Redsaz has done a lot. The hope has been to have it working soon, but that keeps not happing. As soon as there is a work code we will blog about it I am betting.
Ending up:
Hopefully I start writing more code and stop looking into every new and cool tool (but tools are cool) and perhaps we will keep a weekly update on the status of things. If anyone does happen to read this and want to join are learning trip of gaming making just let us know and we will be happy to have you.
-penguin
Subscribe to:
Posts (Atom)