Tango 0.96 beta2 released

[Frits van Bommel]

Sean Kelly wrote:
> 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."

Well, the biggest issue was definitely vararg-related, yeah. And 
specifically unportable assumptions made in regards to them.

>> 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.

I don't think I'll find any others until these are fixed, since all I 
did was try to compile every .d file in the tango/ hierarchy with "find 
-name *.d -exec gdc [...]" :).
Though that last one should be trivial to fix.

>> * 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.

Consider yourself reminded :).

 > But perhaps this should be allowed to compile, accompanied
> by a pragma(msg) that Fibers won't work?

Oh, I didn't even know what it was used for, or that it was used by 
Tango itself at all. Like mentioned above, I just indiscriminately tried 
to compile everything...

 > That said, if someone wants to
> pass on the relevant setjmp headers for a 64-bit glibc then I'll see 
> about expanding support.

You mean the ones attached? Or do you need any others?

 > With this in mind, I don't suppose GDC yet
> supports inline ASM for the new 64-bit registers, etc?

Not using the regular DMD-style with Intel syntax, IIRC. But the 
"extended asm" (using at&t syntax in strings) supports them, I think. 
Actually, if it's anything like regular GCC then it's almost literally 
dumped into the input sent to gas (the gnu assembler).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: setjmp-headers.tar.gz
Type: application/x-gzip
Size: 1884 bytes
Desc: not available
Url : http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20070317/416dad2c/attachment.bin