"Charles" <noone@nowhere.com> wrote...
> Also just a question, how much is Mango.io dependent on the rest of Mango ?

Some lightweight stuff from mango.sys, and then the mango.format package for the higher-level text-oriented writers, such as Stdout.

"Sean Kelly" <sean@f4.ca> wrote ...
> I've considered it, assuming Kris is amenable to the idea.

I was gonna' ask you if I could fold Ares into Mango <G>

Seriously though: you're welcome to add mango.io. You might also consider mango.icu and/or mango.log? These two can optionally be compiled as isolated/standalone packages; otherwise they use a wee bit of mango.io (e.g. raw console output).

Mango.log combined with Chainsaw, and the html-admin, can provide a powerful hook into a running application. Somewhat more so with Ares than with Phobos.

I'd certainly recommend the ICU wrapper, given all the chit-chat about UTF :-)

Kris wrote:
> "Sean Kelly" <sean@f4.ca> wrote ...
>> I've considered it, assuming Kris is amenable to the idea.
> 
> I was gonna' ask you if I could fold Ares into Mango <G>

Given the relative code size, that might be appropriate :-)

> Seriously though: you're welcome to add mango.io. You might also consider mango.icu and/or mango.log? These two can optionally be compiled as isolated/standalone packages; otherwise they use a wee bit of mango.io (e.g. raw console output).

I'll give it a look.  Any thoughts on how to maintain the code if it's merged?  And I suppose the 'Mango' moniker may have to be dropped as well?

> I'd certainly recommend the ICU wrapper, given all the chit-chat about UTF :-)

Definitely.  Now, that does require linking against the IBM ICU library, correct?  I'd kind of like to have some essentials in the Ares core without the need to link against anything else, and then add the ICU wrapper as an add-on.  Still, no reason to postpone ICU support until the core stuff is written.


Sean

"Sean Kelly" <sean@f4.ca> wrote ...
> I'll give it a look.  Any thoughts on how to maintain the code if it's merged?

Given that Mango compiles and runs on both Phobos and Ares, the only concern might be the package names? That can be version'd out too. Which leaves the question "how does one ensure -version=Ares is always applied?". I think that can be resolved.

>And I suppose the 'Mango' moniker may have to be dropped as well?

For package names? See above?


>> I'd certainly recommend the ICU wrapper, given all the chit-chat about UTF :-)
>
> Definitely.  Now, that does require linking against the IBM ICU library, correct?  I'd kind of like to have some essentials in the Ares core without the need to link against anything else, and then add the ICU wrapper as an add-on.  Still, no reason to postpone ICU support until the core stuff is written.

Yes, it uses the ICU dll/so libraries (figured it was better to leverage all that expert and ongoing effort than try to "reinvent" it). But I completely agree with your sentiment.

In article <dldcn5$2r36$1@digitaldaemon.com>, Dave says...
>
>In article <dldart$2pi2$1@digitaldaemon.com>, Lars Ivar Igesund says...
>>
>>Dave wrote:
>>
>>> 1) How much longer before ELF and COFF are supported?
>>
>>I can only say something about ELF, and that is that it might take some time, but the wheels are in motion. I'll probably start posting some progress soon, and get some code committed.
>>
>>Lars Ivar Igesund
>
>Given the current D tool choices, once ELF support is done then we would have something cross platform, right?

That is exactly the direction DDL is moving in.  Provided that D intermediate files (ELF or otherwise) adhere to the same ABI, they will be completely cross-platform within a given processor architecture.

