Re: Beta D 2.071.2-b3

[ketmar via Digitalmars-d-announce]

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 designed to serve the human, not 
vice versa? yet somehow we all trying to make our machines happy 
now, instead of using 'em.


the most funny thing with it is that modern software is bloated, 
dog slow, resource hungry and barely usable. so all this "please 
the machine" movement is completely pointless!

Re: [GSoC] Precise GC

[thedeemon via Digitalmars-d-announce]

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 precise GC is here:
https://github.com/dlang/druntime/pull/1603


So what's its current state, how is it different from the version 
Rainer had years ago? Is stack scan precise? Are closures scanned 
precisely? What about unions? We'd be happy to see some overview 
of this version, what it does and how it succeeds (or fails).

Re: [GSoC] Precise GC

[rikki cattermole via Digitalmars-d-announce]

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://github.com/dlang/druntime/pull/1603

Even though GSoC is over and it isn't quite ready to be merged, I will
still continue working on it in the hopes it'll get in. I have about a
month until school starts up again, and I'm going to try to get it
merged before that point.

Through the work I did and the research of a couple of GC topics, I
discovered that I really enjoyed working on the garbage collector and I
plan on continuing that. I was recently accepted to the University of
Washington's computer science program and I am currently working on
getting some independent study classes set up for future GC work. Once I
have some better programming chops I'm hoping to help take D's GC to new
heights.

Thanks to Martin Nowak and Adam Wilson for being my mentors and for
keeping me going, to Rainer Schuetze for doing a significant portion of
code review, and to the D community for giving me the opportunity to do
this work.

Jeremy


Awesome, please do keep going with it! It would be great over the next 
few years to get some research papers out of this.

Re: [GSoC] Precise GC

[Dsby via Digitalmars-d-announce]

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

[GSoC] Precise GC

[Jeremy DeHaan via Digitalmars-d-announce]

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 though GSoC is over and it isn't quite ready to be merged, I 
will still continue working on it in the hopes it'll get in. I 
have about a month until school starts up again, and I'm going to 
try to get it merged before that point.


Through the work I did and the research of a couple of GC topics, 
I discovered that I really enjoyed working on the garbage 
collector and I plan on continuing that. I was recently accepted 
to the University of Washington's computer science program and I 
am currently working on getting some independent study classes 
set up for future GC work. Once I have some better programming 
chops I'm hoping to help take D's GC to new heights.


Thanks to Martin Nowak and Adam Wilson for being my mentors and 
for keeping me going, to Rainer Schuetze for doing a significant 
portion of code review, and to the D community for giving me the 
opportunity to do this work.


Jeremy

Re: Joakim Intreviews Walter for the D Blog

[Mike Parker via Digitalmars-d-announce]

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 modified version of one of the stock Wordpress themes. I 
tweaked it to have a bit of a larger font, but it's a responsive 
theme with settings for multiple resolutions and it's possible I 
missed something (I'd really love to have someone with lots of 
CSS experience to maintain the theme full-time -- it's just not 
my thing).


Otherwise, font family and size are both highly subjective and 
I'm not inclined to change it unless I get a mass of complaints 
about it. You can always increase the size in your browser (like 
Ctrl + mouse wheel in Chrome, which will remember it).

Re: Battle-plan for CTFE

[ag0aep6g via Digitalmars-d-announce]

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();
mixin(ret);
}


string ctfefunc() {
static if (!assertCTFE!true) {
throw new Exception("Only during ctfe please...");
}
return `import std.stdio; writeln("ctfe generated this");`;
}

template assertCTFE(bool b) {
enum assertCTFE = __traits(compiles, _checkCTFE1());
}
void _checkCTFE1() {
static if (__ctfe) {

}
}


It's not clear to me what this example is supposed to show. In 
particular, how does it relate to catching CTFE errors?


Obviously, `static if (__ctfe)` doesn't compile right now, so 
_checkCTFE1 must be rejected regardless of anything else. And with 
_checkCTFE1, the whole program goes down.


Your code looks like it's supposed to throw an exception when ctfefunc 
is called during normal run-time instead of CTFE. That can be done:



string ctfefunc()
{
if (!__ctfe) throw new Exception("Only during ctfe please...");
return `import std.stdio; writeln("ctfe generated this");`;
}


But I feel like that's missing the point of the example.

Re: Battle-plan for CTFE

[David Nadlinger via Digitalmars-d-announce]

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 semantic analysis as required.


__traits(compiles, _some_function_that_calls_), thinks that the 
invalid code compiles even when it doesn't compile […]


No, you are missing the point. This:

---
void foo() {
  @#$!
}
---

will always cause a compiler error, regardless of whether there 
is a `__traits(compiles, foo())` somewhere else in the module. 
__traits(compiles, …) only applies to its argument and doesn't 
magically cause errors in code somewhere else to be ignored.


 — David

