www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dmd 2.057 release

reply Walter Bright <newshound2 digitalmars.com> writes:
Highlights are use of XMM floating point registers in 64 bit targets, and now 
supporting OS X 64 as a target.

http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.057.zip

A lot of people put a ton of effort into making this D's best release ever.
Thanks!
Dec 13 2011
next sibling parent reply "Bernard Helyer" <b.helyer gmail.com> writes:
Changelog isn't showing up for me.
Dec 13 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-14 08:09, Bernard Helyer wrote:

 Changelog isn't showing up for me.



Same here, latest change log is 2.056, which is empty.

-- 
/Jacob Carlborg
Dec 13 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/13/2011 11:18 PM, Jacob Carlborg wrote:

 On 2011-12-14 08:09, Bernard Helyer wrote:

 Changelog isn't showing up for me.



 Same here, latest change log is 2.056, which is empty.



Andrei's working on uploading it. Sorry about the delay.
Dec 13 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/14/11 1:44 AM, Walter Bright wrote:

 On 12/13/2011 11:18 PM, Jacob Carlborg wrote:

 On 2011-12-14 08:09, Bernard Helyer wrote:

 Changelog isn't showing up for me.



 Same here, latest change log is 2.056, which is empty.



 Andrei's working on uploading it. Sorry about the delay.



Yah, sorry.

Andrei
Dec 14 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Why is the result of this different between 2.056 and 2.057?

import std.stdio;
import std.regex;

void main() {
    string src = "4.5.1";
    foreach (c; match(src, regex(r"(\d+)")))
        writeln(c.hit);
}

2.056:
4
5
1

2.057:
4
Dec 13 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, December 14, 2011 08:09:53 Bernard Helyer wrote:

 Changelog isn't showing up for me.



Walter does the release, but Andrei updates the site. So, there's always a 
delay after a release before the site is updated.

- Jonathan M Davis
Dec 13 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter:


 http://ftp.digitalmars.com/dmd.2.057.zip



Thank you for the work. 2.057beta has allowed me to remove several work-arounds
in my D2 code.

Some thinks I'd like to see some attention on, in 2.058:

1) Fixing import semantics (http://d.puremagic.com/issues/show_bug.cgi?id=313 
https://github.com/D-Programming-Language/dmd/pull/190 ), this causes several
troubles;

2) Face the problems with slice assignment syntax (the bug report is a mess,
but the problem is real, "Syntax & semantics for array assigns":
http://d.puremagic.com/issues/show_bug.cgi?id=3971,  "Ambiguously designed
array syntax": http://d.puremagic.com/issues/show_bug.cgi?id=4703 ). The sooner
this is fixed, the better, because it implies a syntax breaking change;

And an enhancement request too:

3) Discussing/implementing tuple unpacking syntax:
https://github.com/D-Programming-Language/dmd/pull/341 (with a change I have
suggested in comment 40: http://d.puremagic.com/issues/show_bug.cgi?id=6365#c40
).

Bye,
bearophile
Dec 14 2011
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 14.12.2011 11:05, Walter Bright wrote:

 Highlights are use of XMM floating point registers in 64 bit targets,
 and now supporting OS X 64 as a target.

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.057.zip

 A lot of people put a ton of effort into making this D's best release
 ever. Thanks!



Indeed.
Yet I have to issue yet another warning about new std.regex compared 
with old one:

import std.stdio;
import std.regex;

void main() {
     string src = "4.5.1";
     foreach (c; match(src, regex(r"(\d+)")))
         writeln(c.hit);
}

previously this will find all matches, now it finds only first one. To 
get all of matches use "g" option.

Seems like 100% compatibility was next to impossible.

-- 
Dmitry Olshansky
Dec 14 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-14 08:05, Walter Bright wrote:

 Highlights are use of XMM floating point registers in 64 bit targets,
 and now supporting OS X 64 as a target.

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.057.zip

 A lot of people put a ton of effort into making this D's best release
 ever. Thanks!



That's an impressive number of bug fixes and new features, nice.

-- 
/Jacob Carlborg
Dec 14 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-14 08:05, Walter Bright wrote:

 Highlights are use of XMM floating point registers in 64 bit targets,
 and now supporting OS X 64 as a target.

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.057.zip

 A lot of people put a ton of effort into making this D's best release
 ever. Thanks!



What happened to arrays in this release:

void foo (Object[] a) {}
class Foo {}

void main ()
{
     Foo[] b;
     foo(b);
}

The above code fails with the following message:

main.d(54): Error: function main.foo (Object[] a) is not callable using 
argument types (Foo[])
main.d(54): Error: cannot implicitly convert expression (b) of type 
Foo[] to Object[]

Have I missed something, I can't find this in the changelog?

-- 
/Jacob Carlborg
Dec 14 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2011 1:59 AM, Jacob Carlborg wrote:

 What happened to arrays in this release:

 void foo (Object[] a) {}
 class Foo {}

 void main ()
 {
 Foo[] b;
 foo(b);
 }

 The above code fails with the following message:

 main.d(54): Error: function main.foo (Object[] a) is not callable using
argument
 types (Foo[])
 main.d(54): Error: cannot implicitly convert expression (b) of type Foo[] to
 Object[]

 Have I missed something, I can't find this in the changelog?



I don't remember if there was a bugzilla entry for it, but it's the object 
slicing problem. The thing is, main() expects b to be an array of Foo's. If 
foo() replaces one of the array elements with an Object, then b is no longer an 
array of Foo's, and can crash.

Note that if you write foo as:

     void foo(const(Object)[] a)

it will work.
Dec 14 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-14 11:10, Walter Bright wrote:

 On 12/14/2011 1:59 AM, Jacob Carlborg wrote:

 What happened to arrays in this release:

 void foo (Object[] a) {}
 class Foo {}

 void main ()
 {
 Foo[] b;
 foo(b);
 }

 The above code fails with the following message:

 main.d(54): Error: function main.foo (Object[] a) is not callable
 using argument
 types (Foo[])
 main.d(54): Error: cannot implicitly convert expression (b) of type
 Foo[] to
 Object[]

 Have I missed something, I can't find this in the changelog?



 I don't remember if there was a bugzilla entry for it, but it's the
 object slicing problem. The thing is, main() expects b to be an array of
 Foo's. If foo() replaces one of the array elements with an Object, then
 b is no longer an array of Foo's, and can crash.



