www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DConf 2013 last talk

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
I'll answer community questions in my last talk at DConf 2013, which is 
about 24 hours from now. Please send yours here or on Twitter #dconf.

Andrei
May 02 2013
next sibling parent reply "Joseph Cassman" <jc7919 outlook.com> writes:
On Thursday, 2 May 2013 at 23:59:48 UTC, Andrei Alexandrescu 
wrote:

 I'll answer community questions in my last talk at DConf 2013, 
 which is about 24 hours from now. Please send yours here or on 
 Twitter #dconf.

 Andrei


If you could provide an update on the allocators design and 
implementation -- progress and/or roadmap -- that would be great. 
Also if there are any plans to update std.container as a result.

Are there any plans to incorporate some of the ideas in the two 
talks about GC at the conference (or other ideas regarding GC)?

What are the plans for ARM short or long-term?

Thanks!

Joseph
May 02 2013
next sibling parent reply d coder <dlang.coder gmail.com> writes:
On Fri, May 3, 2013 at 5:41 AM, Joseph Cassman <jc7919 outlook.com> wrote:


 If you could provide an update on the allocators design and implementation
 -- progress and/or roadmap -- that would be great. Also if there are any
 plans to update std.container as a result.


+1

And another one. I am working on an embedded DSL on top of D Language. I am
using compile time parser ctpg https://github.com/youkei/ctpg for some
syntax parsing. It works great, expect for memory footprint of the compiler
which makes it impractical to parse any 1000+ lines of code at compile time.

So the question is -- What are the plans to optimize the compiler from
memory perspective? I know that the GC is disabled at compile time to make
the compiler as fast as possible. Can we think about adding a switch to dmd
to optionally enable the GC? This is not going to change the
functional behavior of the compiler and so we can give an option to the
end-user to enable the switch when compile time footprint is becoming an
issue.

Regards
- Puneet
May 02 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/2/13 9:10 PM, d coder wrote:

 And another one. I am working on an embedded DSL on top of D Language. I
 am using compile time parser ctpg https://github.com/youkei/ctpg for
 some syntax parsing. It works great, expect for memory footprint of the
 compiler which makes it impractical to parse any 1000+ lines of code at
 compile time.

 So the question is -- What are the plans to optimize the compiler from
 memory perspective?


This is an important issue. I'll touch on it only at a higher level when 
discussing quality of implementation.

Andrei
May 03 2013
parent reply "Rob T" <alanb ucora.com> writes:
On Friday, 3 May 2013 at 17:27:39 UTC, Andrei Alexandrescu wrote:

 On 5/2/13 9:10 PM, d coder wrote:

 And another one. I am working on an embedded DSL on top of D 
 Language. I
 am using compile time parser ctpg 
 https://github.com/youkei/ctpg for
 some syntax parsing. It works great, expect for memory 
 footprint of the
 compiler which makes it impractical to parse any 1000+ lines 
 of code at
 compile time.

 So the question is -- What are the plans to optimize the 
 compiler from
 memory perspective?


 This is an important issue. I'll touch on it only at a higher 
 level when discussing quality of implementation.

 Andrei


I have significantly reduced CG performance issues (up to 3x 
faster) with strategically placed disabling and enabling of the 
GC, so it may be that the problem can be solved using carefully 
placed GC.disable and GC.enable calls at points in the 
compilation process. This is not the best solution, but it could 
be a quick temporary fix until the GC problem is dealt with 
directly.

A more generalized solution is to adjust the GC to allow fine 
tuning of its behaviour. For example, allow the programmer to 
specify the conditions required for the GC to kick in, and also 
specify the maximum time it can run until it must stop.

