Welcome to NeoOffice developer notes and announcements
NeoOffice
Developer notes and announcements
 
 

This website is an archive and is no longer active
NeoOffice announcements have moved to the NeoOffice News website


Support
· Forums
· NeoOffice Support
· NeoWiki


Announcements
· Twitter @NeoOffice


Downloads
· Download NeoOffice


  
NeoOffice :: View topic - MacIntel
MacIntel
 
   NeoOffice Forum Index -> NeoOffice Development
View previous topic :: View next topic  
Author Message
Guest
Guest





PostPosted: Thu Jan 12, 2006 10:48 am    Post subject:

First of all I would like to offer kudos to Ed, Patrick, Jake and all the other people who spend countless hours of their free time to help us users who are not so proficient in programming.

Enhancements are great, but please keep in mind the time and money it takes to re-engineer anything. I am grateful that these guys have provided us with not only an excellent product in NeoOffice, but also all the support you could ever need. Be thankful for what you have, and help find these guys a generous outside source of income to aid them in their endeavors.

...end rant
Back to top
ALTheFierce
Blue Pill


Joined: Dec 01, 2005
Posts: 2
Location: Atlanta

PostPosted: Thu Jan 12, 2006 10:57 am    Post subject:

I'm a long time OO.o user on Windows that has been planning to switch to Apple for a long time. Since I'd much prefer a native Aqua port than using X11, I've been monitoring the NeoOffice development for a year now b/c I see Neo as the best way to get OO functionality on MacOSX.

I'm also a graduating computer science major from Rice University with JAVA and C++ programming experience, so understand the complexity that such a large application as NeoOffice can entail. I have the utmost respect for open-source programmers who recognize the challenges in undertaking such projects, and then do it for free and (unfortunately) little respect from the general populace. I'm planning on upgrading to one of the MacBook Pro intel machines and would like to offer my support in NeoOffice Mactel development or testing when I get it. Unfortunately, I don't have a non-Apple machine capable of running a hacked MacOSX on Intel so I know that my options are limited now, but if there is anything I can do to help the NeoOffice development for intel machines over the next few months, please let me know.

Thanks for your good work,

Travis

_________________
Buy Apple.
Get Firefox.
Embrace Open Source.
Play Nintendo.
Back to top
jjmckenzie51
The Anomaly


Joined: Apr 01, 2005
Posts: 1055
Location: Southeastern Arizona

PostPosted: Thu Jan 12, 2006 5:20 pm    Post subject: Re: Aqua Ooo 2.0

Anonymous wrote:
That's ok. I'm sure the Aqua version of OOo 2.0 will be out in a few weeks with Mactel support.


Hmmm. I don't think so. I've been following this line of thought quite closely and it seems that simple functions have not been completed (not to say they have not been attempted.) I will keep on watching the activity on this very closely.

James
Back to top
Mox
Operator


Joined: Jun 29, 2005
Posts: 44

PostPosted: Sat Jan 14, 2006 6:25 am    Post subject: Re: MacIntel

jjmckenzie51 wrote:
As soon as I get my hands on a legal copy of MacOSX for the Intel platform, I will try this and see what happens.

James


Do you really mean Mac OSX (the software)? In that case, you will not find it useful until you buy an Apple machine that runs intel (for now, MacBook or iMac Intel). And Apple machines already have MacOSX inside.

Although Mac OSX is now made for Intel, it does not work on any other machine than Apple machines.

There are some *hacked* versions of old MacOSX intel versions around, that allow you to run on *some* non Apple, intel hardware. But this is not legal. And I don't think you can make such changes to MacOSX software that you buy from Apple. It's probably not legal anyways.
Back to top
ovvldc
Captain Naiobi


Joined: Sep 13, 2004
Posts: 2352
Location: Zürich, CH

PostPosted: Sat Jan 14, 2006 7:56 am    Post subject: sticking to PPC for now