I think it would be good if it's in the changelog, even if there is no 
bugzilla entry for it.


 Note that if you write foo as:

 void foo(const(Object)[] a)

 it will work.



Ok, thanks.

-- 
/Jacob Carlborg
Dec 14 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-14 18:00, Jonathan M Davis wrote:

 On Wednesday, December 14, 2011 12:11:03 Jacob Carlborg wrote:

 On 2011-12-14 11:10, Walter Bright wrote:

 On 12/14/2011 1:59 AM, Jacob Carlborg wrote:

 What happened to arrays in this release:

 void foo (Object[] a) {}
 class Foo {}

 void main ()
 {
 Foo[] b;
 foo(b);
 }

 The above code fails with the following message:

 main.d(54): Error: function main.foo (Object[] a) is not callable
 using argument
 types (Foo[])
 main.d(54): Error: cannot implicitly convert expression (b) of type
 Foo[] to
 Object[]

 Have I missed something, I can't find this in the changelog?



 I don't remember if there was a bugzilla entry for it, but it's the
 object slicing problem. The thing is, main() expects b to be an array of
 Foo's. If foo() replaces one of the array elements with an Object, then
 b is no longer an array of Foo's, and can crash.



 I think it would be good if it's in the changelog, even if there is no
 bugzilla entry for it.



 It's the first dmd bug on the list:
 http://d.puremagic.com/issues/show_bug.cgi?id=2095

 - Jonathan M Davis



I see, thanks. I was search for "array" on the changelog page.

-- 
/Jacob Carlborg
Dec 14 2011
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-15 08:43, Jonathan M Davis wrote:

 On Thursday, December 15, 2011 08:19:39 Jacob Carlborg wrote:

 On 2011-12-14 18:00, Jonathan M Davis wrote:

 On Wednesday, December 14, 2011 12:11:03 Jacob Carlborg wrote:

 On 2011-12-14 11:10, Walter Bright wrote:

 On 12/14/2011 1:59 AM, Jacob Carlborg wrote:

 What happened to arrays in this release:

 void foo (Object[] a) {}
 class Foo {}

 void main ()
 {
 Foo[] b;
 foo(b);
 }

 The above code fails with the following message:

 main.d(54): Error: function main.foo (Object[] a) is not callable
 using argument
 types (Foo[])
 main.d(54): Error: cannot implicitly convert expression (b) of
 type
 Foo[] to
 Object[]

 Have I missed something, I can't find this in the changelog?



 I don't remember if there was a bugzilla entry for it, but it's the
 object slicing problem. The thing is, main() expects b to be an
 array of Foo's. If foo() replaces one of the array elements with an
 Object, then b is no longer an array of Foo's, and can crash.



 I think it would be good if it's in the changelog, even if there is no
 bugzilla entry for it.



 It's the first dmd bug on the list:
 http://d.puremagic.com/issues/show_bug.cgi?id=2095

 - Jonathan M Davis



 I see, thanks. I was search for "array" on the changelog page.



 The names of bug reports are frequently not particularly informative, and even
 if they are, they frequently don't contain the necessary information to
 understand the effects of fixing the bug. If you want to actually know what's
 really being fixed, you frequently have to actually read all of the bug reports
 rather than looking at their titles.

 - Jonathan M Davis



Yeah, I guess.

-- 
/Jacob Carlborg
Dec 15 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-15 08:43, Jonathan M Davis wrote:

 The names of bug reports are frequently not particularly informative, and even
 if they are, they frequently don't contain the necessary information to
 understand the effects of fixing the bug. If you want to actually know what's
 really being fixed, you frequently have to actually read all of the bug reports
 rather than looking at their titles.

 - Jonathan M Davis



I wonder if we can list breaking changes in a separate sections in the 
changelog.

-- 
/Jacob Carlborg
Dec 15 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/15/2011 4:16 AM, Jacob Carlborg wrote:

 I wonder if we can list breaking changes in a separate sections in the
changelog.



Any bug fix is a breaking change - code can and does depend on bugs (often 
inadvertently).
Dec 15 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-15 20:25, Walter Bright wrote:

 On 12/15/2011 4:16 AM, Jacob Carlborg wrote:

 I wonder if we can list breaking changes in a separate sections in the
 changelog.



 Any bug fix is a breaking change - code can and does depend on bugs
 (often inadvertently).



In this particular case it could just have been a design decision that 
has changed. And BTW, deprecating typdef can't be considered a bug fix, 
that would be perfect for a list of breaking changes.

-- 
/Jacob Carlborg
Dec 15 2011
parent reply Don <nospam nospam.com> writes:
On 15.12.2011 21:34, Jacob Carlborg wrote:

 On 2011-12-15 20:25, Walter Bright wrote:

 On 12/15/2011 4:16 AM, Jacob Carlborg wrote:

 I wonder if we can list breaking changes in a separate sections in the
 changelog.



 Any bug fix is a breaking change - code can and does depend on bugs
 (often inadvertently).



 In this particular case it could just have been a design decision that
 has changed. And BTW, deprecating typdef can't be considered a bug fix,
 that would be perfect for a list of breaking changes.



Deprecating typedef is in the list of changed features, not in the list 
of fixed bugs. Choosing which list things go in is sometimes a bit 
arbitrary, though.
Occasionally in the changelog, major breaking changes were shown in red. 
That hasn't happened for ages.
Dec 15 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-12-15 22:28, Don wrote:

 On 15.12.2011 21:34, Jacob Carlborg wrote:

 On 2011-12-15 20:25, Walter Bright wrote:

 On 12/15/2011 4:16 AM, Jacob Carlborg wrote:

 I wonder if we can list breaking changes in a separate sections in the
 changelog.



 Any bug fix is a breaking change - code can and does depend on bugs
 (often inadvertently).



 In this particular case it could just have been a design decision that
 has changed. And BTW, deprecating typdef can't be considered a bug fix,
 that would be perfect for a list of breaking changes.



 Deprecating typedef is in the list of changed features, not in the list
 of fixed bugs. Choosing which list things go in is sometimes a bit
 arbitrary, though.
 Occasionally in the changelog, major breaking changes were shown in red.
 That hasn't happened for ages.



