www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Ares & Mango

reply "Kris" <fu bar.com> writes:
Mango 1.6 runs happily upon Ares, with one exception: Ares doesn't have an 
std.regexp in the current release, so the mango servlet engine will fail to 
compile & link (unittest also). I have a modified ares.lib to resolve that 
problem, which I can pass along to anyone who wants it. That aside, Mango 
and Ares operate beautifully together on Win32 ~ Sean has done a great job 
partitioning Ares into a modular and extensible platform. To target Ares, 
use these Build.exe options:

-version=Ares
-I[path to Ares source]
-X[path to Ares source]

Haven't attempted Ares on linux or darwin yet. Has anyone tried that?

-----------------

Ares is here: http://svn.dsource.org/projects/ares/downloads/
Mango is here: http://mango.dsource.org/
Nov 14 2005
parent reply Sean Kelly <sean f4.ca> writes:
Kris wrote:

 Mango 1.6 runs happily upon Ares, with one exception: Ares doesn't have an 
 std.regexp in the current release, so the mango servlet engine will fail to 
 compile & link (unittest also). I have a modified ares.lib to resolve that 
 problem, which I can pass along to anyone who wants it. That aside, Mango 
 and Ares operate beautifully together on Win32 ~ Sean has done a great job 
 partitioning Ares into a modular and extensible platform.


Thanks!  And for what it's worth, std.regexp will be added as a 
submission in the next Ares release.  It may undergo interface changes 
(or implementation tuning) before becoming official, but it will be 
available for Mango before too terribly long.


 Haven't attempted Ares on linux or darwin yet. Has anyone tried that?


If anyone has interest in testing Ares on non-Win32, please let me know. 
  The Posix implementation is fairly sparse in places, as I don't have 
an environment set up to work on this.


Sean
Nov 14 2005
next sibling parent reply John Reimer <John_member pathlink.com> writes:
In article <dlaq0k$1gs$1 digitaldaemon.com>, Sean Kelly says...

Kris wrote:

 Mango 1.6 runs happily upon Ares, with one exception: Ares doesn't have an 
 std.regexp in the current release, so the mango servlet engine will fail to 
 compile & link (unittest also). I have a modified ares.lib to resolve that 
 problem, which I can pass along to anyone who wants it. That aside, Mango 
 and Ares operate beautifully together on Win32 ~ Sean has done a great job 
 partitioning Ares into a modular and extensible platform.


Thanks!  And for what it's worth, std.regexp will be added as a 
submission in the next Ares release.  It may undergo interface changes 
(or implementation tuning) before becoming official, but it will be 
available for Mango before too terribly long.


 Haven't attempted Ares on linux or darwin yet. Has anyone tried that?


If anyone has interest in testing Ares on non-Win32, please let me know. 
  The Posix implementation is fairly sparse in places, as I don't have 
an environment set up to work on this.


Sean


I think I've succeeded in building Ares on Linux, but I can't remember the
results.  If anything,  I think the changes were minor.  I will give it a try
again in the next few days.  I'll also test the combination of Ares and Mango
and see what happens on Linux.

Ares is wondefully small and streamlined.  Ares, Mango.io and std.regexp... for
what more could could one ask?

Thanks Kris and Sean.  You guys are great.  I'm just waiting for Eric's DDL to
reach steady-state; then we'll have it all!

-JJR
Nov 14 2005
parent reply pragma <pragma_member pathlink.com> writes:
In article <dlatoc$erk$1 digitaldaemon.com>, John Reimer says...

Ares is wondefully small and streamlined.  Ares, Mango.io and std.regexp... for
what more could could one ask?


Well, I've always wondered if DMD could be cut free from it's DMC heritage
completely.  When I get to porting DDL over to Ares, I'll get to see how much of
'snn.lib' Ares forces the linker to bring on board.  I suspect that little of it
is actually being used.


Thanks Kris and Sean.  You guys are great.


I have to echo this sentiment: I'm really amazed to see how much things have
changed over just the past two years.  You two have really put your best into
all this.


