need for release?

Torsten Anders torsten.anders at plymouth.ac.uk
Fri Feb 1 16:18:44 CET 2008 

Dear all,

I briefly looked into the Path fix matter again, and I realised why I  
put it off for so long. For the Standard Library, there is no test  
suite or similar available so far. I do have Path-specific test  
cases, but I don't know how to put them in place.

I shy away from starting a test suite all on my own. Can anybody  
perhaps give me a hand there?

Thank you!

Best,
Torsten

On Jan 31, 2008, at 3:23 PM, Torsten Anders wrote:

> 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
>>>> mozart-hackers at mozart-oz.org
>>>> http://www.mozart-oz.org/mailman/listinfo/mozart-hackers
>>>
>>>
>>
>> _____________________________________________________________________ 
>> _
>> ___________
>> mozart-hackers mailing list                           mozart-
>> hackers at mozart-oz.org
>> 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                           mozart- 
> hackers at mozart-oz.org
> 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

More information about the mozart-hackers mailing list