Yes, I noticed typedef in the list, but in this case it would have been 
nice if it had its own section in the list. I know that typedef has been 
"deprecated" for a while but I had no idea it would be official in this 
release.

-- 
/Jacob Carlborg
Dec 15 2011
prev sibling parent JoeCoder <dnewsgroup2 yage3d.net> writes:
On 12/15/2011 2:25 PM, Walter Bright wrote:

 On 12/15/2011 4:16 AM, Jacob Carlborg wrote:

 I wonder if we can list breaking changes in a separate sections in the
 changelog.



 Any bug fix is a breaking change - code can and does depend on bugs
 (often inadvertently).



I've never seen code depend on an ICE :)
Dec 16 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, December 14, 2011 12:11:03 Jacob Carlborg wrote:

 On 2011-12-14 11:10, Walter Bright wrote:

 On 12/14/2011 1:59 AM, Jacob Carlborg wrote:

 What happened to arrays in this release:
 
 void foo (Object[] a) {}
 class Foo {}
 
 void main ()
 {
 Foo[] b;
 foo(b);
 }
 
 The above code fails with the following message:
 
 main.d(54): Error: function main.foo (Object[] a) is not callable
 using argument
 types (Foo[])
 main.d(54): Error: cannot implicitly convert expression (b) of type
 Foo[] to
 Object[]
 
 Have I missed something, I can't find this in the changelog?



 I don't remember if there was a bugzilla entry for it, but it's the
 object slicing problem. The thing is, main() expects b to be an array of
 Foo's. If foo() replaces one of the array elements with an Object, then
 b is no longer an array of Foo's, and can crash.



 I think it would be good if it's in the changelog, even if there is no
 bugzilla entry for it.



It's the first dmd bug on the list: 
http://d.puremagic.com/issues/show_bug.cgi?id=2095

- Jonathan M Davis
Dec 14 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jacob Carlborg:


 What happened to arrays in this release:



They have closed a significant D2 hole.

As Walter has explained, this code used to compile fine and then crash at
runtime:

class Foo {
    void spam() {}
}
class Bar {}
void foo(Object[] a) {
    a[0] = new Bar;
}
void main() {
    Foo[] b = [new Foo];
    foo(b);
    b[0].spam(); // crash
}


Now instead it gives this at compile-time:
test.d(10): Error: function test.foo (Object[] a) is not callable using
argument types (Foo[])
test.d(10): Error: cannot implicitly convert expression (b) of type Foo[] to
Object[]


Now a modified foo is accepted if its 'a' argoment is constant, because you
can't modify the array contents (unless you cast away const):


class Foo {
    void spam() {}
}
void foo(const(Object[]) a) {
}
void main() {
    Foo[] b = [new Foo];
    foo(b);
}


This Java code compiles with no errors:


class Foo {
    Foo() {}
    void spam() {}
}
class Bar {
    Bar() {}
}
class Test {
    static void foo(Object[] a) {
        a[0] = new Bar(); // line 10, runtime error here
    }
    public static void main(String[] args) {
        Foo[] b = {new Foo()};
        Test.foo(b);
        b[0].spam(); // line 15
    }
}


Instead of crashing at run-time at line 15, it raises a
java.lang.ArrayStoreException at runtime at line 10, where at runtime it tests
that in a[0] you put a Foo() instead of something else like a Bar() or
Object(). So  (in theory) the JavaVM has to perform a runtime test every time
you perform an assignment of a class reference to an array cell.

Bye,
bearophile
Dec 14 2011
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Ideally, every nontrivial change should have a bugzilla entry, even if that m=
eans its created by whoever made the change. It's too easy to miss things ot=
herwise.=20

Sent from my iPhone

On Dec 14, 2011, at 3:11 AM, Jacob Carlborg <doob me.com> wrote:


 On 2011-12-14 11:10, Walter Bright wrote:

 On 12/14/2011 1:59 AM, Jacob Carlborg wrote:

 What happened to arrays in this release:
=20
 void foo (Object[] a) {}
 class Foo {}
=20
 void main ()
 {
 Foo[] b;
 foo(b);
 }
=20
 The above code fails with the following message:
=20
 main.d(54): Error: function main.foo (Object[] a) is not callable
 using argument
 types (Foo[])
 main.d(54): Error: cannot implicitly convert expression (b) of type
 Foo[] to
 Object[]
=20
 Have I missed something, I can't find this in the changelog?



 I don't remember if there was a bugzilla entry for it, but it's the
 object slicing problem. The thing is, main() expects b to be an array of
 Foo's. If foo() replaces one of the array elements with an Object, then
 b is no longer an array of Foo's, and can crash.



 I think it would be good if it's in the changelog, even if there is no bug=




=20

 Note that if you write foo as:
=20
 void foo(const(Object)[] a)
=20
 it will work.



 Ok, thanks.
=20
 --=20
 /Jacob Carlborg
Dec 14 2011
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/14/11 1:05 AM, Walter Bright wrote:

 Highlights are use of XMM floating point registers in 64 bit targets,
 and now supporting OS X 64 as a target.

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.057.zip

 A lot of people put a ton of effort into making this D's best release
 ever. Thanks!



Many thanks to all participants for this awesome release and in 
particular for the intense pace of the past few days!

Andrei
Dec 14 2011
prev sibling next sibling parent reply Adrian <adrian.remove-nospam veith-system.de> writes:
Am 14.12.2011 08:05, schrieb Walter Bright:

 Highlights are use of XMM floating point registers in 64 bit targets,
 and now supporting OS X 64 as a target.
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.057.zip
 
 A lot of people put a ton of effort into making this D's best release
 ever. Thanks!



I have a strange crash of the new dmd 2.057 compiler.

