Useful for test plans, etc.
Insert a field each time you want a number produced, with the formula “Seq XYZ”, where XYZ is any arbitrary label you want. (It won’t appear; it just gives a name to the sequence and ensures that each item with that name gets a unique number).
More advanced tips here.
Back in November I was having difficulty getting the S60 3.1 SDK to run on Parallels. At that time I had access to some Symbian OS source code (through a contract) so was able to debug it. (Albeit not the S60 version, so hacking binaries was needed in the end.)
Now I’ve run into the same problem with the UIQ3.1 SDK, and my previous fix doesn’t quite work! And of course now I have no access to any source code to debug it. However I think I’ve found a fix that works.
Fortunately, my previous instructions contained enough pointless irrelevant information to enable me to figure out a fix this time round.
In short, here’s the change you need to make to your epoc32\release\winscw\udeb\ecust.dll binary.
0002e40: 0000 5959 5dc2 0400 b8bc 1041 00e9 ee5b ..YY]......A...[ 0002e50: 0000 5589 e56a ff68 9d2f 4000 64ff 3500 ..U..j.h./@.d.5. 0002e60: 0000 0064 8925 0000 0000 5053 5657 83ec ...d.%....PSVW.. 0002e70: 2851 b8cc cccc cc8d 7c24 04b9 0a00 0000 (Q......|$...... 0002e80: f3ab 5989 4dbc c745 c000 c93d 006a 0fc7 ..Y.M..E...=.j.. 0002e90: 45fc ffff ffff ff15 4042 4100 50c7 45fc E.......@BA.P.E. 0002ea0: ffff ffff ff15 4442 4100 8d45 c450 c745 ......DBA..E.P.E 0002eb0: fcff ffff ffff 1548 4241 0083 f800 0f84 .......HBA...... 0002ec0: a800 0000 8b45 c048 4848 4848 4848 4848 .....E.HHHHHHHHH 0002ed0: 4848 4848 4848 4848 4848 4848 4848 4848 HHHHHHHHHHHHHHHH
The reason the previous fix didn’t work is that the 84a8 instruction I suggested modifying previously no longer exists. Judging by the other stuff around (in particular the series of 4848484848…) this appears to be the same area of code, but no 84a8. Who knows why – maybe a new compiler version, or slightly changed code, or something.
Fortunately, though, in my previous post I’d noted that it was a loop over 4000000 iterations. 4000000 in hex is 0×3d0900. A bit further up (both in the old code and the new) we see 0009 3d00. Changing the digit before the 9 from a 0 into a c worked. It means the loop runs (many) more times, and therefore Parallels’ high-resolution timer is sufficient to distinguish the start and end of the loop.
(In fact, fiddling around with this number, I find that changing it from 4000000 to 8000000 is sufficient. You may experience differences…)
Yuck.
The standard Java libraries come with a convenient package for reading and creating Zip files (java.util.zip). The class representing a Zip file entry has a method isDirectory() which can tell you whether the entry is a directory.
Unfortunately there is no counterpart, setDirectory(), that can be used when you are creating a zip file.
Usually this doesn’t matter, because when you zip up a file and provide it with a path, the unzipper will create all the directories required to store the file in that path. The only problem, then, is if you need to store empty directories which contain no associated files.
Several solutions are found on the web for this, usually involving storing a slightly different type of filename. The Java API documentation itself suggests that any path ending in a slash will be regarded as a directory. None of these solutions work.
The reason none of them work is that there is actually a bit in the Zip file specification which is used to represent directories (in fact, the relevant bit of the Zip file structure is entitled ‘external attributes’ and is supposed to represent the DOS equivalents – set bit 4 to represent a directory). You can find PHP, etc. code on the web setting this field to 16 to represent directories. The Java zip classes simply don’t set that bit.
Solutions:
This is amazing. More details here.
Most people who ever touch Java come to hate the CLASSPATH environment variable. It always needs tweaking to enable Java to load the desired classes. Eclipse, therefore, totally ignores it. One of the features of Java is that you can replace the standard class loader with your own. Eclipse does so; and in fact each Eclipse plug-in has its own class loader.
You then just specify which other plug-ins yours depends on, and it all works beautifully, 99% of the time. It really does.
The only problem is in the very rare circumstances when a plug-in is dependent on classes from some other plug-in which it can’t predict in advance. One such situation applies to Macrobug tools: I have lots of plug-ins which contain events relating to what’s happening on the device. One feature of the tools is to save that stream of events so that it can later be replayed. I’m doing this using Java Serialization, which is an easy way to convert an arbitrary network of Java objects into a stream of bytes which can be written to file – and back again.
The problem lies with that ‘back again’ bit. The plug-in responsible for reading this event stream (com.macrobug.eventrecorder) needs to be able to load classes from myriad other plug-ins which have events that got recorded.
That’s usually impossible, and for that reason I massively constrained the original class structure so that my recordings only contain very basic generic types from plug-ins which the event recorder can safely rely on.
But today I’ve come across this article, most of which I already knew – but not the bit about registering ‘buddy’ class loaders. So, all I have to do is ensure that all my event-providing plug-ins register themselves as a buddy of the event recorder plug-in: and in future, the event recorder plug-in will be able to load classes from those plug-ins!
Hooray. I only wish I had known this months ago.
A while ago I posted that I was going to try to de-eclipsify my software. That involves removing the reliance on fundamental Eclipse facilities – for example, the standard Eclipse classes for paths or memory addresses, or plugin loading – so that the code can be used with standard Java, and no Eclipse present.
I’m doing this partly because I may wish to produce tools which do not depend on Eclipse, but mostly because there are areas for which I don’t currently have a test suite because of these Eclipse dependencies. It will be much easier to test many bits without having Eclipse in the mix.
On the way, though, I experimented with producing standalone Eclipse applications (called RCP – Rich Client Platform – applications). It was very easy, and the resulting application can be used as a standalone GUI application or from the command-line. I could, therefore, have retained my Eclipse dependence if I’d produced everything this way. Unfortunately, though, even the tiniest RCP application seems to weigh in at many megabytes so this didn’t seem the right thing to do for simple command-line tools.
Having said that, I’m still planning on producing tools which use Eclipse’s Draw2D API for graphics – which can then be exported to PDF and/or SVG. So, it’s a bit odd, but I might be producing command-line Eclipse applications which utilise these Eclipse drawing APIs to create graphics.
It’s all so Web 2.0 and fashionable. I have been trying to resist it for months now.
However, it does have a nice photo exporter from iPhoto and appears to accept an unlimited number of photos, so I’m going to use it to store my photos. Sorry for any suckers that therefore get sucked into Facebook because they want to look at them.
Business relevance? None really, but I’m going to pretend it does by mentioning that this tiny simple iPhoto exporter has made me want to use the whole Facebook ecosystem. Perhaps a tiny simple Symbian OS debugging tool will make lots of phone makers use Symbian OS in more of their phones?!!
This should allow me to step between Java code and native code when producing JNI Eclipse plug-ins. In theory. It’ll be really interesting to see if it works, next time I need to actually do that.
Eclipse is very good at creating Eclipse plugins. No surprise there. It’s also very good at creating JAR files for use outside Eclipse. But if I want to write some Java code for use inside Eclipse and outside Eclipse, it’s not obvious what to do. So far I’ve found various different methods, all of which have pros and cons.
| Method | Pros | Cons |
|---|---|---|
| Create single PDE project. Use in both a PDE and a JDT context, exporting as a JAR when necessary | Works, mostly | Slightly odd behaviour relating to the cleanliness of projects – sometimes it doesn’t seem to build the project properly when it’s used from another non-Eclipse project. I don’t know if that’s because I’ve added a PDE nature. Secondly, I need to make sure that I don’t use any Eclipse classes within the code |
| Create entirely independent Java projects. Use my source-code-management system to keep the source code synchronised, roughly, between the two. | I think this is what the Eclipse designers probably expected. It’s always wise to go along with what the software designers expected, or you’ll run up against their invalid assumptions later on. Especially with Eclipse. | Each time I change the code for the Java project, I have to go and mess about in Subversion to copy the code across to the plug-in project (or vice versa). Not practical at all. |
| Create a standalone Java project. Use PDE to “convert to plug-in project”. | Irrelevant. Just converts one type into another – doesn’t allow the two to exist together. | |
| Create Java project. Create JAR exporter. Export as JAR. Create “Plug-in project from existing JAR archive”. | Resulting plug-in project works well. | There is no way to automate the export as a JAR. I can make it a bit easier by saving the JAR’s manifest and its .jardesc file somewhere in subversion. But each time I change the original code, I’d have to right-click on the jardesc and select ‘build JAR’. This method might be viable if there were a way to export the JAR-production process as an Ant buildfile, so that I could build it each time I build the original Java project. Unfortunately, although that seems possible with some of Eclipse’s exporters, the JAR exporter doesn’t seem to be one of them. |
| Create Java project. Create plug-in project. Delete ‘bin’ folder. Create new linked folder pointing to the ‘bin’ directory of the original project. | Doesn’t work. Eclipse gets confused that it doesn’t have to build any source code, and some features of the PDE seem to depend upon the presence of the source code rather than the binaries (such as the nice selection of classes within the plugin.xml and MANIFEST.MF editors). | |
| Create Java project. Create plug-in project. Delete ’src’ folder. Create new linked folder pointing to the ’src’ directory of the original project. | It works! | Eclipse builds two copies of binaries. I don’t fully trust it to observe changes in the original source code and rebuild the binaries properly (I guess it ought to be OK – there’s no real reason why dependency tracking should work less well over linked folders). When debugging, I don’t trust it necessarily to open the source code properly. If it does, I seriously doubt that Subversion will allow me to work with the linked folder. Makes my projects non-mobile, since I have to include absolute file locations in them. |
I’m a little suspicious of the first, most obvious, method but that’s what I’m going to stick with for now.
To those who work outside software, you may be wondering what ‘CM’ is. It stands for Configuration Management, and (largely) refers to the backing up of every single change you make to your software. That would be simple. But it also takes care of the fact that several people may be making changes at once. It backs up each of their changes, and provides some sort of facility to merge them back together again when desired. These parallel lines of development are usually called branches.
What use does Macrobug have for that, I hear you ask? With only one developer…Well, the developer in question (me!) works on several different things at once. I have one branch (’trunk’) which contains all Macrobug’s most stable code. There are also branches representing experimental major development I’m doing, for example, trying to rip out Eclipse dependencies from the heart of my code. And finally there are branches representing release-quality code. Except I haven’t got any of those yet.
Why am I thinking about CM at the moment? Because when designing these branch structures, it’s easy to make assumptions. Right now my branch structure contains the word ‘Eclipse’ – whoops. If ever I want to remove dependency on Eclipse, I have choices:
At Symbian I was always massively careful to avoid such assumptions because I knew the pain of moving away from them later. I tried here too, but missed this one. I’m not sure what to do yet. Ah well. Not a big deal in the grand scheme of things.