Re: To all DConf speakers: please upload slides!

[jmh530 via Digitalmars-d-announce]

On Friday, 13 May 2016 at 15:24:22 UTC, Steven Schveighoffer 
wrote:


You only *need* the slides for when you can watch the talk. 
Having the slides beforehand may be confusing and unhelpful. 
This means there is no reason to provide the slides until the 
talk actually happens.


I almost want to say, if you need to see the presentation live, 
attend the conference :) In some past conferences, there were 
no live streams, and people survived. It's nice to have, but it 
somewhat removes the incentive to support the conference by 
attending.




Have you checked out some of the older DConf pages where the 
slides aren't still available? That's a little frustrating. In my 
opinion, it reflects poor organizational skills.


The best time to get the slides is before the presenter speaks. 
No slides, no speak. Also, if they need to make changes, they can 
always upload a newer version.

Re: Battle-plan for CTFE

[Jonathan M Davis via Digitalmars-d-announce]

On Wednesday, May 11, 2016 07:06:59 maik klein via Digitalmars-d-announce 
wrote:
> What is the current problem with ctfe?

The biggest problem is that it uses up a _lot_ of memory and is generally
slow. For instance, as I understand it, every time it mutates a variable, it
actually allocates a new one to hold the new state. This combined with the
fact that the compiler doesn't actually ever free memory (since it's
normally more efficient for it to work that way), and you risk running out
of memory while compiling. CTFE is a fantastic feature, but it evolved over
time rather than being designed up front, and it's suffered a lot because of
that. Don did a _lot_ of work to improve it, but he wasn't able to continue
working on it, and until now, no one has ever really stepped up to finish
the job. Don's post gives a good background on why CTFE is the way it is
and some of what he did to make it as solid as it is now:

http://forum.dlang.org/post/jmvsbhdpsjgeykpuk...@forum.dlang.org

But having someone like Stefan reimplement will be _huge_, and the D
community will be _very_ grateful.

- Jonathan M Davis

Re: To all DConf speakers: please upload slides!

[Ali Çehreli via Digitalmars-d-announce]

On 05/13/2016 08:24 AM, Steven Schveighoffer wrote:

> But then the slides provided online don't match the slides you are
> showing. That is not good.

Thanks to you, I've fixed my silly binary-tree mistake in one of my 
slides. My slides on dconf.org don't match the ones in the video. :)


Ali

Re: Battle-plan for CTFE

[Stefan Koch via Digitalmars-d-announce]

On Friday, 13 May 2016 at 13:59:57 UTC, Don Clugston wrote:


I think I need to explain the history of CTFE.
Originally, we had constant-folding. Then constant-folding was 
extended to do things like slicing a string at compile time. 
Constant folding leaks memory like the Exxon Valdez leaks oil, 
but that's OK because it only ever happens once.
Then, the constant folding was extended to include function 
calls, for loops, etc. All using the existing constant-folding 
code. Now the crappy memory usage is a problem. But it's OK 
because the CTFE code was kind of proof-of-concept thing anyway.


[...]


Thanks for the explanation, and for doing so much work on CTFE.


I would like to work on a solution that does scale.
The Problem is not making a byteCode-interpreter.
That part is relatively easy. Currently I am trying to get a 
detailed understanding of dmd and it's data-structures. (mainly 
it's AST.)


Generating the byte-code seems to be non-trivial.

I wonder in how far the glue layer can be of help...

Re: Battle-plan for CTFE

[Timon Gehr via Digitalmars-d-announce]

On 13.05.2016 15:59, Don Clugston wrote:

All that's needed is a very simple bytecode interpreter.


Here is the one I have hacked together:
https://github.com/tgehr/d-compiler/blob/master/interpret.d

This file does both constant folding and byte-code interpretation for 
most of the language. I still need to implement exception handling.


I'll let you know when it passes interpret3.d. :)

Re: To all DConf speakers: please upload slides!

[Steven Schveighoffer via Digitalmars-d-announce]

On 5/12/16 6:21 PM, Daniel Kozak via Digitalmars-d-announce wrote:

Dne 12.5.2016 v 22:55 Steven Schveighoffer via Digitalmars-d-announce
napsal(a):


On 5/12/16 4:13 PM, Seb wrote:

On Wednesday, 11 May 2016 at 09:17:54 UTC, Dicebot wrote:

To do the editing of HD videos we need presentation slides which are
currently scattered over different places. It would help a lot to have
them all in github.com/dlang/dlang.org repo - please submit pull
requests asap!


Just a minor complaint - would it be possible for the next dconf to have
the slides (or a link to them) on dconf.org before the talk starts?
Thanks for the great work!


I think it's better to not have the slides available until the talk
starts.


No, you are wrong. It would be really nice to have them. I would say it
was one of the biggest failures of dconf for people who can't attend.


You only *need* the slides for when you can watch the talk. Having the 
slides beforehand may be confusing and unhelpful. This means there is no 
reason to provide the slides until the talk actually happens.


