On Friday, 3 February 2017 at 12:08:44 UTC, qznc wrote:
Topic idea two: A more general talk about abstractions.
Starting from the basics (procedures) up to
Design-by-Introspection techniques which are quite D specific.
In between stuff like the "magic" D Lua bindings. This topic is
probably in
On Sunday, 9 April 2017 at 12:58:30 UTC, Vladimir Panteleev wrote:
_Someone_ should write Markdown rendering plugins for popular
news readers. What mime type will the Markdown enhanced
messages use? text/plain or text/markdown as per
https://de.wikipedia.org/wiki/Markdown ?
text/plain because
On Monday, 10 April 2017 at 06:24:55 UTC, Mike Parker wrote:
[...]
If it's not on there already, put it on the wiki, it will likely
get lost here.
On Thursday, 6 April 2017 at 19:17:53 UTC, Walter Bright wrote:
There's one big difference. The proposal I put forth is fairly
complete, and I am well along implementing it. deadalnix's
requires a great deal of further work just to figure out what
it means - as presented, it is not much more t
On Thursday, 6 April 2017 at 19:27:50 UTC, Andrei Alexandrescu
wrote:
We commit to be more formal about the process, but overall it
is correct that we have more say in what gets in the language.
Allow me to add a couple of things.
First, this is the way things are commonly done in language
Hi there!
These are probably questions directed mostly at Walter and others
shaping D's goals, but this could be of general interest for many
people, so to the forum it goes :-)
DMD is completely free software now and we can legally distribute
it in Debian main - yay! This is an awesome achie
On Monday, 10 April 2017 at 09:35:30 UTC, crimaniak wrote:
IMHO, it's better to do the same as with HTML letters:
text/markdown body + text/plain body for clients not supporting
markdown.
Multipart messages have their issues.
Are there any clients which will render a text/markdown part as
M
On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
Recompiling the dependency-chain of a software from source when
compiling a package using the "right" compiler and statically
adding the code is forbidden by distro policy.
This is the part that I do not understand.
Who came up
On Monday, 10 April 2017 at 09:35:30 UTC, crimaniak wrote:
IMHO, it's better to do the same as with HTML letters:
text/markdown body + text/plain body for clients not supporting
markdown.
BTW, this would mean sending exactly the same text twice, just
with a different Content-Type.
On Saturday, 8 April 2017 at 12:34:56 UTC, Vladimir Panteleev
wrote:
Thanks for the feedback.
What I miss most is to split the General board, as everything
gets buried too quick because it's too messy with different topic
categories together:
- Development (of projects not internal to D)
-
On Monday, 10 April 2017 at 12:40:33 UTC, Vladimir Panteleev
wrote:
On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
Recompiling the dependency-chain of a software from source
when compiling a package using the "right" compiler and
statically adding the code is forbidden by dist
On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
So, in summary:
1) Is there some perspective on D getting a defined ABI that
works with all major D compilers?
2) What would the D community recommend on how to deal with
the ABI issues currently? A Linux distribution is a bun
On 2017-04-09 05:26, Walter Bright wrote:
My previous version did not survive implementation. Here's the revised
version. I have submitted it as a DIP, and there's a trial
implementation up:
What exactly does the user have to do to use throw a RC exception
instead of a GC exception?
--
/Jaco
On Monday, 10 April 2017 at 12:59:37 UTC, Matthias Klumpp wrote:
Who came up with those policies and decided that they apply to
D? Because I really don't think they should.
They are the result of years of experience in building complex
systems and keeping them secure.
If you have a dependency
On Monday, 10 April 2017 at 12:40:33 UTC, Vladimir Panteleev
wrote:
[...]
Can we treat it more like an interpreted language instead?
An interpreted language would interpret the code on the target
system at runtime. This is not what D does, so we can't really
treat it like we treat Python (whe
On Monday, 10 April 2017 at 13:07:22 UTC, Vladimir Panteleev
wrote:
On Monday, 10 April 2017 at 12:59:37 UTC, Matthias Klumpp wrote:
Who came up with those policies and decided that they apply
to D? Because I really don't think they should.
[...]
You need to see here that D is not the center of
On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
Hi there!
[...]
If we do that, we will run into the D ABI trap: Libraries
compiled with compiler X can not be used from software compiled
with D compiler Y. There is actually no ABI stability guarantee
even between DMD releases.
On Monday, 10 April 2017 at 12:59:58 UTC, qznc wrote:
[...]
How do Debian and C++ go along? There is no ABI compatibility
between GCC and Clang afaik.
Clang offers compatibility for most basic features. There are
some ABI compatibility issues though and you find them reported
in the Clang/li
On Monday, 10 April 2017 at 06:17:43 UTC, Dukc wrote:
On Monday, 10 April 2017 at 02:04:35 UTC, Andrew Godfrey wrote:
On Monday, 10 April 2017 at 01:54:54 UTC, Walter Bright wrote:
throw new E(string);
Did you mean to use the "scope" keyword somewhere in the line
above?
No. In the scope
On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
There are a two issues though that we will be facing in Debian
soon, and I would like to get some opinion and maybe
perspective on from the D community on them.
First I would like to say thank you for all the work you did in
get
On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
1) Is there some perspective on D getting a defined ABI that
works with all major D compilers?
2) What would the D community recommend on how to deal with
the ABI issues currently? A Linux distribution is a bunch of
tightly in
On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
3) Will DMD support more architectures in the near future?
How should the architecture issue be handled?
This can be definitively answered as "no",
https://issues.dlang.org/show_bug.cgi?id=15108
Hello,
Does anyone here have a copy of The Art of Computer Programming
and would be willing to lend it between this year's DConf and
next year's? I guess volume 1 would be the logical place to
start, but another volume would also be fine.
Thanks,
Luís
On 10 April 2017 at 15:20, Matthias Klumpp via Digitalmars-d
wrote:
> On Monday, 10 April 2017 at 13:07:22 UTC, Vladimir Panteleev wrote:
>>
>> On Monday, 10 April 2017 at 12:59:37 UTC, Matthias Klumpp wrote:
Who came up with those policies and decided that they apply to D?
Because
On Monday, 10 April 2017 at 06:24:55 UTC, Mike Parker wrote:
Now that I'm managing the DIPs, here's how I intend to move
forward with the process (mostly what Dicebot was already
doing, but I want to outline it somewhere for reference).
[...]
Just throwing my two cents in here - I am a huge
On Monday, 10 April 2017 at 13:20:00 UTC, Matthias Klumpp wrote:
Btw, at time we are just ignore the ABI issues, and
surprisingly nothing broke yet, indicating that ABI breakage
isn't very common or not affecting commonly used interfaces
much.
One big ABI change was in 2.071:
https://issue
On Monday, 10 April 2017 at 15:11:01 UTC, Jack Stouffer wrote:
On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
3) Will DMD support more architectures in the near future?
How should the architecture issue be handled?
This can be definitively answered as "no",
https://issues.
On Monday, 10 April 2017 at 14:21:43 UTC, Gerald wrote:
On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
There are a two issues though that we will be facing in Debian
soon, and I would like to get some opinion and maybe
perspective on from the D community on them.
First I wou
On Mon, Apr 10, 2017 at 11:40:12AM +, Matthias Klumpp via Digitalmars-d
wrote:
[...]
> Naturally, when the reference compiler is available in Debian, we
> would compile everything with that, as it is the development focus and
> the thing many people test with.
>
> We do, however, have quite a
On Monday, 10 April 2017 at 14:33:34 UTC, qznc wrote:
On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
1) Is there some perspective on D getting a defined ABI that
works with all major D compilers?
2) What would the D community recommend on how to deal with
the ABI issues cu
On Monday, 10 April 2017 at 16:12:35 UTC, Iain Buclaw wrote:
[...]
Everyone should follow GDC's ABI, rather than trying to mimic
DMD calling convention. ;-)
GDC is working very well, and using it would actually be the
natural choice for us as GCC is the default compiler.
However, there are a
On Monday, 10 April 2017 at 16:58:05 UTC, Johan Engelen wrote:
On Monday, 10 April 2017 at 13:20:00 UTC, Matthias Klumpp wrote:
Btw, at time we are just ignore the ABI issues, and
surprisingly nothing broke yet, indicating that ABI breakage
isn't very common or not affecting commonly used int
On Monday, 10 April 2017 at 17:29:04 UTC, H. S. Teoh wrote:
On Mon, Apr 10, 2017 at 11:40:12AM +, Matthias Klumpp via
Digitalmars-d wrote: [...]
[...]
If we do that, we will run into the D ABI trap: Libraries
compiled with compiler X can not be used from software
compiled with D compiler Y
On Mon, Apr 10, 2017 at 06:12:26PM +, Matthias Klumpp via Digitalmars-d
wrote:
> On Monday, 10 April 2017 at 17:29:04 UTC, H. S. Teoh wrote:
> > On Mon, Apr 10, 2017 at 11:40:12AM +, Matthias Klumpp via
> > Digitalmars-d wrote: [...]
> > > [...]
> > > If we do that, we will run into the D
The vlang project, which is D code that has been discussed here
previously, now appears to have some relationship with
systemverilog. Was there an announcement here?
http://systemverilog.net/getting-started/installing-vlang/
On 4/10/2017 8:11 AM, Jack Stouffer wrote:
On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
3) Will DMD support more architectures in the near future? How should the
architecture issue be handled?
This can be definitively answered as "no",
https://issues.dlang.org/show_bug.cg
On Monday, 10 April 2017 at 13:00:52 UTC, Jacob Carlborg wrote:
On 2017-04-09 05:26, Walter Bright wrote:
My previous version did not survive implementation. Here's the
revised
version. I have submitted it as a DIP, and there's a trial
implementation up:
What exactly does the user have to do
On Monday, 10 April 2017 at 18:46:31 UTC, H. S. Teoh wrote:
Hmm. I guess there's no easy way to make dmd/ldc emit
dependencies with modified SONAMEs? So yeah, you're right,
every software that depends on said libraries would have to
explicitly depend on a different SONAME depending on what
On Monday, 10 April 2017 at 19:46:23 UTC, Jay Norwood wrote:
The vlang project, which is D code that has been discussed here
previously, now appears to have some relationship with
systemverilog. Was there an announcement here?
http://systemverilog.net/getting-started/installing-vlang/
Why i
On 10 April 2017 at 19:48, Matthias Klumpp via Digitalmars-d
wrote:
> On Monday, 10 April 2017 at 16:12:35 UTC, Iain Buclaw wrote:
>>
>> [...]
>> Everyone should follow GDC's ABI, rather than trying to mimic DMD calling
>> convention. ;-)
>
>
> GDC is working very well, and using it would actually
On 10 April 2017 at 19:50, Matthias Klumpp via Digitalmars-d
wrote:
> On Monday, 10 April 2017 at 16:58:05 UTC, Johan Engelen wrote:
>>
>> On Monday, 10 April 2017 at 13:20:00 UTC, Matthias Klumpp wrote:
>>>
>>>
>>> Btw, at time we are just ignore the ABI issues, and surprisingly nothing
>>> broke
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
Hi Guys :)
I am currently fixing a bug involving complex members of structs
(where complex means (slice, struct, array or pointer))
I did expect them to be broken ...
but not to be _that_ broken :)
struct S
{
uint[]
Everything looks good except this one line:
On Sunday, 9 April 2017 at 03:26:14 UTC, Walter Bright wrote:
throw new E(string);
I don't like it for 2 reasons:
a) E e = new E(string); throw e;
Should be *exactly* the same as
throw new E(string).
I think it's obvious why.
b) U
On Monday, 10 April 2017 at 20:52:21 UTC, Lurker wrote:
Everything looks good except this one line:
On Sunday, 9 April 2017 at 03:26:14 UTC, Walter Bright wrote:
throw new E(string);
I don't like it for 2 reasons:
a) E e = new E(string); throw e;
Should be *exactly* the same as
On Monday, 10 April 2017 at 20:43:06 UTC, Iain Buclaw wrote:
Master sports Phobos 2.071. Someone will have to see whether
latter versions can be built using it.
… and some weird Frankensteinian mix of several frontend
versions, I take it, maybe enough to build Phobos, but not
necessarily com
On 4/10/2017 3:58 AM, Nick B wrote:
Somebody has to work on it to move it forward - who do you propose should do
it? We don't have a team anywhere whose job it is to create detailed proposals
based on other peoples' ideas (which appear in the forum every day). Things
rarely move forward unless a
On Monday, 10 April 2017 at 17:50:08 UTC, Matthias Klumpp wrote:
I am reading release notes, so we rebuilt dependencies of LDC -
(I assume you mean reverse dependencies.)
[…] But since no bugs were reported, I assume no issues are
present :-)
So do we need to put a reminder about the ABI be
On Monday, 10 April 2017 at 13:20:00 UTC, Matthias Klumpp wrote:
This has worked nicely for every language. If you don't have
templates in your API or don't change the templates between
releases, you can survive with one library for a long time.
But the vast majority of D libraries _do_ have t
On 10 April 2017 at 23:52, David Nadlinger via Digitalmars-d
wrote:
> On Monday, 10 April 2017 at 20:43:06 UTC, Iain Buclaw wrote:
>>
>> Master sports Phobos 2.071. Someone will have to see whether latter
>> versions can be built using it.
>
>
> … and some weird Frankensteinian mix of several fro
On Monday, 10 April 2017 at 17:27:28 UTC, Matthias Klumpp wrote:
That's why I have been writing a lot of Makefiles and Meson
build definitions lately.
It seems like doing so without having a closer look at the
realities of D software (no stable ABI, etc.) might not have been
the best use of y
On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
Recompiling the dependency-chain of a software from source when
compiling a package using the "right" compiler and statically
adding the code is forbidden by distro policy.
Yet, from what I could find after a brief search, the Ru
My knee jerk reaction is that it's a very bad thing that "new"
means the same thing everywhere in the language (allocate and
initialize some GC-managed memory), except for this one case.
On 4/10/2017 5:59 AM, Matthias Klumpp wrote:
You need to see here that D is not the center of the world and we will need to
make it work nicely with the rest of the system. The technical policies work for
everything else, so there is nothing that really justifies an exception for D
here (if 10% o
On 4/10/2017 1:43 PM, Iain Buclaw via Digitalmars-d wrote:
This is an unfortunate distribution problem, things would be different
if GCC were more like a library. It's not like anyone is helping me
with the push. I am ultimately the one who is doing the tens of
thousands of lines of code change
On 4/10/2017 6:08 AM, Matthias Klumpp wrote:
I also want to stress that having a single C++ library like Boost compiled into
stuff and rolling dependency transitions when its API/ABI changes with a major
release is less of a problem than having the entire language give zero stability
and interope
On 4/10/2017 6:00 AM, Jacob Carlborg wrote:
What exactly does the user have to do to use throw a RC exception instead of a
GC exception?
case 1:
throw new Exception(args...); // the only way an RC exception
// is ever created
case 2:
catch (Exception e)
On 11 April 2017 at 01:27, Walter Bright via Digitalmars-d
wrote:
>
> The next problem is that dmd occasionally changes the interface to the D
> runtime. Or more accurately, with about every release. This has not been an
> issue historically for us, as the two have always been a matched set. I'm a
On 11 April 2017 at 01:33, Walter Bright via Digitalmars-d
wrote:
> On 4/10/2017 6:08 AM, Matthias Klumpp wrote:
>>
>> I also want to stress that having a single C++ library like Boost compiled
>> into
>> stuff and rolling dependency transitions when its API/ABI changes with a
>> major
>> release
On Monday, 10 April 2017 at 23:27:35 UTC, Walter Bright wrote:
The next problem is that dmd occasionally changes the interface
to the D runtime. […] I also do not know how the gdc/lds
druntime
interfaces differ.
Just to make this very clear to everybody reading this thread:
It's not even jus
On 4/10/2017 2:44 PM, Jonathan Marler wrote:
Another way to think of it is that this proposal makes "throw new" into a
special operator that is different than composing the "throw" and "new"
operations independently. Once you realize this it's easy to understand and
explain to others as well, i.e
On Monday, 10 April 2017 at 23:16:48 UTC, Meta wrote:
My knee jerk reaction is that it's a very bad thing that "new"
means the same thing everywhere in the language (allocate and
initialize some GC-managed memory), except for this one case.
`new SomeClass` has never implied GC allocation only
On Monday, 10 April 2017 at 23:16:48 UTC, Meta wrote:
My knee jerk reaction is that it's a very bad thing that "new"
means the same thing everywhere in the language (allocate and
initialize some GC-managed memory), except for this one case.
Actually, in addition to user defined overloads (whic
On 4/10/2017 4:43 PM, David Nadlinger wrote:
[1] In fact, it looks like – for example with DMD moving to libunwind-based EH
as well – the issue is slowly resolving itself anyway and at some point we'll
merely have to sit down for a week and iron out the last few kinks.
dmd is not moving to a li
On Monday, April 10, 2017 23:08:17 David Nadlinger via Digitalmars-d wrote:
> IIRC OCaml is also very much a statically linked affair. And how
> does Debian distribute Go binaries? Is there any issue with those
> being linked statically? If not, let's just distribute D
> libraries as source and com
On Sunday, 9 April 2017 at 03:26:14 UTC, Walter Bright wrote:
My previous version did not survive implementation. Here's the
revised version. I have submitted it as a DIP, and there's a
trial implementation up:
[...]
Instead of adding new runtime helper functions like
_d_newThrowable and _d
On Tuesday, 11 April 2017 at 00:46:51 UTC, Petar Kirov
[ZombineDev] wrote:
On Sunday, 9 April 2017 at 03:26:14 UTC, Walter Bright wrote:
My previous version did not survive implementation. Here's the
revised version. I have submitted it as a DIP, and there's a
trial implementation up:
[...]
On Monday, April 10, 2017 15:07:11 Walter Bright via Digitalmars-d wrote:
> On 4/10/2017 3:58 AM, Nick B wrote:
> >> Somebody has to work on it to move it forward - who do you propose
> >> should do it? We don't have a team anywhere whose job it is to create
> >> detailed proposals based on other p
On Monday, 10 April 2017 at 20:34:53 UTC, Joakim wrote:
Why is that notable? That's not any kind of official
SystemVerilog site, and it notes that it's maintained by
Coverify, the developers of vlang.
oh, I see. I thought SystemVerilog was a trademarked name.
On 4/10/2017 5:11 PM, Adam D. Ruppe wrote:
`new` itself isn't really changing since it was already allowed to do this in
cases the compiler can prove its lifetime.
Right. It isn't required to actually allocate it on the GC, just that it behaves
as if it did.
The real change in semantics is t
On Tuesday, 11 April 2017 at 00:11:01 UTC, Adam D. Ruppe wrote:
On Monday, 10 April 2017 at 23:16:48 UTC, Meta wrote:
My knee jerk reaction is that it's a very bad thing that "new"
means the same thing everywhere in the language (allocate and
initialize some GC-managed memory), except for this
On 4/10/2017 5:46 PM, Petar Kirov [ZombineDev] wrote:
Instead of adding new runtime helper functions like _d_newThrowable and
_d_delThrowable, can we leverage the existing (though deprecated) support for
class (de)allocators and essentially divide the _d_delThrowable implementation
between the de
On 4/10/2017 6:04 PM, Jonathan M Davis via Digitalmars-d wrote:
LOL. IIRC, there have been cases where you and/or Andrei have actually tried
to get folks to do specific stuff, and it generally hasn't worked. Pretty
much everything that gets done around here is because someone steps and does
it.
On Sunday, 9 April 2017 at 12:55:37 UTC, André wrote:
On Sunday, 9 April 2017 at 08:04:29 UTC, Ali Çehreli wrote:
On 04/08/2017 09:15 PM, Abhishek wrote:
tour.dlang.org is down
Confirmed down. :(
Ali
Hi guys. The tour is up again. I was aware of this and working
on it and hopefully I fixe
73 matches
Mail list logo