Re: Battle-plan for CTFE

[H. S. Teoh via Digitalmars-d-announce]

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
> > this patch __ctfeWriteln() will output every compiletime avilable
> > string to the console.
> 
> More crucially, it also allows you to print runtime values during
> CTFE.  pragma(msg, …) suffices to print compile-time constants. Very
> few people seem to have the correct mental model for the the
> interaction between compile-time features and CTFE, hence I think
> using precise terminology is an important first step.
[...]

Part of the problem is that the term "compile-time" is ambiguous. In the
compilation of a D program, there are (at least) 2 distinct phases that
may be termed "compile-time": (1) expansion of templates and evaluation
of static-if, and (2) CTFE.

Phase (1) conceptually happens before the AST is finalized, and hence at
this stage it makes no sense to refer to variables and such: variables
don't even exist yet because the syntax tree of the program is still
being manipulated.

Phase (2) happens just as the compiler is ready to emit object code: the
AST has been finalized, symbols have been resolved, statements have been
analysed / lowered, etc.. At this stage, static-if no longer makes any
sense because the AST can no longer be manipulated at this point.

Of course, the above is a simplified picture of what actually happens.
In a complex D program, you *can* have phase (2) precede phase (1),
e.g., using static-if on the result of a CTFE function. The important
thing to note here, though, is that the CTFE function's body must
already be in phase (2), because otherwise CTFE is impossible. So
another part of the code can depend on the result of the CTFE function,
but the function itself is already past phase (1) and you can't change
its AST anymore.  So you can have different parts of the program be in
different phases, and they can have interdependencies, but the same
piece of code can only progress from phase (1) to phase (2), and never
the other way around.

Referring to both phases as "compile-time" is ambiguous and causes
confusion to people who are not familiar with how the compilation
process actually works.


T

-- 
Windows: the ultimate triumph of marketing over technology. -- Adrian von Bidder

Re: Beta D 2.071.2-b3

[Johan Engelen via Digitalmars-d-announce]

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 know who accesses 
sth.


"lots of optimizations"
Can you mention a few?


I'm not sure optimizations are had by private variables. Some 
optimizations can be had because the compiler can prove a 
variable could not have been changed. But I don't know that 
private suits that need, it's more due to const or immutable.


Yep.
I was trying to be polite :-)

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

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 doesn't compile in the first
> place, even without attempting any CTFE.
>
> [...]
>
>> Surely the ctfe engine could be changed to catch unsupported code
>> errors. (Not invalid, just unsupported at CT).
>>
>
> Maybe. It isn't obvious to me that it would be a good idea, but it's not
> obviously terrible either.
>
> The ctfe engine would have to "go past" the try anyway, right? This is
>> the part I don't understand. Is it because ctfe actually hasn't started
>> yet and some other analysis is freaking out?
>>
>
> It's just a compiler error. The snippet on its own fails compilation and
> there is no CTFE in there. Something like `static assert(_checkCTFE());`
> would involve CTFE. But that's not needed to trigger the error.
>



Yeah, I'm using an enum to force the evaluation during CT, and its dying
before CTFE from what I can tell. Here is another example:

void main() {
enum ret = ctfefunc();
mixin(ret);
}


string ctfefunc() {
static if (!assertCTFE!true) {
throw new Exception("Only during ctfe please...");
}
return `import std.stdio; writeln("ctfe generated this");`;
}

template assertCTFE(bool b) {
enum assertCTFE = __traits(compiles, _checkCTFE1());
}
void _checkCTFE1() {
static if (__ctfe) {

}
}

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

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 changed to catch unsupported code errors.
>> (Not invalid, just unsupported at CT).
>>
>
> It already does, see above. How is this related to try/catch?
>
>  — David
>

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.

__traits(compiles, _some_function_that_calls_), thinks that the invalid
code compiles even when it doesn't compile, e.g.:

template assertCTFE(bool b) {
enum assertCTFE = __traits(compiles, _checkCTFE1());
}
void _checkCTFE1() {
static if (__ctfe) { // this still stops compilation (probably because this
is checked before __traits(compiled ...) is evaluated

}
}

Re: Battle-plan for CTFE

[ag0aep6g via Digitalmars-d-announce]

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 catch unsupported code
errors. (Not invalid, just unsupported at CT).


Maybe. It isn't obvious to me that it would be a good idea, but it's not 
obviously terrible either.



The ctfe engine would have to "go past" the try anyway, right? This is
the part I don't understand. Is it because ctfe actually hasn't started
yet and some other analysis is freaking out?


It's just a compiler error. The snippet on its own fails compilation and 
there is no CTFE in there. Something like `static assert(_checkCTFE());` 
would involve CTFE. But that's not needed to trigger the error.

