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.

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:jc0fnt$13pu$1@digitalmars.com...> On 12/10/11 2:14 PM, Andrew Wiley wrote:
>>>> ^^
>> I agree. Postponing the current release doesn't really do anything but
>> frustrate the people that depend on recent changes. Setting a goal for
>> the next release accomplishes the same goals without the added
>> frustration.
+1
I do strongly support the new prioritization...but *after* we release 2.057. The thing's already in the middle of the doorway, there's no point in not getting it the rest of the way out the door..
>> There are good ways of addressing that. We can delay the release by only a few days and fix long-standing and extremely important issues. This is not only about doing the expected/reasonable thing here, but breaking a pattern and making a statement.
>
If, as you suggest, there's some big things that can be fixed in a short amount of time, then we can just finish 2.057, and have a short and sweet dev cycle for 2.058. The only thing "breaking a pattern and making a statement" does for anyone is make it look like we've been possessed by Steve Jobs's ghost.

On 12/11/11 12:55 AM, Nick Sabalausky wrote:
> "Andrei Alexandrescu"<SeeWebsiteForEmail@erdani.org> wrote in message
> news:jc0fnt$13pu$1@digitalmars.com...>> On 12/10/11 2:14 PM, Andrew Wiley wrote:
>>>>>> ^^
>>> I agree. Postponing the current release doesn't really do anything but
>>> frustrate the people that depend on recent changes. Setting a goal for
>>> the next release accomplishes the same goals without the added
>>> frustration.
>> +1
>> I do strongly support the new prioritization...but *after* we release 2.057.
> The thing's already in the middle of the doorway, there's no point in not
> getting it the rest of the way out the door..
This is a done deal now. I would like to thank Kenji and Walter for so quickly and resolutely acting on my suggestions.
>> There are good ways of addressing that. We can delay the release by only a
>> few days and fix long-standing and extremely important issues. This is not
>> only about doing the expected/reasonable thing here, but breaking a
>> pattern and making a statement.
>> If, as you suggest, there's some big things that can be fixed in a short
> amount of time, then we can just finish 2.057, and have a short and sweet
> dev cycle for 2.058. The only thing "breaking a pattern and making a
> statement" does for anyone is make it look like we've been possessed by
> Steve Jobs's ghost.
More rigor and perfectionism ethic wouldn't hurt us one bit. Bugs, underdefined and underimplemented features, and an attitude "if it has a workaround it's less of a bug" are our main liabilities right now.
Andrei

On 11 December 2011 10:13, Andrei Alexandrescu < SeeWebsiteForEmail@erdani.org> wrote:
> On 12/11/11 12:55 AM, Nick Sabalausky wrote:
>>> "Andrei Alexandrescu"<SeeWebsiteForEma**il@erdani.org<SeeWebsiteForEmail@erdani.org>>>> wrote in message
>> news:jc0fnt$13pu$1@**digitalmars.com...>>>>> On 12/10/11 2:14 PM, Andrew Wiley wrote:
>>>>>>>>>>> ^^
>>>> I agree. Postponing the current release doesn't really do anything but
>>>> frustrate the people that depend on recent changes. Setting a goal for
>>>> the next release accomplishes the same goals without the added
>>>> frustration.
>>>>>>>>> +1
>>>> I do strongly support the new prioritization...but *after* we release
>> 2.057.
>> The thing's already in the middle of the doorway, there's no point in not
>> getting it the rest of the way out the door..
>>>> This is a done deal now. I would like to thank Kenji and Walter for so quickly and resolutely acting on my suggestions.
>>> There are good ways of addressing that. We can delay the release by only a
>>> few days and fix long-standing and extremely important issues. This is
>>> not
>>> only about doing the expected/reasonable thing here, but breaking a
>>> pattern and making a statement.
>>>>>>> If, as you suggest, there's some big things that can be fixed in a short amount of time, then we can just finish 2.057, and have a short and sweet dev cycle for 2.058. The only thing "breaking a pattern and making a statement" does for anyone is make it look like we've been possessed by Steve Jobs's ghost.
>>>> More rigor and perfectionism ethic wouldn't hurt us one bit. Bugs, underdefined and underimplemented features, and an attitude "if it has a workaround it's less of a bug" are our main liabilities right now.
Don't forget incomplete documentation! ;)

Le 10/12/2011 21:40, Jonathan M Davis a écrit :
> On Saturday, December 10, 2011 13:23:02 Andrei Alexandrescu wrote:
>> I think we have a great release in the making: 64-bit code generation on OSX, improved floating point arithmetic, and a bunch of bugfixes.
>>>> Yet, if I had my way, I'd stop the release until every single complaint of Mehrdad's recent rampage has been looked at and addressed. Sure, we can label Mehrdad as a whiny baby, but I suspect his experience is representative for the out-of-the-box experience of many others: they see D's cool features, they download the compiler to try it out on their own terms, and as soon as they deviate from what is tried and works, or they combine features in an unusual yet meaningful manner, it all comes unglued.
>>>> It's about time to make a statement of reconnecting with our community, and in particular to the whiny babies out there. Sure, the kind of stuff we have in this beta is useful. Floating point arithmetic benchmarks have long hurt us, and 64-bit generation on OSX is a gating issue. But simple, long-standing issues that make babies whine are very important, too, and require our immediate attention.
>>>> I vote for making a strong point of fixing these out-of-the-box experience issues raised before we move forward with this release.
> > I confess that I don't see the point in delaying the current release for this. It's nearly ready. It seems to me that it doesn't cost us anything to just get it out the door and move on. _Then_ we focus on these issues - and possibly release 2.058 sooner than we might otherwise.
> > Personally, it doesn't really affect me much either way, since I always use the latest from github, but I don't quite understand what delaying a release that's about to go out the door will buy us. Focusing on const-related bugs would buy us a _lot_. The situation _has_ been improving (e.g. inout actually started working with the last release), but there's no question that issues with const still remain.
> > - Jonathan M Davis
I can understand Andrei's point. He knows the community is the most important asset of the D project, and we've witnessed what kind of damage a honest but disappointed user can do to it with the Scala project or the MongoDB project. It's about keeping an open ear to what the user has to say.

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.

2011/12/11 Paulo Pinto <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.

Hi,
please spend some time reading the research papers from
Native Oberon(Oberon), Topaz(Modula-2+), Spin(Modula-3),
Singularity(Sing#), just to cite a few examples.
People can argument against that this type of environment
is only possible in research, personally I
am convinced that there are many other reasons like legacy
support, to prevent an widespread support of such systems.
It is just that it takes time to adapt new technologies and
change people's mentalities. Just look how long it took for
funcional programming concepts to become part of mainstream
languages. It takes generations.
--
Paulo
Am 11.12.2011 14:15, schrieb maarten van damme:
>> 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.

> I confess that I don't see the point in delaying the current release for this. It's nearly ready. It seems to me that it
Compiler and runtime-library projects should never release "nearly ready" versions. Some higher level library projects may have that luxury, but compiler/run-time library, never! It should be released when it IS ready. Not earlier.
Problem with D and Phobos is that there is no clear roadmap (or at least I am not aware of its existence). So please tell me how you guys know if dmd+phobos is ready to be released or not when there was no plan on what this release is all about (apart from the list of issues on bugzilla)???