FYI. Getting a Mactel box is only one small part of the effort. The big limitation is developer time. The OOo code has some hairy assembler code and, based on my experience with Apple's version of gcc, there will be many new bugs so moving Neo/J to Mactel is not going to be a simple recompile.
As I am (I think) still supposed to liason with the OOo community: Shouldn't we put this roadmap on the dev@porting list?
I might please them that a switch to Java 1.4 and Cocoa is on the way. If properly worded, it should also let them know they have time to do a good version of 2.0 and we'll be looking forward to work with the fruits of their hard labour. _________________ "What do you think of Western Civilization?"
"I think it would be a good idea!"
- Mohandas Karamchand Gandhi
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Mon Jun 13, 2005 10:13 pm Post subject:
Well, if nothing else, someone should probably let them know that any Java based UNO components will be incompatible with the Rosetta emulator on Intel machines. This will kill JDBC, Base (if the implementation is still in Java), some of the Wizards, etc. for any PowerPC compiled OOo 2.0 X11.
It's exactly the same for both NeoJ and OOo X11...neither of them wil be able to run in the emulator
Well, if nothing else, someone should probably let them know that any Java based UNO components will be incompatible with the Rosetta emulator on Intel machines. This will kill JDBC, Base (if the implementation is still in Java), some of the Wizards, etc. for any PowerPC compiled OOo 2.0 X11.
So we're joined at the hip, as always..
But I assume the Intel version will have a JVM and libraries and be able to run at least some Java code, given recompiling or compiling to byte-code only?
Maybe you could make a post to the dev@porting list to announce what you think this all means to NeoOffice and OOo porting. I don't think I can formulate it precisely enough to be of use, but something should be sent out. Preferably in an encouraging tone, because they're having enough trouble as it is... _________________ "What do you think of Western Civilization?"
"I think it would be a good idea!"
- Mohandas Karamchand Gandhi
I saw something at one point on dev@porting about Florian having been at WWDC; I wonder how much talking with Apple folks he was able to do about these issues?
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Posted: Wed Jun 15, 2005 7:21 pm Post subject: Delgation?
Patrick,
There are four major programming efforts listed in your parent post. That sounds like simply too much work for two part time developers. Which bits of this do you think can be sanely delegated?
My naive outsider viewpoint suggests to me that step 1: Java 1.4.x can only be done by you (and Ed?); it's too low-level for anyone who didn't do the original Java 1.3.x work. The second step, Aqua widgets and dialogs, looks doable by other people. On the other hand, it looks like the most fun job out of the four! The third step, OOo 2.0 should be delegated to anyone who offers (and it's nice to see some support from OOo for the platform finally, which should help getting an X11 version out sooner). The fourth step - MacIntel - sounds like it's so difficult that you can't even make a plan for it yet. I don't pretend to understand the details of how a UNO bridge works, but it does sound like Sun and OOo went out of their way to make things difficult (Assembler????? Are we living in the 1970s?).
Cheers, Phil
PS the more I think about an OOo virtual machine layer acting inside a Java VM, the more amazing I find it that Neo is fast and responsive on my 3 year old Powerbook.
Posted: Wed Jun 15, 2005 10:04 pm Post subject: Re: Delgation?
Anonymous wrote:
There are four major programming efforts listed in your parent post. That sounds like simply too much work for two part time developers. Which bits of this do you think can be sanely delegated?
Part of the problem--Ed and Patrick can fill in the details--is that there just are not enough people with the skills and experience needed to do the jobs, if they could be delegated. In the history of Mac OOo, four people have done all the major lifting (not little "fix the build" patches, but "stop Writer from crashing" or "people really want to print" or "new compiler version, we need new UNO bridges"): Patrick, Ed, Dan, and Kevin Hendricks. By the time OOo 2.0.x for Mac OS X (X11) finally makes it into the hands of end-users, there might be another name to add to that list, but for now...
The Java suff is clearly at the core of Neo/J, so that's Patrick. "Back in the day" Patrick had his own little "Marklar" project going, where some of the Neo/J 0.x builds also built using Java 1.4.x (which is how Patrick learned how buggy Java 1.4.x was!). We're a world away from 0.x now, but possibly some of that work can be useful/reused (and who knows; Patrick never said he stopped doing builds with Java 1.4.x, he just stopped mentioning them)....
Ed and Dan are the only two Mac programmers who've done native widget stuff (and they invented/prototyped the N*F stuff). Some of the KDE-OOo folks have done N*F stuff since then, but they won't be interested in Neo/J. I don't know how complex this is, but it ultimately still requires someone who can at the very least get OOo to build....
As for OOo 2.0, first we have to wait for OOo 2.0 to get released and become stable on the Sun-supported platforms and then wait for a stable Mac OS X release (and in just my little bit of playing around with the 1.9.xxx builds, it'll be a while yet to match the functionality of 1.1.2).
At any rate, Patrick's roadmap is sort of like two steps each with two threads running in parallel (although there's a hidden third thread, OOo 2.0 Mac OS X X11, too): Patrick moves to Java 1.4.x and Ed adds widgets, roughly in parallel (or maybe not?) and potentiallu something similar in the 2006 year....
Or something like that. Maybe I should just let Ed and Patrick answer themselves and put my nose back to the Press Kit grindstone....
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
btw: waiting for Oo 2,0 x11, pluby said he work for a more aqua felling in gui. I'm asking: could be done a 'code-optimization' for more speed?
I don't know if neo could be compiled using g4 or g5 peculiarity (like altivec) but sure I prefer a faster neo with x11 icons, that aqua felling with a slow neo
It is only a curiosity about the pluby possibility of work from this side of the code (java and carbon).
btw: waiting for Oo 2,0 x11, pluby said he work for a more aqua felling in gui. I'm asking: could be done a 'code-optimization' for more speed?
I don't know if neo could be compiled using g4 or g5 peculiarity (like altivec) but sure I prefer a faster neo with x11 icons, that aqua felling with a slow neo
What you suggest isn't going to happen. G4, G5, Altivec, etc. isn't going to make a difference because Java does all of the drawing. We don't compile Java, Apple does. Also, some of the slower drawing operations are slow because Java is buggy (e.g. XOR drawing), not because the Neo/J code is unoptimized.
Hopefully, Java 1.4.x will provide some improvements in speed, but then I won't be surprised if there is no difference.
Posted: Thu Jun 16, 2005 1:04 pm Post subject: Re: Delgation?
sardisson wrote:
Part of the problem--Ed and Patrick can fill in the details--is that there just are not enough people with the skills and experience needed to do the jobs, if they could be delegated. In the history of Mac OOo, four people have done all the major lifting (not little "fix the build" patches, but "stop Writer from crashing" or "people really want to print" or "new compiler version, we need new UNO bridges"): Patrick, Ed, Dan, and Kevin Hendricks. By the time OOo 2.0.x for Mac OS X (X11) finally makes it into the hands of end-users, there might be another name to add to that list, but for now...
For those that haven't contributed code to an open source project, there is a de facto process that most projects use when new developers show up. New developers are expected to show their ability to work in the code by submitting patches for build problems and existing bugs. Once the existing developers (in our case Ed and I) feel confortable that the new developer knows what they are doing, then commit access is usually granted.
This isn't a perfect process, but it generally proves to be an effective means for determining which potential developers will most likely be valuable, self-sufficient code contributors. This is especially true for OOo and Neo/J since, when developers first find out how much effort it takes to make a small change in the OOo code, most are no longer interested.
sardisson wrote:
The Java suff is clearly at the core of Neo/J, so that's Patrick. "Back in the day" Patrick had his own little "Marklar" project going, where some of the Neo/J 0.x builds also built using Java 1.4.x (which is how Patrick learned how buggy Java 1.4.x was!). We're a world away from 0.x now, but possibly some of that work can be useful/reused (and who knows; Patrick never said he stopped doing builds with Java 1.4.x, he just stopped mentioning them)....
Every once in a while I turn on loading of Java 1.4.x to see what happens. Unfortunately, Neo/J just crashes with Java 1.4.x because I haven't implemented any of the Java-to-native code for font handling. Back when fonts used to work, however, printing did not work. So I clearly have some work ahead of me.
sardisson wrote:
At any rate, Patrick's roadmap is sort of like two steps each with two threads running in parallel (although there's a hidden third thread, OOo 2.0 Mac OS X X11, too): Patrick moves to Java 1.4.x and Ed adds widgets, roughly in parallel (or maybe not?) and potentiallu something similar in the 2006 year....
This is pretty accurate. I was planning on getting the most obvious missing Java 1.4.x pieces coded and then putting out a test patch for testers. Then, while testers are finding lots of Java 1.4.x bugs and when I'm not fixing those bugs, Ed and I will be working on implementing the native widgets.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Thu Jun 16, 2005 10:59 pm Post subject:
FWIW, most developers don't make it past the compile phase. Some that can are stuck there forevermore; the deluge of code from Hamburg makes maintaining compilability a full time job
There is a definite lack of skills on the project, that's true. But Patrick is right. Open source is a fiefdom, and we've chosen a "trial by fire" approach. I agree with it because I spent many, many hours, vacation time, and money trying to recruit developers for OOo X11 for years. Most who even try to compile get it to compile and then drop off the face of the earth. It sucked up a *lot* of my time. But...
The "trial by fire" admission has many benefits. First, it shows that a developer is motivated enough to pursue something even in the face of adversity. Second, it proves a willingness to try and solve tough problems to which no one else may know the answer or have time to investigate. Third, fixing breakages, even in the build process, is a great way to get exposed to the internals of a project. Heavens know I didn't learn what I know of OOo's structure from any type of "developer's bible" posted along with Sun's source code...I had to learn it all myself, and the primary way I learned was through fixing build failures and bugs. The same approach is often taken in the real world where the first task a new developer has on the job is bug fixing, especially if they're green out of college. It's common practice in the real world, so it makes sense to apply it to OSS as well.
So anyway, if you're trying, keep it up and don't give up. We're spread so thin that we don't have time to be anyone's guide, so you may have to find your own way...but fame and fortune and women await you at the end of your quest.
Oh wait...
(goes back to cooking his hamburger helper and shooing away the homeless)
Thank you for the answer. After the great pluby and ed work, I only have few bugs in neooffice that I hope before or late will fall in patrick butterfly net.
Now the main problem here (I'm talking about a normal office work) is definitely the speed and the memory, and I'll be curious to see if the moving from java 1.3.1 to 1.4 could help this issue.
I saw something at one point on dev@porting about Florian having been at WWDC; I wonder how much talking with Apple folks he was able to do about these issues?
Hi Smokey, all,
yes, I was at WWDC. But I used my chances to talk to Apple engineers to solve some of the other issues we are currently having, mainly with Java (which they helped me solve).
As I knew gcc4-compatibility is a requirement to run natively on Mactel boxes I tried to first compile the 2.0 codebase with gcc4 out of the new Xcode 2.1 (so far unsuccessful) before approaching one of the lab machines. Sorry, I know I should have at least tried to run it in the Rosetta environment.
But I do hope too that somehow we will get access to one of the DevKits.
All times are GMT - 7 Hours Goto page Previous1, 2, 3, 4Next
Page 2 of 4
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