off hand, i'd say it is probably too early to tell. if this rosetta thing works as well as theSteve says, then current versions of N/J should be fine (which is a big FAT if)
We won't know until someone tries to run Neo/J on the new Intel machines.
Since I'd have to pay $1500 to get access to one of these machines, I have sent a request to Apple to donate a Mac Intel Developer Transition Kit to us. I don't know if my request will go anywhere, but I figured I'd ask them.
I have sent a request to Apple to donate a Mac Intel Developer Transition Kit to us. I don't know if my request will go anywhere, but I figured I'd ask them.
It can't hurt, indeed. And if not, maybe a deep-pocketed contributor could send a donation....
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
If we have to recompile, we won't be using XCode. We will need to update the makefiles and source code to compile directly with gcc 4.0. This is no trivial task, but it is far easier than trying to force the OOo build into XCode. Plus, XCode provides no advantage for us. If we have to recompile, Neo/J is so large that we would have a separate download so XCode's "universal binary" feature (which essentially means two sets of binaries in one application bundle) is not something that we can use.
I understand. So if rosetta fails we'll have* a neooffice/j ppc and a neooffice/j x86.
f.
* "we'll have" means " if pluby and ed could find energy to recompile all the stuff under gcc 4.0"
I remember a previous thread that highlighted the 2 main goals after Neo/J 1.1 is released.
1. Move to a Coca Java engine
2. Move to the Ooo 2.0 code
Knowing that Neo is currently using a Carbon Java engine, will it be absolutely necessary to change to the Coca engine to even start the transition? Considering Ooo 2.0, I'm guessing it would be more work to start working on an Intel version (for Mac ) than it would be to port over the 1.1 code?
Anyway, kudos to everyone working on Neo. I thought the Beta had everything I needed in a Mac app, but it just gets better and better.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Wed Jun 08, 2005 7:38 pm Post subject:
Like Patrick said, the universal binary approach is right out. There's really no point in starting until the ABI settles down from Apple and after we see if there are any gcc 4 failures. Also, like I mentioned in another thread, the way that the OOo process bootstraps into itself (it runs its own binaries), I don't expect it to be easy to get it to "cross-compile" either (and I certainly don't want to do the build system work for it ).
I am still unsure if the PPC emulator on the Intel machines will run the Java 1.3.1 VM in emulation. If it does, then we should be golden. If it doesn't, then we'll need to move. There's some caveats in the Universal Binary guidelines about bundled Java applications failing to launch or ones with incompatible JNIs. I suspect this may imply that they're not planning on shipping PowerPC Java virtual machines with it so apps like Neo which are "pseudo-Java" may have a tough time. Like Patrick, I don't have $1500 to plunk down for a machine I can't even keep just to find out
Posted: Fri Jun 10, 2005 2:49 pm Post subject: Rosetta, conversion, etc..
Listening to the TWIT podcast special, last night, Leo and Patrick interviewed a couple of small developers [and much smaller packages than NeoOffice/J] about their experience, so far, with Rosetta and the package for converting software to MacIntel.
Leo asked, "How long do you think it will take to convert your main product?"
The answer -- "It took about 20 minutes. Most of which was spent looking for the checkbox for Universal Binary."
Their trial with Rosetta before conversion was seamless and invisible with no apparent speed degradation.
Posted: Wed Jun 15, 2005 11:30 am Post subject: Re: Rosetta, conversion, etc..
Anonymous wrote:
Listening to the TWIT podcast special, last night, Leo and Patrick interviewed a couple of small developers [and much smaller packages than NeoOffice/J] about their experience, so far, with Rosetta and the package for converting software to MacIntel.
Leo asked, "How long do you think it will take to convert your main product?"
The answer -- "It took about 20 minutes. Most of which was spent looking for the checkbox for Universal Binary."
Their trial with Rosetta before conversion was seamless and invisible with no apparent speed degradation.
Hmmm. Where did you get this podcast? I'm a long time fan of Leo and Patrick (I'm assuming we are talking about the former hosts of TechTV's The Screen Savers.)
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Thu Jun 16, 2005 10:22 pm Post subject:
If you want more great testimonials you can just to to the ADC website and see them splashed across the banner. The one I liked was that it took longer to copy the files over then to produce the binary.
A real testimonial is going to be to head on to the Mac BU and ask them how painful the transition's going to be for them. They're in the same boat I was in at my real job...they're still compiling with Metrowerks. To move requires moving development environments and switching compilers. This took me a whole week for a < 500000 line program. Things that compiled just fine under Metrowerks for MachO broke in GCC as errors. Warnings became errors. And I haven't even gotten into the endian issues yet.
It really ticks me off that the line coming out of Apple is being heard by end users and is now giving everyone the assumption that it's no big hassle at all for developers to produce Mactel binaries.
It really ticks me off that the line coming out of Apple is being heard by end users and is now giving everyone the assumption that it's no big hassle at all for developers to produce Mactel binaries.
It would be nice if there were a way to temper that Apple-koolaid-optimism without causing fear, uncertainty and harm to the future of the Mac--because I know for sure that we're among the developer communities that will bear the brunt of the false expectations (like the KHTML devs when WebKit passed Acid2...).
I'm still afraid we're going to lose a lot of apps from devs/companies in the same situation but without the massive resources (and Apple hand-holding) that MS and Adobe have....
Knowledge, in this case, is fear
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Fri Jun 17, 2005 9:13 am Post subject:
To be fair, it is a lot easier for developers who have drunk the Apple koolaid and jumped onto their grand dev tool Objective C + Cocoa binge. Using the regular Apple frameworks and development tools makes life a lot easier. Unfortunately, a lot of big apps don't follow the Apple route for any number of reasons (legacy code, portability, tool preference). I think it's more those that will be the ones that may not survive the transition unless they're niche enough to justify the effort. Heck, I can't even get print drivers from Lexmark that are compatible with 10.4 and it's not like they're a small company.
To be fair, it is a lot easier for developers who have drunk the Apple koolaid and jumped onto their grand dev tool Objective C + Cocoa binge. Using the regular Apple frameworks and development tools makes life a lot easier. Unfortunately, a lot of big apps don't follow the Apple route for any number of reasons (legacy code, portability, tool preference).
I read through the porting web site at Apple and they recommend using Carbon for this. I think Patrick and you wisely chose that path, although there is talk on the OOo Porting list about an effort to revive the Cocoa effort.
OPENSTEP wrote:
I think it's more those that will be the ones that may not survive the transition unless they're niche enough to justify the effort. Heck, I can't even get print drivers from Lexmark that are compatible with 10.4 and it's not like they're a small company.
Actually, it depends on the printer model. Is it a current model or one that is no longer made? If it is no longer in production, then the manufacturer has to make an estimated guess of the demand for printer drivers for your particular OS. The 'Wizzards of Redmond' leave enough backwards compatibility so that older drivers will work with newer operating systems. Of course, you cannot use Windows95/98/NT drivers on Windows2003 as the print subsystem is not compatible. This means that I may have to get new drivers for my in current production Epson C86 printer. Oh Well.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum