On Sunday, 21 January 2024 at 07:11:50 UTC, Jordan Wilson wrote:
On Saturday, 20 January 2024 at 22:53:15 UTC, privateWHAT wrote:
On Thursday, 18 January 2024 at 07:19:19 UTC, Mike Parker
wrote:
* establish support for fleshing out ideas before a DIP is
even written
It's 2024. That
On Tuesday, 26 September 2023 at 16:17:34 UTC, Andrey Zherikov
wrote:
On Thursday, 21 September 2023 at 15:59:10 UTC, Atila Neves
wrote:
...
I got your point.
Why does it have multiple languages (front-ends)? Is there
anyone willing to write build script for C++ on JavaScript or
Ruby, for
On Thursday, 21 September 2023 at 13:38:30 UTC, Andrey Zherikov
wrote:
On Wednesday, 20 September 2023 at 21:19:22 UTC, Atila Neves
wrote:
Because we don't have one now. Using CMake for D is horrible,
I would say just using CMake is horrible :-D But there are a
lot of people using it (even
On Thursday, 21 September 2023 at 14:19:27 UTC, jmh530 wrote:
On Wednesday, 20 September 2023 at 21:19:22 UTC, Atila Neves
wrote:
On Wednesday, 20 September 2023 at 15:24:52 UTC, Andrey
Zherikov wrote:
On Thursday, 7 September 2023 at 17:34:48 UTC, Atila Neves
wrote:
[...]
Out of curiosity,
On Wednesday, 20 September 2023 at 15:24:52 UTC, Andrey Zherikov
wrote:
On Thursday, 7 September 2023 at 17:34:48 UTC, Atila Neves
wrote:
https://code.dlang.org/packages/reggae
For those who don't know, reggae is a meta-build system for
and in D. It's like CMake, if you replace their terrible
On Tuesday, 12 September 2023 at 13:17:50 UTC, Adam D Ruppe wrote:
On Tuesday, 12 September 2023 at 13:12:29 UTC, Atila Neves
wrote:
It does mean adding `-I` flags to every dependency though, so
there's that.
Not if you install them properly.
That's the job of the package manager does that.
On Monday, 11 September 2023 at 23:15:28 UTC, Adam D Ruppe wrote:
I tried reggae today. It did not go well.
http://dpldocs.info/this-week-in-d/Blog.Posted_2023_09_11.html#reggae-editorial
One thing I learned from you is that for small projects `dmd -i`
is just as fast as incremental
On Thursday, 7 September 2023 at 21:25:27 UTC, German Diago wrote:
On Thursday, 7 September 2023 at 17:34:48 UTC, Atila Neves
wrote:
https://code.dlang.org/packages/reggae
For those who don't know, reggae is a meta-build system for
and in D. It's like CMake...
How mature is the build
https://code.dlang.org/packages/reggae
For those who don't know, reggae is a meta-build system for and
in D. It's like CMake, if you replace their terrible language
with D*. Like CMake, it can output make and ninja files. Unlike
CMake, it can also output tup files and has its own binary
On Thursday, 13 April 2023 at 01:44:24 UTC, Walter Bright wrote:
On 4/11/2023 7:35 PM, bachmeier wrote:
[...]
It's a seductive idea, and I've considered that (and variations
on it) many times. We have done this, after a fashion, in
having our own versions of the .h files in the form of the
On Saturday, 6 November 2021 at 15:46:57 UTC, JN wrote:
On Friday, 5 November 2021 at 13:19:24 UTC, zjh wrote:
D can aim at `experts`, especially `meta programming users`.
On this point,`rust` can't compete.
`Silky general meta programming`.
Use my `strengths` to attack theirs weaknesses.
On Wednesday, 16 June 2021 at 15:48:07 UTC, Vladimir Panteleev
wrote:
On Wednesday, 16 June 2021 at 14:40:05 UTC, Atila Neves wrote:
Interested? Please send a CV to dot name> at
Replying for the benefit of forum.dlang.org users, for whom the
tags were not visible due to Markdown.
Also,
Interested? Please send a CV to dot name> at
On Thursday, 14 January 2021 at 14:23:28 UTC, Dukc wrote:
On Thursday, 14 January 2021 at 13:24:55 UTC, Atila Neves wrote:
https://forum.dlang.org/post/wdsgkozpnhegqkcwe...@forum.dlang.org
On Tuesday, 1 September 2020 at 09:09:36 UTC, Jacob Carlborg
wrote:
BTW, is timestamps vs SHA-1 hashing
https://forum.dlang.org/post/wdsgkozpnhegqkcwe...@forum.dlang.org
On Tuesday, 1 September 2020 at 09:09:36 UTC, Jacob Carlborg
wrote:
On Sunday, 30 August 2020 at 14:13:36 UTC, Mike Parker wrote:
Looking for a full-time or part-time gig? Not only is Symmetry
Investments hiring D programmers,
On Wednesday, 13 January 2021 at 15:31:33 UTC, Nick Treleaven
wrote:
On Wednesday, 13 January 2021 at 14:48:07 UTC, Atila Neves
wrote:
Why do they have to scroll to the top?
They don't, you're right. But if you want to use it throughout
the module you need a top-level import, by convention
On Monday, 11 January 2021 at 12:32:42 UTC, Nick Treleaven wrote:
On Friday, 8 January 2021 at 14:07:29 UTC, Luhrel wrote:
Example a3 is straightforward the primary use case for
staticArray:
auto a3 = [1,2,3].staticArray;
I really don't like the `.staticArray` because it's
non-esthetic.
On Monday, 4 January 2021 at 01:19:12 UTC, jmh530 wrote:
On Sunday, 3 January 2021 at 20:31:41 UTC, welkam wrote:
[snip]
[snip[
Regardless, the DIP likely could have been improved by
mentioning its inclusion in C++ 11 (and perhaps focused a bit
less on implementation).
Yes.
On Monday, 4 January 2021 at 15:42:05 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 4 January 2021 at 15:25:13 UTC, Atila Neves wrote:
On Tuesday, 29 December 2020 at 19:59:56 UTC, Ola Fosheim
Grøstad wrote:
1. acknowledgment of the issue
2. acknowledgment of what the issue leads to in terms of
On Tuesday, 29 December 2020 at 19:59:56 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 29 December 2020 at 16:14:59 UTC, Atila Neves wrote:
[...]
I am not speaking for Ilya, but from skimming through the
dialogue it struck me that you didn't respond from the
perspective of managing the
On Thursday, 24 December 2020 at 14:14:33 UTC, 9il wrote:
On Thursday, 24 December 2020 at 14:08:32 UTC, welkam wrote:
On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote:
It was a mockery executed by Atila
Read the all comments and didnt saw any mockery
Yes, it wasn't explicit. He
On Tuesday, 22 December 2020 at 04:09:59 UTC, 9il wrote:
On Sunday, 20 December 2020 at 12:32:35 UTC, Petar Kirov
[ZombineDev] wrote:
How does your work compare to sumtype? Would mir.algebraic
offer any benefits, which would make it worth switching over?
replied at
On Sunday, 23 August 2020 at 19:39:35 UTC, Paul Backus wrote:
https://pbackus.github.io/blog/how-does-memory-safety-work-in-d.html
What exactly do we mean when we talk about "memory safety" in
D? Is it the same thing as "undefined behavior"? Is it ever
correct to mark and `extern(C)` function
On Wednesday, 29 July 2020 at 09:49:36 UTC, Martin Tschierschke
wrote:
On Wednesday, 29 July 2020 at 08:25:34 UTC, Eugene Wissner
wrote:
I'm happy to announce a new mocking library developed at
Funkwerk.
[...]
https://github.com/funkwerk/mocked
By searching for the exact definition of
On Saturday, 27 June 2020 at 15:48:33 UTC, Andrei Alexandrescu
wrote:
How to answer "why will yours succeed, when X, Y, and Z have
failed?"
https://www.youtube.com/watch?v=wIHfaH9Kffs
Very insightful talk.
Great talk. Similar to what I was trying to say in my DConf19
talk but in many ways
On Wednesday, 17 June 2020 at 16:01:29 UTC, Paul Backus wrote:
On Tuesday, 16 June 2020 at 13:31:49 UTC, Atila Neves wrote:
With a few changes, yes (added missing semicolons, changed
IGeometry to Geometry in `measure`, passed the current module
so tardy can find the UFCS functions, added
On Wednesday, 17 June 2020 at 11:31:09 UTC, jmh530 wrote:
On Wednesday, 17 June 2020 at 10:04:59 UTC, Atila Neves wrote:
[...]
Cool.
[...]
If I'm understanding you correctly, you could modify
Polymorphic (and a similar change to VirtualTable) to
struct Polymorphic(Interface,
On Wednesday, 17 June 2020 at 10:43:35 UTC, Stanislav Blinov
wrote:
On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
Tardy lets users have their cake and eat it too by not making
them have to use classes for runtime polymorphism.
I've got to ask though. Why "tardy"? Search
On Tuesday, 16 June 2020 at 15:50:07 UTC, jmh530 wrote:
On Tuesday, 16 June 2020 at 13:31:49 UTC, Atila Neves wrote:
[snip]
Pretty cool, thanks for the fixups.
It may make for a good documentation example, in that it may
help make clear that you need to pass the module in somehow
when
On Tuesday, 16 June 2020 at 12:30:24 UTC, jmh530 wrote:
On Tuesday, 16 June 2020 at 11:31:14 UTC, Atila Neves wrote:
On Tuesday, 16 June 2020 at 11:24:05 UTC, jmh530 wrote:
On Tuesday, 16 June 2020 at 09:15:10 UTC, Atila Neves wrote:
[snip]
In the more longer-term, is the goal of the project
On Tuesday, 16 June 2020 at 11:24:05 UTC, jmh530 wrote:
On Tuesday, 16 June 2020 at 09:15:10 UTC, Atila Neves wrote:
[snip]
In the more longer-term, is the goal of the project to
implement a Typescript / Go interfaces like structural type
system in user space?
Yes. Other than allowing
On Tuesday, 16 June 2020 at 03:56:52 UTC, Petar Kirov
[ZombineDev] wrote:
On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
https://code.dlang.org/packages/tardy
https://github.com/atilaneves/tardy
Looks interesting, nice work!
How does it compare to:
On Monday, 15 June 2020 at 20:47:16 UTC, 12345swordy wrote:
On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
https://code.dlang.org/packages/tardy
https://github.com/atilaneves/tardy
[...]
Wouldn't a top type be a better way to achieve this?
-Alex
How?
On Saturday, 13 June 2020 at 18:39:14 UTC, Paul Backus wrote:
On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
https://code.dlang.org/packages/tardy
https://github.com/atilaneves/tardy
Cool stuff!
What's the reasoning behind implementing your own vtables
instead of using D's
On Saturday, 13 June 2020 at 16:15:49 UTC, jmh530 wrote:
On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
https://code.dlang.org/packages/tardy
https://github.com/atilaneves/tardy
[snip]
This is pretty cool. Thanks for sharing.
I have a few questions/comments:
1) It might make
https://code.dlang.org/packages/tardy
https://github.com/atilaneves/tardy
Tardy lets users have their cake and eat it too by not making
them have to use classes for runtime polymorphism. No inheritance
anywhere to be found, which means structs, ints, and arrays can
be used with dynamic
On Monday, 1 June 2020 at 09:03:20 UTC, ag0aep6g wrote:
On 01.06.20 10:49, Atila Neves wrote:
That got fixed a few weeks back - your code doesn't compile
for me.
Huh. Maybe you forgot to commit that? I'm just running this
through `dub --single test.d`:
/+ dub.json:
{
On Thursday, 28 May 2020 at 19:01:22 UTC, jmh530 wrote:
On Thursday, 28 May 2020 at 17:45:26 UTC, Russel Winder wrote:
[snip]
This last is sad, for me. I like using test functions rather
than named unittest blocks.
I recall playing with them when it was originally announced and
thought
On Friday, 29 May 2020 at 14:20:53 UTC, ag0aep6g wrote:
On 28.05.20 17:35, Atila Neves wrote:
https://code.dlang.org/packages/unit-threaded
You got a bad @trusted:
import unit_threaded.light: check;
void main() @safe
{
check!((int a) @system {
/* ... can do unsafe stuff here
On Thursday, 28 May 2020 at 17:45:26 UTC, Russel Winder wrote:
On Thu, 2020-05-28 at 15:35 +, Atila Neves via
Digitalmars-d-announce wrote:
I decided to stop being like Google and finally tag version 1
of unit-threaded:
https://code.dlang.org/packages/unit-threaded
From now on I'm going
I decided to stop being like Google and finally tag version 1 of
unit-threaded:
https://code.dlang.org/packages/unit-threaded
From now on I'm going to focus on compilation speed (no matter
how ugly that might make the implementation), and also dropping
support in v2.x.x for anything other
On Tuesday, 26 May 2020 at 16:10:24 UTC, Bruce Carneal wrote:
On Tuesday, 26 May 2020 at 15:54:31 UTC, Bastiaan Veelo wrote:
On Tuesday, 26 May 2020 at 15:39:11 UTC, Bruce Carneal wrote:
On Tuesday, 26 May 2020 at 15:01:06 UTC, Bastiaan Veelo wrote:
@safe: the compiler checks
The compiler
On Tuesday, 26 May 2020 at 12:28:06 UTC, NaN wrote:
On Tuesday, 26 May 2020 at 06:55:31 UTC, Petar Kirov
[ZombineDev] wrote:
[...]
If the greenwashing part was separated and delayed it would
give time to find out if Walters hypothesis about people just
doing it themselves is true.
On Monday, 25 May 2020 at 17:01:24 UTC, Panke wrote:
On Monday, 25 May 2020 at 16:29:24 UTC, Atila Neves wrote:
A few years ago I submitted several PRs to Phobos to mark all
unittests that could with @safe explicitly. I'd say that was a
good example of nobody reviewing them for their
On Sunday, 24 May 2020 at 16:44:01 UTC, Paul Backus wrote:
On Sunday, 24 May 2020 at 03:28:25 UTC, Walter Bright wrote:
I'd like to emphasize:
1. It is not possible for the compiler to check any
declarations where the implementation is not available. Not in
D, not in any language. Declaring
On Saturday, 23 May 2020 at 10:55:40 UTC, Dukc wrote:
The more I think of Atila's and Walter's responses, the more
they are starting to make sense.
[...]
Thank you for the anecdote, especially since it captures the
spirit of what I've been trying to convey here.
On Friday, 22 May 2020 at 20:08:37 UTC, Dukc wrote:
On Friday, 22 May 2020 at 18:27:42 UTC, Atila Neves wrote:
Sorry, I didn't express myself well. I meant that the user can
still mark functions as @system, they just have to do it
explicitly.
Hm, DPP might be of help here. Becuse I quess
On Friday, 22 May 2020 at 18:17:29 UTC, ag0aep6g wrote:
On 22.05.20 19:54, Atila Neves wrote:
We care. Annotations become explicit. Do I think this is
ideal? No.
"Annotations become explicit." - What now? I probably
misunderstand that sentence, but DIP 1028 does not require
explicit
On Friday, 22 May 2020 at 18:11:28 UTC, ag0aep6g wrote:
So the DIP itself wasn't good enough to convince you.
Had that been the case, I would have rejected it.
Your reasoning is fine when you're dealing with a function that
has a safe interface. I.e., it can only corrupt your code when
it's
On Friday, 22 May 2020 at 17:41:38 UTC, Steven Schveighoffer
wrote:
On 5/22/20 1:07 PM, Atila Neves wrote:
And so I was convinced that everything being @safe is actually
ok, especially because in real life, most C/C++ APIs aren't
going to secretly corrupt your code.
Yes, it can, but not
On Friday, 22 May 2020 at 17:33:11 UTC, rikki cattermole wrote:
On 23/05/2020 5:07 AM, Atila Neves wrote:
[...]
It is not about the linkage.
The problem is solely does the compiler have the source to the
function body to verify it?
That's what I meant, sorry for not making it clearer.
On Friday, 22 May 2020 at 14:37:04 UTC, bachmeier wrote:
On Friday, 22 May 2020 at 13:57:27 UTC, Mike Parker wrote:
[...]
I think the source of the problem is that Walter's DIPs require
the community to prove that Walter's proposal is so bad that he
needs to reject it. Anyone else's
On Friday, 22 May 2020 at 14:13:20 UTC, Paul Backus wrote:
On Friday, 22 May 2020 at 13:58:14 UTC, bachmeier wrote:
On Friday, 22 May 2020 at 03:36:03 UTC, Paul Backus wrote:
This is the nightmare scenario that people are worried about:
safety violations
being introduced *silently* into
On Friday, 22 May 2020 at 12:28:56 UTC, rikki cattermole wrote:
On 23/05/2020 12:19 AM, Joseph Rushton Wakeling wrote:
With the rationale laid out clearly as it is here, I do have
some responses in mind. But before sharing them, I'd like to
know whether that would be useful right now: I've no
On Friday, 22 May 2020 at 03:57:22 UTC, H. S. Teoh wrote:
On Thu, May 21, 2020 at 06:22:19PM -0700, Walter Bright via
Digitalmars-d-announce wrote:
I have made these points before, but I'll summarize them here
for convenient referral.
[...]
Thank you. This makes your position clear, even if
On Thursday, 21 May 2020 at 23:49:22 UTC, Bruce Carneal wrote:
On Thursday, 21 May 2020 at 16:32:32 UTC, Adam D. Ruppe wrote:
On Thursday, 21 May 2020 at 16:14:02 UTC, Seb wrote:
[...]
ditto, I think we should have like a seven person elected DIP
committee who pass/fail things by majority
On Monday, 16 March 2020 at 19:36:20 UTC, Walter Bright wrote:
On 3/16/2020 9:15 AM, bachmeier wrote:
"Have an online conference" isn't especially helpful. There
haven't been any detailed proposals, and Walter hasn't said
anything one way or the other about doing something online.
Oh, I'm
On Thursday, 27 February 2020 at 20:00:52 UTC, H. S. Teoh wrote:
On Thu, Feb 27, 2020 at 11:26:37AM -0800, Walter Bright via
Digitalmars-d-announce wrote: [...]
[...]
[...]
For all the trouble they've given us, built-in AA's is one of
the primary reasons I love D.
[...]
The reason for
On Wednesday, 26 February 2020 at 20:57:53 UTC, H. S. Teoh wrote:
On Wed, Feb 26, 2020 at 08:45:31PM +, Atila Neves via
Digitalmars-d-announce wrote:
On Wednesday, 26 February 2020 at 17:39:14 UTC, jmh530 wrote:
> On Wednesday, 26 February 2020 at 14:51:06 UTC, Atila Neves
>
On Wednesday, 26 February 2020 at 17:39:14 UTC, jmh530 wrote:
On Wednesday, 26 February 2020 at 14:51:06 UTC, Atila Neves
wrote:
[snip]
A lot of the comments were about how stupid I was for not just
using ctypes or cffi. I tried today and both of them are
horrible. As I say in the blog post
On Wednesday, 26 February 2020 at 16:17:06 UTC, Panke wrote:
On Wednesday, 26 February 2020 at 14:51:06 UTC, Atila Neves
wrote:
[...]
Very good read. I my opinion your work with integrating
different languages with D is the most exciting stuff going on
in the moment.
If you had an RSS
On Wednesday, 19 February 2020 at 16:30:04 UTC, Atila Neves wrote:
https://atilaoncode.blog/2020/02/19/want-to-call-c-from-python-use-d/
Discussion elsewhere:
https://www.reddit.com/r/programming/comments/f6agvt/want_to_call_c_from_python_use_d/
https://news.ycombinator.com/item?id=22365166
On Monday, 24 February 2020 at 15:41:16 UTC, Steven Schveighoffer
wrote:
On 2/24/20 4:38 AM, Atila Neves wrote:
There's also the practical question of template instantiations
and compile times even if the DIP that was being discussed
were to be modified in the way suggested.
I want to
On Sunday, 23 February 2020 at 18:57:55 UTC, Adam D. Ruppe wrote:
On Sunday, 23 February 2020 at 16:22:46 UTC, Mike Parker wrote:
The decision was primarily influenced by the lack of consensus
over the implementation and the syntax demonstrated in the two
review threads.
That's not true, we
https://atilaoncode.blog/2020/02/19/want-to-call-c-from-python-use-d/
Discussion elsewhere:
https://www.reddit.com/r/programming/comments/f6agvt/want_to_call_c_from_python_use_d/
https://news.ycombinator.com/item?id=22365166
On Thursday, 28 November 2019 at 14:06:39 UTC, Adam D. Ruppe
wrote:
On Thursday, 28 November 2019 at 13:10:44 UTC, Atila Neves
wrote:
This is the done already by reggae. Unfortunately, since every
D module is effectively a header, the number of files that
need to be recompiled is usually
On Monday, 25 November 2019 at 15:27:10 UTC, Robert Schadek wrote:
On Monday, 25 November 2019 at 13:14:09 UTC, Sebastiaan Koppe
wrote:
The biggest thing for me would be incremental compilation. As
well as a dub build and test 'watch' mode to avoid scanning
the dependencies every time.
I
On Monday, 25 November 2019 at 13:14:09 UTC, Sebastiaan Koppe
wrote:
On Monday, 25 November 2019 at 12:15:42 UTC, Joseph Rushton
Wakeling wrote:
What's currently broken or impossible in DUB? What parts of
that can be fixed without changing the config or CLI? And
what improvements are most
On Wednesday, 16 October 2019 at 15:23:01 UTC, Paolo Invernizzi
wrote:
On Wednesday, 16 October 2019 at 15:01:17 UTC, Atila Neves
wrote:
[...]
I don't think it's political: the change implies breakage for
downstream users who inherit from the class who might not even
care about @nogc.
On Wednesday, 16 October 2019 at 12:32:28 UTC, Paolo Invernizzi
wrote:
On Wednesday, 16 October 2019 at 10:56:40 UTC, Atila Neves
wrote:
On Saturday, 12 October 2019 at 03:10:29 UTC, Walter Bright
wrote:
On 10/7/2019 12:37 AM, Paolo Invernizzi wrote:
- adding another method to a class, marked
On Saturday, 12 October 2019 at 03:10:29 UTC, Walter Bright wrote:
On 10/7/2019 12:37 AM, Paolo Invernizzi wrote:
- adding another method to a class, marked @nogc, and (maybe)
deprecating the previous method is seen as 'annoying', also if
it's a _clear_ improvement over the actual situation
... So not going to be available until I'm back.
On Tuesday, 16 July 2019 at 20:18:30 UTC, John Colvin wrote:
On Tuesday, 16 July 2019 at 18:18:50 UTC, Atila Neves wrote:
On Tuesday, 16 July 2019 at 00:10:19 UTC, Aliak wrote:
On Monday, 15 July 2019 at 21:20:16 UTC, Atila Neves wrote:
On Monday, 15 July 2019 at 11:13:10 UTC, aliak wrote:
On Tuesday, 16 July 2019 at 00:10:19 UTC, Aliak wrote:
On Monday, 15 July 2019 at 21:20:16 UTC, Atila Neves wrote:
On Monday, 15 July 2019 at 11:13:10 UTC, aliak wrote:
I've been using a set of meta tools for a while now, so
decided to release it as 1.0.0 with a few enhancements
chucked on.
On Monday, 15 July 2019 at 11:13:10 UTC, aliak wrote:
I've been using a set of meta tools for a while now, so decided
to release it as 1.0.0 with a few enhancements chucked on.
[...]
Nice! I'm working on something similar but with a different goal.
On Thursday, 27 June 2019 at 22:36:14 UTC, ag0aep6g wrote:
On 27.06.19 23:34, aliak wrote:
I really love that you go in to the code and find things like
this, especially when it comes to abuse of @trusted, but maybe
a little explanation as to why would be more helpful to the OP
;)
Probably.
On Monday, 27 May 2019 at 10:31:10 UTC, ag0aep6g wrote:
On 27.05.19 12:06, Atila Neves wrote:
No, and I guess it can't. I'm trying to figure out what the
implications are. Can Vector only be @safe for Mallocator? Is
it possible to write a @safe Vector at all without having to
force the
On Monday, 27 May 2019 at 09:48:27 UTC, ag0aep6g wrote:
On 27.05.19 10:54, Atila Neves wrote:
I don't see the problem here. This example would throw
RangeError at runtime instead of actually overwriting memory
unless bounds checking is turned off.
No, it doesn't. It's a complete, runnable
On Monday, 27 May 2019 at 09:07:48 UTC, Paolo Invernizzi wrote:
On Monday, 27 May 2019 at 08:54:45 UTC, Atila Neves wrote:
On Friday, 24 May 2019 at 16:51:11 UTC, ag0aep6g wrote:
Then there's the fact that if a 3rd party library really does
want to corrupt memory they can just tag all their
On Friday, 24 May 2019 at 16:51:11 UTC, ag0aep6g wrote:
On 24.05.19 18:19, Atila Neves wrote:
On Friday, 24 May 2019 at 13:30:05 UTC, ag0aep6g wrote:
[...]
My `puts`s might not do any harm, but they could just as well
be buffer overflows.
Could you please give an example of how @system
On Friday, 24 May 2019 at 13:30:05 UTC, ag0aep6g wrote:
On Friday, 24 May 2019 at 13:13:12 UTC, Atila Neves wrote:
Thanks for this. I think the only violation is calling
`stringz` on `Z`, and that was due to a poorly designed DbI
check on being able to call `stringz`. Allocating generally
On Friday, 24 May 2019 at 12:32:45 UTC, ag0aep6g wrote:
On 24.05.19 13:41, Atila Neves wrote:
[...]
You've got safety violations:
/+ dub.sdl:
name "test"
dependency "nogc" version="~>0.5.0"
+/
import core.stdc.stdio: puts;
struct S1
{
S2 s2;
this(ref const S1 src)
I'd been holding off on announcing this until DIP1008 actually
got implemented, and now it has:
https://code.dlang.org/packages/nogc
This dub package has a @nogc version of `std.conv.text` (which
probably isn't as good yet) that, instead of returning a `string`
returns an
On Wednesday, 24 April 2019 at 10:52:14 UTC, jmh530 wrote:
On Wednesday, 24 April 2019 at 01:34:58 UTC, 9il wrote:
Thread safe RC Array and Ptr. Plus C++ headers for code
integration.
[snip]
Cool.
Does this make any use of DIP1000? How is the run-time/memory
performance vs. the GC
On Tuesday, 9 April 2019 at 21:11:28 UTC, DanielG wrote:
re: the difficulties of interfacing D with certain types of
C/C++ code ...
Has anybody looked into something like a JavaCpp[1] approach
for D?
Instead of trying to get D to speak directly with C++, or
translating C/C++ headers to D,
On Monday, 8 April 2019 at 11:30:48 UTC, Andre Pany wrote:
On Monday, 8 April 2019 at 10:28:04 UTC, Mike Parker wrote:
I've just published a new Project Highlight, this one on dpp.
Atila shares some anecdotes about how and why the project came
together. He'll be speaking more about it at DConf
On Sunday, 7 April 2019 at 07:05:32 UTC, bauss wrote:
On Friday, 5 April 2019 at 12:03:48 UTC, Atila Neves wrote:
http://code.dlang.org/packages/jupyter_wire
It's now possible to send markdown or HTML to a jupyter
notebook from D:
return markdownResult("# Header");
Simple, but looks
http://code.dlang.org/packages/jupyter_wire
It's now possible to send markdown or HTML to a jupyter notebook
from D:
return markdownResult("# Header");
Simple, but looks pretty.
On Tuesday, 19 March 2019 at 10:10:28 UTC, Seb wrote:
On Monday, 18 March 2019 at 21:34:40 UTC, Per Nordlöw wrote:
On Monday, 18 March 2019 at 12:33:12 UTC, Seb wrote:
[1] https://github.com/dlang/installer
Does this include a script for building dmd with ldc or this
not yet possible?
On Friday, 8 March 2019 at 10:27:54 UTC, Jacob Carlborg wrote:
On 2019-03-07 16:45, Atila Neves wrote:
C++ is hard:
https://atilaoncode.blog/2019/03/07/the-joys-of-translating-cs-stdfunction-to-d/
Using ".mangleof" and "pragma(mangle)" on the same symbol looks
like something that could
C++ is hard:
https://atilaoncode.blog/2019/03/07/the-joys-of-translating-cs-stdfunction-to-d/
On Tuesday, 26 February 2019 at 03:56:27 UTC, Walter Bright wrote:
On 2/25/2019 7:45 AM, Atila Neves wrote:
I have no idea what people are talking about when they mention
on this forum that D's const is useless. Nearly every function
parameter in my code is `in`. Nearly every variable
On Monday, 25 February 2019 at 00:38:02 UTC, Walter Bright wrote:
The problem with C++ const is it only goes one level, i.e. what
I call "head-const". If you pass a T to a const parameter,
anything T references remains mutable. It's more of a
suggestion than anything reliable or enforceable.
On Monday, 11 February 2019 at 22:32:59 UTC, Vladimir Marchevsky
wrote:
On Monday, 11 February 2019 at 17:03:36 UTC, Atila Neves wrote:
import kwargs;
struct Foo { string value; }
struct Bar { string value; }
struct Baz { string value; }
size_t funImpl(in Foo foo, in Bar bar = Bar("lebar"),
https://code.dlang.org/packages/kwargs
There have been many posts asking about keyword arguments for D a
la Python. Usually I reply saying to just use the type system,
but that has the incovenience of having to pass all 7 parameters
before the optional 8th one you actually care about despite
On Thursday, 31 January 2019 at 16:01:33 UTC, jmh530 wrote:
On Thursday, 31 January 2019 at 14:42:43 UTC, Atila Neves wrote:
[snip]
I've never had a need to use complicated values, so I haven't
coded that.
If presented with an example, I think there's a high chance
I'd consider it an
On Thursday, 31 January 2019 at 15:03:26 UTC, Colin wrote:
On Wednesday, 30 January 2019 at 14:27:25 UTC, Atila Neves
wrote:
New release of unit-threaded, the advanced test framework for
D:
https://code.dlang.org/packages/unit-threaded
Besides bug fixes, the main difference is now cartesian
On Wednesday, 30 January 2019 at 14:55:37 UTC, jmh530 wrote:
On Wednesday, 30 January 2019 at 14:27:25 UTC, Atila Neves
wrote:
[snip]
--
@Types!(ubyte, byte)
@Types!(int, uint, float)
@UnitTest
void fun(T0, T1)() {
static assert(T0.sizeof == 1);
static assert(T1.sizeof
New release of unit-threaded, the advanced test framework for D:
https://code.dlang.org/packages/unit-threaded
Besides bug fixes, the main difference is now cartesian product
of types works as it did for values when it comes to
parameterized tests:
--
@Types!(ubyte, byte)
On Thursday, 24 January 2019 at 13:58:59 UTC, Mike Parker wrote:
I said in my annual D Blog retrospective that I wanted to do a
similar post focused on D at large. Sebastian Wilzbach sent me
a tremendously helpful info dump of all sorts of goings on,
most of which I knew nothing about. When I
1 - 100 of 341 matches
Mail list logo
