Re: lightning date reminder function - application crash
Dave Yeo <[email protected]>
| Newsgroups | gmane.comp.mozilla.devel.os2 |
|---|---|
| Message-ID | <[email protected]> |
Andreas Kohl wrote: > Dave Yeo schrieb: >> Andreas Kohl wrote: >>> But I can confirm that initial joltet display of day calendar view is >>> also an issue with sm 2.35 + lightning 4.4b2 under windows. I reported > ^^^^ > it should be 2.39 - sorry OK, something not to worry about. > >> It wouldn't hurt to create an issue. > > Ok, I took some screenshots. It seems this problems were introduced with > versions 4.0.x here. Former Tb 31.6 with lightning 3.3.8 works fine, > also Sm 2.7.2 with lightning 1.2.3. > >> Here calendar is suddenly quite broken, not dispalying in SM and acting >> really weird in TB, both using the Lightning that was installed with the >> binaries, both of which are ahead of the ones I've distributed. >> I also noticed that the lightning xpi built with SM is 2.6 MBs vs the TB >> one that is 2.2 MBs. Have to review the build logs and see if I can spot >> the differences. BTW, the 4.0.6 I uploaded was built with SM. > > I noticed strange things during installation process. For new profiles > it works generally better. Updating to a newer version using xpi > installation method makes trouble. Old add-on has to be removed first. Yes, thinking about it, it should always be removed first, if only due to calbscmp.dll. Perhaps something that should be added to the readme. > >> Another consideration is that currently intl.js is broken on our port >> and hopefully once that is fixed, things will improve, especially for >> other locales. > > It's a not well tested feature. When it became broken? It was new in 31ESR and not really used. Now it seems to be used more, eg the password manager in FF and TB and probably more. > >> I'll have to build a debug SM, something that is right at the limit of >> my computer due to only having 2GBs of memory. > > What's needing so much memory, C++ compiler? There's a couple of dom C++ files that use well over a GB of memory and with multiple object files being compiled at once, can add up. Linking the debug xul.dll uses at least 2GBs and needs VIRTUALADDRESS=3072 to not run out of address space. With nothing else running the swap file just grows a bit but if I have SM open, the swap file will easily grow over 512MBs. > >> https://github.com/bitwiseworks/mozilla-os2/issues/101 > > I hope that Дмитрий will not introduce new incompatibilities by his > decision. Good luck! > Dave _______________________________________________ dev-ports-os2 mailing list [email protected] https://lists.mozilla.org/listinfo/dev-ports-os2