Wonderful quote from you Walter!
The careful reader will notice something peculiar in what I wrote: “as if”.
What do I mean by that weasel wording? Is there some skullduggery going on? Why
yes, there is. Computer languages are full of “as if” dirty deeds under the
hood, like the money you
On Monday, 15 July 2019 at 14:58:55 UTC, Mike Parker wrote:
In the Draft Review for Walter's DIP, Argument Ownership and
Function Calls (which in the next half hour or so will be
starting a community review as DIP 1021), some folks asked for
some information about the bigger picture. In
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.
[...]
Nice! I'm working on something similar but with
On Monday, 15 July 2019 at 20:57:59 UTC, Johannes Pfau wrote:
I don't see how "should be made public" can be interpreted as
"should be installed", especially considering that templates
need source code installed (core.internal), but that's
completely orthogonal to what functions should be
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.
Am Mon, 15 Jul 2019 20:39:14 + schrieb David Nadlinger:
> On Monday, 15 July 2019 at 20:27:16 UTC, Johannes Pfau wrote:
>> I guess this should be documented somewhere then.
>
> See druntime/CONTRIBUTING.md:
>
> ```
> In general, only modules in the 'core' package should be made public.
>
On Monday, 15 July 2019 at 20:27:16 UTC, Johannes Pfau wrote:
I guess this should be documented somewhere then.
See druntime/CONTRIBUTING.md:
```
In general, only modules in the 'core' package should be
made public. The single exception is the 'object' module
which is not in any package.
The
Am Mon, 15 Jul 2019 19:52:57 + schrieb David Nadlinger:
> On Monday, 15 July 2019 at 11:33:44 UTC, Mike Franklin wrote:
>> My understanding is the `rt` is the language implementation
>> and `core` is the low level library for users.
>
> This understanding would be mistaken. We haven't been
Am Mon, 15 Jul 2019 20:14:46 + schrieb David Nadlinger:
> On Monday, 15 July 2019 at 14:00:23 UTC, Mike Franklin wrote:
>> I'm sorry it broke digger, but digger is not how we typically build
>> DMD, druntime, and Phobos.
>
> Either way, there is a simple resolution here: Put new template
On Monday, 15 July 2019 at 19:41:11 UTC, Johannes Pfau wrote:
And duplicating extern(C) declarations, syncing them manually,
... is a safety liability and maintainance nightmare (see my
other post). So in no way should we start to add more such
functions interfacing rt to core.internal.
On Monday, 15 July 2019 at 14:00:23 UTC, Mike Franklin wrote:
I'm sorry it broke digger, but digger is not how we typically
build DMD, druntime, and Phobos.
It also breaks the LDC build system. Just shipping rt.* too by
itself would be simple, but as the frontend takes various
libraries when
On Monday, 15 July 2019 at 19:52:57 UTC, David Nadlinger wrote:
On Monday, 15 July 2019 at 11:33:44 UTC, Mike Franklin wrote:
My understanding is the `rt` is the language implementation
and `core` is the low level library for users.
This understanding would be mistaken. We haven't been
On Monday, 15 July 2019 at 11:33:44 UTC, Mike Franklin wrote:
My understanding is the `rt` is the language implementation
and `core` is the low level library for users.
This understanding would be mistaken. We haven't been shipping
`rt` on the import path for a long time. `core.internal`
Am Mon, 15 Jul 2019 17:59:25 + schrieb Seb:
> On Monday, 15 July 2019 at 14:00:23 UTC, Mike Franklin wrote:
>> On Monday, 15 July 2019 at 13:00:08 UTC, Vladimir Panteleev wrote:
>>
We are trying to implement many of those `extern(C)` runtime hooks as
templates. Those templates need
Am Mon, 15 Jul 2019 14:00:23 + schrieb Mike Franklin:
> On Monday, 15 July 2019 at 13:00:08 UTC, Vladimir Panteleev wrote:
>
>>> We are trying to implement many of those `extern(C)` runtime hooks as
>>> templates. Those templates need to be implicitly imported through
>>> object.d. That
Am Mon, 15 Jul 2019 12:27:22 + schrieb Vladimir Panteleev:
> On Monday, 15 July 2019 at 12:14:16 UTC, Mike Franklin wrote:
>> Many of the implementations in `rt/array` require importing or
>> referencing other implementations in `rt` (e.g. `rt.lifetime`).
>> If they were moved to
Am Mon, 15 Jul 2019 12:40:50 + schrieb Vladimir Panteleev:
> On Monday, 15 July 2019 at 12:36:14 UTC, Mike Franklin wrote:
>> Many of the implementations in `rt/array` are templates, so the entire
>> implementation should be available through object.d, not just
>> declarations.
>
> The
On Monday, 15 July 2019 at 14:00:23 UTC, Mike Franklin wrote:
On Monday, 15 July 2019 at 13:00:08 UTC, Vladimir Panteleev
wrote:
We are trying to implement many of those `extern(C)` runtime
hooks as templates. Those templates need to be implicitly
imported through object.d. That means code
The first round of Community Review for DIP 1021, "Argument
Ownership and Function Calls", has begun. To participate, please
visit the review thread for the details:
https://forum.dlang.org/post/voxipsuzjjmuffwlw...@forum.dlang.org
*Please leave all feedback in the review thread rather than
In the Draft Review for Walter's DIP, Argument Ownership and
Function Calls (which in the next half hour or so will be
starting a community review as DIP 1021), some folks asked for
some information about the bigger picture. In response, Walter
has put together a post outlining his current
On Monday, 15 July 2019 at 13:00:08 UTC, Vladimir Panteleev wrote:
We are trying to implement many of those `extern(C)` runtime
hooks as templates. Those templates need to be implicitly
imported through object.d. That means code that was in `rt`
is converted to a template, and then moved to
On Monday, 15 July 2019 at 13:27:39 UTC, Mike Franklin wrote:
I asked for input from other developers before moving forward.
They helped me understand that `rt` is where the core language
features are implemented.
Assuming it was the discussion linked in this thread, it did not
seem like
On Monday, 15 July 2019 at 13:06:58 UTC, Vladimir Panteleev wrote:
On Monday, 15 July 2019 at 12:42:57 UTC, Mike Franklin wrote:
... and are the exception, not the rule. I believe they
should be moved to `rt`.
BTW, from this discussion it seems to me that you did not have
a good overview of
On Monday, 15 July 2019 at 12:42:57 UTC, Mike Franklin wrote:
... and are the exception, not the rule. I believe they should
be moved to `rt`.
BTW, from this discussion it seems to me that you did not have a
good overview of the situation and made a bad decision based on
that. No problem
On Monday, 15 July 2019 at 12:57:46 UTC, Mike Franklin wrote:
On Monday, 15 July 2019 at 12:27:22 UTC, Vladimir Panteleev
wrote:
This isn't exactly true. The restriction is that core should
not *import* rt. Have a look at all the extern(C) definitions
in Druntime - using extern(C) functions
On Monday, 15 July 2019 at 12:27:22 UTC, Vladimir Panteleev wrote:
This isn't exactly true. The restriction is that core should
not *import* rt. Have a look at all the extern(C) definitions
in Druntime - using extern(C) functions to communicate between
the compiler and rt, as well as core and
On Monday, 15 July 2019 at 12:42:57 UTC, Mike Franklin wrote:
On Monday, 15 July 2019 at 12:40:50 UTC, Vladimir Panteleev
wrote:
- core.internal.hash contains the implementation of hashing
routines used for associative arrays.
- core.internal.arrayop contains the implementation of array
On Monday, 15 July 2019 at 12:36:14 UTC, Mike Franklin wrote:
Many of the implementations in `rt/array` are templates, so the
entire implementation should be available through object.d, not
just declarations.
The amount of templated code is still finite, otherwise you would
have needed to
On Monday, 15 July 2019 at 12:40:50 UTC, Vladimir Panteleev wrote:
- core.internal.hash contains the implementation of hashing
routines used for associative arrays.
- core.internal.arrayop contains the implementation of array
vector operations. This one doesn't seem to be too far from
your
On Monday, 15 July 2019 at 12:19:02 UTC, Vladimir Panteleev wrote:
You don't need to move the implementations themselves into
core.internal. Adding declarations there for the rt
implementations would suffice.
Many of the implementations in `rt/array` are templates, so the
entire
On Monday, 15 July 2019 at 12:14:16 UTC, Mike Franklin wrote:
Many of the implementations in `rt/array` require importing or
referencing other implementations in `rt` (e.g. `rt.lifetime`).
If they were moved to `core.internal` they would require
importing `rt` or peeking into `rt` with various
On Monday, 15 July 2019 at 12:14:16 UTC, Mike Franklin wrote:
On Monday, 15 July 2019 at 12:02:35 UTC, Seb wrote:
I think that fits core.internal better than rt. Have you
considered that during said discussion?
The implementations in `rt/array` contain templates that are
ports of runtime
On Monday, 15 July 2019 at 12:02:35 UTC, Seb wrote:
I think that fits core.internal better than rt. Have you
considered that during said discussion?
The implementations in `rt/array` contain templates that are
ports of runtime hooks that used to reside in `rt`. The
implementations also
On Monday, 15 July 2019 at 11:49:31 UTC, Vladimir Panteleev wrote:
On Monday, 15 July 2019 at 11:33:44 UTC, Mike Franklin wrote:
I discussed that briefly on Slack with a couple other
developers.
My understanding is the `rt` is the language implementation
and `core` is the low level library
On Monday, 15 July 2019 at 11:33:44 UTC, Mike Franklin wrote:
I discussed that briefly on Slack with a couple other
developers.
My understanding is the `rt` is the language implementation
and `core` is the low level library for users.
The code in `rt/array` are language implementations.
On Monday, 15 July 2019 at 10:52:08 UTC, Vladimir Panteleev wrote:
On Thursday, 4 July 2019 at 12:57:43 UTC, Mike Franklin wrote:
The copy should take place when building druntime from the
makefiles. The files to be copied are listed at
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.
Two of the highlights are the non-eponymous "member" and "iz"
templates, which are shown below with some code. The library also
includes the "from" template because I
On Friday, 5 July 2019 at 03:47:20 UTC, Jonathan M Davis wrote:
Yeah. I ran into the same problem with my own build tool. There
wasn't previously an rt folder in the imports. It was all
hidden in the implementation, and my build tool didn't copy it
over, resulting in confusing errors at first
On Thursday, 4 July 2019 at 12:57:43 UTC, Mike Franklin wrote:
The copy should take place when building druntime from the
makefiles. The files to be copied are listed at
https://github.com/dlang/druntime/blob/12bcb73da97a0c26aaf4b943eabd3c25051a89da/mak/COPY#L405-L408 and, for Windows, should
39 matches
Mail list logo
