Am 31.08.2016 um 16:56 schrieb Martin Tschierschke:
On Wednesday, 31 August 2016 at 09:00:47 UTC, Sönke Ludwig wrote:
Am 31.08.2016 um 10:57 schrieb Sönke Ludwig:
[...]
All changes:
https://github.com/rejectedsoftware/vibe.d/blob/master/CHANGELOG.md
DUB package:
http://code.dlang.org/packages
On Thursday, 1 September 2016 at 07:32:43 UTC, Sönke Ludwig wrote:
Am 31.08.2016 um 16:56 schrieb Martin Tschierschke:
On Wednesday, 31 August 2016 at 09:00:47 UTC, Sönke Ludwig
wrote:
Am 31.08.2016 um 10:57 schrieb Sönke Ludwig:
[...]
All changes:
https://github.com/rejectedsoftware/vibe.d/b
On 08/31/2016 02:08 AM, Martin Nowak wrote:
> On Tuesday, 30 August 2016 at 21:58:05 UTC, Basile B. wrote:
>> I'm a bit sad to see that
>> https://issues.dlang.org/show_bug.cgi?id=15371 was completely ignored
>> to fix issue 15907. Another decision could have been to break the
>> visibility for the
On Wed, Aug 31, 2016 at 10:43 PM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Tuesday, 30 August 2016 at 22:01:45 UTC, tsbockman wrote:
>
>> On Monday, 29 August 2016 at 08:39:56 UTC, Stefan Koch wrote:
>>
>>> I just came up with a nifty little patch
On Thursday, 1 September 2016 at 13:18:18 UTC, Rory McGuire wrote:
the _checkCTFE() function is just a function that does
something we're not
allowed to do at CTFE, but current implementation does not
respect
__traits(compiles, );
As far as I can tell that is a bug. Thoughts?
It is not
On Thu, Sep 1, 2016 at 6:29 PM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Thursday, 1 September 2016 at 13:18:18 UTC, Rory McGuire wrote:
>
>> the _checkCTFE() function is just a function that does something we're not
>> allowed to do at CTFE, but c
On Tuesday, 30 August 2016 at 11:50:52 UTC, Mike Parker wrote:
Joakim has put together an interview with Walter that's all
about D. It's an enjoyable read. You can parse the interview at
[1] and visit the reddit thread at [2]. I anticipate publishing
more of Joakim's interviews on the blog in t
On Thursday, 1 September 2016 at 16:52:41 UTC, Karabuta wrote:
On Tuesday, 30 August 2016 at 11:50:52 UTC, Mike Parker wrote:
Joakim has put together an interview with Walter that's all
about D. It's an enjoyable read. You can parse the interview
at [1] and visit the reddit thread at [2]. I ant
On Thursday, 1 September 2016 at 16:43:53 UTC, Rory McGuire wrote:
is that in one of the "semantic" passes the compiler has?
For reference, I've laid out the reasons why this proposal
couldn't work to Stefan here:
https://github.com/dlang/dmd/pull/6098#issuecomment-243375543
The real reason
On Thursday, 1 September 2016 at 13:18:18 UTC, Rory McGuire wrote:
void main() {
ctfefunc();
}
string ctfefunc() {
static if (assertCTFE!true) {
throw new Exception("asdf");
}
return `import std.stdio; writeln("ctfe generated this");`;
}
template assertCTFE(bool b) {
enum assertCTFE = __traits
On Thu, Sep 1, 2016 at 9:09 PM, David Nadlinger via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Thursday, 1 September 2016 at 16:43:53 UTC, Rory McGuire wrote:
>
>> is that in one of the "semantic" passes the compiler has?
>>
>
> For reference, I've laid out the reas
On Thursday, 1 September 2016 at 19:27:17 UTC, Rory McGuire wrote:
So why can't we even catch the Error during CTFE, that would at
least help somewhat.
You are mixing up runtime exceptions ("throw …") with compiler
errors (missing a semicolon). dm.D.learn should be able to help
clear that up.
On Thursday, 1 September 2016 at 19:27:17 UTC, Rory McGuire wrote:
At the moment I just have a verbose logging mode with
pragma(msg) for my
CTFE stuff.
I have something that will help with that a little bit.
https://github.com/UplinkCoder/dmd/tree/__ctfeWriteln
when you apply this patch __c
On Thursday, 1 September 2016 at 19:38:13 UTC, Stefan Koch wrote:
I have something that will help with that a little bit.
https://github.com/UplinkCoder/dmd/tree/__ctfeWriteln
when you apply this patch __ctfeWriteln() will output every
compiletime avilable string to the console.
More crucially
On 8/31/16 5:56 AM, Johan Engelen wrote:
On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote:
Allowing access to private members has a lot of implications, e.g.
breaks lots of optimizations b/c you can't know who accesses sth.
"lots of optimizations"
Can you mention a few?
I'm no
On 01 Sep 2016 21:36, "David Nadlinger via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Thursday, 1 September 2016 at 19:27:17 UTC, Rory McGuire wrote:
>>
>> So why can't we even catch the Error during CTFE, that would at least
help somewhat.
>
>
> You are mixing up
On Thursday, 1 September 2016 at 21:01:46 UTC, Rory McGuire wrote:
I'm actually asking why we can't catch the ctfe error.
You can, by using __traits(compiles, …).
Surely the ctfe engine could be changed to catch unsupported
code errors. (Not invalid, just unsupported at CT).
It already does
On Thursday, 1 September 2016 at 20:43:16 UTC, David Nadlinger
wrote:
See also: https://github.com/dlang/dmd/pull/692 – it's about
time we finally got __ctfeWrite() merged.
— David
Oh yeah.
Let me get this into PR shape.
On 09/01/2016 11:01 PM, Rory McGuire via Digitalmars-d-announce wrote:
I'm actually asking why we can't catch the ctfe error.
There is no CTFE error in your example. It doesn't compile in the first
place, even without attempting any CTFE.
[...]
Surely the ctfe engine could be changed to cat
On Thu, Sep 1, 2016 at 11:05 PM, David Nadlinger via Digitalmars-d-announce
wrote:
> On Thursday, 1 September 2016 at 21:01:46 UTC, Rory McGuire wrote:
>
>> I'm actually asking why we can't catch the ctfe error.
>>
>
> You can, by using __traits(compiles, …).
>
> Surely the ctfe engine could be c
On Thu, Sep 1, 2016 at 11:26 PM, ag0aep6g via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On 09/01/2016 11:01 PM, Rory McGuire via Digitalmars-d-announce wrote:
>
>> I'm actually asking why we can't catch the ctfe error.
>>
>
> There is no CTFE error in your example. It
On Thursday, 1 September 2016 at 20:46:50 UTC, Steven
Schveighoffer wrote:
On 8/31/16 5:56 AM, Johan Engelen wrote:
On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote:
Allowing access to private members has a lot of implications,
e.g.
breaks lots of optimizations b/c you can't kno
On Thu, Sep 01, 2016 at 08:43:16PM +, David Nadlinger via
Digitalmars-d-announce wrote:
> On Thursday, 1 September 2016 at 19:38:13 UTC, Stefan Koch wrote:
> > I have something that will help with that a little bit.
> > https://github.com/UplinkCoder/dmd/tree/__ctfeWriteln when you apply
> > t
On Thursday, 1 September 2016 at 21:48:41 UTC, Rory McGuire wrote:
I was hoping that the error was coming from the CTFE engine as
it ran the code, but it comes up before ctfe execution I guess.
As a general comment, there is no such thing as a CTFE phase. It
is performed in-line with other sem
On 09/01/2016 11:51 PM, Rory McGuire via Digitalmars-d-announce wrote:
Yeah, I'm using an enum to force the evaluation during CT,
I had missed that detail. Still, the error seems to be independent of
any CTFE that's going on.
[...]
Here is another example:
void main() {
enum ret = ctfefunc
On Thursday, 1 September 2016 at 16:52:41 UTC, Karabuta wrote:
Good write-up. However the font-family and font-size makes
reading a little difficult.
The font family is the same as the rest of dlang.org. As for the
size, what sort of device and resolution are you using? The theme
is a modi
Hi everyone,
I know I'm super late to the party for this, and sorry for that.
While my work on the precise GC didn't go as planned, it is
closer than it was to be getting merged.
My open PR for the actual inclusion of the precise GC is here:
https://github.com/dlang/druntime/pull/1603
Even t
On Friday, 2 September 2016 at 03:25:33 UTC, Jeremy DeHaan wrote:
Hi everyone,
I know I'm super late to the party for this, and sorry for
that. While my work on the precise GC didn't go as planned, it
is closer than it was to be getting merged.
[...]
wait for merge
On 02/09/2016 3:25 PM, Jeremy DeHaan wrote:
Hi everyone,
I know I'm super late to the party for this, and sorry for that. While
my work on the precise GC didn't go as planned, it is closer than it was
to be getting merged.
My open PR for the actual inclusion of the precise GC is here:
https://g
On Friday, 2 September 2016 at 03:25:33 UTC, Jeremy DeHaan wrote:
Hi everyone,
I know I'm super late to the party for this, and sorry for
that. While my work on the precise GC didn't go as planned, it
is closer than it was to be getting merged.
My open PR for the actual inclusion of the prec
On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote:
Allowing access to private members has a lot of implications,
e.g. breaks lots of optimizations b/c you can't know who
accesses sth.
i really HATE modern trend of turning tables. am i the only one
who thinks that the machine was
On 02 Sep 2016 07:40, "ketmar via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote:
>>
>> Allowing access to private members has a lot of implications, e.g.
breaks lots of optimizations b/c you can't know who a
On Friday, 2 September 2016 at 06:27:11 UTC, Rory McGuire wrote:
Perhaps @system code should just completely ignore privacy?
it is uncontrollable. imagine attribute inference: today, your
function was inferred @system, and it sees everything. and
tomorrow you fixed some other things, and now
On 09/01/2016 08:25 PM, Jeremy DeHaan wrote:
> I will still continue working on it in the hopes it'll get in.
Great news! :)
> I
> discovered that I really enjoyed working on the garbage collector
If that's not motivation enough...
> I was recently accepted to the University of Washington's
>
34 matches
Mail list logo
