On 2014-05-06 08:39, Manu via Digitalmars-d wrote:
's at least one DIP which received little attention afaict, it's
> an example of something that I think would probably manifest into code
> in an experimental space, but clearly couldn't be accepted as a
> language feature without lots of field time.
> In lieu of an experimental space, there will be no action.
>
> It's an interesting example actually. I think lots feel the DIP isn't
> really an effective solution, but nobody has the motivation or ideas
> to refine it. The DIP author clearly has no motivation to test it
> experimentally, but perhaps that's what it needs to progress?

Implementing AST macros is probably quite a big investment in time. I'm currently working on other things but I will probably give it a try at some point.

> What happened to std.serislisation? There was motion there a year or
> so back... I was looking forward to it, and did some minor reviewing
> at the time. I wonder if that's an interesting case study? (I haven't
> looked)

To be honest, I got board and started to work on D/Objective-C instead, which I know you have interest in as well. But when that is done I will come back to std.serialization. If not sooner, I have a short attention span sometimes ;)

> Perhaps you misunderstood the point of my post. I've watched people
> make solid contributions that haven't gotten through. That is
> discouraging to others considering starting their own work, and for
> the person who has already put in the effort to continue to do so in
> the future.
> The Obj-C thing as an example. Granted, it's a huge feature and has
> extensive implications. The Authors have said themselves that they
> agree it's not 'ready' for inclusion... so, what? It sits and rots?

No, I'm working on it to making it ready. Feature wise I think it's complete. Or rather good enough for inclusion. It supports for more features than extern(C++) did when it was added.

-- 
/Jacob Carlborg

Am 06.05.2014 20:10, schrieb w0rp:
> On Tuesday, 6 May 2014 at 17:57:11 UTC, Manu via Digitalmars-d wrote:
>> As I said before, dub has never even occurred to me. No windows user
>> is likely to naturally think to use a package manager :/
>> It's sitting in my phobos fork. Isn't that where everyone keeps their
>> developments?
>>
>> If people are pushing dub, then it should really be installed with DMD.
>
> DUB should feel pretty natural on any operating system if you are a
> Python (PyPi), Ruby (Gems), JavaScript (NPM), Perl (CPAN), or PHP (PEAR)
> programmer. Although PyPi I know doesn't work as well on Windows. (It
> doesn't explain to you clearly how to install an MSVC compiler for PIP
> and what not.) I think it would be healthy to host supplementary modules
> first with DUB as third party modules, and then get them merged into
> Phobos after they have seen some real world use. That's sure to result
> in a faster turnaround time for going from experimentation to real usage.

That is the best approach.

--
Paulo

On Tuesday, 6 May 2014 at 18:02:46 UTC, John Colvin wrote:
>
> It never occurred to you that people's libraries would be published as part of a centralised repository with a tool that manages dependencies?

Hate to be the cynic, but how in the world do you expect people to even know about Dub or code.dlang.org in the first place?  I don't see it linked from any of the "obvious" places on dlang.org, and I can't even find a single _mention_ that we apparently have a package manager.  Nothing in the FAQ about "Contributing to D".  And as if all that wasn't enough, the "Links" page still points to digitalmars.com.

From a normal user's standpoint, they simply don't exist.

> It's pretty common-place in a variety of languages. (https://rubygems.org/ https://pypi.python.org/pypi http://www.cpan.org/ etc...).
>
It's rather disingenuous to invoke these three.

Ruby: "Libraries" at the top on the home page links to https://www.ruby-lang.org/en/libraries/, which explains gem and links to rubygems
Python: Not super easy to see, but "PyPI" _is_ linked in the top bar.
Perl: "CPAN" in the top bar links to http://www.perl.org/cpan.html, which explains cpan ...and I think you can see where this is going.

I love my package manager, but I'm going to have to agree with Manu's bewilderment here.

-Wyatt

On 5/6/14, 12:18 PM, Wyatt wrote:
> On Tuesday, 6 May 2014 at 18:02:46 UTC, John Colvin wrote:
>>
>> It never occurred to you that people's libraries would be published as
>> part of a centralised repository with a tool that manages dependencies?
>
> Hate to be the cynic, but how in the world do you expect people to even
> know about Dub or code.dlang.org in the first place?  I don't see it
> linked from any of the "obvious" places on dlang.org