Quite frankly, I intend to buy a new Mac sometime in the next 6 months. It will be a laptop, and it will be a PPC version. They might be slower, but at least I can get everything to work without serious pain.

I just hope to get a discount on an old PPC model when the new Intel ones get in Smile.

Best wishes,
Oscar

_________________
"What do you think of Western Civilization?"
"I think it would be a good idea!"
- Mohandas Karamchand Gandhi
Back to top
Guest
Guest





PostPosted: Sat Jan 14, 2006 12:16 pm    Post subject:

ed said:

"...For better or for worse, if it can't compile with gcc4, as far as Mac on Intel is concerned the application is up shit creek, and Apple has been cozy with this restriction since last July, so it ain't gonna be changing...."

May have something to do with that new 5 year Apple/M$ software agreement just announced unfortunately...
Back to top
OPENSTEP
The One
The One


Joined: May 25, 2003
Posts: 4752
Location: Santa Barbara, CA

PostPosted: Sat Jan 14, 2006 12:38 pm    Post subject:

I doubt it has anything to do with that announcemnet Smile While we all love to be conspiracy theorists, there's only so far these things can be pushed Wink

In reality, I've encountered very few applications that can't work properly on gcc4. Usually it's fixing up some typecasts, maybe changing packages for the non-standard STL hashmaps and the like, but overall if code is clean then things have no problem recompiling.

Unfortunately, OOo 1.x was really really nasty to move over because of changes in template scoping. OOo is incredibly template heavy, particularly in its type system. I spent two months trying to get the type system from OOo 2.x (which is gcc4 compliant) migrated back into 1.x, but encountered issues with weak typing that I couldn't solve.

On the flip side, Neo 2.0 development is coming along and, as it's already gcc4 compliant, the 1.x work is really a dead end.

It does suck that there's no solution out there for the mac on intel early adopters, but we're limited by a lack of resources...and a lack of time. I don't have my own DTS box and need to do work outside of my house and away from my beer and BG DVDs Very Happy