Re: Battle-plan for CTFE

[Stefan Koch via Digitalmars-d-announce]

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.

Re: Battle-plan for CTFE

[David Nadlinger via Digitalmars-d-announce]

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, see above. How is this related to try/catch?

 — David

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

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 runtime exceptions ("throw …") with compiler errors
(missing a semicolon). dm.D.learn should be able to help clear that up.
>
>  — David

I'm actually asking why we can't catch the ctfe error. It's quite obvious
that it is a temporary limitation of ctfe, there have been many limitations
removed over the years.

Surely the ctfe engine could be changed to catch unsupported code errors.
(Not invalid, just unsupported at CT).

The ctfe engine would have to "go past" the try anyway, right? This is the
part I don't understand. Is it because ctfe actually hasn't started yet and
some other analysis is freaking out?

Re: Beta D 2.071.2-b3

[Steven Schveighoffer via Digitalmars-d-announce]

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 not sure optimizations are had by private variables. Some 
optimizations can be had because the compiler can prove a variable could 
not have been changed. But I don't know that private suits that need, 
it's more due to const or immutable.



(I can only think of complicated stuff that requires pretty much
whole-program analysis to prove validity, and in that case adding
`private` doesn't help any more)


Where I see private helping is conceptual -- I know that if a variable 
is private, I can narrow to a given module all the places the variable 
might be read or written. If you just allow private access via anywhere, 
it defeats that analysis.


-Steve

Re: Battle-plan for CTFE

[David Nadlinger via Digitalmars-d-announce]

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, it also allows you to print runtime values during 
CTFE. pragma(msg, …) suffices to print compile-time constants. 
Very few people seem to have the correct mental model for the the 
interaction between compile-time features and CTFE, hence I think 
using precise terminology is an important first step.


See also: https://github.com/dlang/dmd/pull/692 – it's about time 
we finally got __ctfeWrite() merged.


 — David

Re: Battle-plan for CTFE

[Stefan Koch via Digitalmars-d-announce]

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 __ctfeWriteln() will output every 
compiletime avilable string to the console.

It's a little bit nicer then using pragma(msg);

Re: Battle-plan for CTFE

[David Nadlinger via Digitalmars-d-announce]

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.


 — David

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

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 reasons why this proposal couldn't work
> to Stefan here: https://github.com/dlang/dmd/p
> ull/6098#issuecomment-243375543
>
> The real reason is not so much in the pass structure of the compiler as in
> the fact that CTFE by definition executes the same function body that is
> also emitted to the runtime binary.
>
>  — David
>

okay thanks, I'll take a look at the link.

Question: if the function runs the same, why can't I catch the exception?
>From what Stefan said even if I could catch the exception static if still
wouldn't compile different code.

bool _checkCTFE() {
try {
import std.uuid;
enum id = new UUID("8AB3060E-2cba-4f23-b74c-b52db3bdfb46");
return false;
} catch (Throwable t) {
return true;
}
}

The above still fails during CTFE, compiler just exists with:
enforceCTFE.d(20): Error: variable enforceCTFE._checkCTFE.id : Unable to
initialize enum with class or pointer to struct. Use static const variable
instead.


So why can't we even catch the Error during CTFE, that would at least help
somewhat.

At the moment I just have a verbose logging mode with pragma(msg) for my
CTFE stuff.

Re: Battle-plan for CTFE

[David Nadlinger via Digitalmars-d-announce]

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 is not so much in the pass structure of the 
compiler as in the fact that CTFE by definition executes the same 
function body that is also emitted to the runtime binary.


 — David

Re: Joakim Intreviews Walter for the D Blog

[Seb via Digitalmars-d-announce]

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 anticipate 
publishing more of Joakim's interviews on the blog in the 
future.


[1] 
https://dlang.org/blog/2016/08/30/ruminations-on-d-an-interview-with-walter-bright/
[2] 
https://www.reddit.com/r/programming/comments/50aox1/ruminations_on_d_an_interview_with_walter_bright/


Good write-up. However the font-family and font-size makes 
reading a little difficult.


FYI: You can fix it directly 
(https://github.com/dlang/D-Blog-Theme) or open an issue there 
too ;-)

Re: Joakim Intreviews Walter for the D Blog

[Karabuta via Digitalmars-d-announce]

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 the future.


[1] 
https://dlang.org/blog/2016/08/30/ruminations-on-d-an-interview-with-walter-bright/
[2] 
https://www.reddit.com/r/programming/comments/50aox1/ruminations_on_d_an_interview_with_walter_bright/


Good write-up. However the font-family and font-size makes 
reading a little difficult.

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

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 current implementation does not respect
>> __traits(compiles, );
>>
>>
>>
>> As far as I can tell that is a bug. Thoughts?
>>
>
> It is not a bug, because there is no way to mark something as CTFE-only.
> static ifs are not visible at the time where ctfe sees the function, they
> have already been resolved.
>
> getting a static if (__ctfe) to work would require significant changes to
> the semantic-analysis path for functions.
>


Ah, right, understood.


is that in one of the "semantic" passes the compiler has?

Re: Battle-plan for CTFE

[Stefan Koch via Digitalmars-d-announce]

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 a bug, because there is no way to mark something as 
CTFE-only.
static ifs are not visible at the time where ctfe sees the 
function, they have already been resolved.


getting a static if (__ctfe) to work would require significant 
changes to the semantic-analysis path for functions.

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

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 that makes it possible to
>>> ensure that a function is _only_ used at ctfe.
>>> Or the opposite.
>>>
>>> static assert(__ctfe, "This function is not supposed to be called
>>> outside of ctfe");
>>> and static assert(!__ctfe, "This function is not supposed to be called
>>> during ctfe");
>>>
>>> similarly you can use static if (__ctfe).
>>>
>>> Is it worth trying to get it into master ?
>>>
>>
>> Yes, please. I've often wished I could use `__ctfe` in a `static if`.
>>
>
> Sorry. It I overlooked a something rather important. static __ctfe is
> currently not possible and it's rather expensive to make it possible.
>


Surely changing the current implementation slightly could still work if we
made a library implementation like:


// ? module std.exception.enforce_ctfe;

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(compiles, _checkCTFE());
}
void _checkCTFE() {
import std.uuid;
enum id = new UUID("8AB3060E-2cba-4f23-b74c-b52db3bdfb46");
}


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?

Re: Beta D 2.071.2-b3

[Dicebot via Digitalmars-d-announce]

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 traits allMember, getMember, derivedMember and
>> getOverloads.
> 
> Well there was reasoning to choose that solution instead of the other
> (https://github.com/dlang/dmd/pull/6078) and the fact that private
> members aren't accessible (set/get) is a good indication that nobody
> needs this.
> Adding an unsafe facility to access private members is a separate
> problem, but please see the changelog for how to achieve this already by
> mixing in templates.

I think such change is not appropriate in a point release, not matter if
it is going to happen or not.



signature.asc
Description: OpenPGP digital signature

Re: Beta release vibe.d 0.7.30-beta.1

[Suliman via Digitalmars-d-announce]

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/blob/master/CHANGELOG.md

DUB package:
http://code.dlang.org/packages/vibe-d/0.7.30-beta.1

[1]: http://code.dlang.org/packages/vibe-sdlang

[2]: http://code.dlang.org/packages/diet-ng

Nice to read on the ongoing progress!

Can you give a road map of what will be next, may be as an 
interview to

the D Blog?


My intention was to write something up since DConf this year, I 
just didn't manage to do it so far (the last months were 
extremely busy with other things). But it's still on the TODO 
list.



When do you think vibe's version will be 1.0.0?


I'm currently still working on vibe-core [1], which will be the 
1.0.0 of the core parts of the current vibe-d package. The API 
is more or less backwards compatible, but the insides have been 
thoroughly redesigned based on the experiences and language 
changes of the past years. I hope to get that into beta in 
weeks to (few) months and it is more or less just held back by 
the final decision for an event loop abstraction.


Similarly, diet-ng will be the 1.0.0 of the Diet template 
render module. The rest of the sub packages will get the same 
treatment once vibe-core is done. From then on, they will all 
receive their own individual version numbers, according to 
their particular development pace.


[1]: https://github.com/vibe-d/vibe-core


It's not problem with backward compatibility. Much important is 
easy to use and good docs.

Re: Beta release vibe.d 0.7.30-beta.1

[Sönke Ludwig via Digitalmars-d-announce]

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/vibe-d/0.7.30-beta.1

[1]: http://code.dlang.org/packages/vibe-sdlang

[2]: http://code.dlang.org/packages/diet-ng

Nice to read on the ongoing progress!

Can you give a road map of what will be next, may be as an interview to
the D Blog?


My intention was to write something up since DConf this year, I just 
didn't manage to do it so far (the last months were extremely busy with 
other things). But it's still on the TODO list.



When do you think vibe's version will be 1.0.0?


I'm currently still working on vibe-core [1], which will be the 1.0.0 of 
the core parts of the current vibe-d package. The API is more or less 
backwards compatible, but the insides have been thoroughly redesigned 
based on the experiences and language changes of the past years. I hope 
to get that into beta in weeks to (few) months and it is more or less 
just held back by the final decision for an event loop abstraction.


Similarly, diet-ng will be the 1.0.0 of the Diet template render module. 
The rest of the sub packages will get the same treatment once vibe-core 
is done. From then on, they will all receive their own individual 
version numbers, according to their particular development pace.


[1]: https://github.com/vibe-d/vibe-core