gecko-dev/xpcom/build
brendan%mozilla.org 6d895baf1d Bit checkin for bug 68045, r/sr=waterson&shaver, second attempt. It all works
for me on optimized and debug gcc2.96, rh7.1.

- Better failure codes from nsXULPrototypeScript::Deserialize.

- Call nsXULDocument::AbortFastLoads after nsXULPrototypeScript::Serialize
  failure, instead of just nulling the FastLoad service's output stream.

- Expose nsXULDocument::AbortFastLoads via nsIXULPrototypeCache, for use from
  nsChromeProtocolHandler.cpp.  AbortFastLoads flushes the XUL cache now, for
  good measure.

- The needless "Current" adjective in nsIFastLoadService attribute and method
  names is no more.

- Add a do_GetFastLoadService() helper, to use CID instead of contractid, and
  to let the compiler consolidate the static inline CID.

- Add "nglayout.debug.checksum_xul_fastload_file" pref so people can do without
  the checksum verification step when reading a FastLoad file.

- Verify the FastLoad file checksum, by default.  Also, cache it in the FastLoad
  service so we don't recompute it when re-opening the FastLoad file as mailnews
  and other top-levels start up.  Fill the checksum cache in EndFastLoad, when
  the last pseudo-concurrent top-level finishes loading.

  My hope to compute the checksum while writing the FastLoad file ran afoul of
  misordered writes.  The old code to checksum the in-memory nsFastLoadHeader
  also was broken on little endian platforms.  Now all checksumming is done via
  a separate read pass over the complete file, save for the header's checksum
  field, which is summed as if it contained zero.

- Track and check FastLoad file dependencies.  This required groveling with a
  bunch of Necko interfaces in nsChromeProtocolHandler::NewChannel -- read it
  and weep.  Dependency checking, as well as checksum access and computation,
  use better-factored nsIFastLoad{File,Read,Write}Control interfaces.

- nsBufferedStream::Seek wasn't flushing the buffer when seeking backward
  within the buffer, but it must, because mCursor bounds the amount to write
  if the buffer contains the end of file.

- Add an unbufferedStream readonly attribute to nsIStreamBufferAccess, so we
  don't have to screw around with the bufferying layer when checksumming. Also
  implement nsIStreamBufferAccess in nsBufferedOutputStream.

- nsISeekableOutputStream was bogus, based on a bad state I had put the
  nsBufferedOutputStream code in on its way from being completely broken when
  you seek backwards outside of the buffer.  Removing this interface required
  using nsIFastLoadFileIO in nsFastLoadFileWriter, and it also required careful
  ordering of Close calls (the Reader must close after the Writer or Updater,
  so that the Reader's underlying, unbuffered input stream can be read by
  nsFastLoadFileWriter::Close to compute the checksum.

- Miscellaneous tab/indentation, comment typo, bracing, if( => if ( style,
  nsnull vs. 0, useless variable elimination, tortured control flow,
  AutoString instead of String, and gratuitous ; after nsISupportsUtils.h
  macro call cleanups.
2001-08-21 20:51:34 +00:00
..
.cvsignore
dlldeps.cpp Bug 93100. Change NS_DECL_NSGETMODULE to be table driven so we can get at module ctor & dtor callbacks. Update meta-module and static-module stuff for this change, fix meta-module to not register stuff twice. r=cls,leaf 2001-08-21 01:47:31 +00:00
Makefile.in Bug 73353: clean up the REQUIRES lines in Makefiles. 2001-07-23 22:36:12 +00:00
makefile.win Land STATIC_BUILD_20010612_BRANCH, which supports building mozilla with components statically linked into the executable, as well as 'meta modules' that combine components into uber-DLLs. 2001-06-20 20:21:49 +00:00
malloc.c r=waterson sr=cls 2001-02-06 04:52:19 +00:00
nsXPComInit.cpp Bit checkin for bug 68045, r/sr=waterson&shaver, second attempt. It all works 2001-08-21 20:51:34 +00:00
win32.order 65845 - new order files 2001-04-05 06:02:32 +00:00
xpcom_alpha.def bug 54471. Increase the xptcall stubs entry point count to almost 256. This increases the number of methods that can be implmented on a JS object via xpconnect, or on an xpcom/proxy object, or via PyXPCOM. There are platform limitations that would need to worked out to go higher. Also higher counts start getting into a zone where we should be wisely weighing the memory cost. r=markh@activestate.com sr=shaver@mozilla.org 2001-05-19 00:03:01 +00:00