Tango 0.96 beta2 released

[Sean Kelly]

Frits van Bommel wrote:
> [Fair warning: this seems to have become a pretty big post]
> 
> Sean Kelly wrote:
>> Frits van Bommel wrote:
>>>
>>> I attached a patch, though I'm not sure how much use it'll be if you 
>>> insist on your own version of std.c.stdarg ...
>>
>> Thanks.  I think the stdarg issues should now be resolved  [...]
> 
> Sorry to disappoint again.
> Unfortunately, build-gdc.sh only compiles files in lib/ (and some in 
> std/ imported by them). These compile successfully with my patch, AFAICT.

Is this related to the stdarg issues?  Just want to make sure I 
understand what you meant by "sorry to disappoint."
> 
> The stuff in tango/ doesn't work quite as well though.
> For instance, it turns out tango.text.convert.Layout is pretty screwed 
> in the current implementation. Again, this has to do with varargs.

Saw that.  I passed the issue to Kris, but I suspect we may have to work 
together on this one.

> There were some other errors I less thoroughly investigated, but most of 
> these look like they can probably easily be fixed (in the first two 
> cases perhaps even by simply using the same code as for x86?):
> * tango.sys.linux.socket static asserts(0) if version(X86) isn't 
> defined, with comment "// Different values on other platforms." (the X86 
> branch defines a constant named "SOL_SOCKET", whatever that may be)
> * tango.math.IEEE doesn't define the FPU masks for amd64 (just for x86 
> and PPC it seems).
> * tango.text.Regex also seems to assume that va_list is a pointer to a 
> 1-byte type instead of using va_start/va_arg/va_end.

Thanks.  We'll look into these.  And please feel free to submit tickets 
for these or any other problem you find.

> * tango.stdc.posix.setjmp straight static asserts(false, "Architecture 
> not supported.") on version(X86_64) (though the actual error is an 
> undefined identifier used after that, presumably because static asserts 
> are evaluated a bit late in the parsing process)

This was deliberate, as a clear and obvious reminder to expand support 
as needed.  But perhaps this should be allowed to compile, accompanied 
by a pragma(msg) that Fibers won't work?  That said, if someone wants to 
pass on the relevant setjmp headers for a 64-bit glibc then I'll see 
about expanding support.  With this in mind, I don't suppose GDC yet 
supports inline ASM for the new 64-bit registers, etc?


Sean