--rt
May 03 2013
parent d coder <dlang.coder gmail.com> writes:
On Sat, May 4, 2013 at 12:41 AM, Rob T <alanb ucora.com> wrote:


 I have significantly reduced CG performance issues (up to 3x faster) with
 strategically placed disabling and enabling of the GC, so it may be that
 the problem can be solved using carefully placed GC.disable and GC.enable
 calls at points in the compilation process. This is not the best solution,
 but it could be a quick temporary fix until the GC problem is dealt with
 directly.



Hello Rob

I am totally stuck with my compile time parsing memory issues at this
point. I have 8GB RAM on my machine and the compiler goes out of memory
even when parsing a small block. So I am re-opening this old thread. Is it
possible for you to share your work with me so that I can experiment a
little bit.

Thanks and Regards
- Puneet
Oct 13 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/2/13 5:11 PM, Joseph Cassman wrote:

 On Thursday, 2 May 2013 at 23:59:48 UTC, Andrei Alexandrescu wrote:

 I'll answer community questions in my last talk at DConf 2013, which
 is about 24 hours from now. Please send yours here or on Twitter #dconf.

 Andrei


 If you could provide an update on the allocators design and
 implementation -- progress and/or roadmap -- that would be great. Also
 if there are any plans to update std.container as a result.


I will touch on this.


 Are there any plans to incorporate some of the ideas in the two talks
 about GC at the conference (or other ideas regarding GC)?


I'll probably get to this only informally; there's been some discussion 
elsewhere.


 What are the plans for ARM short or long-term?


Will try to discuss.


Andrei
May 03 2013
prev sibling next sibling parent reply "Sergei Nosov" <sergei.nosov gmail.com> writes:
On Thursday, 2 May 2013 at 23:59:48 UTC, Andrei Alexandrescu 
wrote:

 I'll answer community questions in my last talk at DConf 2013, 
 which is about 24 hours from now. Please send yours here or on 
 Twitter #dconf.

 Andrei


What are the plans regarding "functional part" of the language?

1) It seems the standard library would benefit from implementing 
functional alternatives to every statement (e.g. foreach, switch, 
etc.). There are some more interesting functions (like "tap" 
which was discussed on this NG not so long ago)

2)  pure functions - attribute inferring (feasible? good idea? 
going to be implemented in some way?) and optimizations (is there 
any good showcases right know? what's the potential? what's 
planned?)
May 02 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/2/13 11:02 PM, Sergei Nosov wrote:

 On Thursday, 2 May 2013 at 23:59:48 UTC, Andrei Alexandrescu wrote:

 I'll answer community questions in my last talk at DConf 2013, which
 is about 24 hours from now. Please send yours here or on Twitter #dconf.

 Andrei


 What are the plans regarding "functional part" of the language?

 1) It seems the standard library would benefit from implementing
 functional alternatives to every statement (e.g. foreach, switch, etc.).
 There are some more interesting functions (like "tap" which was
 discussed on this NG not so long ago)


Probably I won't discuss this because it's a very new idea.


 2)  pure functions - attribute inferring (feasible? good idea? going to
 be implemented in some way?) and optimizations (is there any good
 showcases right know? what's the potential? what's planned?)


I'll try to touch on attribute inference. Thanks!


Andrei
May 03 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-03 01:59, Andrei Alexandrescu wrote:

 I'll answer community questions in my last talk at DConf 2013, which is
 about 24 hours from now. Please send yours here or on Twitter #dconf.


Could you say something about the general development process of D, how 
the future of that looks like.

* Are we getting any stable branch/releases that there's been talking about?

* Are we done with the surprise commits/features? I'm thinking of UDA's

* Perhaps something about the DIP's. Now they just sitting there doing 
nothing

Oh, and if it's not too late. Make sure there are microphones for the 
audience for the questions. If that's not available, it's important that 
the speaker (or someone) repeats the questions for the recording. Hurb 
Sutter is really good at this but otherwise it seems the recoding are 
mostly forgotten.

