Ben,

Your MinTLc library includes a dependent version of the locks library, which is slightly outdated compared to the independent version offered on your site (i.e. using !== and === instead of !is and is, respectively).

It also breaks compilation in locksimpl.d on linux (haven't tested on Win32, so I can't say), while the independent version compiles just fine.  I don't know if you have special modifications made to the dependent locks library for use with MinTLc vs. the independent locks library.  Hopefully, they should be one in the same, but it is not safe for me to assume so.  For now, I'll try using the independent locks library (overwriting the dependent copy MinTLc.zip unpacks).

Thanks, Ben!

James Dunne wrote:
> Ben,
> 
> Your MinTLc library includes a dependent version of the locks library, which is slightly outdated compared to the independent version offered on your site (i.e. using !== and === instead of !is and is, respectively).
> 
> It also breaks compilation in locksimpl.d on linux (haven't tested on Win32, so I can't say), while the independent version compiles just fine.  I don't know if you have special modifications made to the dependent locks library for use with MinTLc vs. the independent locks library.  Hopefully, they should be one in the same, but it is not safe for me to assume so.  For now, I'll try using the independent locks library (overwriting the dependent copy MinTLc.zip unpacks).
> 
> Thanks, Ben!

On 2nd check, the library completely fails to compile with many errors under linux.  I'm using DMD v0.129.

-- 
Regards,
James Dunne

In article <dfao9k$1or7$1@digitaldaemon.com>, James Dunne says...
>
>James Dunne wrote:
>> Ben,
>> 
>> Your MinTLc library includes a dependent version of the locks library, which is slightly outdated compared to the independent version offered on your site (i.e. using !== and === instead of !is and is, respectively).
>> 
>> It also breaks compilation in locksimpl.d on linux (haven't tested on Win32, so I can't say), while the independent version compiles just fine.  I don't know if you have special modifications made to the dependent locks library for use with MinTLc vs. the independent locks library.  Hopefully, they should be one in the same, but it is not safe for me to assume so.  For now, I'll try using the independent locks library (overwriting the dependent copy MinTLc.zip unpacks).
>> 
>> Thanks, Ben!
>
>On 2nd check, the library completely fails to compile with many errors under linux.  I'm using DMD v0.129.
>
>-- 
>Regards,
>James Dunne

Hmm. I'll check it out after the long weekend. I hadn't been giving much attention to locks and mintlc lately.

"Ben Hinkle" <Ben_member@pathlink.com> wrote in message news:dfcuom$jef$1@digitaldaemon.com...
> In article <dfao9k$1or7$1@digitaldaemon.com>, James Dunne says...
>>
>>James Dunne wrote:
>>> Ben,
>>>
>>> Your MinTLc library includes a dependent version of the locks library, which is slightly outdated compared to the independent version offered on your site (i.e. using !== and === instead of !is and is, respectively).
>>>
>>> It also breaks compilation in locksimpl.d on linux (haven't tested on Win32, so I can't say), while the independent version compiles just fine.  I don't know if you have special modifications made to the dependent locks library for use with MinTLc vs. the independent locks library.  Hopefully, they should be one in the same, but it is not safe for me to assume so.  For now, I'll try using the independent locks library (overwriting the dependent copy MinTLc.zip unpacks).
>>>
>>> Thanks, Ben!
>>
>>On 2nd check, the library completely fails to compile with many errors under linux.  I'm using DMD v0.129.
>>
>>-- 
>>Regards,
>>James Dunne
>
> Hmm. I'll check it out after the long weekend. I hadn't been giving much attention to locks and mintlc lately.

updated to dmd.131 and uploaded to the MinTL page http://home.comcast.net/~benhinkle/mintl/