On Monday, 24 July 2023 at 13:30:27 UTC, cc wrote:
Is there any list of known significant "gotchas" with moving to
LDC from DMD? Any unexpected surprises to watch out for or be
careful for? I'm thinking of all the "features" of DMD that
are now considered verboten by many users (e.g.
On Monday, 24 July 2023 at 09:20:05 UTC, BoQsc wrote:
There are three compilers present in the Dlang website: DMD GDC
and LDC
DMD can build much faster than LDC. In some cases it is quite
extreme, for example the product I work on has a 3.6x faster
debug build time with DMD (well, only with
On Monday, 24 July 2023 at 13:51:06 UTC, Steven Schveighoffer
wrote:
DMD is the point of all D feature introductions, and so
anything that works with LDC should work with DMD.
It's the other way around that might cause trouble, since there
may be DMD features which haven't yet made
s). In LDC, you might get 'duplicate
definition' errors when linking D objects that succeeds when
compiled with dmd.
- DMD supports C opaque struct definitions in headers (though
arguably a bug as well) while LDC will complain, see
https://github.com/ldc-developers/ldc/issues/3817
Known
On 25/07/2023 1:26 AM, devosalain wrote:
I could be interesting to also compare the licenses of the 3 compilers.
There isn't a huge difference between them.
The frontend, druntime and most of phobos (minus zlib and curl) are all
Boost regardless of compiler.
That just leaves backends,
thinking of all the "features" of DMD that are now considered verboten
by many users (e.g. compiling with -release, disabling of asserts or
array bounds checking, etc). Known edge cases of compiler optimization
causing different behavior between vendors?
DMD is the point of all D f
On 25/07/2023 1:30 AM, cc wrote:
Is there any list of known significant "gotchas" with moving to LDC from
DMD? Any unexpected surprises to watch out for or be careful for? I'm
thinking of all the "features" of DMD that are now considered verboten
by many users (e.g. compiling with
On Monday, 24 July 2023 at 09:29:09 UTC, Richard (Rikki) Andrew
Cattermole wrote:
There isn't a huge concern with which one you use.
Its quite common to use dmd for development, and ldc for
release for example.
They all share the same frontend, so they really only differ
between them by
I could be interesting to also compare the licenses of the 3
compilers.
There isn't a huge concern with which one you use.
Its quite common to use dmd for development, and ldc for release for
example.
They all share the same frontend, so they really only differ between
them by their glue code to the relevant backend and some modules in
druntime that are
There are three compilers present in the Dlang website: DMD GDC
and LDC
);
On Thu, Jul 20, 2023 at 4:22 PM Danni Coy
wrote:
https://pastebin.com/Jc9ZaFFs
Redid the code as an almost exact translation of the C code.
should be easier to test and compare. Same issue is occurring.
On Thu, Jul 20, 2023 at 5:30 AM Mike Shah via
Digitalmars-d-learn wrote:
> [...]
Good w
://pastebin.com/Jc9ZaFFs
Redid the code as an almost exact translation of the C code.
should be easier to test and compare. Same issue is occurring.
On Thu, Jul 20, 2023 at 5:30 AM Mike Shah via
Digitalmars-d-learn wrote:
>
> On Wednesday, 19 July 2023 at 07:39:35 UTC, Danni Coy wrote:
>
ost exact translation of the C code.
> should be easier to test and compare. Same issue is occurring.
>
> On Thu, Jul 20, 2023 at 5:30 AM Mike Shah via Digitalmars-d-learn
> wrote:
> >
> > On Wednesday, 19 July 2023 at 07:39:35 UTC, Danni Coy wrote:
> > > https://p
https://pastebin.com/Jc9ZaFFs
Redid the code as an almost exact translation of the C code.
should be easier to test and compare. Same issue is occurring.
On Thu, Jul 20, 2023 at 5:30 AM Mike Shah via Digitalmars-d-learn
wrote:
>
> On Wednesday, 19 July 2023 at 07:39:35 UTC, Danni Coy
On Thu, Jul 20, 2023 at 5:30 AM Mike Shah via Digitalmars-d-learn
wrote:
>
> On Wednesday, 19 July 2023 at 07:39:35 UTC, Danni Coy wrote:
> > https://pastebin.com/JxxJufNB
>
> What platform are you using, and how are you trying to build?
>
> I can try to replicate on
On Wednesday, 19 July 2023 at 07:39:35 UTC, Danni Coy wrote:
https://pastebin.com/JxxJufNB
What platform are you using, and how are you trying to build?
I can try to replicate on my end.
https://pastebin.com/JxxJufNB
>
> I was able to get through the triangle demo a while back. I feel
> like it's more of a D question than a Vulkan library question.
> You'll have to post your code so people can tell what it is. Just
> a hunch, but it's probably something that the gc is collecting
> before i
enabled validation layers and they are not picking up
anything.
Any suggestions?
I was able to get through the triangle demo a while back. I feel
like it's more of a D question than a Vulkan library question.
You'll have to post your code so people can tell what it is. Just
a hunch, but it's
I am trying to run through the basic Vulkan triangle demo. I am getting stuck at
vkGetDeviceQueue which segfaults for me.
I have written the same tutorial to about the same point in C and I am
not getting the segfault.
I have enabled validation layers and they are not picking up anything.
Any
On Thursday, 13 July 2023 at 14:00:49 UTC, Mike Parker wrote:
Finally, I told everyone about a conversation I'd had with
someone who was planning to submit a proposal to add slices to
C. Walter was happy to hear about that, as he had been
informally pushing for that for years. He talked about
On Thursday, 13 July 2023 at 14:00:49 UTC, Mike Parker wrote:
said in the chat window that this is a straight-up bug). Átila
had also learned that static constructors should always be
`nothrow`. Walter said he couldn't see why anyone would write a
static constructor that throws. Átila said
The monthly meeting for June 2023 took place on Friday the 2nd at
15:00 UTC. It lasted about an hour. We had three new faces for
this one: Adam D. Ruppe, Steven Schveighoffer, and Nick
Treleaven. I'll be sending them invites to all of our future
monthlies, but we've left it up to them
don't need *any* numerical literals at all in
D, you could make all of them with string-to-number templates.
You could take such an approach to just about everything in D,
actually! On the other hand, people working on low-level Linux
code might be pretty appalled to find out that they can't
On Sunday, 9 July 2023 at 18:51:01 UTC, IchorDev wrote:
[...]
I felt that I should also clarify that there are some features
that *should* stay dead, for our benefit. I figured I'd name a
few.
1. Bugs that some people treated like features. There's a few
listed among D's deprecated
useful in
its own right. You technically don't need *any* numerical
literals at all in D, you could make all of them with
string-to-number templates. You could take such an approach to
just about everything in D, actually! On the other hand, people
working on low-level Linux code might be pretty
code. How we use
3rd party code right now? DUB. The problem is that dub doesn't
have a flag for keeping 3rd party code shut. So, in MY VIEW,
dub should be the one to address that problem, not the D
compiler itself.
I don't know how dub would address this problem by itself, but
this is the number
On Friday, 7 July 2023 at 22:41:38 UTC, Walter Bright wrote:
The problem has a lot to do with people wanting to use 3rd
party libraries, and it being impractical to upgrade those
libraries when the maintainer of those libraries is no longer
active. If a user's project depends on several such
,
the two closest competitors of D, both have a generalized version
of 'alias this' ('usingnamespace' and 'using', respectively).
On Friday, 7 July 2023 at 10:45:33 UTC, Guillaume Piolat wrote:
On Friday, 7 July 2023 at 09:35:14 UTC, Paolo Invernizzi wrote:
I respectfully disagree, and prefer to keep going on with the
current deprecation and cleanup policy: Scott Meyers' DConf
2014 keynote all the way down.
+1
I've
On Friday, 7 July 2023 at 03:06:28 UTC, Walter Bright wrote:
1. continue to evolve the language
I'm super excited about this!
- Tagged Union? :D
- Pattern Matching? :D ()
- Built-in Tuple with deconstructing? :D
On 7/6/2023 8:14 PM, Richard (Rikki) Andrew Cattermole wrote:
And for the record I still want hex strings to come back. They were incredibly
useful with no good alternatives when we talk about large tables of data being
described.
For reference:
https://github.com/dlang/dmd/pull/13773
On 7/7/2023 7:56 AM, Guillaume Piolat wrote:
It just seems to me, instead of complaining when features become deprecated,
people will complain when obsolete feature becomes deprecated and they see the
message. The proposal here is that they see the message later. In the meantime,
nothing will
On Friday, 7 July 2023 at 03:06:28 UTC, Walter Bright wrote:
As time moves on, the D language has to evolve as well. What do
we do with obsolete and/or problem-causing, legacy features?
[...]
Yes, I agree with all of this. Thank you.
On Friday, 7 July 2023 at 10:45:33 UTC, Guillaume Piolat wrote:
On Friday, 7 July 2023 at 09:35:14 UTC, Paolo Invernizzi wrote:
I respectfully disagree, and prefer to keep going on with the
current deprecation and cleanup policy: Scott Meyers' DConf
2014 keynote all the way down.
+1
I've
On Friday, 7 July 2023 at 13:01:53 UTC, Nick Treleaven wrote:
Possibly obsolete features could become deprecations before
they are actually removed.
It just seems to me, instead of complaining when features become
deprecated, people will complain when obsolete feature becomes
deprecated
On Friday, 7 July 2023 at 03:06:28 UTC, Walter Bright wrote:
To that end, we have a new switch: -wo
Isn't that just another "deprecation" switch?
I'm now thinking that deprecations in general are causing us
headaches, but the all-or-nothing approach. You either turn all
point types & the corresponding
literals,
Deprecated in 2.097, maybe a good candidate to obsolete instead.
built-in 128-bit integer types,
cent and ucent are already an error as of 2.100. Were they even
implemented?
and octal literals, I think could all be added back to D
without cau
On Friday, 7 July 2023 at 10:45:33 UTC, Guillaume Piolat wrote:
alias this was a relatively bad idea, even if an iconic feature.
I don't remember people from outside the community being
impressed by alias this.
There was no way to rewrite the code without breaking dependent
code. That should
A big problem with compiler switches is that they have to apply to
everything in a build, or things won't line up. You can't pick and
choose which module it applies to, even if you could, its going to lead
to people having a very bad day.
This is another reason why strict by default is the
code right now? DUB. The problem is that dub doesn't
have a flag for keeping 3rd party code shut. So, in MY VIEW, dub
should be the one to address that problem, not the D compiler
itself.
One can see here that mostly people that disagreed with Walter's
proposal is people which maintain all
On Friday, 7 July 2023 at 03:06:28 UTC, Walter Bright wrote:
As time moves on, the D language has to evolve as well. What do
we do with obsolete and/or problem-causing, legacy features?
Our answer was deprecation. The deprecation starts out as just
a message, which can be disabled, or can
On Friday, 7 July 2023 at 09:07:28 UTC, zjh wrote:
This is like the
`configuration` of `vim`.
In fact, there is a ready-made tool called `sc.ini` that can
completely extend this file to become a gathering place for more
configuration files for `d` users.
Of course, you can also use the `d
On Friday, 7 July 2023 at 09:35:14 UTC, Paolo Invernizzi wrote:
I respectfully disagree, and prefer to keep going on with the
current deprecation and cleanup policy: Scott Meyers' DConf
2014 keynote all the way down.
+1
I've always agreed with the deprecation in the end, even complex
On Friday, 7 July 2023 at 03:06:28 UTC, Walter Bright wrote:
As time moves on, the D language has to evolve as well. What do
we do with obsolete and/or problem-causing, legacy features?
[...]
I respectfully disagree, and prefer to keep going on with the
current deprecation and cleanup
On Friday, 7 July 2023 at 08:59:19 UTC, zjh wrote:
Each user only needs a `features switch` file with their own
used `features`,
Each user has a `feature` file, and if they publish a project,
they put the `file` into the`project`. This is like the
`configuration` of `vim`, and users can
On Friday, 7 July 2023 at 08:53:17 UTC, zjh wrote:
As long as the compiler code is not deleted, it can be ensured
that the `compilation` compiles the `previous code`. It is
recommended to create a `deprecation` directory to specifically
collect the `deprecation` function.
Each user only
On Friday, 7 July 2023 at 03:06:28 UTC, Walter Bright wrote:
As time moves on, the D language has to evolve as well. What do
we do with obsolete and/or problem-causing, legacy features?
As long as the compiler code is not deleted, it can be ensured
that the `compilation` compiles
On Tuesday, 27 June 2023 at 14:18:52 UTC, Mike Parker wrote:
I still will put at least three or four weeks between the
meetings and the summaries.
I appreciate your summary here. This was very insightful!
I suspect that we kinda have it a little backwards.
Keep it strict by default, but allow more code to pass if desired.
This is how a build manager like dub should operate.
Part of the goal here is to make sure people don't go round using
undesirable features by accident.
Also we should
As time moves on, the D language has to evolve as well. What do we do with
obsolete and/or problem-causing, legacy features?
Our answer was deprecation. The deprecation starts out as just a message, which
can be disabled, or can be set to be errors. The deprecations could last for
many years
On 7/6/23 12:16 AM, IchorDev wrote:
On Wednesday, 5 July 2023 at 21:50:37 UTC, Andrew wrote:
Why not just improve Phobos itself? Make PRs to add new modules to
std.experimental, announce them here and elsewhere on the web, and get
the community to support it.
Earlier in this thread it was
On Wednesday, 5 July 2023 at 21:50:37 UTC, Andrew wrote:
Why not just improve Phobos itself? Make PRs to add new modules
to std.experimental, announce them here and elsewhere on the
web, and get the community to support it.
Earlier in this thread it was pointed out that it's too arbitrary
On Wednesday, 5 July 2023 at 20:03:26 UTC, IchorDev wrote:
Perhaps a fork of Phobos that's more community-driven would be
good for the language?
Why not just improve Phobos itself? Make PRs to add new modules
to std.experimental, announce them here and elsewhere on the web,
and get the
On Saturday, 13 May 2023 at 15:58:12 UTC, ryuukk_ wrote:
- better enums
- tagged union
- pattern matching
- async
- nullable
- tuple/multiple return (deconstruction)
- allocators (don't do them as classes/interface for the love
of god)
- implement GC as an allocator
This is a nice
On Wednesday, 5 July 2023 at 11:46:32 UTC, WebFreak001 wrote:
Hello everyone,
today there is a new D-Scanner release, key features include:
- proper diagnostic ranges (underlining code / end locations
for issues)
- also includes file byte index instead of only line:column in
the JSON formats
Hello everyone,
today there is a new D-Scanner release, key features include:
- proper diagnostic ranges (underlining code / end locations for
issues)
- also includes file byte index instead of only line:column in
the JSON formats (for IDE integration)
- pretty printing format, with colored
On Friday, 30 June 2023 at 16:26:26 UTC, Richard (Rikki) Andrew
Cattermole wrote:
I use it and contribute to it ;)
Thanks to Rikki I was able to figure it out.
—
Dmitry Olshansky
https://olshansky.me
I use it and contribute to it ;)
Have anyone had any luck with it?
So far I'm trying to install DMD as SDK but it fails with not a
valid D compiler home.
--
Dmitry Olshansky
https://olshansky.me
On Tuesday, 27 June 2023 at 12:36:20 UTC, Sergey wrote:
After that real person could verify result and make small
corrections. It should significantly reduce effort and decrease
time-to-market :)
Yes. The next version of Davinci Resolve (which I use for video
editing) will have automated
On Friday, 23 June 2023 at 14:32:51 UTC, Mike Parker wrote:
The monthly meeting for May 2023 took place on Friday the 5th
at 14:00 UTC. It lasted about an hour and a half.
Hi Mike.
Does anyone consider some automatization and application of
modern technologies for the process of meeting
On Tuesday, 27 June 2023 at 12:00:48 UTC, Mike Parker wrote:
Anyway, the main point of this announcement wasn't IVY, it's
that we're finally getting organized. IVY is just the tool
we're using to do it. No D user or contributor needs to pay any
attention to it if they don't want to.
And I
Conf
last month, and Adam summarized it here:
https://dpldocs.info/this-week-in-d/Blog.Posted_2023_05_29.html
TLDR; it's about understanding stakeholder motivations and
looking for opportunities where they align. Right now, we're just
employing it internally to get our house in order. Down the r
efficient and stay motivated. Before we get to that point,
we've got a lot of decisions to make and a lot of work to do
internally to provide a foundation on which we can build.
I'm not exaggerating when I say that this is going to be the
most significant change in the D community in the 20
If you feel up to doing a practice talk, you're welcome to join us on
BeerConf!
as a follow-up presentation.
He was excited about the project and felt it was a big deal in
general and a big deal for D. Even if Sebastiaan decided not to
move the project forward, Walter felt we should find someone to
take it over. He said the ideas behind it were big and would be
a nice thing for us
On Friday, 23 June 2023 at 14:32:51 UTC, Mike Parker wrote:
The monthly meeting for May 2023 took place on Friday the 5th
at 14:00 UTC. It lasted about an hour and a half. This was the
last meeting before we started our new planning sessions.
Nice to read on what you guys are doing!
—
Dmitry
, this time Travelodge Central City Road. The sponsorship
funding will go toward our speaker reimbursement budget.)
Next, I gave an update on registrations. At that point, only one
person had registered. I then talked about some email exchanges
I'd had with some D shops about possible sponsorships
If I use array:
```
extern(C++) {
void getInts(core.stdcpp.array.array!(int, 10) vec) {
foreach (int i; 0 .. 10) {
vec.at(i) = i;
}
}
}
```
```
#include
using namespace std;
void getInts(array* vector);
```
Both DMD and LDC has link error:
base.cpp:42: undefined reference to
On Monday, 19 June 2023 at 05:56:54 UTC, Richard (Rikki) Andrew
Cattermole wrote:
On 19/06/2023 5:54 PM, mw wrote:
Ha, I saw vector.d there, So I can use this vector.d as the D
side of C++'s std::vector?
Probably, I just don't know how well tested it is.
But worth a go!
```
import
On 19/06/2023 5:54 PM, mw wrote:
Ha, I saw vector.d there, So I can use this vector.d as the D side of
C++'s std::vector?
Probably, I just don't know how well tested it is.
But worth a go!
be a reason why it isn't in
https://github.com/dlang/dmd/tree/master/druntime/src/core/stdcpp
Ha, I saw vector.d there, So I can use this vector.d as the D
side of C++'s std::vector?
On 19/06/2023 5:39 PM, mw wrote:
Then it will be very tedious, esp. for such library class std::list.
Yes, you would also need to verify it with every compiler you need
(MSVC, vs linux gcc).
There could be a reason why it isn't in
On Monday, 19 June 2023 at 05:39:51 UTC, mw wrote:
Then it will be very tedious, esp. for such library class
std::list.
Is there a tool that can automate this?
A related question: basically I want to pass an array of objects
from D side to the Cpp side, is there any example showing how
On Monday, 19 June 2023 at 05:32:23 UTC, Richard (Rikki) Andrew
Cattermole wrote:
This is just a guess, but I think the problem is the vtable is
incomplete.
Because of this the offsets are wrong. So you wouldn't be
calling push_back.
So, you mean on the D side, it need to list all
This is just a guess, but I think the problem is the vtable is incomplete.
Because of this the offsets are wrong. So you wouldn't be calling push_back.
lt; "c = " << c << endl;
}
int mul(int factor);
};
template class std_list : public std::list {};
void getInts(std_list* list);
int Derived::mul(int factor)
{
return field * factor;
}
Derived *createInstance(int i)
{
// get list of ints from D sid
UPDATE: life is too short to debug dlang built-in AA to right,
let's just use HashMap from emsi_containers
https://github.com/mw66/grpc-d/blob/master/source/grpc/server/package.d#L25
```
HashMap!(string, ServiceHandlerInterface) services;
```
After this change, the problem goes away.
I think
Hi,
I recently found and started playing with the grpc-d-core[1]
package, and my program structure looks like this:
https://github.com/mw66/grpc-demo/blob/master/source/main.d
If I run L64 alone (without L66 ~ 79 grpc-d part):
```
64: auto t = new Thread({fun();}).start();
```
it works fine
Glad to announce D 2.104.0, ♥ to the 38 contributors.
This release comes with 11 major changes, including:
- In the compiler, User Defined Attributes now parse template
arguments.
- In the standard library, `std.typecons.Rebindable` now supports
all types
- In dub, new properties
On Friday, 2 June 2023 at 12:20:35 UTC, zoujiaqing wrote:
On Thursday, 1 June 2023 at 13:01:44 UTC, user456 wrote:
In case some would still pipe valgrind in ddemangle, be aware
that this is not required anymore. Since [version 3.21.0],
valgrind supports D demangling out of the box.
[version
On Thursday, 1 June 2023 at 13:01:44 UTC, user456 wrote:
In case some would still pipe valgrind in ddemangle, be aware
that this is not required anymore. Since [version 3.21.0],
valgrind supports D demangling out of the box.
[version 3.21.0]:
https://valgrind.org/docs/manual/dist.news.html
On Thursday, 1 June 2023 at 13:01:44 UTC, user456 wrote:
In case some would still pipe valgrind in ddemangle, be aware
that this is not required anymore. Since [version 3.21.0],
valgrind supports D demangling out of the box.
[version 3.21.0]:
https://valgrind.org/docs/manual/dist.news.html
On Thursday, 1 June 2023 at 13:01:44 UTC, user456 wrote:
In case some would still pipe valgrind in ddemangle...
Great! Thanks for sharing!
In case some would still pipe valgrind in ddemangle, be aware
that this is not required anymore. Since [version 3.21.0],
valgrind supports D demangling out of the box.
[version 3.21.0]: https://valgrind.org/docs/manual/dist.news.html
https://issues.dlang.org/show_bug.cgi?id=23950
RazvanN changed:
What|Removed |Added
Keywords||backend, ice
CC|
https://issues.dlang.org/show_bug.cgi?id=23950
--- Comment #1 from m...@ernestocastellotti.it ---
The absurd thing is that instead this code compiles and works correctly:
import core.stdc.stdlib;
void main() {
auto foo = (false != true) && true || abort();
}
This looks just like a bad bug
https://issues.dlang.org/show_bug.cgi?id=23950
Issue ID: 23950
Summary: Weird backend fail with noreturn type - cod1.d(4027):
Assertion failure
Product: D
Version: D2
Hardware: x86_64
OS: Linux
On Wednesday, 3 May 2023 at 11:13:34 UTC, Mike Parker wrote:
Our enthusiasm is high, and we're ready to get going. I think
you'll like where we're headed.
Good job guys!! This reinforces my belief in what you do.
correct C code, not compile incorrect C code
3. implement non-transitive const in D
(1) is the most pragmatic choice. Maybe eventually we can do (3), but it's a
low priority. Note that any hand-translated C code to D has the same issue.
Improving the error message also would be rather clumsy. I wish
efficient and stay motivated. Before we get to that point,
we've got a lot of decisions to make and a lot of work to do
internally to provide a foundation on which we can build.
I'm not exaggerating when I say that this is going to be the
most significant change in the D community in the 20
https://issues.dlang.org/show_bug.cgi?id=23926
--- Comment #2 from dave287...@gmail.com ---
(In reply to dave287091 from comment #1)
> Thinking more about this, C doesn’t have transitive const so maybe this is
> actually correct. Maybe D needs head const to properly express C const.
The
https://issues.dlang.org/show_bug.cgi?id=23926
--- Comment #1 from dave287...@gmail.com ---
Thinking more about this, C doesn’t have transitive const so maybe this is
actually correct. Maybe D needs head const to properly express C const.
--
https://issues.dlang.org/show_bug.cgi?id=23926
Issue ID: 23926
Summary: ImportC: D can’t pass pointer to const struct to C
function declared taking pointer to const struct
Product: D
Version: D2
Hardware: All
https://issues.dlang.org/show_bug.cgi?id=23926
dave287...@gmail.com changed:
What|Removed |Added
Keywords||ImportC
--
On Wednesday, 3 May 2023 at 23:24:53 UTC, Walter Bright wrote:
This initiative has my full support.
argh!!
On Saturday, 29 April 2023 at 00:31:21 UTC, Neto wrote:
On Saturday, 29 April 2023 at 00:29:28 UTC, Neto wrote:
I'm thinking in moving from freelancer to some company, but
I'd like to use D. Are there any companies hiring where D is
used? note: hire without a degree.
and remote.
I received
On Monday, 15 May 2023 at 18:15:54 UTC, jmh530 wrote:
On Monday, 15 May 2023 at 18:02:49 UTC, ryuukk_ wrote:
[snip]
It can be frustrating when you are are neck deep in some
complicated problem to explain to people who haven't spent the
same amount of time with it as you have.
That poster
701 - 800 of 71191 matches
Mail list logo