It's an oversight - code.dlang.org is fairly recent so there are things to be still ironed out. Please submit a pull request to https://github.com/D-Programming-Language/dlang.org to include code.lang.org in the left navigation panel appropriately. -- Andrei

Le 06/05/2014 08:33, Jacob Carlborg a écrit :
> On 06/05/14 08:07, HaraldZealot wrote:
>
>> I notice that I view only part of problem, can anybody link or describe
>> me completely state and problems of current garbage collection and other
>> resource management? It help me in finding of existence solution (at
>> least theoretical).
>
> The major issue with the garbage collector is that it's not guaranteed
> to run a collection. When a collection is run the GC will call the
> destructors for the objects it collects. If there's no guarantee a
> collection is run there can be no guarantee that destructors are called.
> A collection is usually run when allocating new memory and there's not
> enough memory available.
>

For me that working almost every days on mobile devices, that not a good thing to release the memory when there is some new allocations.

Took an application with the notion of projects, here is a classical sequence users will do :
 1) Launch the application
 2) Open a project (heavy load on memory)
 3) Do some modifications (adding few allocations)
 4) Switch to the an other project

Please consider those kind of restrictions (from iOS and/or Android) :
 - After memory warning if you don't release memory enough fast your application will be killed
 - If you lock the main thread for too much time your application will be killed

Now how we implement transition between step 3 and 4 :
 - Saving the current project
 - Release manually all his memory and other resources can't be easily shared
 - At this point we are almost sure that memory and resources footprints are to the minimum amount (except leaks)
 - We can load the new project and allocate memory safely

Now with the GC, we tend to saturate the memory of the device which will cause memory warning with a chance of crash of the application. It's slower than manual release cause of number of scans,...
Even on devices like PC, GC's when they don't share memory pool between applications tends to reduce resources for other applications (bad for multitask OS).
So with a GC for this kind of steps we need shutdown the GC, and force the collect where it's interesting.

IMO, manual management is not the best, GC neither, but with good tools memory issues can be easy to find and fix. Apple have great tools for that on iOS, their memory analyser find leaks without any performance slow down just like if it's supported by the hardware!!!

Le 06/05/2014 06:05, Manu via Digitalmars-d a écrit :
> On 6 May 2014 13:51, HaraldZealot via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>>> That said, I really want my destructors, and would be very upset to
>>> see them go. So... ARC?
>>
>>
>> Manu, can you direct me what is ARC? This abbreviation is very
>> misgooglly.
>
> Automatic reference counting, and solution used by Apple in Obj-C.
> There has been massive debate on the topic already, but it's generally
> been dismissed.
>
As I don't code in Obj-C I can't tell much about that but some of my coworkers like that. Me I really love the Memory Analyzer.

Fork?

Le 06/05/2014 12:58, Manu via Digitalmars-d a écrit :
> On 6 May 2014 16:33, Jacob Carlborg via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On 06/05/14 08:07, HaraldZealot wrote:
>>
>>> I notice that I view only part of problem, can anybody link or describe
>>> me completely state and problems of current garbage collection and other
>>> resource management? It help me in finding of existence solution (at
>>> least theoretical).
>>
>>
>> The major issue with the garbage collector is that it's not guaranteed to
>> run a collection. When a collection is run the GC will call the destructors
>> for the objects it collects. If there's no guarantee a collection is run
>> there can be no guarantee that destructors are called. A collection is
>> usually run when allocating new memory and there's not enough memory
>> available.
>
> I think it's also an important consideration that GC is incompatible
> with low-memory and real-time environments.
>
> The trouble is, GC runs more frequently as the amount of available
> free memory decreases, and trace&collect takes a long time, long
> enough that realtime software typically can't tolerate the pause. If
> the pause is super rare (minutes/hours apart), maybe it's acceptable,
> but if it's closer to every call to alloc (ie, when there is little/no
> free memory), then you realise it's fundamentally incompatible.
> Then consider that this is typically the default operating state of
> embedded systems; to have no free memory at runtime, and therefore D
> is effectively incompatible with a subset of computers...
> specifically, games consoles; a gigantic industry, and one of the few
> that still absolutely relies on native code where D is particularly
> compelling.
>
> If people want to call D a native systems language, this seems like a
> serious conflict with that idea. A major subset of the language is
> incompatible with realtime or embedded use (surely among the most
> compelling use cases remaining for native code these days!). Usually
> the argument is that I represent a niche, and therefore I should
> accept the restrictions of my environment, and revert to full manual
> memory management for my work, while letting everyone else have their
> fun.
> That is a broken argument, not only because it leaves very little
> motivation to leave C++, but also because regardless of whether I
> adopt such restrictions, library authors won't, and we don't live in
> the 1980's where I can write a few lines of self-contained assembly
> and call it a program. To say I can't depend on libraries is
> practically absurd. Games are gigantic software projects, and depend
> on heaps of libraries.
>
> The GC effectively eliminates libraries from embedded/realtime users,
> which I see as an absolute deal-breaker alone, irrespective of a
> further bunch more restrictions it places on that subset of users
> within their own code :/
>
> I'll be happy with any solution that works, really. But as I see it,
> reference counting is the only garbage collection technology I know
> which will reliably clean up eagerly as things fall out of scope (also
> addressing this issue with destructors as bonus), and as such, it
> seems the logical solution. ARC is a demonstrable success in Obj-C,
> and works well in realtime and embedded systems. D has type system
> improvements which would theoretically allow for significant
> improvements over Obj-C.
>
+1