>
>If so, is / can a wrapper then be built around the ELF and OMG libs. to 'choose' the obj. file format at runtime too (so the developer wouldn't have to support both)?

I'm not 100% sure what you're asking here, but let me try to answer as best I can.

The project provides its own file format, '.ddl', that behaves like you describe: as a wrapper around any supported binary file.  This way, one would distribute their program with .ddl files for others to use.  Then, DDL itself will provide the support for whatever types are wrapped by the .ddl file.

It also provides a way to circumvent the ambiguity between OMF and COFF files using the same file extensions.

(aside: I understand that you meant to write "OMF" instead, but I find it funny since that was pretty much my first reaction to reading the "OMG" spec.)

>
>Just curious, how important would COFF be unless MS decided to support D in a big way (fat chance <g>)?

There are several advantages to supporting COFF.

Already there are a few D projects that rely on C-libraries that are made available in COFF format only.  Some of these, like Direct-X, are closed-source. Obviously, one could run COFF2OMF on those files, but that is not a free tool. So DDL can provide a stop-gap for these situations.

Also, good 'ol .dll files are in COFF format as are .exe files.  Since we get support for these types along with formal COFF .lib/.obj support, we get these almost for free.

Ultimately, its there for completeness.  If nobody uses it, nothing changes. :)

>
>Sorry, maybe I'm jumping the gun here a bit, but somehow I missed the implications of DDL before and it really looks promising, especially if we could also have the benefits of header files w/o the hassle, or resorting to some sort of intermediate code format like Java.

That's basically the idea: runtime, GC managed, linking in D without needing a VM or unix*.  Loading intermediate files is the best way to get there.


(* This this kind of thing is largely possible on linux already, provided you're working with position-independent ELF files.  In that case, DDL will simply add a GC to the equation, which is really what we want with D anyway)

- EricAnderton at yahoo

I'll try to answer the bits that haven't been covered yet. :)

In article <dld5lt$2l18$1@digitaldaemon.com>, Dave says...
>
>2) Is there anything started for emitting 'header' source code for static libs?

Nope. But I think it's been brought up before.

One problem with this concept is that D symbol information contains more than enough information to reproduce a D-header quite easily.  Everything else (C/C++ mostly) defies reproduction when working with an intermediate file.  Now if that doesn't seem like a problem then it should be quite easy to cobble together such a utility: the current codebase in SVN already has the parts to do most of this.

>3) I'm not familiar with the .ddl format or what it is capable of -

The .ddl format allows for a clean, portable way to refer to intermediate (object) files without having to manage a constellation of file-types and extensions.  The format is really just a wrapper, which stores some information about the enclosed binary file in the header.

The .ddl header information contains, but is not limited to:
- the name of the (original) enclosed binary
- the binary's type (independent of its file extension) like OMF or COFF
- arbitrary metadata (planned)

> is it (capable of) extracting function body code as well?

Not in a way that would reproduce the original source code.  All the binary file support in DDL is only as capable as what we have for .dll files right now, with the addtion of resolving external dependencies and fixups.

- EricAnderton at yahoo

Dave wrote:
> In article <dldart$2pi2$1@digitaldaemon.com>, Lars Ivar Igesund says...
> 
>>Dave wrote:
>>
>>
>>>1) How much longer before ELF and COFF are supported?
>>
>>I can only say something about ELF, and that is that it might take some
>>time, but the wheels are in motion. I'll probably start posting some
>>progress soon, and get some code committed.
>>
>>Lars Ivar Igesund
> 
> 
> Given the current D tool choices, once ELF support is done then we would have
> something cross platform, right?
> 
> If so, is / can a wrapper then be built around the ELF and OMG libs. to 'choose'
> the obj. file format at runtime too (so the developer wouldn't have to support
> both)?
> 

The what libs?

http://www.orlyowl.com/omg.jpg

> Just curious, how important would COFF be unless MS decided to support D in a
> big way (fat chance <g>)?
> 
> Sorry, maybe I'm jumping the gun here a bit, but somehow I missed the
> implications of DDL before and it really looks promising, especially if we could
> also have the benefits of header files w/o the hassle, or resorting to some sort
> of intermediate code format like Java.
> 
> Thanks,
> 
> - Dave
> 
> 

In article <dle49g$ceu$1@digitaldaemon.com>, James Dunne says...
>
>The what libs?
>
>http://www.orlyowl.com/omg.jpg
>

Nice.  That's definately going in the FAQ.

- EricAnderton at "O RLY?"

