need for release?

Boriss Mejias boris.mejias at uclouvain.be
Tue Feb 5 00:22:16 CET 2008 

Torsten Anders wrote:
> 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.

If the Path fix is conservative enough, and you tested it accordingly, I don't 
think it is necessary to first have a test suite for the standard library to 
decide its inclusion in the release. So, just go for it. You can add the tests 
you used to the bug report.

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

Sorry... this is out of my priorities right now.

cheers
Boriss

> 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
> 
> 
> 
> 
> _________________________________________________________________________________ 
> 
> 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