RELEASE on March, 1st !!!

Christian Schulte schulte at imit.kth.se
Tue Feb 10 10:33:41 CET 2004 

Great,

finally. I have a question and a thing I noticed recently for 1.2.5 (related
to packaging): 

What is the Windows issue? I thought there is also expertise at SICS doing
that? If not, do you still have the slides Leif and me did describing all
this?

Packaging of the linux tarballs: the very idea of having these beasts is to
link as much in statically as possible so as to have them a safe fallback
whenever other packages such as rpms get you in trouble. I noticed, though,
that in the version for 1.2.5 tk.exe is dynamically linked against a great
stuff of things: in practice this meant for my students (using Mozart in a
Constraint Programming Course here at KTH) this package was a no-go and they
had to revert to 1.2.3. (We didn't try 1.2.4)

I do have a general comment about 0. though: without providing information,
chances for getting information from the "out there" are miniscule.

Cheers and keep up the good work!
Christian

--
Christian Schulte, http://www.imit.kth.se/~schulte/ 

-----Original Message-----
From: mozart-hackers-bounces at mozart-oz.org
[mailto:mozart-hackers-bounces at mozart-oz.org] On Behalf Of Konstantin Popov
Sent: Monday, February 09, 2004 6:33 PM
To: hackers at mozart-oz.org
Subject: RELEASE on March, 1st !!!



Dear all,

I'm coming back to the question of the forthcoming release.  There was some
slow, "sneaky" progress made despite everything but we, and myself in
particular, have to concentrate now.

I believe there are several important issues:

0. IS ANYBODY OUT THERE??
   That is, SERIOUSLY, I'd like to know who cares at all, and whom we
   (Kevin+myself) can count on. I learned, for instance, that some
   people recently changed their employer.

1. performace issues [with gcc3]
   It looks like we can solve them for some platforms (intel), at
   least temporarily - and hoping that the future gcc release will be
   better. The things are "all right" out-of-box for other ones
   (e.g. apple). DO I SEE IT RIGHT?

2. ozmake & friends (contrib, mozart-stdlib, MOGUL)
   Well, I know there are plans to sort out the organization of the
   system from the bootstraping & packaging issue, but right now we
   have a mess. As a practical solution *for the release* we propose
   the following:
   . update the MOGUL web page such that it becomes clear that one 
     need ozmake [for dealing with packages] and where&how to get it.
   . leave the contrib&mozart-stdlib things in place for now unless
     someone really wants to fix it (the idea is, if I'm not mistaken,
     that all 'contrib' stuff will eventually go to 'mozart-stdlib'.
     We'd suggest also the ozmake SOURCES go there as well so that
     bootstrapping the stdlib begins with building the ozmake, which
     is then used for everything else).

   Kevin also pointed out that currently the MOGUL web interface does
   not support multiple "platforms" - after the release packages will
   have to be updated (can that be done automatically?) and everyone
   will have to use the new [1.3.0] version. I do care for QTK in
   particular (since it's in the book).

3. packaging
   Probably the bulkiest chunk of work. I'm afraid we might miss
   information about Windows (apparently, the Windows packaging
   business is going to change hands now). MacOS X & other platforms
   (aka FreeBSD) seem to be a bit ad'hoc as well. WE WOULD WELCOME ANY
   INPUT - HELP, INFORMATION, DOCUMENTATION HERE!!! Credits will be 
   of course given..

   We plan to issue packages for testing BEFORE the release (in order
   to avoid packaging-related confusion).

4. web page & access
   As usual, we either need the access to the web page OR someone who
   will fix the webpage himself. PLEASE RESPOND ASAP!! I have to know
   what to do next - start looking at the web server, discuss things
   with involved person(s) or even searching for the responsible
   partner!

5. bugs
   The good news is that we didn't get many new ones recently.  The
   bad news is that not much is going on here anyway (in particular
   when it comes to the compiler, though Kevin - and hopefully a new
   person at our site - will eventually rectify the situation). None
   of them look to be release-precluding, though. A somewhat filtered
   list is attached - PLEASE REPORT ASAP IF SOMETHING IS MISSING.

The good thing is that the 1.3.0 gets its workout - notably in Singapore and
with the version for the book "pre-print", and it is doing fine.

Feedback?

Cheers,

 --- Kostja.


 ----- bugs -----

engine
  1203 (engine hangs on corrupt functors)

Compiler
  low:
   87 299 300
   315 (compiler crashes when static analysis is turned off)
   654 940
  mid:
   343 (compiler crash in OPI only)
   464 (compiler crash on a fairly strange code)
   867 (compiler crash on a fairly strange code)
  high: 
   571 (register allocation)
   655 (bad code for 'try .. end')
   931 (register allocation broken)
   1070 (troubles compiling with '-g'. DIFFERENT problems on win and
linux!!)
   1244 (broken code. The same as 571?)

Documentation
  592 (in general - check the Mozart/C interface?!)
  700 (OsTime module's documentation)
  769 (stuff in 'share/examples' - who??!)
  881 ("Service" module)
  909 (OZLOAD & friends environment variables for 'Resolve' module)
  991 (exceptions & friends)
  1018 (empty pages in "Problem Solving With Finite Set Constraints")
  1115 (subtle (or not so subtle) points about "uniform state syntax")
  1207 (Mozart is NOT listed as "free software" on FSF's web page!)

Constraints
  749? (could not reproduce it on Linux)
  762 (overflow bug in LinEqPropagator)
  800 (optimistic stability after merging)
  814 (broken RecordC:monitorArity propagator)
  894 (explorer delivers wrong results on first invocation)
  1168 (FS.monitorOut on singletons)
  1239 (FS.reified.bounds(N) undocumented)

Distribution
  825 (stale processes? better fix it as Denys suggested)
  888 (watchers: slow when DP is not initialized, and space leaky)
  1080 (I/O fragmentation with connect/accept functors?)
  1243 (MsgContainer::unmarshal: bad Oz term)

ozmake (new category)
  796 970 1209

tools
  904 (inspector ignores default mappings)
  754 (inspector occasionally fails to recognize "named" variables)
  824 (inspector produces wrong outputs when sub-terms are selected)

win-i486
  840 (tcl/tk problem)
  936 (tcl/tk problem?)
  981 (runaway when Application.exit is not called?)
  1064-1072-1073 (remote module manager creation problems under winxp?)
  1161 (Connection.take fails to work without operational DNS)
  1190 (cannot handle Mozart processe with large amounts of data?)
  736 (resolver limitation on Windows)
  859 (ozengine with functor paths generated by cygpath -ws)

solaris-sparc
  1191 (presumably troubles with allocating memory)

darwin-ppc
  997 (hard-wired name of compiler ('gcc') in oztool.sh)

netbsd
  1236 (missing "defined(NETBSD)")

libraries
  685 (minor - error formatting)
  872 (ozmake.ozf in standard-library)

demos
  1127 ("tracks" crash saying "Space already contains distributable thread")

REQUEST, OBSERVATION
  have a look!!
_______________________________________________
mozart-hackers mailing list
mozart-hackers at mozart-oz.org
http://www.mozart-oz.org/mailman/listinfo/mozart-hackers

More information about the mozart-hackers mailing list