Dear all,
I would also like to include my fixes for the Path module, which we
discussed long ago but which I did not yet committed to the repository.
In any case, I feel that after such a long time a maintenance release
is suitable.
Best
Torsten
On Jan 31, 2008, at 2:21 PM, Boriss Mejias wrote:
Hi Filip,
Thanks for your reply. We were discussing your proposal yesterday
and we also
agree that it would be very good to include this fix before
releasing. Some
observations bellow.
Filip Konvička wrote:
Hi Boriss and all,
I have now a work-in-progress bugfix regarding pickles on Windows.
The problem is that the mechanism used for distinguishing between
file
and socket descriptors is done using the FD_XXX macros. This is bad,
because the mechanism is not robust enough. Recently we are facing
problems on long-running server machines, because the file descriptor
handles are mistakenly used as socket descriptors, thus "send" is
used
on them instead of "write" (or vice-versa), resulting in errors.
Of course, this bug also affects many other things than pickles - the
sockets and file io themselves, and many unexpected
distributed-programming failures.
Since this is a bug mainly concerning windows, be sure that the fix
you add is
within the #ifdef WINDOWS ... #endif marks
The solution is obvious - use a dynamic-sized unordered set for the
socket descriptors. But - I need to know what are the choices for
such
implementation. Of course I don't want to introduce problems by
writing
my own hashtable implementation, so I'd like to use
boost::unordered_set
or at least std::map (this would degrade performance a bit in
heavy-IO
programs). But STD Lib is not used anywhere in Mozart, neither is
boost,
so I'm reluctant to introducing a new dependency.
True. It wouldn't be nice to add new dependencies. But as far as we
know, the
code of boost and std are freely available, so you could just add
the code of
what you need into the Mozart sources. Just be sure to put the
corresponding
notes to be compliant with their license.
I think these fixes should go first to the mozart-1-3-0-fixes
branch, and then
you merged them to the trunk.
thanks for the contribution
Boriss
I think that this is a critical bug and I'd be glad if we could
fix it
before releasing the next version.
Cheers,
Filip
PS: to be more specific, the error I'm getting is coming from
platform/emulator/components.cc line 325, and looks like:
%***************** Error: distributed programming ***************
%**
%** Write failed during save
%**
%** File: 'some_file'
%** Error: 'No error'
("no error" because components.cc uses "errno" for reporting, but
since
the error comes from send(), it should be taking it from
WSAGetLastError, which I'm sure reports 10038 "Not a socket handle").
Later, the same call returns:
%***************** Error: distributed programming ***************
%**
%** Write failed during save
%**
%** File: 'some_file'
%** Error: 'Permission denied'
Which I think is because some other calls in between set errno to
"Permission denied".
So I think I'll fix the error reporting first and wait for your
comments
regarding hashtable implementation.
F.
Dear Hackers,
We had a discussion here at UCL about future releases of Mozart, and
we would
like to have your opinion in order to take some decisions.
First, there are two main projects that will produces releases
1.4.0 and
1.5.0. These are MozDSS and GeOz. The numbers will depend on
which one
releases first.
But, since we haven't released since July 2006 (version 1.3.2), we
wonder if
it is worthy to release 1.3.3 before MozDSS and-or GeOz. The
point is
that no
major bug fixes has been added to the 1-3-0-fixes branch, but here
there are
some reasons in favour of doing the release:
- There is now support for windoze Vista. This is a very small fix
that is
already included in a new 1.3.2 installer for windowze, but it would
be good
to uniform the packages.
- The small fix in the oz script that calls the emulator, and that
concerns
spaces in files names, seems to have fixed an annoying bug for
some time.
- The was an issue concerning the default behaviour of the OPI,
where
different threads where launched with every "declare" statement.
This fix
might be interesting mainly for students.
- A 1.3.3 release would be a would opportunity to close the
1-3-0-fixes branch
- Releasing is good to show that the community is still working on
Mozart/Oz
- Having a deadline for a release may force us to try to fix some
extra-small bugs
The strongest argument against the release would be that the
amount of
fixes
is very small, and it might be enough to not release, but I'm not
sure of
that. This is why I would like to discuss this in order to take a
decision.
Best,
Boriss
____________________________________________________________________
_____________
mozart-hackers mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-hackers
______________________________________________________________________
___________
mozart-hackers mailing list mozart-
[EMAIL PROTECTED]
http://www.mozart-oz.org/mailman/listinfo/mozart-hackers
--
Torsten Anders
Interdisciplinary Centre for Computer Music Research
University of Plymouth
Office: +44-1752-233667
Private: +44-1752-558917
http://strasheela.sourceforge.net
http://www.torsten-anders.de
_________________________________________________________________________________
mozart-hackers mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-hackers
