need for release?

Boriss Mejias boris.mejias at uclouvain.be
Tue Feb 5 19:33:07 CET 2008 

Sure, we first have to submit a MEP for acceptance. Since there is a more or 
less a consensus with the release, I can post a draft during the week.

cheers
Boriss

Torsten Anders wrote:
> Dear Boris,
> 
> thanks for your reply. Would it be sufficient for the new release if I 
> do the Path commits early next week? (there is a conference deadline 
> this Friday...)
> 
> Best
> Torsten
> 
> On Feb 4, 2008, at 11:22 PM, Boriss Mejias wrote:
>> 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
>> _________________________________________________________________________________ 
>>
>> 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