I am running the compiler from inside VisualD. In debug mode the code
compiles fine. In release mode the compiler crashes and Windows starts
the Just-In-Time-Debugger saying that there is an unhandled exception
inside dmd.exe.

as a side note: the same code did compile with 2.056 !

When I try to find the source of the error it gets really funky strange:

int main(string[] argv)
{
	writeln("Hello D-World!");
	auto i = uniform(0, 15);          // line A
	auto c = 0;
	if (c++ < c)					  // line B
		writeln("Why did they call it c++"); // line C
	//writeln(bench!(doStringTest));  // line D
	//writeln(bench!(doBench1));	  // line E
	//writeln(bench!(doBench2));      // line F
	//writeln(bench!(doBench3));      // line G
//	main1(argv);			  // line I
//	return 0;                         // line J
//}                                       // line K

//int main1(string[] argv)                // line L
//{                                       // line M

  ... much more code
}

- the code above crashes
- when I comment out line A it compiles
- when I leave A comment out  B and C - dmd gets into an endless loop (
I waited several minutes for the process to terminate)

- when I leave A and uncomment I to M it compiles
- when I uncomment A to G it compiles
- when I uncomment A to F it crashes

now I tried the following:

int main(string[] argv)
{
	writeln("Hello D-World!");
	auto i = uniform(0, 15);          // line A
	auto c = 0;
	if (c++ < c)					  // line B
		writeln("Why did they call it c++"); // line C
	//writeln(bench!(doStringTest));  // line D
	//writeln(bench!(doBench1));	  // line E
	//writeln(bench!(doBench2));      // line F
	//writeln(bench!(doBench3));      // line G
	main1(argv);			  // line I
	return 0;                         // line J
}                                       // line K

int main1(string[] argv)                // line L
{                                       // line M

  ... much more code
}


- as soon as I uncomment line G it compiles with any combination of line
D to F uncommented
- when line G is commented out any combination of line D to F
uncommented crashes.
- when I comment out line "I" any other combination compiles

I really would like to find a minimal stripped down version of the code,
but as soon as I try to find it, the behavior changes.
Dec 14 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2011 6:59 AM, Adrian wrote:

 I have a strange crash of the new dmd 2.057 compiler.



I can't do anything without a reproducible test case.
Dec 14 2011
next sibling parent reply Adrian <adrian.remove-nospam veith-system.de> writes:
Am 14.12.2011 18:57, schrieb Walter Bright:

 On 12/14/2011 6:59 AM, Adrian wrote:

 I have a strange crash of the new dmd 2.057 compiler.



 I can't do anything without a reproducible test case.



If you want, I can sent you the whole source. Its nothing real
important, because I am playing around with D and porting some code to test.

Adrian.
Dec 14 2011
parent Adrian <adrian.remove-nospam veith-system.de> writes:
Am 15.12.2011 07:50, schrieb Adrian:

 Am 14.12.2011 18:57, schrieb Walter Bright:

 On 12/14/2011 6:59 AM, Adrian wrote:

 I have a strange crash of the new dmd 2.057 compiler.



 I can't do anything without a reproducible test case.



 If you want, I can sent you the whole source. Its nothing real
 important, because I am playing around with D and porting some code to test.
 
 Adrian.



I am little step forward. It has to do with the option for array bounds
checking. When disabled dmd crashes, when enabled not. Therefor the
debug version worked and the release not.
Dec 15 2011
prev sibling parent reply Adrian <adrian.remove-nospam veith-system.de> writes:
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Am 14.12.2011 18:57, schrieb Walter Bright:

 On 12/14/2011 6:59 AM, Adrian wrote:

 I have a strange crash of the new dmd 2.057 compiler.



 I can't do anything without a reproducible test case.



I tried to reduce the problem as much as possible and found out the
following:

- I have include a bug.bat which shows the commandline I used.

- for the crash to happen the project has to be compiled with the
switches  -noboundscheck and -deps="bug.dep". if you omit one of them
the crash wont show.

- the module btree.d has to be compiled with the project, even if it is
not referenced from main.d. if it is not in the command line - no crash

- if you comment out the first writeln("Hello D-World!") in main() - no
crash

- if you comment out the other two writeln(..) in main() - no crash


hope you can reproduce it on another system - it sounds too odd to me
and if it is not reproducible on another system I feel a bit crazy.

Adrian.
Dec 15 2011
parent reply Stephan <spam extrawurst.org> writes:
On 15.12.2011 12:02, Adrian wrote:

 - for the crash to happen the project has to be compiled with the
 switches  -noboundscheck and -deps="bug.dep". if you omit one of them
 the crash wont show.



sounds like this one i encountered last release already:

http://d.puremagic.com/issues/show_bug.cgi?id=6951
Dec 15 2011
parent reply Adrian <adrian.remove-nospam veith-system.de> writes:
Am 15.12.2011 12:31, schrieb Stephan:

 On 15.12.2011 12:02, Adrian wrote:

 - for the crash to happen the project has to be compiled with the
 switches  -noboundscheck and -deps="bug.dep". if you omit one of them
 the crash wont show.



 sounds like this one i encountered last release already:
 
 http://d.puremagic.com/issues/show_bug.cgi?id=6951



yes looks pretty much the same. Its total weired, because it seems to
depend on code which is elsewhere.
Dec 15 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/15/2011 6:31 AM, Adrian wrote:

 Am 15.12.2011 12:31, schrieb Stephan:

 On 15.12.2011 12:02, Adrian wrote:

 - for the crash to happen the project has to be compiled with the
 switches  -noboundscheck and -deps="bug.dep". if you omit one of them
 the crash wont show.



 sounds like this one i encountered last release already:

 http://d.puremagic.com/issues/show_bug.cgi?id=6951



 yes looks pretty much the same. Its total weired, because it seems to
 depend on code which is elsewhere.



How about adding your bug.zip to that report?
Dec 15 2011
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Sounds offset-dependent. I bet if you added and removed instructions in the r=
ight place you could reduce it a lot further.=20

Sent from my iPhone