D seems to mainly interests C++ developers that generally aren't interested by dynamically types language and based on a GC.
But we always have the possibility to link C++ to a higher language for some part of applications.
IMO system languages have to continue working with manual memory management.

Le 06/05/2014 13:39, Paulo Pinto a écrit :
> On Tuesday, 6 May 2014 at 10:58:14 UTC, Manu via Digitalmars-d wrote:
>> On 6 May 2014 16:33, Jacob Carlborg via Digitalmars-d
>> <digitalmars-d@puremagic.com> wrote:
>>> On 06/05/14 08:07, HaraldZealot wrote:
>>>
>>>> I notice that I view only part of problem, can anybody link or describe
>>>> me completely state and problems of current garbage collection and
>>>> other
>>>> resource management? It help me in finding of existence solution (at
>>>> least theoretical).
>>>
>>>
>>> The major issue with the garbage collector is that it's not
>>> guaranteed to
>>> run a collection. When a collection is run the GC will call the
>>> destructors
>>> for the objects it collects. If there's no guarantee a collection is run
>>> there can be no guarantee that destructors are called. A collection is
>>> usually run when allocating new memory and there's not enough memory
>>> available.
>>
>> I think it's also an important consideration that GC is incompatible
>> with low-memory and real-time environments.
>>
>> ...
>
> I guess outside the gaming world, embedded and real-time seem to be
> getting lots of Java and .NET love:
>
> https://www.aicas.com/cms/

Is that VM full compatible with Java specifications and standard frameworks?
>
> http://www.is2t.com/products/
>
> http://www.mountaineer.org/netmf-for-stm32/
>
> Just a small sample of the partners providing the said support.
>
>
> --
> Paulo


Android works well, I love my nexus, it proves to me that it's possible to create really smooth applications based completely on Java (not 100% of that) but if we compare the Nexus 5 to iPhone 4 :
Memory : 2 GB RAM vs 512 MB RAM
CPU : Quad-core 2.3 GHz Krait 400 vs 1 GHz Cortex-A8
Battery : Li-Po 2300 mAh battery vs Li-Po 1420 mAh battery

And compared to an iPhone 5s
Memory : 2 GB RAM vs 1 GB RAM
CPU : Quad-core 2.3 GHz Krait 400 vs Dual-core 1.3 GHz Cyclone
Battery : Li-Po 2300 mAh battery vs Li-Po 1560 mAh battery

It's maybe not really significant but the majority of Android devices that have acceptable performances have a lot of memory, a quad cores CPU and an heavy battery.

So that cool Java can run smoothly but at which price? I think the margin of Apple produce is unbelievable.

