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

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

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

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

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

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

On 2013-05-03 19:12, sk wrote:

> 6. ???

Stay with DWT :)

-- 
/Jacob Carlborg

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?
> > 
> > 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.

Yes, but I believe that the precise garbage collector that Rainer Schütze worked on (and discussed in his talk on Thursday) was based on it. And it looks like after that talk, there's definite interest in getting Rainer's work into druntime. Andrei in particular was very enthusiastic about it. 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).

- Jonathan M Davis

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

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