On Dec 15, 2011, at 3:02 AM, Adrian <adrian.remove-nospam veith-system.de> w=
rote:


 Am 14.12.2011 18:57, schrieb Walter Bright:

 On 12/14/2011 6:59 AM, Adrian wrote:

 I have a strange crash of the new dmd 2.057 compiler.



 I can't do anything without a reproducible test case.



 I tried to reduce the problem as much as possible and found out the
 following:
=20
 - I have include a bug.bat which shows the commandline I used.
=20
 - for the crash to happen the project has to be compiled with the
 switches  -noboundscheck and -deps=3D"bug.dep". if you omit one of them
 the crash wont show.
=20
 - the module btree.d has to be compiled with the project, even if it is
 not referenced from main.d. if it is not in the command line - no crash
=20
 - if you comment out the first writeln("Hello D-World!") in main() - no
 crash
=20
 - if you comment out the other two writeln(..) in main() - no crash
=20
=20
 hope you can reproduce it on another system - it sounds too odd to me
 and if it is not reproducible on another system I feel a bit crazy.
=20
 Adrian.
 <bug.zip>
Dec 15 2011
prev sibling next sibling parent Peter Alexander <peter.alexander.au gmail.com> writes:
On 14/12/11 7:05 AM, Walter Bright wrote:

 Highlights are use of XMM floating point registers in 64 bit targets,
 and now supporting OS X 64 as a target.

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.057.zip

 A lot of people put a ton of effort into making this D's best release
 ever. Thanks!



Great release.

64-bit OSX is working for my project without any problems. Had to change 
some uint's to size_t's and fix some inline asm but everything was fine 
after that :-)
Dec 14 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, December 15, 2011 08:19:39 Jacob Carlborg wrote:

 On 2011-12-14 18:00, Jonathan M Davis wrote:

 On Wednesday, December 14, 2011 12:11:03 Jacob Carlborg wrote:

 On 2011-12-14 11:10, Walter Bright wrote:

 On 12/14/2011 1:59 AM, Jacob Carlborg wrote:

 What happened to arrays in this release:
 
 void foo (Object[] a) {}
 class Foo {}
 
 void main ()
 {
 Foo[] b;
 foo(b);
 }
 
 The above code fails with the following message:
 
 main.d(54): Error: function main.foo (Object[] a) is not callable
 using argument
 types (Foo[])
 main.d(54): Error: cannot implicitly convert expression (b) of
 type
 Foo[] to
 Object[]
 
 Have I missed something, I can't find this in the changelog?



 I don't remember if there was a bugzilla entry for it, but it's the
 object slicing problem. The thing is, main() expects b to be an
 array of Foo's. If foo() replaces one of the array elements with an
 Object, then b is no longer an array of Foo's, and can crash.



 I think it would be good if it's in the changelog, even if there is no
 bugzilla entry for it.



 It's the first dmd bug on the list:
 http://d.puremagic.com/issues/show_bug.cgi?id=2095
 
 - Jonathan M Davis



 I see, thanks. I was search for "array" on the changelog page.



The names of bug reports are frequently not particularly informative, and even 
if they are, they frequently don't contain the necessary information to 
understand the effects of fixing the bug. If you want to actually know what's 
really being fixed, you frequently have to actually read all of the bug reports 
rather than looking at their titles.

- Jonathan M Davis
Dec 14 2011
prev sibling next sibling parent "Christian Manning" <cmanning999 gmail.com> writes:
On Wednesday, 14 December 2011 at 07:05:25 UTC, Walter Bright 
wrote:

 Highlights are use of XMM floating point registers in 64 bit 
 targets, and now supporting OS X 64 as a target.

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.057.zip

 A lot of people put a ton of effort into making this D's best 
 release ever. Thanks!



I found a bug when slicing static arrays. It's not new to 2.057 
but I totally forgot about it (my bad) and didn't simplify a test 
case.

auto x() {
    ubyte[4] a;
    return a;
}

auto y() {
    return x()[1..$];
}

void main() {
    y();
}

Gives:
Internal error: ..\ztc\cgcs.c 354

Is this known or should I file a bug?
Dec 16 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, December 16, 2011 16:26:11 Christian Manning wrote:

 On Wednesday, 14 December 2011 at 07:05:25 UTC, Walter Bright
 
 wrote:

 Highlights are use of XMM floating point registers in 64 bit
 targets, and now supporting OS X 64 as a target.
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.057.zip
 
 A lot of people put a ton of effort into making this D's best
 release ever. Thanks!



 I found a bug when slicing static arrays. It's not new to 2.057
 but I totally forgot about it (my bad) and didn't simplify a test
 case.
 
 auto x() {
     ubyte[4] a;
     return a;
 }
 
 auto y() {
     return x()[1..$];
 }
 
 void main() {
     y();
 }
 
 Gives:
 Internal error: ..\ztc\cgcs.c 354
 
 Is this known or should I file a bug?



It may bhttp://d.puremagic.com/issues/show_bug.cgi?id=4414

I'd point out though that that is really bad code, which should probably give 
an error when you try and compile it (though it obviously shouldn't cause the 
compiler to ICE regardless).

http://d.puremagic.com/issues/show_bug.cgi?id=7087

- Jonathan M Davis
Dec 16 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 On Friday, December 16, 2011 22:37:50 Christian Manning wrote: 

 ubyte[4] a;
 auto x() {
 return a;
 }
 void main() {
 auto b = x()[1..$];
 }



 Regardless, the compiler shouldn't be ICEing though.



Is it in Bugzilla?