I almost want to say, if you need to see the presentation live, attend 
the conference :) In some past conferences, there were no live streams, 
and people survived. It's nice to have, but it somewhat removes the 
incentive to support the conference by attending.



There may be jokes/surprises in the slides that you don't want to give
away before the talk happens :)



If there is anything you do not want to make available before talks. You
don't have to ;).


But then the slides provided online don't match the slides you are 
showing. That is not good.


-Steve

Re: To all DConf speakers: please upload slides!

[Steven Schveighoffer via Digitalmars-d-announce]

On 5/12/16 8:31 PM, Vladimir Panteleev wrote:

On Thursday, 12 May 2016 at 23:14:05 UTC, Leandro Lucarella wrote:

Steven Schveighoffer, el 12 de May a las 16:55 me escribiste:

On 5/12/16 4:13 PM, Seb wrote:
>On Wednesday, 11 May 2016 at 09:17:54 UTC, Dicebot wrote:
>>To do the editing of HD videos we need presentation slides >>which
are currently scattered over different places. It >>would help a lot
to have them all in >>github.com/dlang/dlang.org repo - please submit
pull >>requests asap!
>
>Just a minor complaint - would it be possible for the next >dconf to
have the slides (or a link to them) on dconf.org >before the talk
starts? Thanks for the great work!

I think it's better to not have the slides available until the talk
starts. There may be jokes/surprises in the slides that you don't
want to give away before the talk happens :)


Exactly, I would say it depends on the talk, for my talk I didn't want
to provide the slides beforehand ;-)


Here's a crazy idea: provide a simple/short URL to the slides as the
second slide of your talk (and speak out loud the URL just in case the
camera doesn't get it) :)


This is actually exactly what I did :)

-Steve

Re: Battle-plan for CTFE

[Don Clugston via Digitalmars-d-announce]

On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote:

Hi Guys,

I have been looking into the DMD now to see what I can do about 
CTFE.

Unfortunately It is a pretty big mess to untangle.
Code responsible for CTFE is in at least 3 files.
[dinterpret.d, ctfeexpr.d, constfold.d]
I was shocked to discover that the PowExpression actually 
depends on phobos! (depending on the exact codePath it may or 
may not compile...)


Yes. This is because of lowering. Walter said in his DConf talk 
that lowering was a success; actually, it's a quick-and-dirty 
hack that inevitably leads to a disaster.

Lowering always needs to be reverted.

