On Tuesday, 25 January 2022 at 00:08:54 UTC, H. S. Teoh wrote:
This may work for x86, but does it work for other platforms? If
not, it won't fly on LDC/GDC.
I don't think there's anything wrong with d having its own ABI.
But, I checked arm and riscv: both of their c calling conventions
have
On Mon, Jan 24, 2022 at 10:56:57PM +, Elronnd via Digitalmars-d-announce
wrote:
> On Friday, 21 January 2022 at 12:55:58 UTC, ag0aep6g wrote:
> > I still believe it should be fairly simple:
> >
> > https://forum.dlang.org/post/ofc0lj$2u4h$1...@digitalmars.com
>
> There is a simpler solution:
On Friday, 21 January 2022 at 12:55:58 UTC, ag0aep6g wrote:
I still believe it should be fairly simple:
https://forum.dlang.org/post/ofc0lj$2u4h$1...@digitalmars.com
There is a simpler solution: put the context pointer in rax.
This is currently a caller-saved register, so there is no problem
On 21.01.22 13:55, ag0aep6g wrote:
On 21.01.22 13:33, Mike Parker wrote:
### Mathias
Mathias would very much like to see the unification of delegates and
function pointers. There was general agreement that this is a good
goal to aim for. Mathias subsequently informed me he will look into it
o
On 24.01.22 03:11, Mathias LANG wrote:
Actually, the idea I had in mind is a little different.
Because a delegate is essentially:
```D
T function (T, Args..)(void* ctx, Args args)
```
It should be possible for the compiler to generate a call to a
trampoline function that just forwards to the ac
On Friday, 21 January 2022 at 12:55:58 UTC, ag0aep6g wrote:
On 21.01.22 13:33, Mike Parker wrote:
### Mathias
Mathias would very much like to see the unification of
delegates and function pointers. There was general agreement
that this is a good goal to aim for. Mathias subsequently
informed
On Sunday, 23 January 2022 at 15:35:17 UTC, Paul Backus wrote:
The main benefit of having multiple versions available in
separate namespaces is that it allows them to coexist in the
same project, which means that users can migrate their code
incrementally from one to the other.
Yeah, I know t
On Sunday, 23 January 2022 at 14:53:21 UTC, Adam Ruppe wrote:
On Sunday, 23 January 2022 at 14:33:26 UTC, Paul Backus wrote:
Absolutely-no-breakage-ever is basically the C++ approach, and
I have already explained why I think it's a bad idea, though I
recognize that reasonable people can disagre
On Sunday, 23 January 2022 at 14:33:26 UTC, Paul Backus wrote:
Absolutely-no-breakage-ever is basically the C++ approach, and
I have already explained why I think it's a bad idea, though I
recognize that reasonable people can disagree on this point.
My view is it isn't worth shipping mixed ver
On Sunday, 23 January 2022 at 12:54:16 UTC, Adam D Ruppe wrote:
I'm not so sure. Isn't the whole point of the versioning thing
so you can use old things that haven't kept up with the latest?
When it was written, sure, they used import std because that's
easy and of course they want the lates
On Saturday, 22 January 2022 at 05:43:55 UTC, Paul Backus wrote:
`std.v1, std.v2`
We can like this:
`std->std2->std`,this is very convenient!
or like C++'s `/std:c++latest`.
On Sunday, 23 January 2022 at 04:12:30 UTC, H. S. Teoh wrote:
On Sun, Jan 23, 2022 at 03:24:04AM +, Paul Backus via
Digitalmars-d-announce wrote: [...]
The way I envision it, `std` would be the "rolling release"
namespace that allows breaking changes, and if you wanted
stability, you'd have
On Sunday, 23 January 2022 at 03:24:04 UTC, Paul Backus wrote:
The way I envision it, `std` would be the "rolling release"
namespace that allows breaking changes, and if you wanted
stability, you'd have to explicitly depend on `std.vN`. What we
currently call `std` would be renamed to `std.v1
On Sun, Jan 23, 2022 at 03:24:04AM +, Paul Backus via
Digitalmars-d-announce wrote:
[...]
> The way I envision it, `std` would be the "rolling release" namespace
> that allows breaking changes, and if you wanted stability, you'd have
> to explicitly depend on `std.vN`. What we currently call `
On Sunday, 23 January 2022 at 00:07:17 UTC, forkit wrote:
On Saturday, 22 January 2022 at 05:43:55 UTC, Paul Backus wrote:
(I think it would also be ideal if the namespace `std` were
reserved for the latest stable release...
wouldn't this prevent breaking changes from being allowed in a
new
On Sunday, 23 January 2022 at 00:07:17 UTC, forkit wrote:
I'd like to argue, that an introduction of 'phobos versioning' is
a good idea, but should not be allowed in D2, but would warrant a
D3 release.
In D3, std phobos would always be the latest and greatest. By
using D3, you agree to th
On Saturday, 22 January 2022 at 21:49:11 UTC, H. S. Teoh wrote:
Is undead versioned? If Phobos starts innovating again, we may
need to keep multiple old versions in undead for old codebases
to continue working.
T
Why multiple old versions? Can't we just have previous
implementation stored
On Saturday, 22 January 2022 at 05:43:55 UTC, Paul Backus wrote:
(I think it would also be ideal if the namespace `std` were
reserved for the latest stable release...
wouldn't this prevent breaking changes from being allowed in a
newer version of phobos?
by using phobos versioning, you're
On Sat, Jan 22, 2022 at 05:09:51PM +, Alexandru Ermicioi via
Digitalmars-d-announce wrote:
> On Saturday, 22 January 2022 at 05:43:55 UTC, Paul Backus wrote:
> > On Friday, 21 January 2022 at 12:33:25 UTC, Mike Parker wrote:
> > > ### Andrei
> > > Andrei brought up std.v2, but this is where me
On Saturday, 22 January 2022 at 05:43:55 UTC, Paul Backus wrote:
On Friday, 21 January 2022 at 12:33:25 UTC, Mike Parker wrote:
### Andrei
Andrei brought up std.v2, but this is where memory fails me.
What I do recall is that there was a bit of talk about the
std.v2 namespace and how it will li
On Friday, 21 January 2022 at 12:33:25 UTC, Mike Parker wrote:
### Andrei
Andrei brought up std.v2, but this is where memory fails me.
What I do recall is that there was a bit of talk about the
std.v2 namespace and how it will live alongside std, and this
came up because Robert isn't convinced
On Friday, 21 January 2022 at 12:33:25 UTC, Mike Parker wrote:
### Adam
Adam was unable to fully participate due to an issue with his
microphone. He did leave comments in the text chat, and he
noted that he was fine this time as an observer. We'll invite
him to future meetings when his mic is
On 21.01.22 13:33, Mike Parker wrote:
### Mathias
Mathias would very much like to see the unification of delegates and
function pointers. There was general agreement that this is a good goal
to aim for. Mathias subsequently informed me he will look into it once
some other things are off his TO
I had a severe case of user error going into our January meeting.
I had previously disabled audio input in OBS Studio for a project
I was working on. I then forgot to enable it when I recorded the
meeting. The text chat in Jitsi Meet, which I always make a point
to keep open when recording, pro
24 matches
Mail list logo