Bye,
bearophile
Dec 17 2011
prev sibling next sibling parent "Christian Manning" <cmanning999 gmail.com> writes:
On Friday, 16 December 2011 at 16:43:29 UTC, Jonathan M Davis 
wrote:

 On Friday, December 16, 2011 16:26:11 Christian Manning wrote:

 On Wednesday, 14 December 2011 at 07:05:25 UTC, Walter Bright
 
 wrote:

 Highlights are use of XMM floating point registers in 64 bit
 targets, and now supporting OS X 64 as a target.
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.057.zip
 
 A lot of people put a ton of effort into making this D's best
 release ever. Thanks!



 I found a bug when slicing static arrays. It's not new to 2.057
 but I totally forgot about it (my bad) and didn't simplify a 
 test
 case.
 
 auto x() {
   ubyte[4] a;
   return a;
 }
 
 auto y() {
   return x()[1..$];
 }
 
 void main() {
   y();
 }
 
 Gives:
 Internal error: ..\ztc\cgcs.c 354
 
 Is this known or should I file a bug?



 It may bhttp://d.puremagic.com/issues/show_bug.cgi?id=4414

 I'd point out though that that is really bad code, which should 
 probably give an error when you try and compile it (though it 
 obviously shouldn't cause the compiler to ICE regardless).

 http://d.puremagic.com/issues/show_bug.cgi?id=7087

 - Jonathan M Davis



It was just some mess around code, but I'll avoid it in the 
future, so thanks for pointing it out :)

It does indeed look to be the same problem as 
http://d.puremagic.com/issues/show_bug.cgi?id=4414
I should also point out that the appearance of the error is 
dependant on the slice size.

How about this as a better test case?

ubyte[4] a;
auto x() {
    return a;
}
void main() {
    auto b = x()[1..$];
}
Dec 16 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, December 16, 2011 22:37:50 Christian Manning wrote: 

 How about this as a better test case?
 
 ubyte[4] a;
 auto x() {
 return a;
 }
 void main() {
 auto b = x()[1..$];
 }



That actually has exactly the same problem. You're slicing a temporary. You 
can't slice a static array unless it's an actual variable, or you're going to 
have problems. b points to a slice of a static array which doesn't exist 
anymore. It _might_ work depending on how the registers used and how the stack 
is laid out, but it's still a bad idea.

Regardless, the compiler shouldn't be ICEing though.

- Jonathan M Davis
Dec 16 2011
prev sibling next sibling parent "Christian Manning" <cmanning999 gmail.com> writes:
On Friday, 16 December 2011 at 22:48:21 UTC, Jonathan M Davis 
wrote:

 That actually has exactly the same problem. You're slicing a 
 temporary. You can't slice a static array unless it's an actual 
 variable, or you're going to have problems. b points to a slice 
 of a static array which doesn't exist anymore. It _might_ work 
 depending on how the registers used and how the stack is laid 
 out, but it's still a bad idea.



Ah I get it now, thanks.
Dec 16 2011
prev sibling next sibling parent "Christian Manning" <cmanning999 gmail.com> writes:
On Saturday, 17 December 2011 at 11:02:41 UTC, bearophile wrote:

 Jonathan M Davis:


 On Friday, December 16, 2011 22:37:50 Christian Manning wrote:

 ubyte[4] a;
 auto x() {
 return a;
 }
 void main() {
 auto b = x()[1..$];
 }



 Regardless, the compiler shouldn't be ICEing though.



 Is it in Bugzilla?

 Bye,
 bearophile



Looks to be the same issue as 
http://d.puremagic.com/issues/show_bug.cgi?id=4414
Dec 17 2011
prev sibling next sibling parent reply Caligo <iteronvexor gmail.com> writes:
--f46d042f93cec1cea504b59aeffd
Content-Type: text/plain; charset=ISO-8859-1

Considering the rate at which bugs are being discovered and fixed, would it
be possible to shorten the release cycle, say, every 2-3 weeks instead of
1-2 months?

--f46d042f93cec1cea504b59aeffd
Content-Type: text/html; charset=ISO-8859-1

Considering the rate at which bugs are being discovered and fixed, would it be
possible to shorten the release cycle, say, every 2-3 weeks instead of 1-2
months?<br>

--f46d042f93cec1cea504b59aeffd--
Jan 02 2012
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 03-01-2012 08:49, Caligo wrote:

 Considering the rate at which bugs are being discovered and fixed, would
 it be possible to shorten the release cycle, say, every 2-3 weeks
 instead of 1-2 months?



Perhaps some kind of experimental releases would be better. It could 
help getting new features out to the community (and thus tested) faster.

- Alex
Jan 03 2012
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 03/01/2012 14:49, Alex Rønne Petersen wrote:

 On 03-01-2012 08:49, Caligo wrote:

 Considering the rate at which bugs are being discovered and fixed, would
 it be possible to shorten the release cycle, say, every 2-3 weeks
 instead of 1-2 months?



 Perhaps some kind of experimental releases would be better. It could
 help getting new features out to the community (and thus tested) faster.

 - Alex



Beta releases are made weeks before an actual release for testing on 
this mailing list:

http://lists.puremagic.com/cgi-bin/mailman/listinfo/dmd-beta

Web interface:

http://dfeed.kimsufi.thecybershadow.net/discussion/group/dmd-beta

-- 
Robert
http://octarineparrot.com/
Jan 03 2012
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 03-01-2012 15:56, Robert Clipsham wrote:

 On 03/01/2012 14:49, Alex Rønne Petersen wrote:

 On 03-01-2012 08:49, Caligo wrote:

 Considering the rate at which bugs are being discovered and fixed, would
 it be possible to shorten the release cycle, say, every 2-3 weeks
 instead of 1-2 months?



 Perhaps some kind of experimental releases would be better. It could
 help getting new features out to the community (and thus tested) faster.

 - Alex



 Beta releases are made weeks before an actual release for testing on
 this mailing list:

 http://lists.puremagic.com/cgi-bin/mailman/listinfo/dmd-beta

 Web interface:

 http://dfeed.kimsufi.thecybershadow.net/discussion/group/dmd-beta



I mean something weekly or bi-weekly. Beta releases are only made very 
close to the actual release.

- Alex
Jan 03 2012
parent simendsjo <simendsjo gmail.com> writes:
On 03.01.2012 16:07, Alex Rønne Petersen wrote:

 On 03-01-2012 15:56, Robert Clipsham wrote:

 On 03/01/2012 14:49, Alex Rønne Petersen wrote:

 On 03-01-2012 08:49, Caligo wrote:

 Considering the rate at which bugs are being discovered and fixed,
 would
 it be possible to shorten the release cycle, say, every 2-3 weeks
 instead of 1-2 months?



 Perhaps some kind of experimental releases would be better. It could
 help getting new features out to the community (and thus tested) faster.

 - Alex



 Beta releases are made weeks before an actual release for testing on
 this mailing list:

 http://lists.puremagic.com/cgi-bin/mailman/listinfo/dmd-beta

 Web interface:

 http://dfeed.kimsufi.thecybershadow.net/discussion/group/dmd-beta



 I mean something weekly or bi-weekly. Beta releases are only made very
 close to the actual release.

 - Alex