I'm just waiting for Eric's DDL to reach steady-state; then we'll have it all!


I can't wait either.  ;)

- EricAnderton at yahoo
Nov 14 2005
next sibling parent "Kris" <fu bar.com> writes:
"pragma" <pragma_member pathlink.com> wrote

 Well, I've always wondered if DMD could be cut free from it's DMC heritage
 completely.  When I get to porting DDL over to Ares, I'll get to see how 
 much of
 'snn.lib' Ares forces the linker to bring on board.  I suspect that little 
 of it
 is actually being used.


I can answer that via a build of the Mango servlet example, using Ares 
(named phobos.lib) in conjunction with a misnamed snn.lib. You can see 
what's used by Mango, and then Ares (phobos.lib), in the list below.

C:\D\mango\mango\io\Socket.obj(Socket)
 Error 42: Symbol Undefined _strlen
C:\D\mango\mango\servlet\ServletProvider.obj(ServletProvider)
 Error 42: Symbol Undefined __fltused
C:\D\mango\mango\servlet\ServletProvider.obj(ServletProvider)
 Error 42: Symbol Undefined __except_list
C:\D\mango\mango\format\Number.obj(Number)
 Error 42: Symbol Undefined __ULDIV 
C:\D\mango\mango\sys\Epoch.obj(Epoch)
 Error 42: Symbol Undefined __LDIV 
C:\D\mango\mango\cache\HashMap.obj(HashMap)
 Error 42: Symbol Undefined _memcmp
C:\D\mango\mango\io\FileProxy.obj(FileProxy)
 Error 42: Symbol Undefined _wcslen
servlets.obj(servlets)
 Error 42: Symbol Undefined __acrtused_con
C:\D\mango\mango\io\Buffer.obj(Buffer)
 Error 42: Symbol Undefined _memcpy
C:\D\mango\mango\io\Uri.obj(Uri)
 Error 42: Symbol Undefined _memchr
C:\D\mango\mango\io\Tokenizer.obj(Tokenizer)
 Error 42: Symbol Undefined _ispunct
C:\D\mango\mango\io\Tokenizer.obj(Tokenizer)
 Error 42: Symbol Undefined _isspace
C:\D\mango\mango\format\Styled.obj(Styled)
 Error 42: Symbol Undefined _isdigit
C:\D\mango\mango\format\Double.obj(Double)
 Error 42: Symbol Undefined _frexp
C:\D\mango\mango\format\Double.obj(Double)
 Error 42: Symbol Undefined _memicmp
C:\D\mango\mango\http\server\HttpCookies.obj(HttpCookies)
 Error 42: Symbol Undefined _isalnum
C:\D\mango\mango\http\server\HttpCookies.obj(HttpCookies)
 Error 42: Symbol Undefined _isalpha


C:\d\dmd\bin\..\lib\phobos.lib(gc)
 Error 42: Symbol Undefined _memset
C:\d\dmd\bin\..\lib\phobos.lib(gc)
 Error 42: Symbol Undefined _malloc
C:\d\dmd\bin\..\lib\phobos.lib(deh)
 Error 42: Symbol Undefined __local_except_handler
C:\d\dmd\bin\..\lib\phobos.lib(deh)
 Error 42: Symbol Undefined __global_unwind
C:\d\dmd\bin\..\lib\phobos.lib(regexp)
 Error 42: Symbol Undefined _toupper
C:\d\dmd\bin\..\lib\phobos.lib(regexp)
 Error 42: Symbol Undefined _islower
C:\d\dmd\bin\..\lib\phobos.lib(regexp)
 Error 42: Symbol Undefined ___alloca
C:\d\dmd\bin\..\lib\phobos.lib(regexp)
 Error 42: Symbol Undefined _tolower
C:\d\dmd\bin\..\lib\phobos.lib(thread)
 Error 42: Symbol Undefined __beginthreadex
C:\d\dmd\bin\..\lib\phobos.lib(monitor)
 Error 42: Symbol Undefined _free
