[m-rev.] for review: Use a better algorithm for unwinding version_arrays.

[Paul Bone]

On Tue, Sep 09, 2014 at 03:17:15PM +1000, Julien Fischer wrote:
>
>
> On Tue, 9 Sep 2014, Paul Bone wrote:
>
>> On Tue, Sep 09, 2014 at 02:47:58PM +1000, Julien Fischer wrote:
>>> Hi Paul,
>>>
>>> On Tue, Sep 9, 2014 at 2:24 PM, Paul Bone <paul at bone.id.au> wrote:
>>>
>>>> On Thu, Aug 07, 2014 at 12:49:52PM +1000, Paul Bone wrote:
>>>>> On Wed, Aug 06, 2014 at 02:27:37PM +1000, Peter Wang wrote:
>>>>>> I think it would be better to update the C# backend at the same time.
>>>>>> If you can't test it then make a best effort and post an updated patch,
>>>>>> then I can fix any minor compilation problems.
>>>>>>
>>>>>
>>>>> Right now I can't even run the mono compiler.  So I'll have to fix this
>>>>> before I can make any reasonable amount of progress.
>>>>>
>>>>
>>>> The RTS for the C# backend is organised differently from the other
>>>> backends.
>>>> It seems to be contained within one file runtime/mercury_dotnet.cs.  Or is
>>>> it? is this file used by the C# backend or just the old .net backend?
>>>>
>>>
>>> The runtime modules for the C# grade are included directly in the stdlib,
>>> From library/Mmakefile:363:
>>>
>>>     # For C# we include the runtime module directly into mer_std.dll.
>>>     ifneq ("$(filter csharp%,$(GRADE))","")
>>>     LINK_LIB_OPTS :=
>>>     MLOBJS += ../runtime/mercury_dotnet.cs
>>>     endif
>>>
>>
>> Would anyone object to me putting MercuryBitmap at
>> library/csharp/MercuryBitmap.cs and adding it to MLOBJS here?
>
> Yes, I object.  If we are going to end up with multiple C# modules
> forming part of the runtime / stdlib then they should be separated out
> as per the Java backend.  Relying on developers to always update the
> assignment to MLOBJS is very brittle.

What's the difference between having to add an extra line to a Makefile or
an :- import_module directive in a .m file?

Since we use GNU make we could also avoid this totally by saying:

    MLOBJS += ../runtime/mercury_dotnet.cs $(wildcard csharp/*.cs)

>> Other shared code that's not exactly runtime code could go into the same
>> location.
>>
>> It seems to me that MercuryBitmap isn't runtime code because not all/most
>> modules need it.
>
> The bitmap code for C backends lives in runtime/mercury_bitmap.[ch]; I
> don't see that this situation is any different.  Just put it in
> runtime/mercury_dotnet.cs.
>

Putting all the code in one file doesn't seem right to me.  MercuryBitmap
doesn't call code in mercury_dotnet.cs, or vice-versa.  This is why I'd
prefer seperate files.


-- 
Paul Bone