ISO files in OS X

To make one from a CD:

Insert the CD and use the “mount” command to figure out its device name. We want to unmount the CD without actually ejecting it.

sudo umount -f /dev/disk1s1s2

dd if=/dev/desk1s1s2 of=mynewimage.iso

I tried using `hdiutil eject /dev/disk1s1s2` to then eject the CD but that failed me. So, I rebooted and ejected the traditional way (drag the mounted CD icon to the trash in the finder).

Head of the Charles

This past weekend I rowed in the Head of the Charles Regatta, the world’s biggest. This was my second time rowing here. In 2005 I rowed in the Men’s Open Club 4+. This year I rowed in the Men’s Open Collegiate 4+. We got a penalty for “Aggressive Passing” (how are you supposed to pass?!?) and had a run-in with Duke, which caused us to finish in the middle of the pack. I wonder how well we would have done without those two incidents? Anyways, here are some pictures!

Subversion / SVN with Carbide C++

I’ve pasted this here from a Thread in Forum Nokia where I originally figured out what to do, with the help of some others. Here is the thread again:


Hello,

From what documentation I’ve managed to read, it seems that the current version of Carbide.c++ does not include support for SVN. Though there are plugins for the full version of Eclipse, these do not seem to work with Carbide.c++. So, even though there is no clean way to integrate SVN with Carbide right now, I’m looking for an interim solution. What project files must be included in the repository? What can be safely excluded? What kind of hang-ups can I expect?

For example, I suspect Carbide.c++ will want the paths to remain the same on all installed systems. This can be remedied easily enough by always checking things out into c:\project, or something similar.

Any other hints or war stories would be greatly appreciated.

Thanks,
-Jon


I have no experience and no warstories but..

– Any directories that have a build config name in them such as “S60 2.8 Emulator Debug” are autogenerated for each build and you should therefore be able to safely exclude them
– In the project root (in the workspace) you can find some files (.cdtbuild, .cdtproject and .project) that are “sort of” important
– Under the root dir there is a .settings directory with a file called org.eclipse.cdt.managedbuilder.core.prefs. This is one of the files causing issues as this one has fixed paths. You can just open with an editor to see what is fixed.
– Also we have some developer reports that settings are not written into the setting files above immediately but only some time later (not sure when) so you might need to do something like “Close project” to flush the stuff out.

Most importantly, it would be good if you reported any findings here, that would be most helpful.

Integration with various source control systems will be improved in the forthcoming versions of the product.


Hello,

Thanks for your reply; I have some [fairly positive] experience to report.

To get around the hard-coded path issue, we have just decided to always checkout to a fixed path, e.g. c:\stuff\workspace. I initially created that directory and committed it, empty, before starting my workspace / project in Carbide.

I then started Carbide, providing Carbide with the c:\stuff\workspace path at startup. I created my project(s) in Carbide (resulting in the creation of c:\stuff\workspace\project), added a bunch of source files, got things running, and then did a clean under each target I used (to get rid of the, e.g., S60 2.8 Emulator Debug directories).

I then did a recursive svn add of the \project directory, which added .cdtbuilt, .cdtproject, .project, .generated, and .settings\org.eclipse.cdt.managedbuilder.core.prefs, in addition to all the source code.

I suspect .generated is unnecessary, but it doesn’t hurt anything because it is just a directory, so I haven’t tried to remove it.

Then, another member of my team checked things out into c:\stuff. He specified c:\stuff\workspace when starting Carbide, but Carbide did not automatically show Project. He was able to do “Import Existing Project” and everything imported smoothly. I believe this action populated the c:\stuff\workspace\.metadata folder (note that I did not add the .metadata folder to SVN). He added another subdirectory within \project, which required changing the build settings in Carbide. He added the newly created source files to SVN, but did not take any deliberate actions with regard to Carbide-specific files. He then committed.

Now, back on my machine, …

When I did an update, I got a conflict on the file
project/.settings/org.eclipse.cdt.managedbuilder.core.prefs

I simply deleted the file, ran `svn resolved
project/.settings/org.eclipse.cdt.managedbuilder.core.prefs`, and did
another up to restore it.

I then started up Carbide.c++ with c:\stuff\workspace as the
workspace. Our project was listed as a project but when I expanded it the
new subdirectory did not appear.

I then right-clicked on the project and selected “Refresh”. At that point, the
new subdirectory appeared. I did a clean, then a build for ARMI. It just worked. 🙂

Hope this is helpful to someone…

Cheers,
-Jon


Somebody also added:

The Subclipse SVN plugin for Eclipse works fine with carbide.C++ Express, at least for me.
Reply With Quote