Archive for February, 2012

How new programming styles and paradigms makes one stupid

Monday, February 20th, 2012

I think we all know by now how a big resource hog every single application today is.
I’ve been ranting for a while on browser memory hogs. All major of them. This are still unchanged. My FF currently eats up 2 GB of memory.

Here’s another fine programming example:
I was installing flash player 11.1, upgrade. However, the idiot started after my browser with about 100 tabs opened. So I left it running for the day in order to not forget to update at the end of the day.
And at the end of the day, I don’t remember why, I checked the task manager and surprise surprise: the upgrade program used 2 hours of CPU time, 300 MB of memory and 2.131.894 handles open…. over 2 million open handles.

Are you guys nuts?

Do none of you understand that system resource ARE FINITE and LIMITED?

Related posts

Delphi XE2 bug: memory leak

Friday, February 17th, 2012

That’s an easy one to reproduce if you are building a lot. All you need to do is keep building. Same project, or different one. Just keep building and watch the memory grow, grow until you get an Out of memory error.

Xe2 SP3. seriously? is this your level? The basic operations in your second version of XE at the 3rd service pack are still not working right? When in Gods name are you going to release a XE2 IDE that builds right? Am I really asking for too much? I haven’t even gotten to test the unicode and 64 bit support as I’m still migrating (way too many projects) and I’m already sick of this. All I want is to build. A very simple and basic command. The first one you use when you are building your application in order to be able to test it.

I just can’t believe this. Memory leak? COME ON!!!

Related posts

Delphi XE2 bug: nested option set depth limitation

Wednesday, February 8th, 2012

Some time ago I bumped into a very odd limitation on option sets (beside the bug I posted earlier). It’s about nested usage, when you have nested build targets, each with its own option set. You can see a more descriptive example in the stackoverflor post below:

http://stackoverflow.com/questions/8863041/delphi-xe2-option-set-nested-limit

I got to tell you, there are quite a lot of annoying bugs I keep bumping into with this XE2. I was so happy to see all the supported features that ease building so that I won’t have to write up complex batch files for it but bummer, they are buggy or don’t work at all.

The stupid thing is that if I modify one common file located some 10 packages up in the groupproject, I have to rebuild ALL the 10 packages, with ALL the 8-10 build targets.

Oh well, back to batch files.

Related posts

Delphi XE2 bug: build events not saved in option set

Wednesday, February 8th, 2012

As I’m working on a groupproject with a lot of projects each having a lot of (the same) build targets, I decided to go with option sets to have a good centralized control over things.
The surprise came when the build events didn’t work anymore the next day after I added them. Took me a little to figure out they were not saved. A little googling turned out he issue to be reported since well over a year on D2010. It’s “good” to see the bug to have gone by over 2 versions and a lot of updates.

Related posts

Delphi XE2 bug: build multiple targets

Wednesday, February 8th, 2012

When Building multiple targets on a project (like release and debug, in the same time (that is you select them all, shift select) and rightclick and then build, you will notice that the configurations used are those of the active configuration. So if you have the release active, then even though it builds the debug, it will do it with the release configurations (that includes option sets as well).
How to reproduce?
Have a project with multiple targets. Set different conditional defines in each (either directly or via option set, doesn’t matter), select them all, right click, and build. After the build, check the command line in the output and try not to curse. Took me about 2 hours to figure out why one of my projects was using a unit even though the conditional compiler directive was flagging to use another.

PS: if you think that using a build group saves you, surprise: it has the exact same bug.

Related posts