[m-dev.] 0.13 release

Ian MacLarty maclarty at cs.mu.OZ.AU
Thu Mar 2 00:29:33 AEDT 2006


On 1 Mar 2006, at 14:13, Julien Fischer wrote:

>
> On Wed, 1 Mar 2006, Ian MacLarty wrote:
>
>> On 1 Mar 2006, at 13:42, Julien Fischer wrote:
>>
>>>
>>> On Wed, 1 Mar 2006, Ian MacLarty wrote:
>>>
>>>> On 1 Mar 2006, at 05:27, Julien Fischer wrote:
>>>>
>>>>> * `mmc --make' does not work with MinGW
>>>>>
>>>>
>>>> Can you be more specific?  I can compile the xml parser with mmc
>>>> --make
>>>> on MinGW.
>>>>
>>>
>>> Specifically, we couldn't get the last g12 release to build and 
>>> install
>>> with MinGW/MSYS (IIRC it had something to do with libary 
>>> installation).
>>>
>>
>> I'm not sure installation via mmc --make is the right way to do things
>> on Windows.  Typically you don't install from source on Windows unless
>> you're restricting yourself to a unix like environment like MSYS or
>> Cygwin.  Usually you'd distribute a binary package.
>>
>
> Where are you proposing we build the binary package?  This was in MSYS.
>

I thought the problem was you couldn't install using mmc --make, but 
you could build?

>>>> Do we want the streams proposal to be in 0.13 (assuming we are able 
>>>> to
>>>> come up with a design everyone is happy with)?
>>>>
>>>
>>> Provided we actually have a design for it I have no problem with
>>> including the stream module itself in the standard library for 0.13.
>>> I'm somewhat more hesitant of about the idea of converting to
>>> term_to_xml, term_io to use it for 0.13 though - that should probably
>>> wait.
>>>
>>
>> What's the reason you want to wait?
>> term_to_xml definitely needs to work on streams.
>> It's crippled at the moment because it can only
>> write to files and often you want to send XML over
>> network connections.
>
> For term_io and friends we would need to be careful about the 
> performance
> impact on the compiler; for term_to_xml I guess that's not so 
> important.
>
> (Ideally this would all be sorted out before we fork the repository as 
> well.)
>
>>> Also, if we want io.input_stream and friends to be instances of the
>>> stream class the io module is going to require a bit of surgery.
>>> I'm happy to include the stream module as part of the standard 
>>> library,
>>>
>>
>> Did you mean to write something more there?
>>
>
> Hmmm... I don't think that line is meant to be there.
>
>> Yes I realise quite a bit of surgery is required for io and term_io, 
>> but
>> it will be quite easy to change term_to_xml.
>
> Actually, I've already had a go at modifying some of the io module but
> there's not a lot of point in finishing it until the streams design is
> nailed down.
>
> term_to_xml is, of course, your problem ;-)
>

of course :-)

I will have a look at the new streams design shortly.

Ian.

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list