On 2011-08-13 04:13, Trass3r wrote:
I'm working on a tool to convert C header files to D modules based on
clang. But currently it's not a prioritized project.
I also played with the idea. Clang's Rewrite facilities should be
perfect for that.
Yeah, I'm using Rewrite, if I recall correctly.
On 2011-08-13 02:59, maarten van damme wrote:
Are you really working on a better htod?
Yes, I guess so.
will it try to convert ifdefs in version()?
I don't know yet. I'm avoiding the preprocessor for as long as I can.
2011/8/12 Jacob Carlborg d...@me.com mailto:d...@me.com
On 2011
On 2011-08-13 04:13, Trass3r wrote:
I'm working on a tool to convert C header files to D modules based on
clang. But currently it's not a prioritized project.
I also played with the idea. Clang's Rewrite facilities should be
perfect for that.
Yeah, I'm using Rewrite, if I recall correctly.
I'm attempting to convert a c header to d using htod. If this is not
current best practice please point me in another direction.
C:\dirhtod -I c:\d\dm\include ocilib.h
Fatal error: unable to open input file 'stdlib.h'
C:\dirdir c:\d\dm\include\stdlib.h
Directory of c:\d\dm\include
07/28
On Friday, August 12, 2011 04:07:47 Jason King wrote:
I'm attempting to convert a c header to d using htod. If this is not
current best practice please point me in another direction.
C:\dirhtod -I c:\d\dm\include ocilib.h
Fatal error: unable to open input file 'stdlib.h'
C:\dirdir c:\d
On 12.08.2011 11:24, Jonathan M Davis wrote:
On Friday, August 12, 2011 04:07:47 Jason King wrote:
I'm attempting to convert a c header to d using htod. If this is not
current best practice please point me in another direction.
C:\dirhtod -I c:\d\dm\include ocilib.h
Fatal error: unable
My expectation is not that I can htod that 17k line header and magically
have a d module. A lot of the header is #define'd constants and
typedefs and I _do_ expect htod to remove some of the scutwork involved
there.
At this point I'd just be happy if it ran w/o error.
There's nothing
On 2011-08-12 11:36, simendsjo wrote:
htod is a fork of dmc or something, right? How difficult is it to update
the program to make it more user friendly?
Is the source public? Would it be better to use gcc or clang instead?
htod is a great thought, but I haven't either gotten it to work
Am 12.08.2011, 13:35 Uhr, schrieb Jacob Carlborg d...@me.com:
On 2011-08-12 11:36, simendsjo wrote:
htod is a fork of dmc or something, right? How difficult is it to update
the program to make it more user friendly?
Is the source public? Would it be better to use gcc or clang instead?
htod
htod is a fork of dmc or something, right?
Yep.
How difficult is it to update the program to make it more user friendly?
Only Walter can.
Is the source public?
No.
Would it be better to use gcc or clang instead?
Hell yeah. Clang's predestined for that.
On 8/12/11, Jason King jhk...@airmail.net wrote:
I'm attempting to convert a c header to d using htod. If this is not
current best practice please point me in another direction.
C:\dirhtod -I c:\d\dm\include ocilib.h
Fatal error: unable to open input file 'stdlib.h'
You have an extra space
On 2011-08-12 13:48, Trass3r wrote:
Am 12.08.2011, 13:35 Uhr, schrieb Jacob Carlborg d...@me.com:
On 2011-08-12 11:36, simendsjo wrote:
htod is a fork of dmc or something, right? How difficult is it to update
the program to make it more user friendly?
Is the source public? Would it be better
I'm working on a tool to convert C header files to D modules based on
clang. But currently it's not a prioritized project.
I also played with the idea. Clang's Rewrite facilities should be
perfect for that.
Yeah, I'm using Rewrite, if I recall correctly.
Should really be a community effort
http://d.puremagic.com/issues/show_bug.cgi?id=6349
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
Severity|critical|major
--
http://d.puremagic.com/issues/show_bug.cgi?id=6349
Summary: HTOD needs -od or -of switch
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: critical
Priority: P2
Component
http://d.puremagic.com/issues/show_bug.cgi?id=6292
Summary: HTOD hides constants behind a comment
Product: D
Version: D2
Platform: Other
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component
http://d.puremagic.com/issues/show_bug.cgi?id=6248
Summary: HTOD leaves out const when translating C headers
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: major
Priority: P2
http://d.puremagic.com/issues/show_bug.cgi?id=6249
Summary: HTOD deletes files without notice
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: major
Priority: P2
Component
--- Comment #1 from yebblies yebbl...@gmail.com 2011-07-05 12:45:43 EST ---
This is because there is only one version of htod, for D1 and D2, and D1 does
not have const. I think the fix would be for htod to emit 'in' instead of
const in C function prototypes.
--
Configure issuemail: http
http://d.puremagic.com/issues/show_bug.cgi?id=6239
Mike Parker aldac...@gmail.com changed:
What|Removed |Added
CC||aldac...@gmail.com
http://d.puremagic.com/issues/show_bug.cgi?id=6239
Jacob Carlborg d...@me.com changed:
What|Removed |Added
CC||d...@me.com
--- Comment
http://d.puremagic.com/issues/show_bug.cgi?id=6237
Summary: htod generates invalid module name and declaration
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Resolution||WORKSFORME
--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-07-01
21:43:48 PDT ---
Ah but I can already do this:
htod cairo-win32.h cairo_win32.d
I guess I should close it then.
--
Configure issuemail: http://d.puremagic.com
http://d.puremagic.com/issues/show_bug.cgi?id=6239
Summary: HTOD: Add support for converting opaque C types to D
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
http://d.puremagic.com/issues/show_bug.cgi?id=6239
--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-07-01
22:27:52 PDT ---
For what it's worth this helps for us porting monkeys:
regex: alias \w+
replace with: typedef void
But you have to do this manually..
--
Configure
http://d.puremagic.com/issues/show_bug.cgi?id=6239
--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-07-01
22:33:59 PDT ---
Well crap that's not good, it needs to be:
typedef void cairo_device_t;
typedef void _cairo_device;
Stupid C APIs!
--
Configure issuemail:
While having a look at etc.curl which has a »converted by htod« comment
in its header, I noticed that values having type »long« in the original
C headers are declared as »int« there – shouldn't this rather be c_long
from core.stdc.config to avoid problems on non-LLP64 (i.e. non-Windows)
64 bit
htod doesn't know anything about c_long afaik. And since it runs on
Windows only, I guess it was hardcoded to think that long would always
be an int.
Den 12-06-2011 20:05, David Nadlinger skrev:
While having a look at etc.curl which has a »converted by htod« comment
in its header, I noticed that values having type »long« in the original
C headers are declared as »int« there – shouldn't this rather be c_long
from core.stdc.config to avoid
On 05.03.2011 20:04, Bekenn wrote:
On 3/4/2011 3:31 PM, simendsjo wrote:
The htod page, http://www.digitalmars.com/d/2.0/htod.html, says that
system files will be included using the -hs option.
htod mysql.h -hs
Fatal error: unable to open input file 'sys/types.h'
Does it try to find
On 21/12/2010 22:08, Jonathan M Davis wrote:
snip
Just so you know, htod works on wine.
But how many people are willing to install Wine just to run this program?
I'd still like to know what on earth the barrier is to building htod to
run on platforms other than Windows.
Stewart.
I have a C header with a whole bunch of simple macros like:
#define PM_FILT_FD (1 0x0D)
Unfortunately htod won't translate these (I've tried every flag documented).
However, I vaguely remember Walter mentioning some kind of technique where one
could use DMC to translate these(?). Or maybe I'm
On 2010-12-27 17:07, Andrej Mitrovic wrote:
I have a C header with a whole bunch of simple macros like:
#define PM_FILT_FD (1 0x0D)
Unfortunately htod won't translate these (I've tried every flag documented).
However, I vaguely remember Walter mentioning some kind of technique where one
On 23/12/2010 05:34, Mariusz Gliwiński wrote:
wig looks interesting. Again, it strips const so probably D1 (i just skipped
D1, it wasn't interesting enough for me to switch from widely used languages
so don't know it's feature-set) and it's using tango, but looks promising.
SWIG 4 D uses
I think you just need to pass a flag to SWIG when building it to get
D2 support. I've done it a few days ago..
On 12/23/10, BLS windev...@hotmail.de wrote:
On 23/12/2010 05:34, Mariusz Gliwiński wrote:
wig looks interesting. Again, it strips const so probably D1 (i just
skipped
D1, it wasn't
On Thu, Dec 23, 2010 at 10:29 AM, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
I think you just need to pass a flag to SWIG when building it to get
D2 support. I've done it a few days ago..
On 12/23/10, BLS windev...@hotmail.de wrote:
On 23/12/2010 05:34, Mariusz Gliwiński wrote:
Mariusz GliwiÅski Wrote:
Hello,
Why don't You make htod opensource? I don't think it has commercial
potential,
or I'm wrong? I'm asking, because it's a shame that people who wants publish
D
bindings have to make their own scripts for that (so bindings can be
generated
on !windows
== Quote from Sean Kelly (s...@invisibleduck.org)'s article
Mariusz Gliwiński Wrote:
Hello,
Why don't You make htod opensource? I don't think it has commercial
potential,
or I'm wrong? I'm asking, because it's a shame that people who wants publish
D
bindings have to make their own scripts
On 22/12/2010 16:19, Sean Kelly wrote:
I hate to say it, but I've found that creating the D headers by hand is faster
than running htod and hand-editing to fix screw-ups. Particularly if there are
any #if statements to contend with.
Did you consider to use SWIG instead of htod ?
BLS Wrote:
On 22/12/2010 16:19, Sean Kelly wrote:
I hate to say it, but I've found that creating the D headers by hand is
faster than running htod and hand-editing to fix screw-ups. Particularly
if there are any #if statements to contend with.
Did you consider to use SWIG instead
On 2010-12-21 22:58, Mariusz Gliwiński wrote:
Hello,
Why don't You make htod opensource? I don't think it has commercial potential,
or I'm wrong? I'm asking, because it's a shame that people who wants publish D
bindings have to make their own scripts for that (so bindings can be generated
Well, Clang can build binaries on Windows. AFAIK the only problem is
exceptions on Windows.
On 12/22/10, Jacob Carlborg d...@me.com wrote:
On 2010-12-21 22:58, Mariusz Gliwiński wrote:
Hello,
Why don't You make htod opensource? I don't think it has commercial
potential,
or I'm wrong? I'm
On 22/12/2010 19:11, Sean Kelly wrote:
BLS Wrote:
On 22/12/2010 16:19, Sean Kelly wrote:
I hate to say it, but I've found that creating the D headers by hand is faster
than running htod and hand-editing to fix screw-ups. Particularly if there are
any #if statements to contend with.
Did
Wednesday 22 December 2010 @ 23:02:44 BLS:
tried SWIG for C++ to D. But frankly said I am not able to offer
substantial feedback 'cause every binding I have created was more or
less in a toy area..
Thanks for answers everyone,
swig looks interesting. Again, it strips const so probably D1 (i
On Tuesday, December 21, 2010 13:58:02 Mariusz Gliwiński wrote:
Hello,
Why don't You make htod opensource? I don't think it has commercial
potential, or I'm wrong? I'm asking, because it's a shame that people who
wants publish D bindings have to make their own scripts for that (so
bindings
Dnia wtorek 21 grudzień 2010 o 23:08:34 Jonathan M Davis napisał(a):
On Tuesday, December 21, 2010 13:58:02 Mariusz Gliwiński wrote:
Hello,
Why don't You make htod opensource? I don't think it has commercial
potential, or I'm wrong? I'm asking, because it's a shame that people who
wants
Is htod a part of the C++ DM toolkit? I don't think it is, I mean it's
only useful for the D language. Sooner or later Walter is either going
to open-source it or we'll be forced to reinvent the tool. It's
probably wouldn't be much work for a C-only header translator.
On 12/21/10, Mariusz
It's probably wouldn't.
I need a new brand of coffee. -_-
On 12/21/10, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
Is htod a part of the C++ DM toolkit? I don't think it is, I mean it's
only useful for the D language. Sooner or later Walter is either going
to open-source it or we'll
On 2010-12-21 16:58:02 -0500, Mariusz Gliwiński alienballa...@gmail.com said:
Hello,
Why don't You make htod opensource?
If I remember well, Walter said it includes parts of his C++ compiler
(DMC), which he sells, is closed source, and has a long history. It's
possible he does not have
Michel Fortin wrote:
If I remember well, Walter said it includes parts of his C++ compiler
(DMC), which he sells, is closed source, and has a long history. It's
possible he does not have the right to license it as open source, or
perhaps he just doesn't want to disclose the source for DMC.
Mariusz Gliwiński wrote:
Why don't You make htod opensource?
htod is built out of the C and C++ compiler front end, the source of which
Digital Mars sells.
22.12.2010 @ 03:17:31 Walter:
htod is built out of the C and C++ compiler front end, the source of which
Digital Mars sells.
Thanks, I understand that. Why htod strips out const?
1)
in: const int var = 2;
out: null
2)
in: DLL const char *func( int arg );
out: char * func(int arg);
3)
in: DLL
Mariusz Gliwiński wrote:
Thanks, I understand that. Why htod strips out const?
1)
in: const int var = 2;
out: null
2)
in: DLL const char *func( int arg );
out: char * func(int arg);
3)
in: DLL void func( int arg, const char *arg2 );
out: void func(int arg, const char *arg2);
4
On Sun, 17 Oct 2010 20:39:02 -0500
Andrei == Andrei Alexandrescu wrote:
Andrei Whaddya think?
Andrei
Andrei It's useful, as would be the addition on 2010/10/17 at
Andrei 20:38:50 CST and the htod version used.
What about http://github.com/klickverbot/swig/commits/swigd (Swig4D)
to create D
Alexandrescu wrote:
Andrei Whaddya think?
Andrei
Andrei It's useful, as would be the addition on 2010/10/17 at
Andrei 20:38:50 CST and the htod version used.
What about http://github.com/klickverbot/swig/commits/swigd (Swig4D)
to create D-bindings for C-libs?
Sincerely,
Gour
--
Gour
On 10/18/10 5:39 PM, Andrej Mitrovic wrote:
[…] I didn't know there was an active on github. […]
That's probably because I haven't officially announced it yet – I am
currently trying to get it into SWIG trunk. After this is done (which
could take quite some time, since I have not received a
On Mon, 18 Oct 2010 17:39:46 +0200
Andrej == Andrej Mitrovic wrote:
Andrej This is cool! I was going to look for some SWIG-like tools
Andrej these days. I saw the swig4d project on dsource, but it's page
Andrej says it's abandoned. I didn't know there was an active on
Andrej github. Thanks.
And
I don't know where else to put this topic. Currently htod translates a C/CPP
header file to D and adds a line at the top such as:
/* Converted to D from someheaderfile.h by htod */
The Bindings project relies heavily on htod, but the problem is: when a new
version of a library comes out you're
On 10/17/2010 07:52 PM, Andrej Mitrovic wrote:
I don't know where else to put this topic. Currently htod translates a C/CPP
header file to D and adds a line at the top such as:
/* Converted to D from someheaderfile.h by htod */
The Bindings project relies heavily on htod, but the problem
htod could also use a --help switch so we don't have to fire up the
browser every time we need to remind ourselves on what arguments it
can take. Or, you know, Walter could give us the source code and we'll
fix it for him. Hehe. :
Here's one failed conversion from 5 minutes ago:
C:
typedef
On Mon, 18 Oct 2010 07:51:34 +0400, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
htod could also use a --help switch so we don't have to fire up the
browser every time we need to remind ourselves on what arguments it
can take. Or, you know, Walter could give us the source code and we'll
, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
htod could also use a --help switch so we don't have to fire up the
browser every time we need to remind ourselves on what arguments it
can take. Or, you know, Walter could give us the source code and we'll
fix it for him. Hehe. :
Here's one
On 17/08/2010 20:47, Paul Dufresne wrote:
I downloaded htod.zip and found there is only htod.exe inside.
Any version for Linux?
Just as to the point, why is htod closed source?
Stewart.
. But like htod, only c-code is supported.
http://dotmars.googlecode.com/svn/trunk/tools/htd/
greets
Matthias
of the language or is the gcc extensions used in too
many headers for htod to be useful ?
--
/Jacob Carlborg
Walter Bright wrote:
Paul Dufresne wrote:
I downloaded htod.zip and found there is only htod.exe inside.
Any version for Linux?
No. The problem is it is built out of the DM C compiler, which does not
parse gcc extensions found in Linux.
But if the headers the user wants to convert are
On 08/18/2010 05:44 PM, Stewart Gordon wrote:
Walter Bright wrote:
Paul Dufresne wrote:
I downloaded htod.zip and found there is only htod.exe inside.
Any version for Linux?
No. The problem is it is built out of the DM C compiler, which does
not parse gcc extensions found in Linux.
But if
the rest of the language or is the gcc extensions used in too
many headers for htod to be useful ?
I don't know how hard the problem is. I haven't spent any time attempting to
make it work on linux.
extensions to the language. Besides, there's a version
of GCC (MinGW) for Windows as well.
How about the rest of the language or is the gcc extensions used in
too many headers for htod to be useful ?
I don't know how hard the problem is. I haven't spent any time
attempting to make it work
compatibility is a separate issue from compatibility with
vendor-specific extensions to the language. Besides, there's a version
of GCC (MinGW) for Windows as well.
How about the rest of the language or is the gcc extensions used in
too many headers for htod to be useful ?
I don't know how hard
dsimcha wrote:
snip
Well, if we don't care about GNU extensions, then I'll ask again, what's wrong
with Wine? I'm not saying it wouldn't be nice to have a Linux port of htod, but
if Wine provides an easy workaround, I think it should be a very low priority.
Some users may object to installing
I downloaded htod.zip and found there is only htod.exe inside.
Any version for Linux?
Paul Dufresne wrote:
I downloaded htod.zip and found there is only htod.exe inside.
Any version for Linux?
No. The problem is it is built out of the DM C compiler, which does not parse
gcc extensions found in Linux.
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Paul Dufresne wrote:
I downloaded htod.zip and found there is only htod.exe inside.
Any version for Linux?
No. The problem is it is built out of the DM C compiler, which does not parse
gcc extensions found in Linux.
Shouldn't a command line utility like this that doesn't have a lot
of external
dependencies be trivial to run on Wine?
Well, yes, it is just that I have a very slow connection and wine is
not already installed.
dsimcha wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Paul Dufresne wrote:
I downloaded htod.zip and found there is only htod.exe inside.
Any version for Linux?
No. The problem is it is built out of the DM C compiler, which does not parse
gcc extensions found in
Michel Fortin wrote:
What I meant is that this is dependent on link order (and I tested it):
module a;
import a_base;
import b;
int ai;
extern(C) void initA() { ai = bi+2; }
module a_base;
extern(C) void initA();
static this() { initA(); }
module b;
import b_base;
import a;
int bi;
extern(C)
Walter Bright Wrote:
Eldar Insafutdinov wrote:
The issue is that we need it in a performance critical part of QtD.
The library mixes in static constructors to initialise user-defined
classes. This means that we can't use it when user code is in cyclic
dependency. static constructors are
On 3/10/10 22:59, Justin Johansson wrote:
Jacob Carlborg Wrote:
On 3/10/10 16:33, Steve Teale wrote:
The #1 show-stopper for me was lack of shared object (.so) support under
Linux; virtually mandated by my audience (Apache/LAMP). (A workaround
like FastCGI is simply not appealing to
On 3/10/10 23:50, Walter Bright wrote:
Jacob Carlborg wrote:
How dangerous would it be with a compiler option that allowed the
above and the programmer have to make sure that they don't depend on
each other?
The idea is to eliminate implementation-defined behavior as much as
practical. I
On 3/11/10 11:22, Eldar Insafutdinov wrote:
Walter Bright Wrote:
Eldar Insafutdinov wrote:
The issue is that we need it in a performance critical part of QtD.
The library mixes in static constructors to initialise user-defined
classes. This means that we can't use it when user code is in
Jacob Carlborg Wrote:
On 3/10/10 22:59, Justin Johansson wrote:
Jacob Carlborg Wrote:
On 3/10/10 16:33, Steve Teale wrote:
The #1 show-stopper for me was lack of shared object (.so) support under
Linux; virtually mandated by my audience (Apache/LAMP). (A workaround
like FastCGI is
On 2010-03-11 05:22:38 -0500, Eldar Insafutdinov
e.insafutdi...@gmail.com said:
Walter Bright Wrote:
Eldar Insafutdinov wrote:
The issue is that we need it in a performance critical part of QtD.
The library mixes in static constructors to initialise user-defined
classes. This means that we
Michel Fortin wrote:
I'd like to point out that the trick of creating a separate module to
initialize another one is not much safer than C++ static initialization.
Take for instance std.stdio which it is initialized by std.stdiobase's
static constructor. If your module import std.stdio and
Max Samukha wrote:
Michel Fortin wrote:
I'd like to point out that the trick of creating a separate module to
initialize another one is not much safer than C++ static initialization.
Take for instance std.stdio which it is initialized by std.stdiobase's
static constructor. If your module
I also had done a fair amount of work, and foundered on the inability to
dynamically load anything without it being a big deal.
Like you say, it has been brought up many many times. Everyone says yes,
this is a real show-stopper, then the thread dies down and so on.
Steve
What
On 3/11/10 14:12, Justin Johansson wrote:
Jacob Carlborg Wrote:
On 3/10/10 22:59, Justin Johansson wrote:
Jacob Carlborg Wrote:
On 3/10/10 16:33, Steve Teale wrote:
The #1 show-stopper for me was lack of shared object (.so) support under
Linux; virtually mandated by my audience
I think what we can do to help is to track down exactly what the
problems are and make sure Walter knows about them. If possible we could
also try to fix them.
The problems I have are:
Undefined symbols:
__deh_beg
__deh_end
__Dmain
__minfo_beg
__minfo_end
Undefined symbols is not the
On 3/11/10 22:34, Jacob Carlborg wrote:
On 3/11/10 14:12, Justin Johansson wrote:
Jacob Carlborg Wrote:
On 3/10/10 22:59, Justin Johansson wrote:
Jacob Carlborg Wrote:
On 3/10/10 16:33, Steve Teale wrote:
The #1 show-stopper for me was lack of shared object (.so)
support under
Linux;
On 3/11/10 22:52, Igor Lesik wrote:
I think what we can do to help is to track down exactly what the
problems are and make sure Walter knows about them. If possible we could
also try to fix them.
The problems I have are:
Undefined symbols:
__deh_beg
__deh_end
__Dmain
__minfo_beg
__minfo_end
On 2010-03-11 13:26:17 -0500, Walter Bright newshou...@digitalmars.com said:
Max Samukha wrote:
Michel Fortin wrote:
I'd like to point out that the trick of creating a separate module to
initialize another one is not much safer than C++ static initialization.
Take for instance std.stdio
Michel Fortin wrote:
Ah, you're right indeed. I thought it was std.stdiobase that imported
std.stdio, but its the reverse so it's a little better.
Still, std.stdiobase uses this clever external definition to avoid a
circular import:
extern(C) void std_stdio_static_this();
This hack is
On 10.03.2010 0:57, Walter Bright wrote:
The circular module thing is usually a result of static constructors in
each of two modules that import each other. There are many solutions to
this, such as switching to lazy initialization, moving the
initializations to a 3rd module, having the
Max Samukha wrote:
2. A third module cannot be used. At least, we haven't been able to
figure out how to do that. Probably, something could be hacked up if
this bug (feature) is fixed
http://d.puremagic.com/issues/show_bug.cgi?id=2671
Thanks, I'll have a look at it.
Walter Bright wrote:
Max Samukha wrote:
2. A third module cannot be used. At least, we haven't been able to
figure out how to do that. Probably, something could be hacked up if
this bug (feature) is fixed
http://d.puremagic.com/issues/show_bug.cgi?id=2671
Thanks, I'll have a look at it.
Justin Johansson wrote:
Walter Bright Wrote:
Justin Johansson wrote:
Having spent six months developing a significant app in D only to find
impediments to
practical completion of the project and ultimate deployment,
Which ones did you find to be blocking?
(My time zone is way different to
On 3/10/10 13:55, Ary Borenszweig wrote:
Justin Johansson wrote:
Walter Bright Wrote:
Justin Johansson wrote:
Having spent six months developing a significant app in D only to
find impediments to
practical completion of the project and ultimate deployment,
Which ones did you find to be
On 3/9/10 22:35, Justin Johansson wrote:
Walter Bright Wrote:
Justin Johansson wrote:
Having spent six months developing a significant app in D only to find
impediments to
practical completion of the project and ultimate deployment,
Which ones did you find to be blocking?
(My time zone
On 3/9/10 23:57, Walter Bright wrote:
Justin Johansson wrote:
The #1 show-stopper for me was lack of shared object (.so) support
under Linux; virtually
mandated by my audience (Apache/LAMP). (A workaround like FastCGI is
simply not
appealing to customers.) This topic discussed many times before
On 3/10/10 01:15, Walter Bright wrote:
Ellery Newcomer wrote:
I hate the restriction on modules with static constructors and cyclic
dependencies. IMO it's the most patronizing 'feature' D has.
I understand, but the alternative is the essentially random order of
execution that C++ has.
How
101 - 200 of 244 matches
Mail list logo
