December 12, 2011
On Sunday, 11 December 2011 at 22:01:06 UTC, Jonathan M Davis wrote:
> And if we're going to really try and get the const issues sorted out, Walter really should look at Michel Fortin's changes which replace Rebindable.
>
> And we definitely need to sort out what we want to be doing with const-
> correctness and object. Kenji did some pull requests related to that, but there were some issues, and I'm not quite sure where that all stands at the moment. It _is_ a major element in fixing const though.
>
> - Jonathan M Davis

I concur, these two are major const issues.

Fixing Rebindable seems instrumental in fixing Variant if I understand the situation correctly. Fixing Variant is instrumental to fixing std.concurrency. A lot of issues are solved by going down this path.

As for Object - this week on IRC I had to explain to someone relatively new to D that the error he encountered was due to Object not being const-correct yet. Which surely sounds like a trivial problem to fix, but at least I could link to the discussion in the pull request to clarify that it isn't entirely straight-forward. This is definitely another source of frustration when working with const.
December 12, 2011
On 12/11/2011 10:34 AM, Paulo Pinto wrote:
> In my experience programming embedded systems in highly constrained environments
> usually means assembly or at most a C compiler using lots
> of compiler specific extensions for the target environment.
>
> I fail to see how D without GC could be a better tool in such enviroments.

For a system with a tiny amount of memory, D probably is the wrong tool. My suggestion would be:

0..64K assembler
64K..1M C
1M+ D

The larger your program is, the more D starts to pull ahead.
December 12, 2011
Walter Bright Wrote:

> On 12/11/2011 10:34 AM, Paulo Pinto wrote:
> > In my experience programming embedded systems in highly constrained environments
> > usually means assembly or at most a C compiler using lots
> > of compiler specific extensions for the target environment.
> >
> > I fail to see how D without GC could be a better tool in such enviroments.
> 
> For a system with a tiny amount of memory, D probably is the wrong tool. My suggestion would be:
> 
> 0..64K assembler
> 64K..1M C
> 1M+ D
> 
> The larger your program is, the more D starts to pull ahead.

Exactly, and with 1M+ we are already getting into the processor's realm which have C# and Java tolchains with AOT compilation and GC with real time extensions available. So why have D without GC for such environments?

December 12, 2011
On 12 December 2011 09:33, Paulo Pinto <pjmlp@progtools.org> wrote:

> Walter Bright Wrote:
>
> > On 12/11/2011 10:34 AM, Paulo Pinto wrote:
> > > In my experience programming embedded systems in highly constrained
> environments
> > > usually means assembly or at most a C compiler using lots of compiler specific extensions for the target environment.
> > >
> > > I fail to see how D without GC could be a better tool in such
> enviroments.
> >
> > For a system with a tiny amount of memory, D probably is the wrong tool.
> My
> > suggestion would be:
> >
> > 0..64K assembler
> > 64K..1M C
> > 1M+ D
> >
> > The larger your program is, the more D starts to pull ahead.
>
> Exactly, and with 1M+ we are already getting into the processor's realm which have C# and Java tolchains with AOT compilation and GC with real time extensions available. So why have D without GC for such environments?
>

I wrote a massive email, respond to that...


December 12, 2011
On 12/12/2011 03:58, Walter Bright wrote:
> On 12/11/2011 10:34 AM, Paulo Pinto wrote:
>> In my experience programming embedded systems in highly constrained
>> environments
>> usually means assembly or at most a C compiler using lots
>> of compiler specific extensions for the target environment.
>>
>> I fail to see how D without GC could be a better tool in such
>> enviroments.
>
> For a system with a tiny amount of memory, D probably is the wrong tool.
> My suggestion would be:
>
> 0..64K assembler
> 64K..1M C

enum there = areALotOfCoolThingsInDThatDontNeedGC();

It'd be nice if D was an option here too.

> 1M+ D
>
> The larger your program is, the more D starts to pull ahead.


-- 
Robert
http://octarineparrot.com/
December 12, 2011
Some of us essentially want "C++ done right".... D does is currently the closest thing to this that I am aware of.

On Mon, Dec 12, 2011 at 4:34 AM, Paulo Pinto <pjmlp@progtools.org> wrote:

> Am 11.12.2011 19:18, schrieb Manu:
>
>> On 11 December 2011 15:15, maarten van damme <maartenvd1994@gmail.com <mailto:maartenvd1994@gmail.**com <maartenvd1994@gmail.com>>> wrote:
>>
>>
>>    2011/12/11 Paulo Pinto <pjmlp@progtools.org
>>    <mailto:pjmlp@progtools.org>>
>>
>>
>>        Am 10.12.2011 21:35, schrieb Andrei Alexandrescu:
>>
>>            On 12/10/11 2:22 PM, maarten van damme wrote:
>>
>>                Just for fun I
>>                wanted to create a program as little as possible,
>>                compiled without
>>                garbage collector/phobos/... and it turned out that
>>                compiling without
>>                garbage collector is pretty much impossible (memory
>>                leaks all around the
>>                place in druntime). dynamic linking for the d standard
>>                library would be
>>                a great new option for a dmd release in the future :).
>>
>>
>>            Using D without GC is an interesting direction, and dynamic
>>            linking
>>            should be available relatively soon.
>>
>>
>>            Andrei
>>
>>
>>        As a long time beliver in systems programming languages with GC
>>        support
>>        (Modula-3, Oberon, Sing#, ...), I think allowing this in D is
>>        the wrong direction.
>>
>>        Sure provinding APIs to control GC behavior makes sense, but not
>>        turn it
>>        off, we already have enough languages to do systems programming
>>        without GC.
>>
>>
>>    I was only trying it "for the fun of it", not to be used seriously.
>>    D should always have it's GC support built-in and have some
>>    functions to control it's behaviour (core.memory). But I think that
>>    D, beeing a systems programming language, should also be able to be
>>    used without GC. I don't mean phobos to be writtin without a GC in
>>    mind but druntime should be compilable with something like a -nogc
>>    flag that make it usable without GC.
>>
>>    There are a lot of users out there who think that a GC produces
>>    terribly slow programs, big hangs while collecting,... (thank java
>>    for that. Right now the java GC has been improved and it's extremely
>>    good but the memory stays :p)
>>    Letting them know that D can be run without GC can be a good point.
>>    If they don't like it, they can turn it off.
>>
>>
>> That's got nothing to do with it. People who seriously NEED to be able
>> to use the language without the GC enabled are probably working on small
>> embedded systems with extremely limited resources. It's also possible
>> that various different resource types need to be allocated/located in
>> different places.
>> Also, In many cases, you need to able to have confidence in strict
>> deterministic allocation patterns. You can't do that with a GC enabled.
>> I'm all about having a GC in D, obviously, but I certainly couldn't
>> consider the language for universal adoption in many of my projects
>> without the option to control/disable it at times.
>> If I can't write some small programs with the GC completely disabled,
>> then I basically can't work on microprocessors. It's fair to give up the
>> standard library when working in this environment, but druntine, the
>> fundamental library, probably still needs to work. Infact, I'd
>> personally like it if it was designed in such a way that it never used
>> the GC under any circumstances. No library FORCED on me should restrict
>> my usage of the language in such a way.
>>
>
> In my experience programming embedded systems in highly constrained environments usually means assembly or at most a C compiler using lots of compiler specific extensions for the target environment.
>
> I fail to see how D without GC could be a better tool in such enviroments.
>
>
>


December 12, 2011
On 12 December 2011 05:58, Walter Bright <newshound2@digitalmars.com> wrote:

> On 12/11/2011 10:34 AM, Paulo Pinto wrote:
>
>> In my experience programming embedded systems in highly constrained
>> environments
>> usually means assembly or at most a C compiler using lots
>> of compiler specific extensions for the target environment.
>>
>> I fail to see how D without GC could be a better tool in such enviroments.
>>
>
> For a system with a tiny amount of memory, D probably is the wrong tool. My suggestion would be:
>
> 0..64K assembler
> 64K..1M C
> 1M+ D
>
> The larger your program is, the more D starts to pull ahead.
>

I'd like to hear your comment on my last big email in this thread.


December 12, 2011
On 2011-12-10 22:32, Walter Bright wrote:
> On 12/10/2011 12:53 PM, maarten van damme wrote:
>> Could also someone shed some light on creating shared library's on
>> linux? there
>> was some news about -fPIC beeing fixed but no real confirmation.
>
> Turns out there was a bug where EBX was not set correctly when calling a
> function that existed in a shared library. This bug was fixed. So we're
> ready to try again at creating a shared library with dmd.

That's great to hear. We'll see how far we get this time.

-- 
/Jacob Carlborg
December 12, 2011
Sure, I just am not connected to the Internet all the time.

Regarding the Cell processor, many game studios in Germany actually do code the SPE directly in assembly instead of C with intrinsics, as they even do code rewriting tricks.

But there is a research JVM for it, hence a GC enabled language http://people.inf.ethz.ch/anoll/publications/cellvm.pdf

Larrabee is dead, however its sucessor "Manycore", has Haskell support, which again means a GC enabled language,

http://software.intel.com/en-us/blogs/2010/10/14/prerelease-ghc-and-haskell-cnc-installed-on-intels-manycore-testing-lab-for-academic-use-2/

There are DSP boards that make use of .NET Micro Framework http://www.analog.com/en/processors-dsp/blackfin/processors/bf518_fmc_dev-kit_ref-design/fca.html http://www.ghielectronics.com/catalog/product/256/

The Propeller chip for embbeded solutions has the high level Spin language as main development tool, besides Assembly.

And there is also a JVM available for it. http://www.parallax.com/tabid/255/Default.aspx

French Radar systems are controlled with the Aonix Perc Ultra JVM. For sure you are aware of what a GC pause might cause on a missile guidance system if it wasn't properly implemented.
http://www.mtemag.com/ArticleItem.aspx?Cont_Title=Aonix+lands+Normandie+deal+with+Thales+

Regarding game engines targeting mobile devices and consoles we have Unity Engine and the upcoming Delta Engine. Both have GC enabled languages.

http://deltaengine.net/
http://unity3d.com/

--
Paulo


Manu Wrote:

> On 12 December 2011 05:58, Walter Bright <newshound2@digitalmars.com> wrote:
> 
> > On 12/11/2011 10:34 AM, Paulo Pinto wrote:
> >
> >> In my experience programming embedded systems in highly constrained
> >> environments
> >> usually means assembly or at most a C compiler using lots
> >> of compiler specific extensions for the target environment.
> >>
> >> I fail to see how D without GC could be a better tool in such enviroments.
> >>
> >
> > For a system with a tiny amount of memory, D probably is the wrong tool. My suggestion would be:
> >
> > 0..64K assembler
> > 64K..1M C
> > 1M+ D
> >
> > The larger your program is, the more D starts to pull ahead.
> >
> 
> I'd like to hear your comment on my last big email in this thread.
> 
> <div class="gmail_quote">On 12 December 2011 05:58, Walter Bright <span dir="ltr">&lt;<a href="mailto:newshound2@digitalmars.com">newshound2@digitalmars.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
> <div class="im">On 12/11/2011 10:34 AM, Paulo Pinto wrote:<br>
> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> In my experience programming embedded systems in highly constrained environments<br>
> usually means assembly or at most a C compiler using lots<br>
> of compiler specific extensions for the target environment.<br>
> <br>
> I fail to see how D without GC could be a better tool in such enviroments.<br>
> </blockquote>
> <br></div>
> For a system with a tiny amount of memory, D probably is the wrong tool. My suggestion would be:<br>
> <br>
> 0..64K assembler<br>
> 64K..1M C<br>
> 1M+ D<br>
> <br>
> The larger your program is, the more D starts to pull ahead.<br>
> </blockquote></div><br><div>I'd like to hear your comment on my last big email in this thread.</div>
> 

December 12, 2011
On 12 December 2011 14:52, Paulo Pinto <pjmlp@progtools.org> wrote:

> Sure, I just am not connected to the Internet all the time.
>
> Regarding the Cell processor, many game studios in Germany actually do code the SPE directly in assembly instead of C with intrinsics, as they even do code rewriting tricks.
>
> But there is a research JVM for it, hence a GC enabled language http://people.inf.ethz.ch/anoll/publications/cellvm.pdf
>
> Larrabee is dead, however its sucessor "Manycore", has Haskell support,
> which
> again means a GC enabled language,
>
>
> http://software.intel.com/en-us/blogs/2010/10/14/prerelease-ghc-and-haskell-cnc-installed-on-intels-manycore-testing-lab-for-academic-use-2/
>
> There are DSP boards that make use of .NET Micro Framework
>
> http://www.analog.com/en/processors-dsp/blackfin/processors/bf518_fmc_dev-kit_ref-design/fca.html http://www.ghielectronics.com/catalog/product/256/
>
> The Propeller chip for embbeded solutions has the high level Spin language as main development tool, besides Assembly.
>
> And there is also a JVM available for it. http://www.parallax.com/tabid/255/Default.aspx
>
> French Radar systems are controlled with the Aonix Perc Ultra JVM. For sure you are aware of what a GC pause might cause on a missile guidance system if it wasn't properly implemented.
>
> http://www.mtemag.com/ArticleItem.aspx?Cont_Title=Aonix+lands+Normandie+deal+with+Thales+
>
> Regarding game engines targeting mobile devices and consoles we have Unity Engine and the upcoming Delta Engine. Both have GC enabled languages.
>
> http://deltaengine.net/
> http://unity3d.com/
>
> --
> Paulo


Side note; I was addressing that comment mainly to Walter...

I am aware of all these use cases, and I don't believe any of those are actually counter arguments. You've just showed some different usages, which I never suggested don't exist.

Half of that is research (jvm on some platform 'x' is just the same as
saying "linux is inevitable").
Noting that some PS3 devs may use assembly directly doesn't change the fact
that most devs use C, or asm via C intrinsics, and will continue to use
assembly/intrinsics via D aswell given the opportunity.
Yes, there are engines which implement *game logic* using GC based
scripts/JIT-ers, but both the ENGINES you mention are still written in
C/C++, and have very tight control of the hardware. Given this example, are
you suggesting D is a scripting language to sit above some C/C++ app? For
me, that's the opposite of what D is.

I'm arguing what is common, expected by many, and shouldn't be taken away for no reason.