On Thursday, 1 June 2017 at 12:04:40 UTC, Jacob Carlborg wrote:
So DStep works, just that will generate platform specific
bindings.
That is good enough if it is integrated with the compiler then.
On 2017-06-01 10:25, Ola Fosheim Grøstad wrote:
Even though a stand-alone tool is just as good in theory I think most
developers want as hassle free builds as possible. If one can just point
to the OS include directory and import directly that would be very neat.
Currently DStep will just
On Thursday, 1 June 2017 at 06:43:44 UTC, Jacob Carlborg wrote:
On 2017-05-31 17:50, Ola Fosheim Grøstad wrote:
But you don't have to do that if it is built into the compiler?
Ah, you mean like that. No, that should be necessary if the
bindings are always generated on the fly. My answer was
On 2017-05-31 17:50, Ola Fosheim Grøstad wrote:
But you don't have to do that if it is built into the compiler?
Ah, you mean like that. No, that should be necessary if the bindings are
always generated on the fly. My answer was assuming how DStep currently
is working.
--
/Jacob Carlborg
On Wednesday, 31 May 2017 at 06:52:00 UTC, Jacob Carlborg wrote:
But trying to compile the code in the "body" for Windows, on
any other platform will fail because windows.h is not available.
But you don't have to do that if it is built into the compiler?
On Wednesday, 31 May 2017 at 06:52:00 UTC, Jacob Carlborg wrote:
Yes, but it's very difficult to do.
Say there's some code looking like this:
[snip]
Some simpler #ifdefs might be easier to handle and add a lot of
value. Then you can make a list of stuff that is not supported,
like #ifdefs
On 2017-05-30 17:50, Swoorup Joshi wrote:
How difficult is it to turn C++ headers usable for D?
Currently DStep doesn't support C++ headers at all. If think it's quite
some work to support that. Of course it's possible to start simple, i.e.
C++ free functions and continue from there.
--
On 2017-05-30 21:42, Ola Fosheim Grøstad wrote:
On Tuesday, 30 May 2017 at 19:12:28 UTC, Jacob Carlborg wrote:
Currently DStep cannot handle #if or #ifdef.
Oh, that is often required…
Yes, but it's very difficult to do.
Say there's some code looking like this:
#ifdef Windows
#include
On Monday, May 29, 2017 13:58:54 Brad Roberts via Digitalmars-d wrote:
> On 5/29/2017 1:36 PM, Moritz Maxeiner via Digitalmars-d wrote:
> > On Monday, 29 May 2017 at 17:09:21 UTC, aberba wrote:
> >> IMO, the most important thing is getting the job done.
> >
> > * getting the job done right.
> >
On Tuesday, 30 May 2017 at 15:50:01 UTC, Swoorup Joshi wrote:
On Tuesday, 30 May 2017 at 15:06:19 UTC, Jacob Carlborg wrote:
On 2017-05-30 14:27, Ola Fosheim Grøstad wrote:
Maybe even turning some macros into functions?
DStep can do that today.
How difficult is it to turn C++ headers
On Tuesday, 30 May 2017 at 19:12:28 UTC, Jacob Carlborg wrote:
Currently DStep cannot handle #if or #ifdef.
Oh, that is often required…
What were the objections to integration with DMD?
I don't recall exactly, I recommend reading the post I linked
to [1].
My impression is that there is
On 2017-05-30 17:15, Ola Fosheim Grostad wrote:
That's cool! How robust is in practice on typical header files (i.e
zlib and similar)?
I would say ok. I did try to run DStep on zlib.h just now. It got quite
confused when translating the comments. But disabling that it looked a
lot better.
On Tuesday, 30 May 2017 at 15:06:19 UTC, Jacob Carlborg wrote:
On 2017-05-30 14:27, Ola Fosheim Grøstad wrote:
Maybe even turning some macros into functions?
DStep can do that today.
How difficult is it to turn C++ headers usable for D? Interfacing
with D for giant libraries like Physx is
On Tuesday, 30 May 2017 at 15:06:19 UTC, Jacob Carlborg wrote:
On 2017-05-30 14:27, Ola Fosheim Grøstad wrote:
Maybe even turning some macros into functions?
DStep can do that today.
That's cool! How robust is in practice on typical header files
(i.e zlib and similar)?
What were the
On 2017-05-30 14:27, Ola Fosheim Grøstad wrote:
Maybe even turning some macros into functions?
DStep can do that today.
--
/Jacob Carlborg
On 2017-05-30 14:26, Ola Fosheim Grøstad wrote:
What happend to that Calypso project? I suppose libclang also would
allow you to inspect C header-files and then maybe it would be possible
to synthesize Dish bindings from it on the fly? Not that I have given it
much thought.
I did that by
On Tuesday, 30 May 2017 at 11:22:29 UTC, bachmeier wrote:
One of the things I hated when I started using D was links to
dsource libraries. I think that writing new libraries in D is
often a mistake for that very reason. Bindings to C libraries
is what we need. Put everything into one D file if
On Tuesday, 30 May 2017 at 12:26:22 UTC, Ola Fosheim Grøstad
wrote:
What happend to that Calypso project? I suppose libclang also
would allow you to inspect C header-files and then maybe it
would be possible to synthesize Dish bindings from it on the
fly? Not that I have given it much
On Tuesday, 30 May 2017 at 11:22:29 UTC, bachmeier wrote:
One of the things I hated when I started using D was links to
dsource libraries. I think that writing new libraries in D is
often a mistake for that very reason. Bindings to C libraries
is what we need. Put everything into one D file if
And in good news, despite Dub's inability to understand the way things
are on Debian, and using some egregious hacks, I have a DStep build on
Debian Sid that appears to work. No such luck on Fedora but that is a
"known issue" for DStep (*).
It seems libdvbv5 D wrapper generation may be working.
On Tuesday, 30 May 2017 at 05:50:13 UTC, Ola Fosheim Grostad
wrote:
Focusing on getting many libraries won't work, because you need
to maintain them. I never use unmaintained libraries... Having
many unmaintained libraries is in a way worse than having a few
long-running ones that improve at
On Tuesday, 30 May 2017 at 07:56:43 UTC, Wulfklaue wrote:
Its been my firm believe that lose packages are a detriment to
a language.
It isn't good if many of the interesting packages are
unmaintained, as it gives an sense of being in the past.
Half baked solutions are no solutions. Packages
On Tuesday, 30 May 2017 at 07:15:08 UTC, Russel Winder wrote:
Others have mentioned widening D's appeal by widening the
number of C APIs there are wrappers for. This is a good idea, I
agree – in my case libdvbv5 and librtlsdr are the beasties of
interest. I argue Deimos is the wrong direction
On Tue, 2017-05-30 at 08:39 +0200, Jacob Carlborg via Digitalmars-d
wrote:
> On 2017-05-29 18:08, Russel Winder via Digitalmars-d wrote:
>
> > My biggest problem of the moment is libdvbv5 and librtlsdr. DStep
> > seemingly cannot help as yet.
>
> I know you have reported a few bugs for DStep.
On 2017-05-29 18:08, Russel Winder via Digitalmars-d wrote:
My biggest problem of the moment is libdvbv5 and librtlsdr. DStep
seemingly cannot help as yet.
I know you have reported a few bugs for DStep. Are those all or anything
else that has not been reported yet?
--
/Jacob Carlborg
On Tuesday, 30 May 2017 at 01:46:02 UTC, bachmeier wrote:
I'm not necessarily disagreeing with RW's post. My reading is
that the goal would be to get D into the enterprise, but maybe
I misinterpreted. If D as a successor to Vala leads to more
projects like Tilix, that's great.
I never quite
On Monday, 29 May 2017 at 22:20:34 UTC, Ola Fosheim Grøstad wrote:
I don't think Russel Winder was talking about enterprise code,
but for a language to take hold you need at least one
significant publicly visible application written in it.
E.g. Go has Docker, Rust has a Firefox engine, and
On Monday, 29 May 2017 at 21:43:30 UTC, bachmeier wrote:
Incremental is key. It's what enabled me to use D for my work.
Apologies to anyone that feels only enterprise code bases with
at least 10 million lines of code are worth talking about, but
good luck convincing anyone to rewrite a code
On Monday, 29 May 2017 at 20:58:54 UTC, Brad Roberts wrote:
Each time someone wraps a new library, each time someone fixes
some bug because it affects them, etc.. these all push things
forward inch by inch.
Eventually that mass might actually reach critical. But even
if it doesn't, things
On Monday, 29 May 2017 at 16:08:11 UTC, Russel Winder wrote:
I like the comment from DConf that D should be the successor to
Vala for writing GObject-based code. We have GtkD and in it
GStreamer. Writing programs in C with them is a real pain in
the a### and using C++ is only a little bit
On 5/29/2017 1:36 PM, Moritz Maxeiner via Digitalmars-d wrote:
On Monday, 29 May 2017 at 17:09:21 UTC, aberba wrote:
IMO, the most important thing is getting the job done.
* getting the job done right.
Otherwise, you are just going to accumulate patchy code for which you
will pay down the
On Monday, 29 May 2017 at 17:09:21 UTC, aberba wrote:
IMO, the most important thing is getting the job done.
* getting the job done right.
Otherwise, you are just going to accumulate patchy code for which
you will pay down the line continuously.
On Monday, 29 May 2017 at 16:08:11 UTC, Russel Winder wrote:
A few thoughts not entirely random but without a well thought
out storyline, prompted by a couple of recent threads here.
I like the comment from DConf that D should be the successor to
Vala for writing GObject-based code. We have
On Monday, 29 May 2017 at 16:08:11 UTC, Russel Winder wrote:
A few thoughts not entirely random but without a well thought
out storyline, prompted by a couple of recent threads here.
I like the comment from DConf that D should be the successor to
Vala for writing GObject-based code. We have
A few thoughts not entirely random but without a well thought out
storyline, prompted by a couple of recent threads here.
I like the comment from DConf that D should be the successor to Vala
for writing GObject-based code. We have GtkD and in it GStreamer.
Writing programs in C with them is a
35 matches
Mail list logo