C:\d\dmd\bin\..\lib\phobos.lib(monitor)
 Error 42: Symbol Undefined __assert
C:\d\dmd\bin\..\lib\phobos.lib(monitor)
 Error 42: Symbol Undefined _calloc
C:\d\dmd\bin\..\lib\phobos.lib(ti_long)
 Error 42: Symbol Undefined __LCMP 
C:\d\dmd\bin\..\lib\phobos.lib(dmain2)
 Error 42: Symbol Undefined _exit
C:\d\dmd\bin\..\lib\phobos.lib(gcx)
 Error 42: Symbol Undefined _realloc
C:\d\dmd\bin\..\lib\phobos.lib(gcx)
 Error 42: Symbol Undefined _memmove
C:\d\dmd\bin\..\lib\phobos.lib(win32)
 Error 42: Symbol Undefined __end
C:\d\dmd\bin\..\lib\phobos.lib(win32)
 Error 42: Symbol Undefined __xi_a

As you suspected; not very much. I cheated a little by removing the 
remaining refererences to printf() from Ares. Sean made this trivial since 
they're now all in dmain2.d, rather than scattered about (Mango has its own 
formatting package).



I'm just waiting for Eric's DDL to reach steady-state; then we'll have it 
all!


 I can't wait either.  ;)


Me neither! On the fly link-loading will forever change the way D 
server-code is written. Some non-server code too.
Nov 14 2005
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <dlb5a0$1bq9$1 digitaldaemon.com>, pragma says...

In article <dlatoc$erk$1 digitaldaemon.com>, John Reimer says...

Ares is wondefully small and streamlined.  Ares, Mango.io and std.regexp... for
what more could could one ask?


Well, I've always wondered if DMD could be cut free from it's DMC heritage
completely.  When I get to porting DDL over to Ares, I'll get to see how much of
'snn.lib' Ares forces the linker to bring on board.  I suspect that little of it
is actually being used.


Thanks Kris and Sean.  You guys are great.


I have to echo this sentiment: I'm really amazed to see how much things have
changed over just the past two years.  You two have really put your best into
all this.


I'm just waiting for Eric's DDL to reach steady-state; then we'll have it all!


I can't wait either.  ;)


I went to the dsource site and looked things over - very cool!

Don't want to put you on the 'spot' here, but I have a couple of questions:

1) How much longer before ELF and COFF are supported?
2) Is there anything started for emitting 'header' source code for static libs?
3) I'm not familiar with the .ddl format or what it is capable of - is it
(capable of) extracting function body code as well?

Thanks,

- Dave


- EricAnderton at yahoo
Nov 15 2005
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
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
Nov 15 2005
parent reply Dave <Dave_member pathlink.com> writes:
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)?

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
Nov 15 2005
next sibling parent reply pragma <pragma_member pathlink.com> writes:
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
Nov 15 2005
parent Dave <Dave_member pathlink.com> writes:
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
Nov 15 2005
prev sibling next sibling parent reply James Dunne <james.jdunne gmail.com> writes:
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
Nov 15 2005
next sibling parent pragma <pragma_member pathlink.com> writes:
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?"
Nov 15 2005
prev sibling parent Dave <Dave_member pathlink.com> writes:
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
Nov 15 2005
prev sibling parent Don Clugston <dac nospam.com.au> writes:
Dave wrote:

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


Very important, for me at least. The inability of DMD to directly link 
to COFF libraries is a show-stopper for several of my projects, and is 
the only reason why they must remain in C++. The commercial libraries 
which I use* are in COFF format, and it is illegal to redistribute them 
in a different format. In this case, because of the requirement to 
purchase COFF2OMF, D does not operate as free software. I appreciate the 
necessity for revenue protection of DMC -- it's just a shame we don't 
have a COFF2OMF that is free for D but which wouldn't work for DMC. 
Sounds like DDL could solve that problem.

