need for release?

[Torsten Anders]

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