which let to me prematurely stating that it worked at ctfe 
[http://forum.dlang.org/thread/ukcoibejffinknrbz...@forum.dlang.org]


My Plan is as follows.

Add a new file for my ctfe-interpreter and update it gradually 
to take more and more of the cases the code in the files 
mentioned above was used for.


Do Dataflow analysis on the code that is to be ctfe'd so we can 
tell beforehand if we need to store state in the ctfe stack or 
not.


You don't need dataflow analysis. The CtfeCompile pass over the 
semantic tree was intended to determine how many variables are 
required by each function.


Or baring proper data-flow analysis: RefCouting the variables 
on the ctfe-stack could also be a solution.


I will post more details as soon as I dive deeper into the code.


The current implementation stores persistent state for every 
ctfe incovation.
While caching nothing. Not even the compiled for of a function 
body.

Because it cannot relax purity.


No. Purity is not why it doesn't save the state. It's because of 
history.


I think I need to explain the history of CTFE.
Originally, we had constant-folding. Then constant-folding was 
extended to do things like slicing a string at compile time. 
Constant folding leaks memory like the Exxon Valdez leaks oil, 
but that's OK because it only ever happens once.
Then, the constant folding was extended to include function 
calls, for loops, etc. All using the existing constant-folding 
code. Now the crappy memory usage is a problem. But it's OK 
because the CTFE code was kind of proof-of-concept thing anyway.


Now, everyone asks, why doesn't it use some kind of byte-code 
interpreter or something?
Well, the reason is, it just wasn't possible. There was actually 
no single CTFE entry point. Instead, it was a complete mess. For 
example, with template arguments, the compiler would first try to 
run CTFE on the argument, with error messages suppressed. If that 
succeeded, it was a template value argument. If it generated 
errors, it would then see if was a type. If that failed as well, 
it assumed it was a template alias argument.
The other big problem was that CTFE was also often called on a 
function which had semantic errors.


So, here is what I did with CTFE:
(1) Implement all the functionality, so that CTFE code can be 
developed. The valuable legacy of this, which I am immensely 
proud of, is the file "interpret3.d" in the test suite. It is 
very comprehensive. If an CTFE implementation passes the test 
suite, it's good to go.
The CTFE implementation itself is practically worthless. It's 
value was to get the test suite developed.


(2) Created a single entry point for CTFE. This involved working 
out rules for every place that CTFE is actually required, 
removing the horrid speculative execution of CTFE.
It made sure that functions had actually been semantically 
analyzed before they were executed (there were really horrific 
cases where the function had its semantic tree modified while it 
was being executed!!)
Getting to this point involved about 60 pull requests and six 
months of nearly full-time work. Finally it was possible to 
consider a byte-code interpreter or JITer.


We reached this point around Nov 2012.

(3) Added a 'ctfeCompile' step which runs over the semantic tree 
the first time the function is executed at compile time. Right 
now it does nothing much except that check that the semantic tree 
is valid. This detected many errors in the rest of the compiler.


We reached this point around March 2013.

My intention was to extend the cfteCompile step to a byte-code 
generator. But then I had to stop working on it and concentrate 
on looking after my family.


Looking at the code without knowing the history, you'll think, 
the obvious way to do this would be with a byte-code generator or 
JITer, and wonder why the implementation is so horrible. But for 
most of the history, that kind of implementation was just not 
possible.
People come up with all these elaborate schemes to speed up CTFE. 
It's totally not necessary. All that's needed is a very simple 
bytecode interpreter.

Re: Adventures in D Programming

[Laeeth Isharc via Digitalmars-d-announce]

On Thursday, 12 May 2016 at 21:08:58 UTC, Matthias Klumpp wrote:
To elaborate a bit more on the version incompatibilities thing: 
E.g. me as a new user reads about std.concurrency.Generator, 
wants to use it, and it turns out that the standard library 
doesn't contain it yet (in GDC). Same for 
std.experimental.logger.

Okay, means I can't use these.


I haven't tried myself for these, but it might turn out to be not 
so much work just to copy the relevant files over and clean up 
the rough edges if you want to use these in GDC/LDC.  But I know 
that it's harder and a nuisance if you aren't that familiar with 
the language and just want to get your job done.


Then, I want to use D-YAML, which depends on std.stream. But 
std.stream is completely deprecated, with no clear path for me 
to see to replace it. That's really bad, and it also means I 
can't compile my code with making the use of deprecated stuff 
fail the compilation.


https://github.com/DigitalMars/undeaD/blob/master/src/undead/stream.d

You might want to submit a pull request so D-YAML depends on this 
(where removed parts of Phobos go to live) rather than std.stream.


That was by far the most frustrating things I experienced in D. 
So ideally the docs would be split for different Phobos 
versions, that would already be a great help. Then, when 
deprecating stuff, showing a thing that replaces it or the 
proper way to write code using it would also be really nice.


I agree.

It would actually be really awesome if Phobos wasn't tied to a 
compiler, and all D compilers which are standard-compliant 
could compile it. Then, one could assume that people have the 
most recent Phobos. But it looks like it will take a longer 
time to get there, if at all.


A matter of maturity and resources.  It's quite astonishing the 
value that the small number of people working on LDC and GDC have 
been able to create.  (DMD too, but there are more people).  
Maybe there ought to be a way to express concrete appreciation 
for their work.

Re: Adventures in D Programming

[Kagamin via Digitalmars-d-announce]

On Thursday, 12 May 2016 at 22:01:04 UTC, David Nadlinger wrote:

Are there any bug reports for this, by the way? Thanks!


I believe, it was the atomicOp bug. You can see the link to 
discussion there.

Re: To all DConf speakers: please upload slides!

[Rory McGuire via Digitalmars-d-announce]

On Thu, May 12, 2016 at 10:55 PM, Steven Schveighoffer via
Digitalmars-d-announce  wrote:

> On 5/12/16 4:13 PM, Seb wrote:
>
>> On Wednesday, 11 May 2016 at 09:17:54 UTC, Dicebot wrote:
>>
>>> To do the editing of HD videos we need presentation slides which are
>>> currently scattered over different places. It would help a lot to have
>>> them all in github.com/dlang/dlang.org repo - please submit pull
>>> requests asap!
>>>
>>
>> Just a minor complaint - would it be possible for the next dconf to have
>> the slides (or a link to them) on dconf.org before the talk starts?
>> Thanks for the great work!
>>
>
> I think it's better to not have the slides available until the talk
> starts. There may be jokes/surprises in the slides that you don't want to
> give away before the talk happens :)
>
> -Steve
>

Surely we should make it a requirement that slides are uploaded on the
dconf site, then make sure they only show once the talk starts.

I'd imagine its easier to get most of the admin stuff done before the
conference, because those involved are already busy with it.

Re: To all DConf speakers: please upload slides!

[Adrian Matoga via Digitalmars-d-announce]

On Wednesday, 11 May 2016 at 17:31:32 UTC, dilkROM wrote:
And also, if anyone can identify all lightning speakers, that 
would be terrific. We do need their slides and their names / 
desired nicknames / contact info as well. :)


I didn't use slides, but only a few code examples, collected in a 
text file that Andrei pasted here: 
http://dpaste.dzfl.pl/36e4c089d0d6