I just asked about this in D, but as there is a discussion here already: 
The auto-tester builds dmd++, why not let the latest binary that 
successfully passed the tests be available for download?
Jan 03 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/3/2012 6:49 AM, Alex Rønne Petersen wrote:

 Perhaps some kind of experimental releases would be better. It could help
 getting new features out to the community (and thus tested) faster.



We call them betas <g>.

But anyone can pull the latest from github and use it, many do.
Jan 03 2012
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 03-01-2012 19:47, Walter Bright wrote:

 On 1/3/2012 6:49 AM, Alex Rønne Petersen wrote:

 Perhaps some kind of experimental releases would be better. It could help
 getting new features out to the community (and thus tested) faster.



 We call them betas <g>.

 But anyone can pull the latest from github and use it, many do.



That's not very practical for most users. Some kind of ready-to-download 
builds would be much better. As others suggested, the auto-tester 
publishing builds for download would be ideal.

- Alex
Jan 03 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/3/2012 10:55 AM, Alex Rønne Petersen wrote:

 On 03-01-2012 19:47, Walter Bright wrote:

 On 1/3/2012 6:49 AM, Alex Rønne Petersen wrote:

 Perhaps some kind of experimental releases would be better. It could help
 getting new features out to the community (and thus tested) faster.



 We call them betas <g>.

 But anyone can pull the latest from github and use it, many do.



 That's not very practical for most users. Some kind of ready-to-download builds
 would be much better. As others suggested, the auto-tester publishing builds
for
 download would be ideal.



Using a nightly build is not very practical for most users, either, probably
the 
same group.
Jan 03 2012
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 03-01-2012 20:25, Walter Bright wrote:

 On 1/3/2012 10:55 AM, Alex Rønne Petersen wrote:

 On 03-01-2012 19:47, Walter Bright wrote:

 On 1/3/2012 6:49 AM, Alex Rønne Petersen wrote:

 Perhaps some kind of experimental releases would be better. It could
 help
 getting new features out to the community (and thus tested) faster.



 We call them betas <g>.

 But anyone can pull the latest from github and use it, many do.



 That's not very practical for most users. Some kind of
 ready-to-download builds
 would be much better. As others suggested, the auto-tester publishing
 builds for
 download would be ideal.



 Using a nightly build is not very practical for most users, either,
 probably the same group.



I don't know. There are many things in DMD that are far from bug-free, 
and some people would like to actually use those features. So when fixes 
are committed, it'd be nice to just be able to switch to a nightly build.

We have to bear in mind that while D itself is fairly mature, it is 
still very much an evolving language, and thus, as is the compiler. For 
this reason, sticking to a stable release is not always practical.

- Alex
Jan 03 2012
prev sibling parent reply Sean Cavanaugh <WorksOnMyMachine gmail.com> writes:
On 1/3/2012 1:25 PM, Walter Bright wrote:

 On 1/3/2012 10:55 AM, Alex Rønne Petersen wrote:

 On 03-01-2012 19:47, Walter Bright wrote:

 On 1/3/2012 6:49 AM, Alex Rønne Petersen wrote:

 Perhaps some kind of experimental releases would be better. It could
 help
 getting new features out to the community (and thus tested) faster.



 We call them betas <g>.

 But anyone can pull the latest from github and use it, many do.



 That's not very practical for most users. Some kind of
 ready-to-download builds
 would be much better. As others suggested, the auto-tester publishing
 builds for
 download would be ideal.



 Using a nightly build is not very practical for most users, either,
 probably the same group.



Well there is always the google (and mozilla) route of force-feeding the 
latest binaries to everyone :)
Jan 03 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-01-04 00:02, Sean Cavanaugh wrote:

 On 1/3/2012 1:25 PM, Walter Bright wrote:

 On 1/3/2012 10:55 AM, Alex Rønne Petersen wrote:

 On 03-01-2012 19:47, Walter Bright wrote:

 On 1/3/2012 6:49 AM, Alex Rønne Petersen wrote:

 Perhaps some kind of experimental releases would be better. It could
 help
 getting new features out to the community (and thus tested) faster.



 We call them betas <g>.

 But anyone can pull the latest from github and use it, many do.



 That's not very practical for most users. Some kind of
 ready-to-download builds
 would be much better. As others suggested, the auto-tester publishing
 builds for
 download would be ideal.



 Using a nightly build is not very practical for most users, either,
 probably the same group.



 Well there is always the google (and mozilla) route of force-feeding the
 latest binaries to everyone :)



They don't install nightly builds, do they?

-- 
/Jacob Carlborg
Jan 03 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Alex Rønne Petersen" <xtzgzorex gmail.com> wrote in message 
news:jdviuj$16e$1 digitalmars.com...

 On 03-01-2012 19:47, Walter Bright wrote:

 On 1/3/2012 6:49 AM, Alex Rønne Petersen wrote:

 Perhaps some kind of experimental releases would be better. It could 
 help
 getting new features out to the community (and thus tested) faster.



 We call them betas <g>.

 But anyone can pull the latest from github and use it, many do.



 That's not very practical for most users. Some kind of ready-to-download 
 builds would be much better.



I don't remember if this feature has made it into a formal DVM release yet 
or not, but it's been in the main DVM master branch for awhile:


git clone https://github.com/D-Programming-Language/dmd.git
git clone https://github.com/D-Programming-Language/druntime.git
git clone https://github.com/D-Programming-Language/phobos.git
git clone https://github.com/D-Programming-Language/tools.git  # for RDMD
dvm compile
./dmd/bin32/dmd  # or ./dmd/bin64/dmd



...etc...

Of course, that completely ignores the results of the auto-tester.


 As others suggested, the auto-tester publishing builds for download would 
 be ideal.

 - Alex
