|
» Subscribe » Favorite Links » What is S60? » Freeware & Trials » S60 devices » Hints and tips » About this blog |
» Blognotes (15) » Bugs and Workarounds (4) » Build tools (5) » Carbide.c++ 1.1 (4) » Carbide.c++ 1.2 (8) » Carbide.c++ 1.3.x (8) » Carbide.c++ 2.0.x (1) » Carbide Plug-Ins (4) » CodeWarrior (2) » FAQ (6) » Future directions (24) » General (46) » Off-topic (4) » On-device debugging (13) » Performance Investigator (2) » Product features (16) » Product releases (16) » Screencast (12) » Support (30) » Tool setup (5) » UI Designer (8) » Usability (15) » Work in Progress (13) » Write-build-debug (4) |
|
» Where's my console output? » S60 Build Performance: Don't Forget to Update Your Makefiles » Saving RAM space when developing Java apps » Capability Scanner on S60 3rd FP2 |
|
Subscribe to RSS feed For email notification, please click here ยป |
In Carbide 1.3.1 we revamped the wording and internal code for the generation of console output. Mainly this was done to unify the option's wording and make it easy identify which console program and error output was sent to. Remember, the Console view has several default pages associated with it.
However, an additional step was overlooked in the Carbide manual, the editing of the epoc.ini file, which must be made for a couple of these options to work. Here's how to correct that.
Continue reading "Where's my console output?" »If you are building scalable (SVG) icons for your S60 application, chances are you are using makefiles without dependency tracking. I've noticed quite a few large projects that contain several icon makefiles without proper dependency tracking which can vastly degrage rebuild performance. For example, taking 15 minutes to rebuild instead of 10 seconds for a dependency check. This is typically due to header files that are always generated under \epoc32\include (e.g. MBG files) and causing subsequent CPP files to be unnecessarily re-compiled and the project re-linked.
Continue reading "S60 Build Performance: Don't Forget to Update Your Makefiles" »Though Carbide C++ is a C++ development environment, I am sure that many developers develop Java apps for s60 as well. We had a weird problem when reading a large file into a java byte array. Despite the fact that I had 1 GB allocated to Java VM, I was getting 'Out of memory' exception when trying to create 100MB byte array. The solution to this problem is to use a MappedMemoryBuffer class from nio package. It doesn't allocate the memory but instead maps the memory buffer to the file in the file systems. It is even more useful for the s60 development, since the available memory on the devices is really small. It is nice to use nio APIs for s60 Java development!
We just noticed a glitch in the S60 3rd FP2 SDK: The capability definition files are out of date. The consequence is that if you run the capability scanner against this SDK is will likely miss most of your capabilities and report that you don't need any.
Luckily the solution is easy: Just delete the 'capabilities' folder and contents under:
Then run the scanner again. Carbide contains the most recent capability definitions for all the S60 3rd SDK editions to date so when they aren't in the SDK, Carbide will use the ones installed in the IDE.
Tim