Le 06/05/2014 14:04, Manu via Digitalmars-d a écrit :
> On 6 May 2014 21:39, Paulo Pinto via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On Tuesday, 6 May 2014 at 10:58:14 UTC, Manu via Digitalmars-d wrote:
>>>
>>> On 6 May 2014 16:33, Jacob Carlborg via Digitalmars-d
>>> <digitalmars-d@puremagic.com> wrote:
>>>>
>>>> On 06/05/14 08:07, HaraldZealot wrote:
>>>>
>>>>> I notice that I view only part of problem, can anybody link or describe
>>>>> me completely state and problems of current garbage collection and other
>>>>> resource management? It help me in finding of existence solution (at
>>>>> least theoretical).
>>>>
>>>>
>>>>
>>>> The major issue with the garbage collector is that it's not guaranteed to
>>>> run a collection. When a collection is run the GC will call the
>>>> destructors
>>>> for the objects it collects. If there's no guarantee a collection is run
>>>> there can be no guarantee that destructors are called. A collection is
>>>> usually run when allocating new memory and there's not enough memory
>>>> available.
>>>
>>>
>>> I think it's also an important consideration that GC is incompatible
>>> with low-memory and real-time environments.
>>>
>>> ...
>>
>>
>> I guess outside the gaming world, embedded and real-time seem to be getting
>> lots of Java and .NET love:
>>
>> https://www.aicas.com/cms/
>>
>> http://www.is2t.com/products/
>>
>> http://www.mountaineer.org/netmf-for-stm32/
>>
>> Just a small sample of the partners providing the said support.
>
> True, much embedded work isn't realtime. There are a lot of purpose
> devices where performance is not particularly important, probably
> correctness is, hence Java may be popular in this environment, and
> @safe D may have a great application here.
>
> In another realm, if we're talking about really small systems
> (microcontrollers with memory in the megabytes), the tendency to rely
> on libraries is reduced significantly, since you probably can't afford
> the memory for the libs. This environment is the one where it's
> realistic to say "tag main() with @nogc, and work from there", ie, ban
> the GC throughout the whole project.
>
> However, another very popular use for embedded systems IS realtime software.
> Games consoles are the obvious one here, but also POS/retail devices,
> kiosks, televisions, PVR's/dvd/bluray and other entertainment related
> devices, cars and automobile HUD's, music players, advertising
> displays, etc. There's no shortage of realtime devices in the embedded
> space.
> Notably, I didn't say 'phones'. Although I think they do generally
> fall into this category, I think they're drifting away. Since they run
> full OS stack's, it's typical to have unknown amounts of free memory
> for user-space apps and virtual memory managers that can page swap, so
> having excess memory overhead probably isn't such a big deal. It's
> still a major performance hazard though. Stuttering realtime
> applications is never a professional look, and Android suffers
> chronically in this department compared to iOS.
>
I suspect iOS and Android to have best of swap management. I think that almost every time you switch applications, the previous one see his memory collected and swapped on the Flash (maybe also compressed).

> I spent my last weekend trying to get a PS4 game (built with Unity;
> uses mono as a scripting environment) running at an acceptable frame
> rate. I didn't succeed, and a significant factor was the JS/C# garbage
> collector. We'll probably need to cut content from the game, such that
> it leaves plenty of 'excess' resource available to absorb the spikes
> it causes when they occur. What a waste of the machine!
> Note, C#'s GC is much better than D's. It does seem to run in the
> realm of single-digit milliseconds.
>

Le 06/05/2014 14:30, Michel Fortin a écrit :
> On 2014-05-06 12:04:55 +0000, Manu via Digitalmars-d
> <digitalmars-d@puremagic.com> said:
>
>> Notably, I didn't say 'phones'. Although I think they do generally
>> fall into this category, I think they're drifting away. Since they run
>> full OS stack's, it's typical to have unknown amounts of free memory
>> for user-space apps and virtual memory managers that can page swap, so
>> having excess memory overhead probably isn't such a big deal. It's
>> still a major performance hazard though. Stuttering realtime
>> applications is never a professional look, and Android suffers
>> chronically in this department compared to iOS.
>
> Note that iOS has no page swap. Apps just get killed if there isn't
> enough memory (after being sent a few low memory signals they can react
> on, clearing caches, etc.). Apps that takes a lot of memory cause other
> apps in the background to be killed (and later restarted when they come
> to the foreground).
>
And it's viable because majority of applications can be launch at the exact same state (or really close) they was before the kill.