Just some quick info: Kevin's changes are fine by me as I told him. Sorry
for forgetting you (should again be strict on never answering Mozart related
Email).
CS
<duchier@ps.uni-sb.de> wrote in message news:87y8wyf5g3.fsf@tdg.loria.fr...
> kost@sics.se (Konstantin Popov) writes:
>
> > 1. "uniform state access" syntax
> > As far as I understand, the thing is agreed upon (and present in
> > the book), and does really work. What is missing:
> > . test suite?!
> > . Documentation! Should it come into the "Oz Notation",
> > or stay as a separate document?
>
> It is an important improvement on the current situation (eventhough I
> still believe that the weird asymmetry was a mistake and makes Oz
> syntax unnecessarily inconsistent with 4 decades of computing
> practice).
>
> Kevin: did we fix all performance issues? I think there are still
> issues with OO programming where we take a hit with the new syntax
> (because SA cannot help). IIRC, we also had the idea to eventually
> provide bytecode support for the new syntax: this would probably fix
> the remaining performance problems, but we should schedule it for
> after the 1.3.0 release.
>
> Apropos documentation: when we consider this question, we should
> probably include the loop documentation in our thinking. (Ah, having
> read more carefully to the end, I now see that you also suggest that)
>
> > 2. New "by need" synchronization primitives
> > As far as I can see, the thing is agreed upon and actually there,
> > but now somehow still did not yet even made as a "candidate feature"
>
> where is this work? I certainly never heard of it before it was
> recently mentioned on the list and I have not seen it in CVS. Is
> there a branch for it?
>
> > . how exactly we're goint to tell about this change to users?
>
> there is really not much to tell (as such) from the perspective of a
> user. There is a new primitive WaitNeeded (or whatever). ... That is
> unless you really insist on changing the semantics of ByNeed. I
> understand the desire to have better primitives with better names, but
> changing the semantics of a primitive in wide use will certainly cause
> problems.
>
> > 3. The fate of old "ByNeed futures".
>
> I think they should remain (under whatever name) - they work, are
> economical, and allocate resources on-need rather than up-front. When
> better read-only vars are designed/implemented, then they should be
> modified to use that. We should be careful to better document their
> semantics: we now know how to do this well.
>
> > 4. Memory leaks [at the level of Mozart bytecode]
> > Kevin did IMHO a great (and patient) job, which is basically in
> > place (except that "GC recursiveness" controversy, where (a) real
> > "against" arguments must be delivered (Christian? Denys?), and (b)
> > I believe we know how to fix it if proven guilty).
>
> I'd really like to hear Christian's opinion on this issue. I would
> also really like Leif to also review the changes. I have very high
> confidence in Kevin, but this is really very difficult stuff -
> additional eyes can only help.
>
> Also, Kevin mentioned that he has since made improvements over the
> diffs that I saw. Is this stuff in CVS? in a branch? If you want to
> put it directly in the trunk, then please tag before you add the
> patches so that we can more easily do before/after benchmarks.
>
> > 6. Performance and memory leaks [at the level of the runtime system]
> > I did some tests (which were fine) and we (with Kevin) will do some
> > more (in particular, gcc 3.* -related). Does anyone has some open
> > concerns here?
>
> Now that I think about it, I recall that there was a thread on "time
> and space leakage with watchers". Erik was looking into it. Whatever
> happened to this issue?
>
> > 7. Windows.
> > Oh, that Windows ;-( In general - very little clue on my side of
> > what's going on there (Kevin reported that the bootstrapping and
> > wrapping procedure, God bless us, (still) works). Any issues??!
>
> What version of gcc does it work with. Have the issues with 3.x
> disappeared?
>
> Also, there are quite a few bug reports concerning Windows. We need
> people to act on them.
>
> > 8. MacOS X
> > It looks like we should now support this platform.
>
> We do since 2001.
>
> > Our Belgian
> > colleagues even have know-how (I was pleasantly surprised to see
> > them doing the "by need" stuff on a Mac laptop!) I would not mind
> > to deal with that myself too but do not have hardware.
>
> Until now, MacOS X development has been handled with Marc-Antoine
> Parent. He is the guy who made it happen and continues to improve the
> port, track progress, and prepare MacOS X distros. Don't
> short-circuit him out. He might appreciate to have some new
> colleagues to work with, but you should consider him the senior MacOS
> X dev. he certainly has earned it.
>
> > 9. Any missing "fixes" (and not only ;-9) from the 1.2.* branch??!
> > Reportedly there are none, but I'll study this issue in more
> > detail.
>
> good luck! I am glad you're doing this. That's always the part I
> hated most. Especially since, as you go, you should take note of bug
> fixes, and important checkins that need to be reported in the Changes
> document (because unfortunately we always forget to report these
> things to the "changes" newsgroup). It's a PITA.
>
> > 10. Bugs.
> > There are still some in the repository; I'll try to do my best to
> > at least classify them by the end of the next week. Expect
> > assignments ;-)
>
> - the windows stuff really needs to be worked on
> - tk issues with e.g. accented characters (is this fixed now?)
>
> > 11. Documentation.
> > Well, I'm happy by myself :-) but probably not others, so I can
> > try to coordinate sensible requests from you. However, one point
> > is for sure, besides already mentioned above: should the
> > syntax of the loop constructs be propagated to "Oz Notation"?
>
> Some of it, sure, but the Oz Notation is just a reference document and
> not very useful to users. A separate document is still needed that
> really explains things, but perhaps it could be consolidated with
> other things that also need to be documented (like the uniform state
> stuff).
>
> Cheers,
>
> --
> Denys Duchier - Équipe Calligramme - LORIA, Nancy, France
> -
> Please send submissions to hackers@mozart-oz.org
> and administriva mail to hackers-request@mozart-oz.org.
> The Mozart Oz web site is at http://www.mozart-oz.org/.
-
Please send submissions to hackers@mozart-oz.org
and administriva mail to hackers-request@mozart-oz.org.
The Mozart Oz web site is at http://www.mozart-oz.org/.