* eg libraries for interfacing to A/D cards. Supplied by the vendor of 
the A/D boards.
Nov 17 2005
prev sibling parent reply pragma <pragma_member pathlink.com> writes:
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
Nov 15 2005
parent reply Dave <Dave_member pathlink.com> writes:
In article <dle3ro$c8h$1 digitaldaemon.com>, pragma says...

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.


The reason I ask is because I'm thinking it would be cool if the 'consumer' of a
library could use DDL to either dynamically load the library or create 'header'
files with which to statically link; their choice. And, if the header generator
was built into or called by the compiler, without the hassle of more than one
set of files to maintain.. The compiler generates the 'headers' when it needs
them and then disposes of them.


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.


Not reproducing the original source code sounds great from a 'code security'
perspective for those concerned about it -- how about in a way that would emit
legal D source code (even if it's in asm{} blocks) to allow functions to be
inlined at compile time?

What I have in mind is basically a 'header file' generated as above where
functions are not only declared but defined in such a way so that a compiler
could examine them, and inline or otherwise optimize based on this information.

Alot to ask for or even mention, no? <g>

Don't get me wrong - DDL is nice as-is and would be huge for D. Just thinking
out loud..


- EricAnderton at yahoo
Nov 15 2005
parent reply pragma <pragma_member pathlink.com> writes:
In article <dlec9i$3vm$1 digitaldaemon.com>, Dave says...

Not reproducing the original source code sounds great from a 'code security'
perspective for those concerned about it -- how about in a way that would emit
legal D source code (even if it's in asm{} blocks) to allow functions to be
inlined at compile time?

What I have in mind is basically a 'header file' generated as above where
functions are not only declared but defined in such a way so that a compiler
could examine them, and inline or otherwise optimize based on this information.


This is certainly possible.  What you're suggesting is a hybrid between what
OBJ2ASM and a D header generator; you get a .d file instead of an .asm file is
all.  Its quite the concept, especially since it invites the compiler to do what
it does best.  However, I'm skeptical as to how DMD treats "naked asm{}"
functions with respect to inlining.

To accomplish this, the various DDL binary types would have to expose a little
more metadata than usual (returning exports as raw byte[] for starters), and the
demangler would be put to use in creating the needed D stub code.  Fixups would
have to be translated into D symbols suitable for recompilation, ModuleInfo
parts get thrown out and re-done imports and "static this()"... it can be done,
but its not trivial.

I'll see what I can do for chalking the door open for this.  Its a neat idea,
and would open DDL up to supporting object-format translators as well.  


Alot to ask for or even mention, no? <g>


Not really.  Its just a new direction... something I didn't give much thought to
before.  


Don't get me wrong - DDL is nice as-is and would be huge for D. Just thinking
out loud..


The envelope is made to be pushed around.  I don't think we've tapped D's
potential yet, so please don't quit "thinking out loud".

- EricAnderton at yahoo
Nov 15 2005
parent Dave <Dave_member pathlink.com> writes:
In article <dleg0q$6l6$1 digitaldaemon.com>, pragma says...

In article <dlec9i$3vm$1 digitaldaemon.com>, Dave says...

Not reproducing the original source code sounds great from a 'code security'
perspective for those concerned about it -- how about in a way that would emit
legal D source code (even if it's in asm{} blocks) to allow functions to be
inlined at compile time?

What I have in mind is basically a 'header file' generated as above where
functions are not only declared but defined in such a way so that a compiler
could examine them, and inline or otherwise optimize based on this information.


This is certainly possible.  What you're suggesting is a hybrid between what
OBJ2ASM and a D header generator; you get a .d file instead of an .asm file is
all.  Its quite the concept, especially since it invites the compiler to do what
it does best.  However, I'm skeptical as to how DMD treats "naked asm{}"
functions with respect to inlining.


I've been playing with that stuff a little so I know that a function with an
asm{} statement is basically flagged as not inlinable right now, so some work
would have to be done here definitely.

Maybe the possibility of getting rid of needing to distribute anything but
library binaries would be enough to change that.


To accomplish this, the various DDL binary types would have to expose a little
more metadata than usual (returning exports as raw byte[] for starters), and the
demangler would be put to use in creating the needed D stub code.  Fixups would
have to be translated into D symbols suitable for recompilation, ModuleInfo
parts get thrown out and re-done imports and "static this()"... it can be done,
but its not trivial.

I'll see what I can do for chalking the door open for this.  Its a neat idea,
and would open DDL up to supporting object-format translators as well.  


Alot to ask for or even mention, no? <g>


Not really.  Its just a new direction... something I didn't give much thought to
before.  


Don't get me wrong - DDL is nice as-is and would be huge for D. Just thinking
out loud..


The envelope is made to be pushed around.  I don't think we've tapped D's
potential yet, so please don't quit "thinking out loud".


In my mind, the ultimate goal would be to have the ability to distribute 3 or 4
files for a standardized base compiler distribution:

- The compiler executable.
- The DDL executable to create either the .ddl file or 'header' input for the
compiler to use 'on the fly'.
- The standard runtime lib.
- Linker

If we could then get the compiler to optimize using the 'header' input for
static builds, we would not have to sacrifice anything.

Maybe even bigger would be that 3rd party lib. developers could distribute one
file, and bigger yet would be that the end-user wouldn't have to worry about
keeping 'headers' and binaries in sync. This would actually make distributing
and using libraries /easier/ than Java or .NET all while keeping the same
performance potential.


- EricAnderton at yahoo
Nov 16 2005
prev sibling parent reply "Charles" <noone nowhere.com> writes:
 Thanks!  And for what it's worth, std.regexp will be added as a
 submission in the next Ares release.


I hope this is PCRE  -- does anyone actually use posix regular expressions
anymore ?

Also just a question, how much is Mango.io dependent on the rest of Mango ?
Have you thought about moving the IO lib into ares?


Charlie


"Sean Kelly" <sean f4.ca> wrote in message
news:dlaq0k$1gs$1 digitaldaemon.com...

 Kris wrote:

 Mango 1.6 runs happily upon Ares, with one exception: Ares doesn't have




an

 std.regexp in the current release, so the mango servlet engine will fail




to

 compile & link (unittest also). I have a modified ares.lib to resolve




that

 problem, which I can pass along to anyone who wants it. That aside,




Mango

 and Ares operate beautifully together on Win32 ~ Sean has done a great




job

 partitioning Ares into a modular and extensible platform.


 Thanks!  And for what it's worth, std.regexp will be added as a
 submission in the next Ares release.  It may undergo interface changes
 (or implementation tuning) before becoming official, but it will be
 available for Mango before too terribly long.


 Haven't attempted Ares on linux or darwin yet. Has anyone tried that?


 If anyone has interest in testing Ares on non-Win32, please let me know.
   The Posix implementation is fairly sparse in places, as I don't have
 an environment set up to work on this.


 Sean
Nov 15 2005
next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <dlcvbb$2drq$1 digitaldaemon.com>, Charles says...

 Thanks!  And for what it's worth, std.regexp will be added as a
 submission in the next Ares release.


I hope this is PCRE  -- does anyone actually use posix regular expressions
anymore ?


std.regexp was added just to have something available--before the module becomes
standard it may be rewritten entirely.  What I'd like to do is simply support
the "standard" regular expression syntax as described in compiler design texts
and such.  I think this is what std.regexp supports, but I haven't given it a
close enough look to be sure.


Also just a question, how much is Mango.io dependent on the rest of Mango ?
Have you thought about moving the IO lib into ares?


I've considered it, assuming Kris is amenable to the idea.


Sean
Nov 15 2005
parent reply "Kris" <fu bar.com> writes:
"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 
:-)
Nov 15 2005
parent reply Sean Kelly <sean f4.ca> writes:
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
Nov 15 2005
parent "Kris" <fu bar.com> writes:
"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.
Nov 15 2005
prev sibling parent "Kris" <fu bar.com> writes:
"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.
Nov 15 2005