In article <dle49g$ceu$1@digitaldaemon.com>, James Dunne says...
>
>Dave wrote:
>> In article <dldart$2pi2$1@digitaldaemon.com>, Lars Ivar Igesund says...
>> 
>>>Dave wrote:
>>>
>>>
>>>>1) How much longer before ELF and COFF are supported?
>>>
>>>I can only say something about ELF, and that is that it might take some time, but the wheels are in motion. I'll probably start posting some progress soon, and get some code committed.
>>>
>>>Lars Ivar Igesund
>> 
>> 
>> Given the current D tool choices, once ELF support is done then we would have something cross platform, right?
>> 
>> If so, is / can a wrapper then be built around the ELF and OMG libs. to

I have to ask myself: Typo or Freudian slip? <g>

'choose'
>> the obj. file format at runtime too (so the developer wouldn't have to support
>> both)?
>> 
>
>The what libs?
>
>http://www.orlyowl.com/omg.jpg
>

Ha!

>> Just curious, how important would COFF be unless MS decided to support D in a big way (fat chance <g>)?
>> 
>> Sorry, maybe I'm jumping the gun here a bit, but somehow I missed the implications of DDL before and it really looks promising, especially if we could also have the benefits of header files w/o the hassle, or resorting to some sort of intermediate code format like Java.
>> 
>> Thanks,
>> 
>> - Dave
>> 
>> 

In article <dle2in$b48$1@digitaldaemon.com>, pragma says...
>
>In article <dldcn5$2r36$1@digitaldaemon.com>, Dave says...
>>
>>In article <dldart$2pi2$1@digitaldaemon.com>, Lars Ivar Igesund says...
>>>
>>>Dave wrote:
>>>
>>>> 1) How much longer before ELF and COFF are supported?
>>>
>>>I can only say something about ELF, and that is that it might take some time, but the wheels are in motion. I'll probably start posting some progress soon, and get some code committed.
>>>
>>>Lars Ivar Igesund
>>
>>Given the current D tool choices, once ELF support is done then we would have something cross platform, right?
>
>That is exactly the direction DDL is moving in.  Provided that D intermediate files (ELF or otherwise) adhere to the same ABI, they will be completely cross-platform within a given processor architecture.
>
>>
>>If so, is / can a wrapper then be built around the ELF and OMG libs. to 'choose' the obj. file format at runtime too (so the developer wouldn't have to support both)?
>
>I'm not 100% sure what you're asking here, but let me try to answer as best I can.
>
>The project provides its own file format, '.ddl', that behaves like you describe: as a wrapper around any supported binary file.  This way, one would distribute their program with .ddl files for others to use.  Then, DDL itself will provide the support for whatever types are wrapped by the .ddl file.
>
>It also provides a way to circumvent the ambiguity between OMF and COFF files using the same file extensions.
>
>(aside: I understand that you meant to write "OMF" instead, but I find it funny since that was pretty much my first reaction to reading the "OMG" spec.)
>
>>
>>Just curious, how important would COFF be unless MS decided to support D in a big way (fat chance <g>)?
>
>There are several advantages to supporting COFF.
>
>Already there are a few D projects that rely on C-libraries that are made available in COFF format only.  Some of these, like Direct-X, are closed-source. Obviously, one could run COFF2OMF on those files, but that is not a free tool. So DDL can provide a stop-gap for these situations.
>
>Also, good 'ol .dll files are in COFF format as are .exe files.  Since we get support for these types along with formal COFF .lib/.obj support, we get these almost for free.
>
>Ultimately, its there for completeness.  If nobody uses it, nothing changes. :)
>
>>
>>Sorry, maybe I'm jumping the gun here a bit, but somehow I missed the implications of DDL before and it really looks promising, especially if we could also have the benefits of header files w/o the hassle, or resorting to some sort of intermediate code format like Java.
>
>That's basically the idea: runtime, GC managed, linking in D without needing a VM or unix*.  Loading intermediate files is the best way to get there.
>
>
>(* This this kind of thing is largely possible on linux already, provided you're working with position-independent ELF files.  In that case, DDL will simply add a GC to the equation, which is really what we want with D anyway)
>
>- EricAnderton at yahoo

Thanks for the answers (and you guessed right at what I was asking). Very cool.

- Dave