[plt-scheme] 301.16

It was just the error message.  Is there something I need to do to enable
the stack tracing?

Doug

> -----Original Message-----
> From: Robby Findler [mailto:robby at cs.uchicago.edu]
> Sent: Thursday, May 25, 2006 9:38 AM
> To: Williams, M. Douglas
> Cc: Matthew Flatt; plt-scheme at list.cs.brown.edu
> Subject: RE: [plt-scheme] 301.16
> 
> Did you get a stack trace with that message?
> 
> Robby
> 
> At Thu, 25 May 2006 08:35:48 -0700, "Williams, M. Douglas" wrote:
> > Matthew,
> >
> > I am having a problem with my code that uses the plot collection (via
> the
> > simulation collection) in 301.16.  I get the following error message:
> >
> > build-path: absolute path "C:\Program
> > Files\PLT-FULL-
> 301.16\collects\plot/compiled\native\win32\i386\libplplot.dll
> > " cannot be added to the path "C:\Documents and Settings\w..."
> >
> > I've attached two example programs - I run them under the 'Pretty Big'
> > language level.  Example-3 is a short example, while model-2a is more
> > complex.
> >
> > I am running under Windows XP and have not tried it under Linux yet.
> >
> > Thanks,
> > Doug
> >
> > > -----Original Message-----
> > > From: plt-scheme-bounces at list.cs.brown.edu [mailto:plt-scheme-
> > > bounces at list.cs.brown.edu] On Behalf Of Matthew Flatt
> > > Sent: Wednesday, May 24, 2006 1:44 PM
> > > To: plt-scheme at list.cs.brown.edu
> > > Subject: [plt-scheme] 301.16
> > >
> > > MzScheme and MrEd are now version 301.16 in the SVN repository trunk.
> > >
> > > This is most of the last step that I promised in the 301.15
> > > announcement:
> > >  http://list.cs.brown.edu/pipermail/plt-scheme/2006-May/013023.html
> > >
> > > Changes:
> > >
> > >  * Under Unix, when you create a executable with `mzc --[gui-]exe',
> > >    the resulting executable is a wrapper for MzScheme or MrEd, instead
> > >    of a copy of the MzScheme of MrEd executable.
> > >
> > >    This change may seem like a step backward, because it makes the
> > >    generated executable dependent on another executable. However, this
> > >    change is consistent with the fact that generated Windows and Mac
> OS
> > >    X executables are dependent on shared libraries --- as are Unix
> > >    executables when built with --enable-shared.
> > >
> > >    To get the old behavior back, use mzc's new --orig-exe flag, but
> > >    probably you want the next bullet, instead...
> > >
> > >  * Added a new mode to the mzc: --exe-dir. Given a target directory
> and
> > >    one or more executables generated with --[gui-]exe, it combines the
> > >    executables with any needed DLLs, frameworks, or shared libraries,
> > >    so that the resulting package can be moved to any machine.
> > >
> > >    For Windows, executables are put directly into the package
> > >    directory, and DLLs go into a "lib" sub-directory.
> > >
> > >    For Mac OS X, MrEd executables go into the package directory,
> > >    MzScheme executables go into a "bin" subdirectory, and frameworks
> go
> > >    into a "lib" sub-directory. As a special case, if the package has a
> > >    single MrEd executable, then the "lib" directory is hidden inside
> > >    the application bundle.
> > >
> > >    For Unix, executables go into a "bin" subdirectory, shared
> libraries
> > >    (if any) go into a "lib" subdirectory, and the wrapped executables
> > >    are placed into a "lib/plt" subdirectory with version-specific
> > >    names. This is consistent with FHS, and it means that packages can
> > >    be safely unpacked into, say, /usr/local.
> > >
> > >    The package also has a "collects" directory that is used as the
> main
> > >    "collects" for the packaged executables. Currently, the "collects"
> > >    directory is empty, but mzc will soon let you supply directories to
> > >    populate the package's "collects" directory. In particular, you'll
> > >    be able to package multiple executables that share collection-based
> > >    libraries.
> > >
> > >    The "collects" directory is in "lib/plt/<X>", where "<X>" is the
> > >    name of the first packaged executable (sans suffix). Again, the
> > >    "<X>" means that packages with potentially colliding collections
> can
> > >    be safely unpacked in the standard place.
> > >
> > >    The Scheme interface to the new functionality is in
> > >    "distribute.ss" from the "setup" collection.
> > >
> > >  * An executable created with --[gui-]exe ignores PLTCOLLECTS and the
> > >    user-specific "collects" directory, because an executable packaged
> > >    for separate distribution shouldn't act like part of a PLT Scheme
> > >    installation. To get the old behavior back, use --ccf -U.
> > >
> > >  * Added `use-user-specific-search-path' and a -U command-line flag to
> > >    MzScheme/MrEd. These are used in the implementation of the previous
> > >    bullet.
> > >
> > >  * `system-type' now accepts an optional symbol argument --- one of
> > >    'os, 'machine, or 'link --- instead of an optional boolean.
> > >
> > >
> > > Matthew
> > >
> > > _________________________________________________
> > >   For list-related administrative tasks:
> > >   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> >
> >
> > ------------------------------------------------------------------------
> ------
> > [application/octet-stream "model-2a.ss"] [save & open]
> >
> > ------------------------------------------------------------------------
> ------
> > [application/octet-stream "example-3.ss"] [save & open]
> > _________________________________________________
> >   For list-related administrative tasks:
> >   http://list.cs.brown.edu/mailman/listinfo/plt-scheme