-- 
/Jacob Carlborg
May 02 2013
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 02 May 2013 23:22:01 -0700, Jacob Carlborg <doob me.com> wrote:


 Oh, and if it's not too late. Make sure there are microphones for the  
 audience for the questions. If that's not available, it's important that  
 the speaker (or someone) repeats the questions for the recording. Hurb  
 Sutter is really good at this but otherwise it seems the recoding are  
 mostly forgotten.


Microphones were provided for all questions (and facebook even provided  
staff that ran microphones to people who asked them, along with a mixing  
engineer to cut down on feedback and adjust the level of the mics to the  
speaker's voice level/distance to mic).  I would say if the videos turn  
out to be anything but spectacular, I'd be surprised.

-Steve
May 02 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-05-03 08:32, Steven Schveighoffer wrote:


 Microphones were provided for all questions (and facebook even provided
 staff that ran microphones to people who asked them, along with a mixing
 engineer to cut down on feedback and adjust the level of the mics to the
 speaker's voice level/distance to mic).  I would say if the videos turn
 out to be anything but spectacular, I'd be surprised.


That sounds great. Can't wait for the videos :)

-- 
/Jacob Carlborg
May 03 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/2/13 11:22 PM, Jacob Carlborg wrote:

 On 2013-05-03 01:59, Andrei Alexandrescu wrote:

 I'll answer community questions in my last talk at DConf 2013, which is
 about 24 hours from now. Please send yours here or on Twitter #dconf.


 Could you say something about the general development process of D, how
 the future of that looks like.

 * Are we getting any stable branch/releases that there's been talking
 about?


I will discuss this.


 * Are we done with the surprise commits/features? I'm thinking of UDA's


This as well.


 * Perhaps something about the DIP's. Now they just sitting there doing
 nothing


This too.


Andrei
May 03 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-05-03 19:30, Andrei Alexandrescu wrote:


 * Are we getting any stable branch/releases that there's been talking
 about?


 I will discuss this.


 * Are we done with the surprise commits/features? I'm thinking of UDA's


 This as well.


 * Perhaps something about the DIP's. Now they just sitting there doing
 nothing


 This too.


Great :)

-- 
/Jacob Carlborg
May 04 2013
prev sibling next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Thursday, 2 May 2013 at 23:59:48 UTC, Andrei Alexandrescu 
wrote:

 I'll answer community questions in my last talk at DConf 2013, 
 which is about 24 hours from now. Please send yours here or on 
 Twitter #dconf.


1. How do you plan to solve the const postblit problem? i.e. the 
problem that you cannot create a const copy of a struct since the 
postblit constructor cannot be run on non-mutable objects. Is the 
solution to introduce C++-style copy constructors?

2. What, in your opinion (and Walter's), are the top issues with 
D that are hindering uptake?

3. What do you believe are D's biggest weaknesses that will 
likely remain unresolved by design? (*real* weaknesses, not just 
temporary shortcomings)
May 03 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/3/13 12:38 AM, Peter Alexander wrote:

 On Thursday, 2 May 2013 at 23:59:48 UTC, Andrei Alexandrescu wrote:

 I'll answer community questions in my last talk at DConf 2013, which
 is about 24 hours from now. Please send yours here or on Twitter #dconf.


 1. How do you plan to solve the const postblit problem? i.e. the problem
 that you cannot create a const copy of a struct since the postblit
 constructor cannot be run on non-mutable objects. Is the solution to
 introduce C++-style copy constructors?


Probably won't go to this level of detail. Depends on time.


 2. What, in your opinion (and Walter's), are the top issues with D that
 are hindering uptake?


I will talk about our largest weaknesses.


 3. What do you believe are D's biggest weaknesses that will likely
 remain unresolved by design? (*real* weaknesses, not just temporary
 shortcomings)


Fundamentally we're a compiled language building on C's memory bedrock. 
That setup has innate strengths and weaknesses. Of course, we've added 
our own blunders to all that and there are limitations to what you get 
to express in D. But I see our largest problems solvable through design 
(and one such design emerged at this conference).


Andrei
May 03 2013
prev sibling next sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 2 May 2013 at 23:59:48 UTC, Andrei Alexandrescu 
wrote:

 I'll answer community questions in my last talk at DConf 2013, 
 which is about 24 hours from now. Please send yours here or on 
 Twitter #dconf.

 Andrei


Are there any chances at seeing more design focus on hardcore 
embedded needs? Something about make D usage there possible not 
only in theory, but also in practice. Stuff like silently 
allocating language features and stdlib, excessive TypeInfo's, 
fat runtime etc. Some of those issues are already being addressed 
by pull requests but bug picture is still not clear.
May 03 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/3/13 1:49 AM, Dicebot wrote:

 On Thursday, 2 May 2013 at 23:59:48 UTC, Andrei Alexandrescu wrote:

 I'll answer community questions in my last talk at DConf 2013, which
 is about 24 hours from now. Please send yours here or on Twitter #dconf.

 Andrei


 Are there any chances at seeing more design focus on hardcore embedded
 needs? Something about make D usage there possible not only in theory,
 but also in practice. Stuff like silently allocating language features
 and stdlib, excessive TypeInfo's, fat runtime etc. Some of those issues
 are already being addressed by pull requests but bug picture is still
 not clear.


I'll talk about expanding our platform base. The memory allocation topic 
will probably come up along with allocators.

Andrei
May 03 2013
prev sibling next sibling parent reply "Tavi Cacina" <octavian.cacina outlook.com> writes:
On Thursday, 2 May 2013 at 23:59:48 UTC, Andrei Alexandrescu 
wrote:

 I'll answer community questions in my last talk at DConf 2013,


which design decisions in language and/or phobos, that are now 
more or less 'carved in stone', would you like to have 
differently?
May 03 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/3/13 2:34 AM, Tavi Cacina wrote:

 On Thursday, 2 May 2013 at 23:59:48 UTC, Andrei Alexandrescu wrote:

 I'll answer community questions in my last talk at DConf 2013,


 which design decisions in language and/or phobos, that are now more or
 less 'carved in stone', would you like to have differently?


This is a good Q&A topic. If I remember I'll address it.

Andrei
May 03 2013
prev sibling next sibling parent reply Arlen <arlen.ng gmx.com> writes:
On Thu, May 2, 2013 at 6:59 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 I'll answer community questions in my last talk at DConf 2013, which is about
24 hours from now. Please send yours here or on Twitter #dconf.

 Andrei



1. How many years must pass before GCC includes a front end for D?
2. Are we going to spend the next 10-20 years writing garbage collectors for D?

Arlen
May 03 2013
next sibling parent reply David <d dav1d.de> writes:
 2. Are we going to spend the next 10-20 years writing garbage collectors for D?


Good question, what's with the GC from last years GSoC?
May 03 2013
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Friday, 3 May 2013 at 11:38:38 UTC, David wrote:

 2. Are we going to spend the next 10-20 years writing garbage 
 collectors for D?


 Good question, what's with the GC from last years GSoC?


 From what I understand (which could be completely incorrect) the 
author disappeared when GSoC ended, so it was never pulled in.
May 03 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, May 03, 2013 16:18:58 Peter Alexander wrote:

 On Friday, 3 May 2013 at 11:38:38 UTC, David wrote:

 2. Are we going to spend the next 10-20 years writing garbage
 collectors for D?


=20
 Good question, what's with the GC from last years GSoC?


=20
  From what I understand (which could be completely incorrect) the
 author disappeared when GSoC ended, so it was never pulled in.


Yes, but I believe that the precise garbage collector that Rainer Sch=C3=
=BCtze=20
worked on (and discussed in his talk on Thursday) was based on it. And =
it=20
looks like after that talk, there's definite interest in getting Rainer=
's work=20
into druntime. Andrei in particular was very enthusiastic about it. So,=
 it's=20
probably only a matter of time before we have a more precise garbage co=
llector=20
in druntime (which will seriously reduce the false pointers problem, th=
ough I=20
can't remember if it completely eliminates it).

- Jonathan M Davis
May 04 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 So, it's
 probably only a matter of time before we have a more precise 
 garbage collector
 in druntime (which will seriously reduce the false pointers 
 problem, though I
 can't remember if it completely eliminates it).


Probably it doesn't use things like a shadow stack, so it doesn't 
trace stack pointers well. So probably it's not fully precise.

Bye,
bearophile
May 04 2013
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, May 05, 2013 03:55:35 bearophile wrote:

 Jonathan M Davis:

 So, it's
 probably only a matter of time before we have a more precise
 garbage collector
 in druntime (which will seriously reduce the false pointers
 problem, though I
 can't remember if it completely eliminates it).


 
 Probably it doesn't use things like a shadow stack, so it doesn't
 trace stack pointers well. So probably it's not fully precise.


IIRC, it wasn't doing anything with the stack (though I could be wrong). The 
main thing was that it had more type information so that it was able to scan 
the heap more precisely. And though this wasn't part of Rainer's GC, an 
interesting bonus that we might be able to get out of that extra type 
information is improved finalization of structs on the heap.

- Jonathan M Davis
May 04 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 5 May 2013 at 01:55:36 UTC, bearophile wrote:

 Jonathan M Davis:


 So, it's
 probably only a matter of time before we have a more precise 
 garbage collector
 in druntime (which will seriously reduce the false pointers 
 problem, though I
 can't remember if it completely eliminates it).


 Probably it doesn't use things like a shadow stack, so it 
 doesn't trace stack pointers well. So probably it's not fully 
 precise.


It is conservative with stack and unions. So it isn't fully 
precise. I do think the tradeoff that is made here is the right 
one.
May 05 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/3/13 2:43 AM, Arlen wrote:

 1. How many years must pass before GCC includes a front end for D?


This has been discussed after Iain's talk. There's progress, both on the 
technical and legal front, but we don't have a precise target yet.


 2. Are we going to spend the next 10-20 years writing garbage
 collectors for D?


Not sure whether that's good or bad!


Andrei
May 03 2013
prev sibling parent reply "sk" <abcdefg gmail.com> writes:
Any plans or roadmap on including a GUI lib in phobos?
Is it 5 years away? 10 years? Never?
May 03 2013
parent reply "sk" <abcdefg gmail.com> writes:
My journey using GUI libs is as follows:

1. Started using DWT lib (old one, when it was still supported)
2. DWT was abandoned, so I moved to DFL, tinkered with min-win etc
3. DFL is abondened now? ... moved to GTKD
4. GTKD is good, but API is hard to understand (atleast for me)
5. DWT is supported again, so move back to DWT
6. ???
May 03 2013
next sibling parent "thedeemon" <dlang thedeemon.com> writes:
On Friday, 3 May 2013 at 17:12:18 UTC, sk wrote:

 Any plans or roadmap on including a GUI lib in phobos?


I don't think that will ever happen. GUIs are just too different 
on different platforms and use cases, you'll never get the degree 
of universality for including into stdlib.


 My journey using GUI libs is as follows:

 1. Started using DWT lib (old one, when it was still supported)
 2. DWT was abandoned, so I moved to DFL, tinkered with min-win 
 etc
 3. DFL is abondened now? ... moved to GTKD
 4. GTKD is good, but API is hard to understand (atleast for me)
 5. DWT is supported again, so move back to DWT
 6. ???


For Windows apps I'm using DFL and quite happy with it. It's not 
abandoned, just maintained by other people, not the original 
author: https://github.com/Rayerd/dfl
May 03 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-05-03 19:12, sk wrote:


 6. ???


Stay with DWT :)

-- 
/Jacob Carlborg
May 04 2013