What we need to do is endianness and compilation support (which I've already done once for the experimental work from last year). The big thing is going to be the assembly bridge code.

In essence, all of my bitching about Apple is really due to their lack of support for older technologies...but also at the rampant evil that is the crufty OOo source code base that makes it reliant on those older technologies. There's some really gnarly stuff in OOo that puts us inbetween a rock and a hard place in the middle of a heavy snowstorm.

ed
Back to top
jjmckenzie51
The Anomaly


Joined: Apr 01, 2005
Posts: 1055
Location: Southeastern Arizona

PostPosted: Sat Jan 14, 2006 1:02 pm    Post subject:

OPENSTEP wrote:
I doubt it has anything to do with that announcemnet Smile While we all love to be conspiracy theorists, there's only so far these things can be pushed Wink


It really would not be in the best interests, for now, for Apple to crush OpenOffice.org and NeoOffice development.

OPENSTEP wrote:

In reality, I've encountered very few applications that can't work properly on gcc4. Usually it's fixing up some typecasts, maybe changing packages for the non-standard STL hashmaps and the like, but overall if code is clean then things have no problem recompiling.


This is very true. If you wrote clean code to gcc 3.3, then it should compile out-of-the-box with gcc 4.0(.1).

OPENSTEP wrote:
Unfortunately, OOo 1.x was really really nasty to move over because of changes in template scoping. OOo is incredibly template heavy, particularly in its type system. I spent two months trying to get the type system from OOo 2.x (which is gcc4 compliant) migrated back into 1.x, but encountered issues with weak typing that I couldn't solve.


This is because it was very easy. However, this was found and corrected (partially) in OpenOffice 2.0. This is why is was easier to move OpenOffice 2.0 to gcc 4.0.

OPENSTEP wrote:

On the flip side, Neo 2.0 development is coming along and, as it's already gcc4 compliant, the 1.x work is really a dead end.


Other than fixing bugs, 1.x is really at a dead end. I don't expect to see an OOo 1.1.6 release at any time and most of the fixes for it were for the Mac. A great deal of work is going into OOo 2.0.2 with a scheduled release date sometime in February. Even the folks working on code are in the process of deciding if their code will make this deadline.

OPENSTEP wrote:

It does suck that there's no solution out there for the mac on intel early adopters, but we're limited by a lack of resources...and a lack of time. I don't have my own DTS box and need to do work outside of my house and away from my beer and BG DVDs Very Happy


In other words, folks we do have a life outside of NeoOffice. We will do our best to fix problems you bring up, but we do have limited resources and time.

OPENSTEP wrote:
What we need to do is endianness and compilation support (which I've already done once for the experimental work from last year). The big thing is going to be the assembly bridge code.


I think that Pavel is looking into the endianness problems and may be looking at the assembler code to make sure it does what it is supposed to. This will definately help in the move to either Intel based binaries or Universal Binaries.

OPENSTEP wrote:
In essence, all of my bitching about Apple is really due to their lack of support for older technologies...but also at the rampant evil that is the crufty OOo source code base that makes it reliant on those older technologies. There's some really gnarly stuff in OOo that puts us inbetween a rock and a hard place in the middle of a heavy snowstorm.


And some of that OOo 'stuff' is very old and goes back to the StarDivision days. At times it looks good to back off and use newer technologies to make things work. However, some in the OpenOffice project and those at SUN who work on StarOffice, do not want to abandon those who are 'stuck' back using StarOffice 5.2 and 6.0. Sadly, you have to 'draw the line' and make a decision that you are going to have to abandon them so that you can concentrate on new features and elimination of the problems introduced by supporting those older technologies. This was done when the OpenOffice.org folks decided that it would be a good idea to not support Jaguar. I would not be at all surprised if OpenOffice 3.0 does not support Panther as its usage is dropping as the anomolies in Tiger are worked out. Of course, there are going to be folks that cannot afford to upgrade to a system that supports even Panther, but they will also be 'stuck' with older and older programs. This is a sad fact of life in this day of ever increasing system power.

James


Last edited by jjmckenzie51 on Sun Jan 15, 2006 12:30 pm; edited 1 time in total
Back to top
OPENSTEP
The One
The One


Joined: May 25, 2003
Posts: 4752
Location: Santa Barbara, CA

PostPosted: Sat Jan 14, 2006 1:25 pm    Post subject:

jjmckenzie51 wrote:
OPENSTEP wrote:
Unfortunately, OOo 1.x was really really nasty to move over because of changes in template scoping. OOo is incredibly template heavy, particularly in its type system. I spent two months trying to get the type system from OOo 2.x (which is gcc4 compliant) migrated back into 1.x, but encountered issues with weak typing that I couldn't solve.


This is because it was very easy. However, this was found and corrected (partially) in OpenOffice 2.0. This is why is was easier to move OpenOffice 2.0 to gcc 4.0.


Well, no, the weak typing is not easy. Weak typing is runtime dependent and dependencies are tracked through hash maps and the like. The C++ bindings are also a rat's nest of templates for 12+ implementations. It's also undocumented and lacks thorough automated tests that exercise the type system in the way it's actually used by other OOo components.

Go try and debug it sometime and you'll rip your eyes out.

ed
Back to top
jjmckenzie51
The Anomaly


Joined: Apr 01, 2005
Posts: 1055
Location: Southeastern Arizona

PostPosted: Sat Jan 14, 2006 4:57 pm    Post subject:

OPENSTEP wrote:
jjmckenzie51 wrote:
OPENSTEP wrote:
Unfortunately, OOo 1.x was really really nasty to move over because of changes in template scoping. OOo is incredibly template heavy, particularly in its type system. I spent two months trying to get the type system from OOo 2.x (which is gcc4 compliant) migrated back into 1.x, but encountered issues with weak typing that I couldn't solve.


This is because it was very easy. However, this was found and corrected (partially) in OpenOffice 2.0. This is why is was easier to move OpenOffice 2.0 to gcc 4.0.


Well, no, the weak typing is not easy. Weak typing is runtime dependent and dependencies are tracked through hash maps and the like. The C++ bindings are also a rat's nest of templates for 12+ implementations. It's also undocumented and lacks thorough automated tests that exercise the type system in the way it's actually used by other OOo components.


Ok, you misunderstood what I was trying to say. Weak typing is easier than other methods that the OOo/StarOffice team could have used.

OPENSTEP wrote:

Go try and debug it sometime and you'll rip your eyes out.


I know that this is very hard to do. Given the other implementations that are much easier to troubleshoot, but way more difficult to implement, this leads to the question "Why?" I think the folks at OpenOffice wanted it that way.

It sorta matches why the method that was/is used with digital tropospheric forward scatter is used (I used to troubleshoot Military Super High Frequency radios). The individual who created it ended up commiting suicide because he lost the ability to understand his creation.

This is why I feel that weak typing has not been completely abandoned. It was easy to implement, is in use and replacing it may be a total bear. That is why I also stated that some work was done with OpenOffice 2.0 to start eliminating it. However, it is not totally eliminated and may never be.

This also makes porting OpenOffice to different platforms difficult (not just building a new interface, but actually getting OpenOffice to work on a new platform.) This may be encountered when porting in earnest starts for the MacIntel system.

James
Back to top
OPENSTEP
The One
The One


Joined: May 25, 2003
Posts: 4752
Location: Santa Barbara, CA

PostPosted: Sat Jan 14, 2006 7:27 pm    Post subject:

No, the weak typing system is crap (why in the hell do you need your own component model anyway), and it continues to become even worse with time. Hell, in the 2.0 source base the c++ implementation starts making assumptions about how compilers layout vtables! This should raise a big red flag for any seasoned C++ developer.

Go read the code and you'll change your mind in a hurry.

ed
Back to top
jjmckenzie51
The Anomaly


Joined: Apr 01, 2005
Posts: 1055
Location: Southeastern Arizona

PostPosted: Sat Jan 14, 2006 8:03 pm    Post subject:

OPENSTEP wrote:
No, the weak typing system is crap (why in the hell do you need your own component model anyway), and it continues to become even worse with time.


I did not mean to imply that it is high quality. It is far from it. However, it is EASY. But is is a BITCH to maintain and it is absolute HELL to port. As I said it is legacy code and no one wants to get rid of it due to the amount of work needed to replace it.

OPENSTEP wrote:

Hell, in the 2.0 source base the c++ implementation starts making assumptions about how compilers layout vtables! This should raise a big red flag for any seasoned C++ developer.


I totally agree. You should MAKE NO ASSUMPTIONS when you build items like that.

OPENSTEP wrote:

Go read the code and you'll change your mind in a hurry.


I did. I was wondering what they were doing. I thought it was some sort of Microsoft trick they were trying to pull. I used to see this stuff with re-enterant code (think Zork I). It is very messy but, again, it is easy to do. However, maintenance is a bear (see above for my opinion) and you have to rely on a certain level of compiler. One change and it is just as friendly as a hand grenade with the pin pulled and the spoon is somewhere in the grass and it ls super-glued to your hand.

Maybe, if we find the time, we can recode this mess to make it friendlier. This will make moving to new platforms easier and more fun. I really hate tracing down bugs that are not steady and reproducible.

James
Back to top
OPENSTEP
The One
The One


Joined: May 25, 2003
Posts: 4752
Location: Santa Barbara, CA

PostPosted: Sat Jan 14, 2006 8:48 pm    Post subject:

What makes it worse is, when trying to debug problems in a custom type system, the debugger is not aware of your type system. Combine that with the fact your primary reference method for types are Unicode strings...which makes for fun printing them in a debugger, not to mention an intriguing security loophole for components spoofing IDs...not to mention try to debug paramaterized templates in gdblll

I can rant against the typesystem endlessly. I think its implementation is crap and I think it's unnecessary for implementing an office suite. The old Star Division loved to reinvent the wheel, whether it be DCOM, their own widget set, or what have you. It always looks great in the short term but is a really shitty long-term engineering strategy. It sucks that such an important program in reality is just built on quicksand.

I could go off on the OOo "community" right now, but that's a topic better suited for the ranting forum Wink

ed
Back to top
jjmckenzie51
The Anomaly


Joined: Apr 01, 2005
Posts: 1055
Location: Southeastern Arizona

PostPosted: Sat Jan 14, 2006 9:28 pm    Post subject:

[quote="OPENSTEP"]What makes it worse is, when trying to debug problems in a custom type system, the debugger is not aware of your type system. Combine that with the fact your primary reference method for types are Unicode strings...which makes for fun printing them in a debugger, not to mention an intriguing security loophole for components spoofing IDs...not to mention try to debug paramaterized templates in gdblll{/quote]

Like I said it is a BITCH to maintain. It is very easy to implement.

OPENSTEP wrote:

I can rant against the typesystem endlessly. I think its implementation is crap and I think it's unnecessary for implementing an office suite. The old Star Division loved to reinvent the wheel, whether it be DCOM, their own widget set, or what have you. It always looks great in the short term but is a really shitty long-term engineering strategy. It sucks that such an important program in reality is just built on quicksand.


Yes, it is poor system if you want to build a long-term project. Like I said, the OpenOffice folks wanted to improve the old code and I think they realized the scope of what they wante to do and maybe abandoned it or just partially implemented it (which may be worse than just leaving it alone in the first place.)

OPENSTEP wrote:

I could go off on the OOo "community" right now, but that's a topic better suited for the ranting forum Wink


So, let's take it there...

James
Back to top
OPENSTEP
The One
The One


Joined: May 25, 2003
Posts: 4752
Location: Santa Barbara, CA

PostPosted: Sat Jan 14, 2006 9:47 pm    Post subject:

jjmckenzie51 wrote:

Yes, it is poor system if you want to build a long-term project. Like I said, the OpenOffice folks wanted to improve the old code and I think they realized the scope of what they wante to do and maybe abandoned it or just partially implemented it (which may be worse than just leaving it alone in the first place.)


The weak typing UNO system was in place and engineered by StarDivision/Hamburg prior to the open sourcing of the StarOffice code. In fact, the typing system was one of the primary reasons for the abandonment of the old Classic MacOS StarOffice port...the new component loading system was incompatible with CFM symbol resolution rules.

It's not anything the "openoffice.org" folk with (few that exist...). It's something that StarDiv did back in antiquity (read, mid 90s) that we're all stuck with. At one point stardiv even sold their widget set (VCL/SVX/UNO) as an actual cross platform development framework.

Even if it was thought of at the time as an "improvement", it was a poor engineering decision, a questionable implementation, and problematic in the long term. I have no sympathy for engineering decisions that experience has proven to be wrong.

There are a number of legacy engineering decisions that make OOo/StarOffice a really shitty base to work off of, from custom type systems to custom build systems. They've made this source code a bear from the beginning and are a severe hinderance for this source base to become a viable long term source code base (read Moz5).

(note, there's no community rant...I think engineering-based rants belong here as reminders of what should be avoided in the future Smile )

ed
Back to top
Display posts from previous:   
   NeoOffice Forum Index -> NeoOffice Development All times are GMT - 7 Hours
Goto page Previous  1, 2, 3, 4  Next
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

Powered by phpBB © 2001, 2005 phpBB Group

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © Planamesa Inc.
NeoOffice is a registered trademark of Planamesa Inc. and may not be used without permission.
PHP-Nuke Copyright © 2005 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.