Jan 03 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-01-03 20:46, Nick Sabalausky wrote:

 "Alex Rønne Petersen"<xtzgzorex gmail.com>  wrote in message
 news:jdviuj$16e$1 digitalmars.com...

 On 03-01-2012 19:47, Walter Bright wrote:

 On 1/3/2012 6:49 AM, Alex Rønne Petersen wrote:

 Perhaps some kind of experimental releases would be better. It could
 help
 getting new features out to the community (and thus tested) faster.



 We call them betas<g>.

 But anyone can pull the latest from github and use it, many do.



 That's not very practical for most users. Some kind of ready-to-download
 builds would be much better.



 I don't remember if this feature has made it into a formal DVM release yet
 or not, but it's been in the main DVM master branch for awhile:


 git clone https://github.com/D-Programming-Language/dmd.git
 git clone https://github.com/D-Programming-Language/druntime.git
 git clone https://github.com/D-Programming-Language/phobos.git
 git clone https://github.com/D-Programming-Language/tools.git  # for RDMD
 dvm compile
 ./dmd/bin32/dmd  # or ./dmd/bin64/dmd






No, it's not in a release yet, sorry. But I can make one. I was hoping 
to make DVM download the source from github automatically but I haven't 
had time to implement that yet. I've been focused on other projects lately.

-- 
/Jacob Carlborg
Jan 03 2012
prev sibling next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
On Tue, Jan 3, 2012 at 5:02 PM, Sean Cavanaugh
<WorksOnMyMachine gmail.com> wrote:

 On 1/3/2012 1:25 PM, Walter Bright wrote:

 On 1/3/2012 10:55 AM, Alex R=F8nne Petersen wrote:

 On 03-01-2012 19:47, Walter Bright wrote:

 On 1/3/2012 6:49 AM, Alex R=F8nne Petersen wrote:

 Perhaps some kind of experimental releases would be better. It could
 help
 getting new features out to the community (and thus tested) faster.




 We call them betas <g>.

 But anyone can pull the latest from github and use it, many do.




 That's not very practical for most users. Some kind of
 ready-to-download builds
 would be much better. As others suggested, the auto-tester publishing
 builds for
 download would be ideal.




 Using a nightly build is not very practical for most users, either,
 probably the same group.




 Well there is always the google (and mozilla) route of force-feeding the
 latest binaries to everyone :)



They can get away with that because their users don't really care
about versions. As long as Chrome starts and browses when I want it
to, I don't care whether Google pushes updates out behind my back.
Development tools are a different game because versions introduce
breaking changes and silently changing versions will just create a
horde of angry developers.
Jan 03 2012
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
--bcaec50165ed14eb5304b5b4ead0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Chrome and Firefox both have several different auto updating versions. For
Chrome there's stable, beta, dev channel, and canary (which is basically a
nightly build). So there are lots of opportunities for bugs to be found by
developers before they go live in the stable release channel.

--bb
Sent from my Android.
On Jan 4, 2012 1:43 AM, "Jacob Carlborg" <doob me.com> wrote:


 On 2012-01-04 00:02, Sean Cavanaugh wrote:


 On 1/3/2012 1:25 PM, Walter Bright wrote:


 On 1/3/2012 10:55 AM, Alex R=F8nne Petersen wrote:


 On 03-01-2012 19:47, Walter Bright wrote:


 On 1/3/2012 6:49 AM, Alex R=F8nne Petersen wrote:


 Perhaps some kind of experimental releases would be better. It could
 help
 getting new features out to the community (and thus tested) faster.



 We call them betas <g>.

 But anyone can pull the latest from github and use it, many do.



 That's not very practical for most users. Some kind of
 ready-to-download builds
 would be much better. As others suggested, the auto-tester publishing
 builds for
 download would be ideal.



 Using a nightly build is not very practical for most users, either,
 probably the same group.



 Well there is always the google (and mozilla) route of force-feeding the
 latest binaries to everyone :)



 They don't install nightly builds, do they?

 --
 /Jacob Carlborg



--bcaec50165ed14eb5304b5b4ead0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p>Chrome and Firefox both have several different auto updating versions. F=
or Chrome there&#39;s stable, beta, dev channel, and canary (which is basic=
ally a nightly build). So there are lots of opportunities for bugs to be fo=
und by developers before they go live in the stable release channel. </p>

<p>--bb<br>
Sent from my Android. </p>
<div class=3D"gmail_quote">On Jan 4, 2012 1:43 AM, &quot;Jacob Carlborg&quo=
t; &lt;<a href=3D"mailto:doob me.com">doob me.com</a>&gt; wrote:<br type=3D=
"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
On <a href=3D"tel:2012-01-04%2000" value=3D"+12012010400" target=3D"_blank"=

2012-01-04 00</a>:02, Sean Cavanaugh wrote:<br>



x #ccc solid;padding-left:1ex">
On 1/3/2012 1:25 PM, Walter Bright wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 1/3/2012 10:55 AM, Alex R=F8nne Petersen wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 03-01-2012 19:47, Walter Bright wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 1/3/2012 6:49 AM, Alex R=F8nne Petersen wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Perhaps some kind of experimental releases would be better. It could<br>
help<br>
getting new features out to the community (and thus tested) faster.<br>
</blockquote>
<br>
We call them betas &lt;g&gt;.<br>
<br>
But anyone can pull the latest from github and use it, many do.<br>
</blockquote>
<br>
That&#39;s not very practical for most users. Some kind of<br>
ready-to-download builds<br>
would be much better. As others suggested, the auto-tester publishing<br>
builds for<br>
download would be ideal.<br>
</blockquote>
<br>
Using a nightly build is not very practical for most users, either,<br>
probably the same group.<br>
</blockquote>
<br>
Well there is always the google (and mozilla) route of force-feeding the<br=



</blockquote>
<br>
They don&#39;t install nightly builds, do they?<br>
<br>
-- <br>
/Jacob Carlborg<br>
</blockquote></div>

--bcaec50165ed14eb5304b5b4ead0--



 Jan 04 2012