"Ok. It is taking a real long time to load and run, too."
Now, now, let's not go there jj, that's touchy subject... *hehe*
Just out of curiosity, how long does it take to launch if you remove all but OS X system-required fonts?
Since I built a newer version with Patrick's fixes for the Java drawing routines, about ten to fifteen seconds. It was taking almost a minute and was much longer than NeoOfficeJ-1.1 Oh, I don't have any special fonts on my machine, although there are a couple that I would like to have.
Thanks for the fix, Patrick. However, the insertation marker in calc is still not 'there'. Also, there are drawing anomolies, like the lines around the highlighted row/column are not straight. However, the colors do change!
I guess I will have to look at the Bugs area and see if I can find/confirm bugs.
I suspect that you didn't get a full update of the code in the vcl module. When you invoke "cvs update -d" in the neojava/vcl directory, do you get any files listed with a status of "M" or "C"? If so, these files aren't being updated as "M" means modified and "C" means conflict and cvs will bypass those files. If you get any of these, delete those files, reinvoke "cvs update -d", and rebuild.
I will rerun the update tonight. I like the fact that I can redirect the files retrieved or not retrieved, by themselves, into a file and then look through it for the list that I have to get again.
pluby wrote:
BTW, there are no bugs for the Java 1.4.2 code in Bugzilla yet as you and I are the only people who have used the new code.
That's a really small audience. But with the level of stability (or actually, the lack of it) I would not want more than a couple more folks looking at the code and building with it.
pluby wrote:
jjmckenzie51 wrote:
And I did build it with SRX645_m57, which Eric B. is having problems committing your changes to. I guess it is time to print out the JCA and send it in.
That's not surprising. I may be wrong, but I have had the impression that Eric B. and Eric H. are good at fixing OOo build breakages, but they haven't been doing any substantial amount of coding in the year that they have been working on OOo.
Eric B. was just 'promoted' to co-lead of the porting team. I think that he ran into a bug with CVS and had to fix that before continuing on. With the fixes from macxjoin1153 it will be much easier to build on MacOSX, especially MacOSX 10.4.
I've backported, manually, the fixes in macxjoin1153 into SRX645_m57 (the latest release candidate for 1.1.5) and it builds without many errors and no errors that stop the build. I would like to find the fix for the 'deleting void * not defined' warning in C++ code. That will eliminate many warnings and hopefully reduce the size of my build logs, which are about 60MB in size.
I will rerun the update tonight. I like the fact that I can redirect the files retrieved or not retrieved, by themselves, into a file and then look through it for the list that I have to get again.
On second thought, I think you should ignore my shortcut for vcl and do the following instead. I recommend this because I just cvs removed some obsolete vcl files and getting vcl to rebuild properly is tricky the first time you rebuild after that:
1. cd into the "neojava" directory and "cvs update -d dtrans stoc" directories.
2. Use my shortcut to build those two modules.
3. cd into the "neojava" directory and "rm -Rf vcl ; cvs update -d" to get a fresh copy of the vcl subdirectory.
4. cd into the "neojava" directory and "mv build.neo_vcl_patch build.neo_vcl_patch.bak ; make build.neo_vcl_patch ; mv build.neo_vcl_patch.bak build.neo_vcl_patch". This will perform a clean rebuild of vcl without triggering the full installer to rebuild.
5. cd into the "neojava" directory and "rm build.patch_package ; make build.patch_package" to rebuild the patch.
I will rerun the update tonight. I like the fact that I can redirect the files retrieved or not retrieved, by themselves, into a file and then look through it for the list that I have to get again.
On second thought, I think you should ignore my shortcut for vcl and do the following instead. I recommend this because I just cvs removed some obsolete vcl files and getting vcl to rebuild properly is tricky the first time you rebuild after that:
1. cd into the "neojava" directory and "cvs update -d dtrans stoc" directories.
I got them all. I made backups to the original files. I am getting a bunch of 'P' in the update.
pluby wrote:
2. Use my shortcut to build those two modules.
Ok. I'm confused now. Was this to remove some of the build.neo...patch files and then rebuild?
pluby wrote:
3. cd into the "neojava" directory and "rm -Rf vcl ; cvs update -d" to get a fresh copy of the vcl subdirectory.
4. cd into the "neojava" directory and "mv build.neo_vcl_patch build.neo_vcl_patch.bak ; make build.neo_vcl_patch ; mv build.neo_vcl_patch.bak build.neo_vcl_patch". This will perform a clean rebuild of vcl without triggering the full installer to rebuild.
This I UNDERSTAND!
pluby wrote:
5. cd into the "neojava" directory and "rm build.patch_package ; make build.patch_package" to rebuild the patch.
Ok. Will this also rebuild all of the exportable .pkg directories?
Ok. I'm confused now. Was this to remove some of the build.neo...patch files and then rebuild?
No. with "drans" and "stoc", I have not cvs removed any files so you can do my old shortcut of sourcing the build/MacosxEnvJava.Set file and invoking the build command in each of these two directories.
jjmckenzie51 wrote:
pluby wrote:
5. cd into the "neojava" directory and "rm build.patch_package ; make build.patch_package" to rebuild the patch.
Ok. Will this also rebuild all of the exportable .pkg directories?
If you followed step 4, then no. Note that in step 4 I have you move your old build.neo_vcl_patch back into place. This preserves the date stamp so make won't rebuild later dependencies. This also why step 5 requires you to delete the build.patch_package file before invoking "make build.patch_package".
In sum, I made the Neo/J build system give you the developer total control over which targets get rebuilt. The idea is that 98% of Neo/J development work is spent in vcl so I tried to prevent unnecessary rebuilding of OOo or the installer to make my build and test cycles fast.
I don't have a build.patch_package, but I do have a build.package file. Is this the file I need to delete?
No. If you look in the "makefile" file, you will notice that the "build.package" target builds the entire installer. Building the installer takes at least a half hour. The "build.patch_package" target builds only the patch installer.
I don't have a build.patch_package, but I do have a build.package file. Is this the file I need to delete?
No. If you look in the "makefile" file, you will notice that the "build.package" target builds the entire installer. Building the installer takes at least a half hour. The "build.patch_package" target builds only the patch installer.
Thank you for the explanation, but I wanted a complete build. Also, you must have a live Internet connection as you pull down the NeoLight program when you do a complete build.
In any case, the boxes are back in calc. Now to check writer.
Thank you for the explanation, but I wanted a complete build. Also, you must have a live Internet connection as you pull down the NeoLight program when you do a complete build.
Now that you have a complete build and installation, you can save yourself a huge amount of time by just cvs updating the modules that I change (which will be only vcl 98% of time), doing the source and build, and copying the rebuild libraries and jar files (vcl/unxmacxp.pro/lib/libvcl645mxp.dylib and vcl/unxmacxp.pro/class/vcl.jar for the vcl module) into your installation.
This may seem contrary to the build steps that are used for OOo, but (not surprisingly) this approach is actually very similar to how Sun's engineers work on OOo. Within Sun (and I know this because I worked as an engineer within the StarOffice group at Sun a few years ago), a few people build the entire OOo set once a week and then each developer just installs the prebuilt binaries and copyies in libraries that they change. Almost none of the developers at Sun actually build more than one or two modules.
[quote="pluby"]
This may seem contrary to the build steps that are used for OOo, but (not surprisingly) this approach is actually very similar to how Sun's engineers work on OOo. Within Sun (and I know this because I worked as an engineer within the StarOffice group at Sun a few years ago), a few people build the entire OOo set once a week and then each developer just installs the prebuilt binaries and copyies in libraries that they change. Almost none of the developers at Sun actually build more than one or two modules.[/auote]
I've found that incomplete builds can and does lead to 'strangeness'. I agree that someone on the build team should do a complete build once a week.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Aug 21, 2005 10:29 pm Post subject:
Just a random thought.. The "someone" who does the complete builds should be a build tinderbox doing it as an automated process. I don't have a machine that can be one, of course...but in general, babysitting builds is a waste of good talent. Unfortunately, that's the majority of what OOo porting really is...
I have excellent news! I finally got direct drawing to windows working. Previously, Neo/J would maintain an offscreen image for each window and it would draw to the offscreen image and frequently copy the offscreen image to the window. This was necessary because of horrible bottlenecks and missing XOR drawing support in Java 1.3.1.
With Java 1.4.2, many of the missing XOR drawing support now works and many of the bottlenecks no longer exist. So, I have eliminated all of those memory-consuming offscreen images and the CPU-consuming copying of the images with direct drawing to windows. I still need to reimplement the OpenGL support to work with this new approach, but everything else works.
James and Ed,
If you want to build the latest code, execute the following commands:
This will take at least an hour to rebuild, but then you will be completely updated and you can install the patch that is built over your existing Neo/J 1.1 installation.
I have excellent news! I finally got direct drawing to windows working. Previously, Neo/J would maintain an offscreen image for each window and it would draw to the offscreen image and frequently copy the offscreen image to the window. This was necessary because of horrible bottlenecks and missing XOR drawing support in Java 1.3.1.
Thanks for the update. I found a problem with the Open/Save dialog and that is if you attempt to expand it, the program would appear to lock up and had to be forced closed using the Force Quit widget.
pluby wrote:
With Java 1.4.2, many of the missing XOR drawing support now works and many of the bottlenecks no longer exist. So, I have eliminated all of those memory-consuming offscreen images and the CPU-consuming copying of the images with direct drawing to windows. I still need to reimplement the OpenGL support to work with this new approach, but everything else works.
I used the same type of code when I was in college to 'throw' stuff onto a Windows3.1 program screen. Yes, it is CPU intensive and can slow down drawing to a crawl depending on how many objects you need to update on the screen.
pluby wrote:
This will take at least an hour to rebuild, but then you will be completely updated and you can install the patch that is built over your existing Neo/J 1.1 installation.
Do I need to do this for the independent NeoOffice build that I am working with or should I invoke build.package as I have been?
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
*hehe*
