www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 1.036 and 2.020 releases

reply Walter Bright <newshound1 digitalmars.com> writes:
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.036.zip

The 2.0 version splits phobos into druntime and phobos libraries (thanks 
to Sean Kelly). This will enable both Tango and Phobos to share a common 
core library.

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

There are a lot of structural changes that go along with this, so expect 
some rough patches with this release. It may take a followup release to 
file them down. There's also some renaming of imports and function 
names, as a compromise with Tango names.
Oct 20 2008
next sibling parent Dejan Lekic <dejan.lekic tiscali.co.uk> writes:
Mr. Bright, can we please have 64bit version of DMD 2.020? 
Alternatively, we can have ability to specify where 32bit libraries are 
in the case one wishes to use DMD 2.x on 64bit Linux box.

Thanks for wonderful news, and BIG THANKS to Sean Kelly and You for 
separating the core library! It is IMHO a major step forward.

Kind regards
Oct 20 2008
prev sibling next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Tue, Oct 21, 2008 at 8:29 AM, Walter Bright
<newshound1 digitalmars.com> wrote:

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.036.zip

 The 2.0 version splits phobos into druntime and phobos libraries (thanks to
 Sean Kelly). This will enable both Tango and Phobos to share a common core
 library.

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

 There are a lot of structural changes that go along with this, so expect
 some rough patches with this release. It may take a followup release to file
 them down. There's also some renaming of imports and function names, as a
 compromise with Tango names.


Hooray for progress on mending the Tango/Phobos schism!

One question about the D2 release notes.  This one doesn't look quite right:
    OLD                         NEW
import std.array; 	import core.exception;

--bb
Oct 20 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
Bill Baxter wrote:

 On Tue, Oct 21, 2008 at 8:29 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.036.zip

 The 2.0 version splits phobos into druntime and phobos libraries (thanks to
 Sean Kelly). This will enable both Tango and Phobos to share a common core
 library.

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

 There are a lot of structural changes that go along with this, so expect
 some rough patches with this release. It may take a followup release to file
 them down. There's also some renaming of imports and function names, as a
 compromise with Tango names.


 
 Hooray for progress on mending the Tango/Phobos schism!
 
 One question about the D2 release notes.  This one doesn't look quite right:
     OLD                         NEW
 import std.array; 	import core.exception;
 
 --bb


But http://www.digitalmars.com/d/2.0/phobos/std_array.html got 404'ed, 
and std/array.d is really removed.
Oct 21 2008
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
KennyTM~ wrote:

 Bill Baxter wrote:

 On Tue, Oct 21, 2008 at 8:29 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.036.zip

 The 2.0 version splits phobos into druntime and phobos libraries 
 (thanks to
 Sean Kelly). This will enable both Tango and Phobos to share a common 
 core
 library.

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

 There are a lot of structural changes that go along with this, so expect
 some rough patches with this release. It may take a followup release 
 to file
 them down. There's also some renaming of imports and function names, 
 as a
 compromise with Tango names.


 Hooray for progress on mending the Tango/Phobos schism!

 One question about the D2 release notes.  This one doesn't look quite 
 right:
     OLD                         NEW
 import std.array;     import core.exception;

 --bb


 
 But http://www.digitalmars.com/d/2.0/phobos/std_array.html got 404'ed, 
 and std/array.d is really removed.


That's odd. I have a bunch of (uncommitted) stuff in my array.d. Of 
course, if there's any problem with the module name I can gladly change it.

Andrei
Oct 21 2008
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"KennyTM~" wrote

 Bill Baxter wrote:

 On Tue, Oct 21, 2008 at 8:29 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.036.zip

 The 2.0 version splits phobos into druntime and phobos libraries (thanks 
 to
 Sean Kelly). This will enable both Tango and Phobos to share a common 
 core
 library.

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

 There are a lot of structural changes that go along with this, so expect
 some rough patches with this release. It may take a followup release to 
 file
 them down. There's also some renaming of imports and function names, as 
 a
 compromise with Tango names.


 Hooray for progress on mending the Tango/Phobos schism!

 One question about the D2 release notes.  This one doesn't look quite 
 right:
     OLD                         NEW
 import std.array; import core.exception;

 --bb


 But http://www.digitalmars.com/d/2.0/phobos/std_array.html got 404'ed, and 
 std/array.d is really removed.


The comment for the commit is

"Removed std.array. To trap an array bounds error, import 'exception' from 
druntime and catch ArrayBoundsException."

It says nothing about the other functions that were in std.array.  Are those 
replaced by functions elsewhere?

It might have been an oversight by Sean.

-Steve
Oct 21 2008
prev sibling next sibling parent Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:
Walter Bright Wrote:


 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.036.zip
 
 The 2.0 version splits phobos into druntime and phobos libraries (thanks 
 to Sean Kelly). This will enable both Tango and Phobos to share a common 
 core library.
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.020.zip
 
 There are a lot of structural changes that go along with this, so expect 
 some rough patches with this release. It may take a followup release to 
 file them down. There's also some renaming of imports and function 
 names, as a compromise with Tango names.


Gee, Walter -- could we change 'immutable' to 'nonchangeable'? (What have you
done for me lately?)

Thank you (and Sean too!!)

Paul
Oct 20 2008
prev sibling next sibling parent reply "Craig Black" <craigblack2 cox.net> writes:
This is a huge step forward for D libraries.  Great work guys!  Is the plan 
to eventually merge Tango and Phobos?

-Craig
Oct 20 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Craig Black wrote:

 This is a huge step forward for D libraries.  Great work guys!  Is the 
 plan to eventually merge Tango and Phobos?


No plans for that at the moment. Just the ability to mix & match.
Oct 20 2008
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Walter Bright wrote:

 It may take a followup release to file them down.


Eh, I already screwed up. There was supposed to be a change in the 
Exception hierarchy. I'll have to fix that next update.
Oct 20 2008
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
I'd love to try these releases, but on a stock setup trying to compile a Hello
World, I get:

E:\dmd\bin\..\src\phobos\std\stdio.d(27): module memory cannot read file
'core\memory.d'
Oct 20 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Tue, Oct 21, 2008 at 9:16 AM, dsimcha <dsimcha yahoo.com> wrote:

 I'd love to try these releases, but on a stock setup trying to compile a Hello
 World, I get:

 E:\dmd\bin\..\src\phobos\std\stdio.d(27): module memory cannot read file
 'core\memory.d'



Assuming Windows, looks like DFLAGS aren't set right in dmd\bin\sc.ini.

Should be:
DFLAGS="-I% P%\..\src\phobos"  "-I% P%\..\src\druntime\import"


That fixes things for me.

--bb
Oct 20 2008
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Bill Baxter (wbaxter gmail.com)'s article

 On Tue, Oct 21, 2008 at 9:16 AM, dsimcha <dsimcha yahoo.com> wrote:

 I'd love to try these releases, but on a stock setup trying to compile a Hello
 World, I get:

 E:\dmd\bin\..\src\phobos\std\stdio.d(27): module memory cannot read file
 'core\memory.d'


 Assuming Windows, looks like DFLAGS aren't set right in dmd\bin\sc.ini.
 Should be:
 DFLAGS="-I% P%\..\src\phobos"  "-I% P%\..\src\druntime\import"
 That fixes things for me.
 --bb


Works.  Thanks.  Now I just get weird, inscrutable linker errors.  This one
might
be a little too bleeding edge even for me.
Oct 20 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Tue, Oct 21, 2008 at 9:39 AM, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from Bill Baxter (wbaxter gmail.com)'s article

 On Tue, Oct 21, 2008 at 9:16 AM, dsimcha <dsimcha yahoo.com> wrote:

 I'd love to try these releases, but on a stock setup trying to compile a Hello
 World, I get:

 E:\dmd\bin\..\src\phobos\std\stdio.d(27): module memory cannot read file
 'core\memory.d'


 Assuming Windows, looks like DFLAGS aren't set right in dmd\bin\sc.ini.
 Should be:
 DFLAGS="-I% P%\..\src\phobos"  "-I% P%\..\src\druntime\import"
 That fixes things for me.
 --bb


 Works.  Thanks.  Now I just get weird, inscrutable linker errors.  This one
might
 be a little too bleeding edge even for me.


Even with Hello World?  That one linked and ran fine for me after
adding the druntime include.

--bb
Oct 20 2008
next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Bill Baxter (wbaxter gmail.com)'s article

 On Tue, Oct 21, 2008 at 9:39 AM, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from Bill Baxter (wbaxter gmail.com)'s article

 On Tue, Oct 21, 2008 at 9:16 AM, dsimcha <dsimcha yahoo.com> wrote:

 I'd love to try these releases, but on a stock setup trying to compile a Hello
 World, I get:

 E:\dmd\bin\..\src\phobos\std\stdio.d(27): module memory cannot read file
 'core\memory.d'


 Assuming Windows, looks like DFLAGS aren't set right in dmd\bin\sc.ini.
 Should be:
 DFLAGS="-I% P%\..\src\phobos"  "-I% P%\..\src\druntime\import"
 That fixes things for me.
 --bb


 Works.  Thanks.  Now I just get weird, inscrutable linker errors.  This one
might
 be a little too bleeding edge even for me.


 Even with Hello World?  That one linked and ran fine for me after
 adding the druntime include.
 --bb


No, but with anything much more complex, like a small home-brew statistics lib
I'm
trying to port.  I'm sure it's just some silly thing.  I'll figure it out
eventually.
Oct 20 2008
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Bill Baxter (wbaxter gmail.com)'s article

 On Tue, Oct 21, 2008 at 9:39 AM, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from Bill Baxter (wbaxter gmail.com)'s article

 On Tue, Oct 21, 2008 at 9:16 AM, dsimcha <dsimcha yahoo.com> wrote:

 I'd love to try these releases, but on a stock setup trying to compile a Hello
 World, I get:

 E:\dmd\bin\..\src\phobos\std\stdio.d(27): module memory cannot read file
 'core\memory.d'


 Assuming Windows, looks like DFLAGS aren't set right in dmd\bin\sc.ini.
 Should be:
 DFLAGS="-I% P%\..\src\phobos"  "-I% P%\..\src\druntime\import"
 That fixes things for me.
 --bb


 Works.  Thanks.  Now I just get weird, inscrutable linker errors.  This one
might
 be a little too bleeding edge even for me.


 Even with Hello World?  That one linked and ran fine for me after
 adding the druntime include.
 --bb


Ok, looks like DMD isn't finding Object properly, using stock config except for
Bill Baxter's change to sc.ini.

class Foo {}

void main() {
    auto foo = new Foo;
}

 Error 42: Symbol Undefined _D6object6Object5printMFZv

Seriously, though, Walter, thank you very much for this release.  You have done
a
tremendous job bringing us a better language.  Merging the Phobos and Tango
runtime is a monumental task (Sean, thank you, too) and a few bumps along the
road
are definitely understandable.
Oct 20 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Tue, Oct 21, 2008 at 10:59 AM, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from Bill Baxter (wbaxter gmail.com)'s article

 On Tue, Oct 21, 2008 at 9:39 AM, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from Bill Baxter (wbaxter gmail.com)'s article

 On Tue, Oct 21, 2008 at 9:16 AM, dsimcha <dsimcha yahoo.com> wrote:

 I'd love to try these releases, but on a stock setup trying to compile a Hello
 World, I get:

 E:\dmd\bin\..\src\phobos\std\stdio.d(27): module memory cannot read file
 'core\memory.d'


 Assuming Windows, looks like DFLAGS aren't set right in dmd\bin\sc.ini.
 Should be:
 DFLAGS="-I% P%\..\src\phobos"  "-I% P%\..\src\druntime\import"
 That fixes things for me.
 --bb


 Works.  Thanks.  Now I just get weird, inscrutable linker errors.  This one
might
 be a little too bleeding edge even for me.


 Even with Hello World?  That one linked and ran fine for me after
 adding the druntime include.
 --bb


 Ok, looks like DMD isn't finding Object properly, using stock config except for
 Bill Baxter's change to sc.ini.

 class Foo {}

 void main() {
    auto foo = new Foo;
 }

  Error 42: Symbol Undefined _D6object6Object5printMFZv

 Seriously, though, Walter, thank you very much for this release.  You have
done a
 tremendous job bringing us a better language.  Merging the Phobos and Tango
 runtime is a monumental task (Sean, thank you, too) and a few bumps along the
road
 are definitely understandable.


Hmm, first off it looks like druntime.lib doesn't exist in the D2 download.
I was able to build it by running build-dmd.bat in one of the druntime
subdirectories.

But there's more to it than that.

There's an object.d in src/phobos with a prototype for a print() function.
But the object.di in src/druntime/import does not have a print() function.

So maybe the phobos.lib included was built using the old object.d
instead of the new one from druntime?

--bb
Oct 20 2008
next sibling parent Sergey Gromov <snake.scaly gmail.com> writes:
Tue, 21 Oct 2008 11:19:22 +0900,
Bill Baxter wrote:

 On Tue, Oct 21, 2008 at 10:59 AM, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from Bill Baxter (wbaxter gmail.com)'s article

 On Tue, Oct 21, 2008 at 9:39 AM, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from Bill Baxter (wbaxter gmail.com)'s article

 On Tue, Oct 21, 2008 at 9:16 AM, dsimcha <dsimcha yahoo.com> wrote:

 I'd love to try these releases, but on a stock setup trying to compile a Hello
 World, I get:

 E:\dmd\bin\..\src\phobos\std\stdio.d(27): module memory cannot read file
 'core\memory.d'


 Assuming Windows, looks like DFLAGS aren't set right in dmd\bin\sc.ini.
 Should be:
 DFLAGS="-I% P%\..\src\phobos"  "-I% P%\..\src\druntime\import"
 That fixes things for me.
 --bb


 Works.  Thanks.  Now I just get weird, inscrutable linker errors.  This one
might
 be a little too bleeding edge even for me.


 Even with Hello World?  That one linked and ran fine for me after
 adding the druntime include.
 --bb


 Ok, looks like DMD isn't finding Object properly, using stock config except for
 Bill Baxter's change to sc.ini.

 class Foo {}

 void main() {
    auto foo = new Foo;
 }

  Error 42: Symbol Undefined _D6object6Object5printMFZv

 Seriously, though, Walter, thank you very much for this release.  You have
done a
 tremendous job bringing us a better language.  Merging the Phobos and Tango
 runtime is a monumental task (Sean, thank you, too) and a few bumps along the
road
 are definitely understandable.


 
 Hmm, first off it looks like druntime.lib doesn't exist in the D2 download.
 I was able to build it by running build-dmd.bat in one of the druntime
 subdirectories.
 
 But there's more to it than that.
 
 There's an object.d in src/phobos with a prototype for a print() function.
 But the object.di in src/druntime/import does not have a print() function.
 
 So maybe the phobos.lib included was built using the old object.d
 instead of the new one from druntime?


You need to delete the src/phobos/object.d.  Then 
src/druntime/import/object.di is included instead and everything starts 
to work (for some simple projects at least).  Building druntime.lib 
doesn't seem to be required.

I think it's also a good idea to delete src/phobos/std/gc.d because it's 
not in the libs.  You have to use core.memory instead.
Oct 20 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:

 But there's more to it than that.
 
 There's an object.d in src/phobos with a prototype for a print() function.
 But the object.di in src/druntime/import does not have a print() function.
 
 So maybe the phobos.lib included was built using the old object.d
 instead of the new one from druntime?


I see the problem. The phobos.lib was built correctly, but I'd forgotten 
to remove the old object.d. If you simply delete 
/dmd/src/phobos/object.d, it should work.
Oct 20 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Walter Bright wrote:

 I see the problem. The phobos.lib was built correctly, but I'd forgotten 
 to remove the old object.d. If you simply delete 
 /dmd/src/phobos/object.d, it should work.


I removed them from the zip file.
Oct 20 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Mon, 20 Oct 2008 19:56:01 -0700,
Walter Bright wrote:

 Walter Bright wrote:

 I see the problem. The phobos.lib was built correctly, but I'd forgotten 
 to remove the old object.d. If you simply delete 
 /dmd/src/phobos/object.d, it should work.


 
 I removed them from the zip file.


Still a problem in dmd.conf:

  -I% P%/../src/runtime/import

should be

  -I% P%/../src/druntime/import

note the 'd' in 'druntime'
Oct 21 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Sergey Gromov wrote:

 note the 'd' in 'druntime'


Sigh, I seem to have a hard time getting this right!
Oct 21 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Bill Baxter wrote:

 On Tue, Oct 21, 2008 at 10:59 AM, dsimcha <dsimcha yahoo.com> wrote:

 Seriously, though, Walter, thank you very much for this release.  You have
done a
 tremendous job bringing us a better language.  Merging the Phobos and Tango
 runtime is a monumental task (Sean, thank you, too) and a few bumps along the
road
 are definitely understandable.


 
 Hmm, first off it looks like druntime.lib doesn't exist in the D2 download.
 I was able to build it by running build-dmd.bat in one of the druntime
 subdirectories.
 
 But there's more to it than that.
 
 There's an object.d in src/phobos with a prototype for a print() function.
 But the object.di in src/druntime/import does not have a print() function.
 
 So maybe the phobos.lib included was built using the old object.d
 instead of the new one from druntime?


I have family visiting and haven't been online much the past few days as 
a result.  But from a quick perusal these are some issues with the 
current release:

* ship druntime.lib in dmd/lib
* remove object.d and errno.c from phobos/
* modify DFLAGS to reference the druntime import path

Also, something will have to be done about druntime including a 'std' 
package in its import directory.  I'd say just remove it for now, but 
hopefully at some point it won't be necessary to retain it at all (the 
reasons for it being there are somewhat weird).  This shouldn't affect 
use of the current release, though you may have to place the phobos 
directory first in your import path list.

Finally, I still need to look over the core.memory.GC.xxxHandle() 
routines, which were added by necessity just prior to release.  The 
basic functionality will remain, but names may be changed to protect the 
innocent, etc.

If anyone runs across any other issues, please submit a ticket on 
dsource or the puremagic site as appropriate, or simply post them here.

By the way... thank you all for testing this out.  I know the initial 
release is a bit rough, but hopefully things will be smoothed out soon. 
  Once DMD is sorted I'll be porting the GDC runtime as well.  I just 
wanted to get one distro sorted out first before dealing with the others.


Sean
Oct 20 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Sean Kelly wrote:

 Bill Baxter wrote:

 On Tue, Oct 21, 2008 at 10:59 AM, dsimcha <dsimcha yahoo.com> wrote:

 Seriously, though, Walter, thank you very much for this release.  You 
 have done a
 tremendous job bringing us a better language.  Merging the Phobos and 
 Tango
 runtime is a monumental task (Sean, thank you, too) and a few bumps 
 along the road
 are definitely understandable.


 Hmm, first off it looks like druntime.lib doesn't exist in the D2 
 download.
 I was able to build it by running build-dmd.bat in one of the druntime
 subdirectories.

 But there's more to it than that.

 There's an object.d in src/phobos with a prototype for a print() 
 function.
 But the object.di in src/druntime/import does not have a print() 
 function.

 So maybe the phobos.lib included was built using the old object.d
 instead of the new one from druntime?


 
 I have family visiting and haven't been online much the past few days as 
 a result.  But from a quick perusal these are some issues with the 
 current release:
 
 * ship druntime.lib in dmd/lib
 * remove object.d and errno.c from phobos/
 * modify DFLAGS to reference the druntime import path
 
 Also, something will have to be done about druntime including a 'std' 
 package in its import directory.  I'd say just remove it for now, but 
 hopefully at some point it won't be necessary to retain it at all (the 
 reasons for it being there are somewhat weird).  This shouldn't affect 
 use of the current release, though you may have to place the phobos 
 directory first in your import path list.
 
 Finally, I still need to look over the core.memory.GC.xxxHandle() 
 routines, which were added by necessity just prior to release.  The 
 basic functionality will remain, but names may be changed to protect the 
 innocent, etc.
 
 If anyone runs across any other issues, please submit a ticket on 
 dsource or the puremagic site as appropriate, or simply post them here.
 
 By the way... thank you all for testing this out.  I know the initial 
 release is a bit rough, but hopefully things will be smoothed out soon. 
  Once DMD is sorted I'll be porting the GDC runtime as well.  I just 
 wanted to get one distro sorted out first before dealing with the others.
 
 
 Sean


Thanks to you & Walter for all your hard work.
Oct 21 2008
parent Leandro Lucarella <llucax gmail.com> writes:
Robert Fraser, el 21 de octubre a las 03:09 me escribiste:

 Thanks to you & Walter for all your hard work.


ditto =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
El día que falten los niños, que sobren las mujeres y que se prenda
fuego el último árbol, será el Apocalípsis.
	-- Ricardo Vaporeso. Camino Negro, 1916.
Oct 21 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:

 Assuming Windows, looks like DFLAGS aren't set right in dmd\bin\sc.ini.


You're right. sc.ini should be:


 [Version]
 version=7.51 Build 020
 
 [Environment]
 LIB="% P%\..\lib";\dm\lib
 DFLAGS="-I% P%\..\src\phobos -I% P%\..\src\druntime\import"
 LINKCMD=% P%\..\..\dm\bin\link.exe


and dmd.conf should be:


 
 [Environment]
 
 DFLAGS=-I% P%/../src/phobos -I% P%/../src/runtime/import -L-L% P%/../lib
Oct 20 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Tue, Oct 21, 2008 at 9:45 AM, Walter Bright
<newshound1 digitalmars.com> wrote:

 Bill Baxter wrote:

 Assuming Windows, looks like DFLAGS aren't set right in dmd\bin\sc.ini.


 You're right. sc.ini should be:


 [Version]
 version=7.51 Build 020

 [Environment]
 LIB="% P%\..\lib";\dm\lib
 DFLAGS="-I% P%\..\src\phobos -I% P%\..\src\druntime\import"




Actually it doesn't work for me with the whole string as one big
quote.  I had to split it into two quotes like I posted it before:

    DFLAGS="-I% P%\..\src\phobos"  "-I% P%\..\src\druntime\import"

--bb
Oct 20 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
You're right again.
Oct 20 2008
prev sibling next sibling parent John Reimer <terminal.node gmail.com> writes:
Hello Walter,


 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.036.zip
 The 2.0 version splits phobos into druntime and phobos libraries
 (thanks to Sean Kelly). This will enable both Tango and Phobos to
 share a common core library.
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.020.zip
 There are a lot of structural changes that go along with this, so
 expect some rough patches with this release. It may take a followup
 release to file them down. There's also some renaming of imports and
 function names, as a compromise with Tango names.
 



Thank you! :)

-JJR
Oct 20 2008
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Thank you Walter, this step improves D2 significantly :-)

I have seen that's there's an improvement in the AAs in D1 too, I'll do few
benchmarks.

I have also seen this nasty bug fixed in D2:
http://d.puremagic.com/issues/show_bug.cgi?id=2333
Can't it be fixed in D1 too?

Bye,
bearophile
Oct 20 2008
parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Mon, Oct 20, 2008 at 10:40 PM, bearophile <bearophileHUGS lycos.com> wrote:

 Thank you Walter, this step improves D2 significantly :-)

 I have seen that's there's an improvement in the AAs in D1 too, I'll do few
benchmarks.

 I have also seen this nasty bug fixed in D2:
 http://d.puremagic.com/issues/show_bug.cgi?id=2333
 Can't it be fixed in D1 too?

 Bye,
 bearophile


As far as I know that bug exists only in D2.  I remember being
confused about this before; it works fine in D1.
Oct 20 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Jarrett Billingsley:

 As far as I know that bug exists only in D2.  I remember being
 confused about this before; it works fine in D1.


Ah, I see. Sorry for bothering then.

A note: 1.036 has compiled successfully all my code :-)

Bye,
bearophile
Oct 20 2008
prev sibling next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Walter Bright Wrote:


 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.036.zip
 
 The 2.0 version splits phobos into druntime and phobos libraries (thanks 
 to Sean Kelly). This will enable both Tango and Phobos to share a common 
 core library.
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.020.zip
 
 There are a lot of structural changes that go along with this, so expect 
 some rough patches with this release. It may take a followup release to 
 file them down. There's also some renaming of imports and function 
 names, as a compromise with Tango names.


Great news! thank you Sean And Walter for this important first step. I hope the
rest of the tango/phobos issue will be sorted out as well..
Oct 20 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Yigal Chripun wrote:

 Walter Bright Wrote:
 

 http://www.digitalmars.com/d/1.0/changelog.html 
 http://ftp.digitalmars.com/dmd.1.036.zip
 
 The 2.0 version splits phobos into druntime and phobos libraries
 (thanks to Sean Kelly). This will enable both Tango and Phobos to
 share a common core library.
 
 http://www.digitalmars.com/d/2.0/changelog.html 
 http://ftp.digitalmars.com/dmd.2.020.zip
 
 There are a lot of structural changes that go along with this, so
 expect some rough patches with this release. It may take a followup
 release to file them down. There's also some renaming of imports
 and function names, as a compromise with Tango names.


 
 Great news! thank you Sean And Walter for this important first step.
 I hope the rest of the tango/phobos issue will be sorted out as
 well..


I was hoping there is no more issue. The common runtime levels the 
ground for library interoperability.

Andrei
Oct 20 2008
next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Andrei Alexandrescu wrote:

 Yigal Chripun wrote:

 Walter Bright Wrote:


 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.036.zip

 The 2.0 version splits phobos into druntime and phobos libraries
 (thanks to Sean Kelly). This will enable both Tango and Phobos to
 share a common core library.

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

 There are a lot of structural changes that go along with this, so
 expect some rough patches with this release. It may take a followup
 release to file them down. There's also some renaming of imports
 and function names, as a compromise with Tango names.


 Great news! thank you Sean And Walter for this important first step.
 I hope the rest of the tango/phobos issue will be sorted out as
 well..


 
 I was hoping there is no more issue. The common runtime levels the
 ground for library interoperability.
 
 Andrei
 


What I meant was that now that the runtime is unified the next step
would be to unify the user APIs.
You've posted in the NG your intention to re-implement several key
modules in phobos including IO and algorithm, I'm hoping that instead of
two separate IO systems (tango and phobos) you could use the Tango IO
and implement your Range proposal on top of it. Others already suggested
that on this NG.
I know that there are license issues with this which I don't understand.
 both Tango and Phobos use very liberal open-source licenses so all is
needed to use Tango code legally in the future unified standard library
is to comply with the restrictions which IIRC require only
acknowledgment. IANAL but all those differences between open source
licenses shouldn't be a big deal.
Oct 20 2008
parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Yigal Chripun" <yigal100 gmail.com> wrote in message 
news:gdjqd6$2mia$1 digitalmars.com...

 You've posted in the NG your intention to re-implement several key
 modules in phobos including IO and algorithm, I'm hoping that instead of
 two separate IO systems (tango and phobos) you could use the Tango IO
 and implement your Range proposal on top of it. Others already suggested
 that on this NG.


There are good reasons for keeping the IO separate. Phobos is based on the C 
runtime, meaning you can interleave D IO with C IO and everything will 
behave nicely. Tango's IO layer is written from scratch, using OS calls. You 
shouldn't mix Tango IO with IO in a linked-in C library.

L.
Oct 20 2008
parent Yigal Chripun <yigal100 gmail.com> writes:
Lionello Lunesu wrote:

 
 "Yigal Chripun" <yigal100 gmail.com> wrote in message
 news:gdjqd6$2mia$1 digitalmars.com...

 You've posted in the NG your intention to re-implement several key
 modules in phobos including IO and algorithm, I'm hoping that instead of
 two separate IO systems (tango and phobos) you could use the Tango IO
 and implement your Range proposal on top of it. Others already suggested
 that on this NG.


 
 There are good reasons for keeping the IO separate. Phobos is based on
 the C runtime, meaning you can interleave D IO with C IO and everything
 will behave nicely. Tango's IO layer is written from scratch, using OS
 calls. You shouldn't mix Tango IO with IO in a linked-in C library.
 
 L.


IMHO, Tango's IO is a better default for D exactly because it's written
from scratch specifically for D. the benefits are better performance and
no dependence on the C stdlib.
interleaving D IO with C IO is also possible with tango, with the
relevant stdc modules, but that should IMHO be an opt-in feature.
Oct 21 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote

 Yigal Chripun wrote:

 Walter Bright Wrote:


 http://www.digitalmars.com/d/1.0/changelog.html 
 http://ftp.digitalmars.com/dmd.1.036.zip

 The 2.0 version splits phobos into druntime and phobos libraries
 (thanks to Sean Kelly). This will enable both Tango and Phobos to
 share a common core library.

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

 There are a lot of structural changes that go along with this, so
 expect some rough patches with this release. It may take a followup
 release to file them down. There's also some renaming of imports
 and function names, as a compromise with Tango names.


 Great news! thank you Sean And Walter for this important first step.
 I hope the rest of the tango/phobos issue will be sorted out as
 well..


 I was hoping there is no more issue. The common runtime levels the ground 
 for library interoperability.


one big issue:  druntime only supported with phobos using D2. but Tango only 
supports D1 ;)

But some of us are working to get Tango to compile on D2 (it does currently, 
but Tango is not fully constified yet).

I think I'll wait until some of the dust settles before trying to build 
Tango with D2 druntime.

Thanks for the efforts!

-Steve
Oct 21 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:

 one big issue:  druntime only supported with phobos using D2.


That's because the druntime support is a breaking change for Phobos users.


 Thanks for the efforts!


You're welcome!
Oct 21 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Walter Bright" wrote

 Steven Schveighoffer wrote:

 one big issue:  druntime only supported with phobos using D2.


 That's because the druntime support is a breaking change for Phobos users.


Yes, I wasn't suggesting it should be done for D1, what I was saying is the 
magical land where Tango and Phobos apps live together in harmony is not 
available yet ;)  Which is part of the reason why several of us Tango devs 
are working on a D2 branch.

-Steve
Oct 21 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:

 Yes, I wasn't suggesting it should be done for D1, what I was saying is the 
 magical land where Tango and Phobos apps live together in harmony is not 
 available yet ;)  Which is part of the reason why several of us Tango devs 
 are working on a D2 branch.


Right!
Oct 21 2008
prev sibling next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Walter,


 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.036.zip
 The 2.0 version splits phobos into druntime and phobos libraries
 (thanks to Sean Kelly). This will enable both Tango and Phobos to
 share a common core library.
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.020.zip
 There are a lot of structural changes that go along with this, so
 expect some rough patches with this release. It may take a followup
 release to file them down. There's also some renaming of imports and
 function names, as a compromise with Tango names.
 


I have been ignoring the tango/phobos stuff for the most part because it's 
not something I have time for. :(

Will D1.0 ever get the same fix-up?
Oct 20 2008
next sibling parent "Saaa" <empty needmail.com> writes:
bump

 Will D1.0 ever get the same fix-up?
Oct 20 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:

 Will D1.0 ever get the same fix-up?


No, as there are many changes that break existing code.
Oct 21 2008
prev sibling next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Tue, Oct 21, 2008 at 8:29 AM, Walter Bright
<newshound1 digitalmars.com> wrote:

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.036.zip

 The 2.0 version splits phobos into druntime and phobos libraries (thanks to
 Sean Kelly). This will enable both Tango and Phobos to share a common core
 library.

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

 There are a lot of structural changes that go along with this, so expect
 some rough patches with this release. It may take a followup release to file
 them down. There's also some renaming of imports and function names, as a
 compromise with Tango names.


Wao!  Missed this at first:

class Foo
{
    ref int getref() {
        return m_int;
    }
private:
    int m_int = 23;
}

void main() {
    auto foo = new Foo;

    writefln(foo.getref);
    foo.getref() = 7;
    writefln(foo.getref);
}
//Outputs:
//23
//7

It works!  This is maybe even bigger news than cure for TangoPhobia!

But I think maybe more documentation is needed in the Ref returns
section regarding how this affects opIndex.

class Foo
{
    this() {
        m_arr.length = 10;
        foreach(i, ref a; m_arr) { a=i;}
    }
    int[] array() {
        return m_arr;
    }
    ref int opIndex(size_t idx) {
        return m_arr[idx];
    }

private:
    int[] m_arr;
}

void main() {
    auto foo = new Foo;
    foo[3] = -99;
//hello.d(44): Error: operator [] assignment overload with opIndex(i,
value) illegal, use opIndexAssign(value, i)
//hello.d(44): function hello.Foo.opIndex (uint idx) does not match
parameter types (int,int)
//hello.d(44): Error: expected 1 arguments, not 2
}

Apparently using opIndex with ref return is not allowed as a way to
set an index.
This works though:

    *(&foo[3]) = -99;

Is there a good reason why it shouldn't be possible to use opAssign as
a replacement for opIndexAssign?

--bb
Oct 20 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Bill Baxter" <wbaxter gmail.com> wrote in message 
news:mailman.186.1224567134.3087.digitalmars-d-announce puremagic.com...

 On Tue, Oct 21, 2008 at 8:29 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.036.zip

 The 2.0 version splits phobos into druntime and phobos libraries (thanks 
 to
 Sean Kelly). This will enable both Tango and Phobos to share a common 
 core
 library.

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

 There are a lot of structural changes that go along with this, so expect
 some rough patches with this release. It may take a followup release to 
 file
 them down. There's also some renaming of imports and function names, as a
 compromise with Tango names.


 Wao!  Missed this at first:

 class Foo
 {
    ref int getref() {
        return m_int;
    }
 private:
    int m_int = 23;
 }

 void main() {
    auto foo = new Foo;

    writefln(foo.getref);
    foo.getref() = 7;
    writefln(foo.getref);
 }
 //Outputs:
 //23
 //7

 It works!  This is maybe even bigger news than cure for TangoPhobia!

 But I think maybe more documentation is needed in the Ref returns
 section regarding how this affects opIndex.

 class Foo
 {
    this() {
        m_arr.length = 10;
        foreach(i, ref a; m_arr) { a=i;}
    }
    int[] array() {
        return m_arr;
    }
    ref int opIndex(size_t idx) {
        return m_arr[idx];
    }

 private:
    int[] m_arr;
 }

 void main() {
    auto foo = new Foo;
    foo[3] = -99;
 //hello.d(44): Error: operator [] assignment overload with opIndex(i,
 value) illegal, use opIndexAssign(value, i)
 //hello.d(44): function hello.Foo.opIndex (uint idx) does not match
 parameter types (int,int)
 //hello.d(44): Error: expected 1 arguments, not 2
 }

 Apparently using opIndex with ref return is not allowed as a way to
 set an index.
 This works though:

    *(&foo[3]) = -99;

 Is there a good reason why it shouldn't be possible to use opAssign as
 a replacement for opIndexAssign?


I think it should be a bug.  I believe Andrei fully intended to use it this 
way.

-Steve
Oct 21 2008
prev sibling next sibling parent reply Extrawurst <spam extrawurst.org> writes:
Walter Bright wrote:

 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.036.zip
 
 The 2.0 version splits phobos into druntime and phobos libraries (thanks 
 to Sean Kelly). This will enable both Tango and Phobos to share a common 
 core library.
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.020.zip
 
 There are a lot of structural changes that go along with this, so expect 
 some rough patches with this release. It may take a followup release to 
 file them down. There's also some renaming of imports and function 
 names, as a compromise with Tango names.



Sounds great !

But why is it that since 2.020 i cannot name a package "shared" anymore?

moudle shared.foo;

dmd: "Identifier expected following module"

WTF ?
Oct 21 2008
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Extrawurst wrote:


 Walter Bright wrote:

 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.036.zip
 
 The 2.0 version splits phobos into druntime and phobos libraries (thanks
 to Sean Kelly). This will enable both Tango and Phobos to share a common
 core library.
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.020.zip
 
 There are a lot of structural changes that go along with this, so expect
 some rough patches with this release. It may take a followup release to
 file them down. There's also some renaming of imports and function
 names, as a compromise with Tango names.


 
 
 Sounds great !
 
 But why is it that since 2.020 i cannot name a package "shared" anymore?
 
 moudle shared.foo;
 
 dmd: "Identifier expected following module"
 
 WTF ?


Because shared is now a keyword.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
Oct 21 2008
parent reply Extrawurst <spam extrawurst.org> writes:
Lars Ivar Igesund wrote:

 Extrawurst wrote:
 

 Walter Bright wrote:

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.036.zip

 The 2.0 version splits phobos into druntime and phobos libraries (thanks
 to Sean Kelly). This will enable both Tango and Phobos to share a common
 core library.

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

 There are a lot of structural changes that go along with this, so expect
 some rough patches with this release. It may take a followup release to
 file them down. There's also some renaming of imports and function
 names, as a compromise with Tango names.


 Sounds great !

 But why is it that since 2.020 i cannot name a package "shared" anymore?

 moudle shared.foo;

 dmd: "Identifier expected following module"

 WTF ?


 
 Because shared is now a keyword.
 


Ok, what is it for ? Where is it documented ? Or is it another reserved 
keyword like "macro" is ?
Oct 21 2008
next sibling parent KennyTM~ <kennytm gmail.com> writes:
Extrawurst wrote:

 Lars Ivar Igesund wrote:

 Extrawurst wrote:


 Walter Bright wrote:

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.036.zip

 The 2.0 version splits phobos into druntime and phobos libraries 
 (thanks
 to Sean Kelly). This will enable both Tango and Phobos to share a 
 common
 core library.

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

 There are a lot of structural changes that go along with this, so 
 expect
 some rough patches with this release. It may take a followup release to
 file them down. There's also some renaming of imports and function
 names, as a compromise with Tango names.


 Sounds great !

 But why is it that since 2.020 i cannot name a package "shared" anymore?

 moudle shared.foo;

 dmd: "Identifier expected following module"

 WTF ?


 Because shared is now a keyword.


 
 Ok, what is it for ? Where is it documented ? Or is it another reserved 
 keyword like "macro" is ?


shared & unshared memories for parallel computing IIRC.
Oct 21 2008
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Extrawurst Wrote:


 But why is it that since 2.020 i cannot name a package "shared" anymore?

 moudle shared.foo;

 dmd: "Identifier expected following module"

 WTF ?


 
 Because shared is now a keyword.
 


 
 Ok, what is it for ? Where is it documented ? Or is it another reserved 
 keyword like "macro" is ?


There was a long discussion on digitalmars.d about this.  It's definitely
coming in the short term.  It was on Walter's top 5 a week or so ago... along
with integrating druntime, ref return values, and implementing immutable.  I
don't recall the whole list, but he's definitely working on this.

This is part of the change to allow thread local storage and have non-local
objects marked as shared.  Shared objects would have a number of volatile-like
properties.  I'm sure I've butchered the whole topic in trying to do a summary
in a sentence or two, but it should give you the general idea of what it is and
why the word has become a keyword.
Oct 21 2008
parent Extrawurst <spam extrawurst.org> writes:
Jason House wrote:

 Extrawurst Wrote:
 

 But why is it that since 2.020 i cannot name a package "shared" anymore?

 moudle shared.foo;

 dmd: "Identifier expected following module"

 WTF ?


 Because shared is now a keyword.


 Ok, what is it for ? Where is it documented ? Or is it another reserved 
 keyword like "macro" is ?


 
 There was a long discussion on digitalmars.d about this.  It's definitely
coming in the short term.  It was on Walter's top 5 a week or so ago... along
with integrating druntime, ref return values, and implementing immutable.  I
don't recall the whole list, but he's definitely working on this.
 
 This is part of the change to allow thread local storage and have non-local
objects marked as shared.  Shared objects would have a number of volatile-like
properties.  I'm sure I've butchered the whole topic in trying to do a summary
in a sentence or two, but it should give you the general idea of what it is and
why the word has become a keyword.


Ok thank you for the summary.
Oct 21 2008
prev sibling next sibling parent reply Don <nospam nospam.com.au> writes:
Walter Bright wrote:

 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.036.zip
 
 The 2.0 version splits phobos into druntime and phobos libraries (thanks 
 to Sean Kelly). This will enable both Tango and Phobos to share a common 
 core library.
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.020.zip
 
 There are a lot of structural changes that go along with this, so expect 
 some rough patches with this release. It may take a followup release to 
 file them down. There's also some renaming of imports and function 
 names, as a compromise with Tango names.


Thanks Walter. This is a great day!

One rough patch:
Phobos docs don't include the new 'core' modules, except core.memory 
which appears where std.gc used to be.

We also now have two modules called 'bitmanip', which is somewhat ironic 
since we brainstormed for ages trying to come up with a better name for 
it. Modules with duplicate names have caused linking problems in the 
past -- not sure if that applies here.
Oct 21 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Don wrote:

 
 We also now have two modules called 'bitmanip', which is somewhat ironic 
 since we brainstormed for ages trying to come up with a better name for 
 it. Modules with duplicate names have caused linking problems in the 
 past -- not sure if that applies here.


It applies if the modules from both Phobos and druntime end up in the 
same library on *nix.  Windows doesn't appear to have the same issue. 
But I'd love to hear suggestions for alternative names-- I'm not 
terribly good at naming modules :-p.

Also, any I'd like to see how people feel about having three top-level 
packages in druntime vs. one-- an alternative I'd considered was to put 
everything under core.


Sean
Oct 21 2008
next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Tue, 21 Oct 2008 09:40:28 -0700,
Sean Kelly wrote:

 Don wrote:

 
 We also now have two modules called 'bitmanip', which is somewhat ironic 
 since we brainstormed for ages trying to come up with a better name for 
 it. Modules with duplicate names have caused linking problems in the 
 past -- not sure if that applies here.


 
 It applies if the modules from both Phobos and druntime end up in the 
 same library on *nix.  Windows doesn't appear to have the same issue. 
 But I'd love to hear suggestions for alternative names-- I'm not 
 terribly good at naming modules :-p.
 
 Also, any I'd like to see how people feel about having three top-level 
 packages in druntime vs. one-- an alternative I'd considered was to put 
 everything under core.


I actually was expecting all the runtime stuff to be in core.* and was 
surprised to find std and sys there.
Oct 21 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Sergey Gromov wrote:

 Tue, 21 Oct 2008 09:40:28 -0700,
 Sean Kelly wrote:

 Don wrote:

 We also now have two modules called 'bitmanip', which is somewhat ironic 
 since we brainstormed for ages trying to come up with a better name for 
 it. Modules with duplicate names have caused linking problems in the 
 past -- not sure if that applies here.


 It applies if the modules from both Phobos and druntime end up in the 
 same library on *nix.  Windows doesn't appear to have the same issue. 
 But I'd love to hear suggestions for alternative names-- I'm not 
 terribly good at naming modules :-p.

 Also, any I'd like to see how people feel about having three top-level 
 packages in druntime vs. one-- an alternative I'd considered was to put 
 everything under core.


 
 I actually was expecting all the runtime stuff to be in core.* and was 
 surprised to find std and sys there.


I didn't even create core until just recently--before that, the modules 
in core were global, much like object.  So my thoughts on the druntime 
package layout are still evolving.  I do now think that having a single 
top-level package would probably be best, but figured I'd solicit 
opinions before changing anything.


Sean
Oct 21 2008
next sibling parent Extrawurst <spam extrawurst.org> writes:
Sean Kelly wrote:

 Sergey Gromov wrote:

 Tue, 21 Oct 2008 09:40:28 -0700,
 Sean Kelly wrote:

 Don wrote:

 We also now have two modules called 'bitmanip', which is somewhat 
 ironic since we brainstormed for ages trying to come up with a 
 better name for it. Modules with duplicate names have caused linking 
 problems in the past -- not sure if that applies here.


 It applies if the modules from both Phobos and druntime end up in the 
 same library on *nix.  Windows doesn't appear to have the same issue. 
 But I'd love to hear suggestions for alternative names-- I'm not 
 terribly good at naming modules :-p.

 Also, any I'd like to see how people feel about having three 
 top-level packages in druntime vs. one-- an alternative I'd 
 considered was to put everything under core.


 I actually was expecting all the runtime stuff to be in core.* and was 
 surprised to find std and sys there.


 
 I didn't even create core until just recently--before that, the modules 
 in core were global, much like object.  So my thoughts on the druntime 
 package layout are still evolving.  I do now think that having a single 
 top-level package would probably be best, but figured I'd solicit 
 opinions before changing anything.
 
 
 Sean


I am all for one toplevel package too.
Oct 21 2008
prev sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Tue, 21 Oct 2008 11:04:56 -0700,
Sean Kelly wrote:

 Sergey Gromov wrote:

 Tue, 21 Oct 2008 09:40:28 -0700,
 Sean Kelly wrote:

 Don wrote:

 We also now have two modules called 'bitmanip', which is somewhat ironic 
 since we brainstormed for ages trying to come up with a better name for 
 it. Modules with duplicate names have caused linking problems in the 
 past -- not sure if that applies here.


 It applies if the modules from both Phobos and druntime end up in the 
 same library on *nix.  Windows doesn't appear to have the same issue. 
 But I'd love to hear suggestions for alternative names-- I'm not 
 terribly good at naming modules :-p.

 Also, any I'd like to see how people feel about having three top-level 
 packages in druntime vs. one-- an alternative I'd considered was to put 
 everything under core.


 
 I actually was expecting all the runtime stuff to be in core.* and was 
 surprised to find std and sys there.


 
 I didn't even create core until just recently--before that, the modules 
 in core were global, much like object.  So my thoughts on the druntime 
 package layout are still evolving.  I do now think that having a single 
 top-level package would probably be best, but figured I'd solicit 
 opinions before changing anything.


I think the <default> package should be left for the user.  This also 
gives you an opportunity to use package protection where appropriate.
Oct 21 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Oct 22, 2008 at 9:19 AM, Sergey Gromov <snake.scaly gmail.com> wrote:

 Tue, 21 Oct 2008 11:04:56 -0700,
 Sean Kelly wrote:

 Sergey Gromov wrote:

 Tue, 21 Oct 2008 09:40:28 -0700,
 Sean Kelly wrote:

 Don wrote:

 We also now have two modules called 'bitmanip', which is somewhat ironic
 since we brainstormed for ages trying to come up with a better name for
 it. Modules with duplicate names have caused linking problems in the
 past -- not sure if that applies here.


 It applies if the modules from both Phobos and druntime end up in the
 same library on *nix.  Windows doesn't appear to have the same issue.
 But I'd love to hear suggestions for alternative names-- I'm not
 terribly good at naming modules :-p.

 Also, any I'd like to see how people feel about having three top-level
 packages in druntime vs. one-- an alternative I'd considered was to put
 everything under core.


 I actually was expecting all the runtime stuff to be in core.* and was
 surprised to find std and sys there.


 I didn't even create core until just recently--before that, the modules
 in core were global, much like object.  So my thoughts on the druntime
 package layout are still evolving.  I do now think that having a single
 top-level package would probably be best, but figured I'd solicit
 opinions before changing anything.


 I think the <default> package should be left for the user.  This also
 gives you an opportunity to use package protection where appropriate.


I like core as the package name.  Or maybe even std.core if that's
technically possible.
The stuff in there is going to be kind of rare to import directly,
right?  So doesn't seem like the modules need to be top-level (or even
second level).

I also like the idea of renaming the whole project from druntime to
dcore.  Just sounds cooler. :-)

--bb
Oct 21 2008
parent Sean Kelly <sean invisibleduck.org> writes:
Bill Baxter wrote:

 
 I also like the idea of renaming the whole project from druntime to
 dcore.  Just sounds cooler. :-)


Yeah it does :-)


Sean
Oct 21 2008
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Sean Kelly wrote:


 Don wrote:

 
 We also now have two modules called 'bitmanip', which is somewhat ironic
 since we brainstormed for ages trying to come up with a better name for
 it. Modules with duplicate names have caused linking problems in the
 past -- not sure if that applies here.


 
 It applies if the modules from both Phobos and druntime end up in the
 same library on *nix.  Windows doesn't appear to have the same issue.
 But I'd love to hear suggestions for alternative names-- I'm not
 terribly good at naming modules :-p.
 
 Also, any I'd like to see how people feel about having three top-level
 packages in druntime vs. one-- an alternative I'd considered was to put
 everything under core.
 
 
 Sean


Functionality exposed from the runtime should reside in core, std shouldn't
be used in druntime and any other packages (sys) is presumingly reserved
for what corresponds to tango.sys

In any case, a hierarchy of the type

common/
  core/
  sys/
  stdc/

should be highly considered. This would allow a namespace for functionality
that is truly common, not only the runtime, but math and eventually other
functionality. In addition it is naive to believe that just because
druntime is meant to be a common runtime, that it will be the only runtime
in the long run.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
Oct 22 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Lars Ivar Igesund wrote:

 Sean Kelly wrote:
 

 Don wrote:

 We also now have two modules called 'bitmanip', which is somewhat ironic
 since we brainstormed for ages trying to come up with a better name for
 it. Modules with duplicate names have caused linking problems in the
 past -- not sure if that applies here.


 It applies if the modules from both Phobos and druntime end up in the
 same library on *nix.  Windows doesn't appear to have the same issue.
 But I'd love to hear suggestions for alternative names-- I'm not
 terribly good at naming modules :-p.

 Also, any I'd like to see how people feel about having three top-level
 packages in druntime vs. one-- an alternative I'd considered was to put
 everything under core.


 Sean


 
 Functionality exposed from the runtime should reside in core, std shouldn't
 be used in druntime and any other packages (sys) is presumingly reserved
 for what corresponds to tango.sys
 
 In any case, a hierarchy of the type
 
 common/
   core/
   sys/
   stdc/
 
 should be highly considered. This would allow a namespace for functionality
 that is truly common, not only the runtime, but math and eventually other
 functionality. In addition it is naive to believe that just because
 druntime is meant to be a common runtime, that it will be the only runtime
 in the long run.


A problem I see with the proliferation of top-level packages in the 
standard library is that each of them makes homonym user-defined 
packages inaccessible. Heck, I have a package called "common" today.

Andrei
Oct 22 2008
next sibling parent reply Don <nospam nospam.com.au> writes:
Andrei Alexandrescu wrote:

 Lars Ivar Igesund wrote:

 Sean Kelly wrote:


 Don wrote:

 We also now have two modules called 'bitmanip', which is somewhat 
 ironic
 since we brainstormed for ages trying to come up with a better name for
 it. Modules with duplicate names have caused linking problems in the
 past -- not sure if that applies here.


 It applies if the modules from both Phobos and druntime end up in the
 same library on *nix.  Windows doesn't appear to have the same issue.
 But I'd love to hear suggestions for alternative names-- I'm not
 terribly good at naming modules :-p.

 Also, any I'd like to see how people feel about having three top-level
 packages in druntime vs. one-- an alternative I'd considered was to put
 everything under core.


 Sean


 Functionality exposed from the runtime should reside in core, std 
 shouldn't
 be used in druntime and any other packages (sys) is presumingly reserved
 for what corresponds to tango.sys

 In any case, a hierarchy of the type

 common/
   core/
   sys/
   stdc/

 should be highly considered. This would allow a namespace for 
 functionality
 that is truly common, not only the runtime, but math and eventually other
 functionality. In addition it is naive to believe that just because
 druntime is meant to be a common runtime, that it will be the only 
 runtime
 in the long run.


 
 A problem I see with the proliferation of top-level packages in the 
 standard library is that each of them makes homonym user-defined 
 packages inaccessible. Heck, I have a package called "common" today.
 
 Andrei


'std', 'stdc' and 'sys' sound OK to me. Although is there any reason why 
stdc couldn't be part of 'sys'?
IMHO: 'common' sounds far too generic. 'core' is borderline.

Of course if the non-common parts of Phobos were moved to a namespace 
called 'phobos', std would become the perfect location for common code. 
But changing std.stdio to phobos.stdio might not be acceptable.

Anyway, we need to arrange a common location somehow.
Oct 22 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Don wrote:

 
 'std', 'stdc' and 'sys' sound OK to me. Although is there any reason why 
 stdc couldn't be part of 'sys'?
 IMHO: 'common' sounds far too generic. 'core' is borderline.


My current thought is to have:

core/
     stdc/
     sys/posix
     sys/windows

(yes, I'm planning to move posix support out of stdc)

Alternatives to core are: lang, d, base...  But I like core the best so far.


Sean
Oct 22 2008
next sibling parent Extrawurst <spam extrawurst.org> writes:
Sean Kelly wrote:

 Don wrote:

 'std', 'stdc' and 'sys' sound OK to me. Although is there any reason 
 why stdc couldn't be part of 'sys'?
 IMHO: 'common' sounds far too generic. 'core' is borderline.


 
 My current thought is to have:
 
 core/
     stdc/
     sys/posix
     sys/windows
 
 (yes, I'm planning to move posix support out of stdc)
 
 Alternatives to core are: lang, d, base...  But I like core the best so 
 far.
 
 
 Sean


vote++;
Oct 22 2008
prev sibling next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Wed, 22 Oct 2008 20:42:05 +0200, Sean Kelly <sean invisibleduck.org>  
wrote:


 Don wrote:

  'std', 'stdc' and 'sys' sound OK to me. Although is there any reason  
 why stdc couldn't be part of 'sys'?
 IMHO: 'common' sounds far too generic. 'core' is borderline.


 My current thought is to have:

 core/
      stdc/
      sys/posix
      sys/windows

 (yes, I'm planning to move posix support out of stdc)

 Alternatives to core are: lang, d, base...  But I like core the best so  
 far.


 Sean


core is good. d or base also, but I think core is the best.

-- 
Simen
Oct 22 2008
parent reply Jesse Phillips <jessekphillips gmail.com> writes:
On Wed, 22 Oct 2008 22:44:56 +0200, Simen Kjaeraas wrote:


 On Wed, 22 Oct 2008 20:42:05 +0200, Sean Kelly <sean invisibleduck.org>
 wrote:
 

 Don wrote:

  'std', 'stdc' and 'sys' sound OK to me. Although is there any reason
 why stdc couldn't be part of 'sys'?
 IMHO: 'common' sounds far too generic. 'core' is borderline.


 My current thought is to have:

 core/
      stdc/
      sys/posix
      sys/windows

 (yes, I'm planning to move posix support out of stdc)

 Alternatives to core are: lang, d, base...  But I like core the best so
 far.


 Sean


 
 core is good. d or base also, but I think core is the best.


I like core. std better if phobos would step aside, for the reasons 
already stated.
Oct 22 2008
parent Leandro Lucarella <llucax gmail.com> writes:
Jesse Phillips, el 23 de octubre a las 02:04 me escribiste:

 On Wed, 22 Oct 2008 22:44:56 +0200, Simen Kjaeraas wrote:
 

 On Wed, 22 Oct 2008 20:42:05 +0200, Sean Kelly <sean invisibleduck.org>
 wrote:
 

 Don wrote:

  'std', 'stdc' and 'sys' sound OK to me. Although is there any reason
 why stdc couldn't be part of 'sys'?
 IMHO: 'common' sounds far too generic. 'core' is borderline.


 My current thought is to have:

 core/
      stdc/
      sys/posix
      sys/windows

 (yes, I'm planning to move posix support out of stdc)

 Alternatives to core are: lang, d, base...  But I like core the best so
 far.


 Sean


 
 core is good. d or base also, but I think core is the best.


 
 I like core. std better if phobos would step aside, for the reasons 
 already stated.


I think std is the best too. It's a little confusing that there are
2 *standard* namespaces :S

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
When I was a child I had a fever
My hands felt just like two balloons.
Now I've got that feeling once again
I can't explain you would not understand
This is not how I am.
I have become comfortably numb.
Oct 24 2008
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Sean Kelly:

 Alternatives to core are: lang, d, base...  But I like core the best so far.


"d" is the name of the package my libs, so I hope you will use something
different :-) (But this isn't really much important).

A possible organization (if technically possible) that looks more symmetric to
me is to keep the std as core and push the rest of phobos into a phobos package:

import std.gc; // the common core
import phobos.md5; // from Phobos
import tango.foo; // from tango

In Python standard modules aren't in a top-level package, so you just do:

import collections
from gc import enable, disable

Following that Python style it may become:

import gc; // the common core
import phobos.md5; // from Phobos
import tango.foo; // from tango

Bye,
bearophile
Oct 22 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Oct 23, 2008 at 6:22 AM, bearophile <bearophileHUGS lycos.com> wrote:

 Sean Kelly:

 Alternatives to core are: lang, d, base...  But I like core the best so far.


 "d" is the name of the package my libs, so I hope you will use something
different :-) (But this isn't really much important).


I would have thought that having a 'd' as the name of a top-level
package would make it impossible to use 'd' as a local identifier.  Is
that not so?

Anyway, if you have to rename it then you'll be getting what you
deserve from having the meglomania to use the name of the language as
your package name.

--bb
Oct 22 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:

 I would have thought that having a 'd' as the name of a top-level
 package would make it impossible to use 'd' as a local identifier.  Is
 that not so?


I have had no problems so far. And my identifiers are usually a little longer,
and I generally use qualified imports.

(In my opinion a well designed module system has to not import the name of the
module/package when you import qualified names from it.)



 Anyway, if you have to rename it then you'll be getting what you
 deserve from having the meglomania to use the name of the language as
 your package name.


No meglomania, I think. I did chose "d" because it's short and I was unable to
invent a better name... But I've I have said it's not a problem, changing the
package name requires me just few minutes.

Bye,
bearophile
Oct 22 2008
prev sibling parent reply torhu <no spam.invalid> writes:
Bill Baxter wrote:

 On Thu, Oct 23, 2008 at 6:22 AM, bearophile <bearophileHUGS lycos.com> wrote:

 Sean Kelly:

 Alternatives to core are: lang, d, base...  But I like core the best so far.


 "d" is the name of the package my libs, so I hope you will use something
different :-) (But this isn't really much important).


 
 I would have thought that having a 'd' as the name of a top-level
 package would make it impossible to use 'd' as a local identifier.  Is
 that not so?


Seems it'll work as long as you don't refer to something in the 'd' 
package using its fully qualified name.  Then the package name will 
conflict with any locals named 'd'.

But the package name will always conflict with globals, at least it does 
when I try it with DMD 1.033.  Not that globals with single-letter names 
is something I'd recommend using.
Oct 22 2008
parent bearophile <bearophileHUGS lycos.com> writes:
torhu:

 But the package name will always conflict with globals, at least it does 
 when I try it with DMD 1.033.  Not that globals with single-letter names 
 is something I'd recommend using.


I see. Then I'll invent and use a different package name. Thank you.

Bye,
bearophile
Oct 22 2008
prev sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Oct 23, 2008 at 6:22 AM, bearophile <bearophileHUGS lycos.com> wrote:

 In Python standard modules aren't in a top-level package, so you just do:

 import collections
 from gc import enable, disable


But I think that's starting to bite Python in the behind as the number
of std library packages increases.  Funny to have so many top level
things in a language whose motto is "Namespaces are one honking great
idea.  Let's do more of those."

Other responsible development organizations that release packages tend
to collect them under a single top level package like "zope.*"  or
"enthought.*".

There's also so many standard packages these days that when I see an
unfamiliar import I'm never sure if it's a standard one or not.

--bb
Oct 22 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:

 But I think that's starting to bite Python in the behind as the number
 of std library packages increases.


I tend to agree. That's why I have never complained for D having a "std"
package name for its standard lib :-)

Bye,
bearophile
Oct 22 2008
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Sean Kelly Wrote:


 Don wrote:

 
 'std', 'stdc' and 'sys' sound OK to me. Although is there any reason why 
 stdc couldn't be part of 'sys'?
 IMHO: 'common' sounds far too generic. 'core' is borderline.


 
 My current thought is to have:
 
 core/
      stdc/
      sys/posix
      sys/windows
 
 (yes, I'm planning to move posix support out of stdc)
 
 Alternatives to core are: lang, d, base...  But I like core the best so far.


What happens to the other parts of Phobos? Like others, I hope it will be
ranamed from std to phobos.
Oct 22 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Jason House wrote:

 Sean Kelly Wrote:
 

 Don wrote:

 'std', 'stdc' and 'sys' sound OK to me. Although is there any reason why 
 stdc couldn't be part of 'sys'?
 IMHO: 'common' sounds far too generic. 'core' is borderline.


 My current thought is to have:

 core/
      stdc/
      sys/posix
      sys/windows

 (yes, I'm planning to move posix support out of stdc)

 Alternatives to core are: lang, d, base...  But I like core the best so far.


 
 What happens to the other parts of Phobos? Like others, I hope it will be
ranamed from std to phobos. 


That isn't something I can answer, though I'd expect Phobos to continue 
using 'std'.


Sean
Oct 22 2008
parent Leandro Lucarella <llucax gmail.com> writes:
Sean Kelly, el 22 de octubre a las 16:14 me escribiste:

 Jason House wrote:

Sean Kelly Wrote:

Don wrote:

'std', 'stdc' and 'sys' sound OK to me. Although is there any reason why stdc
couldn't be part of 'sys'?
IMHO: 'common' sounds far too generic. 'core' is borderline.


My current thought is to have:

core/
     stdc/
     sys/posix
     sys/windows

(yes, I'm planning to move posix support out of stdc)

Alternatives to core are: lang, d, base...  But I like core the best so far.


What happens to the other parts of Phobos? Like others, I hope it will be
ranamed from std to phobos. 


 
 That isn't something I can answer, though I'd expect Phobos to continue using
'std'.


If phobos is part of a "spec-conformant" compiler, I think it should still
be in the std namespace, with the runtime (also in the std namespace).

I this currently there are 2 separated projects for phobos and runtime,
but if in the specification there is only one standard library, all it's
modules should be in the same namespace (std). The fact that now are
2 separated projects is an "implementation detail" and should not impact
in the namespace naming (IHMO).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
More than 50% of the people in the world have never made
Or received a telephone call
Oct 24 2008
prev sibling parent reply Moritz Warning <moritzwarning web.de> writes:
On Wed, 22 Oct 2008 18:47:49 -0400, Jason House wrote:


 Sean Kelly Wrote:
 

 Don wrote:

 
 'std', 'stdc' and 'sys' sound OK to me. Although is there any reason
 why stdc couldn't be part of 'sys'?
 IMHO: 'common' sounds far too generic. 'core' is borderline.


 
 My current thought is to have:
 
 core/
      stdc/
      sys/posix
      sys/windows
 
 (yes, I'm planning to move posix support out of stdc)
 
 Alternatives to core are: lang, d, base...  But I like core the best so
 far.


 
 What happens to the other parts of Phobos? Like others, I hope it will
 be ranamed from std to phobos.


Would be nice no have std renamed to phobos. This would enable a common 
ground and just looks well designed. It would also remove confusion for
newcomers (why is std also named phobos?).
But I don't think this will happen...


(...and tango should be renamed to deimos, so both can circle around mars 
- just kidding)
Oct 22 2008
parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Moritz Warning wrote:


 Would be nice no have std renamed to phobos. This would enable a common 
 ground and just looks well designed. It would also remove confusion for
 newcomers (why is std also named phobos?).
 But I don't think this will happen...
 
 
 (...and tango should be renamed to deimos, so both can circle around mars 
 - just kidding)


Then again "etc" was already named deimos, so it would still confuse...

http://dsource.org/projects/deimos/
http://www.dsource.org/forums/viewforum.php?f=26

Everything but etc.c.zlib and etc.gamma died, but that's another story.

--anders
Oct 22 2008
prev sibling parent Sergey Gromov <snake.scaly gmail.com> writes:
Wed, 22 Oct 2008 11:42:05 -0700,
Sean Kelly wrote:

 Don wrote:

 
 'std', 'stdc' and 'sys' sound OK to me. Although is there any reason why 
 stdc couldn't be part of 'sys'?
 IMHO: 'common' sounds far too generic. 'core' is borderline.


 
 My current thought is to have:
 
 core/
      stdc/
      sys/posix
      sys/windows
 
 (yes, I'm planning to move posix support out of stdc)


I like it.
Oct 23 2008
prev sibling next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Andrei Alexandrescu wrote:


 Lars Ivar Igesund wrote:

 Sean Kelly wrote:
 

 Don wrote:

 We also now have two modules called 'bitmanip', which is somewhat
 ironic since we brainstormed for ages trying to come up with a better
 name for it. Modules with duplicate names have caused linking problems
 in the past -- not sure if that applies here.


 It applies if the modules from both Phobos and druntime end up in the
 same library on *nix.  Windows doesn't appear to have the same issue.
 But I'd love to hear suggestions for alternative names-- I'm not
 terribly good at naming modules :-p.

 Also, any I'd like to see how people feel about having three top-level
 packages in druntime vs. one-- an alternative I'd considered was to put
 everything under core.


 Sean


 
 Functionality exposed from the runtime should reside in core, std
 shouldn't be used in druntime and any other packages (sys) is presumingly
 reserved for what corresponds to tango.sys
 
 In any case, a hierarchy of the type
 
 common/
   core/
   sys/
   stdc/
 
 should be highly considered. This would allow a namespace for
 functionality that is truly common, not only the runtime, but math and
 eventually other functionality. In addition it is naive to believe that
 just because druntime is meant to be a common runtime, that it will be
 the only runtime in the long run.


 
 A problem I see with the proliferation of top-level packages in the
 standard library is that each of them makes homonym user-defined
 packages inaccessible. Heck, I have a package called "common" today.


This is not about proliferation, but having _one_ for common functionality.
common was just a suggestion that I like, it could be something else that
fits the purpose.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
Oct 22 2008
prev sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Andrei Alexandrescu wrote:

 Lars Ivar Igesund wrote:

 Sean Kelly wrote:


 Don wrote:

 We also now have two modules called 'bitmanip', which is somewhat 
 ironic
 since we brainstormed for ages trying to come up with a better name for
 it. Modules with duplicate names have caused linking problems in the
 past -- not sure if that applies here.


 It applies if the modules from both Phobos and druntime end up in the
 same library on *nix.  Windows doesn't appear to have the same issue.
 But I'd love to hear suggestions for alternative names-- I'm not
 terribly good at naming modules :-p.

 Also, any I'd like to see how people feel about having three top-level
 packages in druntime vs. one-- an alternative I'd considered was to put
 everything under core.


 Sean


 Functionality exposed from the runtime should reside in core, std 
 shouldn't
 be used in druntime and any other packages (sys) is presumingly reserved
 for what corresponds to tango.sys

 In any case, a hierarchy of the type

 common/
   core/
   sys/
   stdc/

 should be highly considered. This would allow a namespace for 
 functionality
 that is truly common, not only the runtime, but math and eventually other
 functionality. In addition it is naive to believe that just because
 druntime is meant to be a common runtime, that it will be the only 
 runtime
 in the long run.


 
 A problem I see with the proliferation of top-level packages in the 
 standard library is that each of them makes homonym user-defined 
 packages inaccessible. Heck, I have a package called "common" today.
 
 Andrei


I thought that's what this idea was trying to address ;-P ... Having 
"common" in the global namespace is only a single identifier; having 
"core", "sys", "stdc" and "std" is 4.
Oct 23 2008
prev sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Wed, 22 Oct 2008 15:56:30 +0200,
Lars Ivar Igesund wrote:

 In any case, a hierarchy of the type
 
 common/
   core/
   sys/
   stdc/
 
 should be highly considered. This would allow a namespace for functionality
 that is truly common, not only the runtime, but math and eventually other
 functionality. In addition it is naive to believe that just because
 druntime is meant to be a common runtime, that it will be the only runtime
 in the long run.


There is no 'truly common' functionality beyond the absolutely necessary 
core runtime.  The fact that Phobos and Tango share some code only means 
that such code is ought to be in any stand-alone, general-purpose 
library.  Not that it must be built-in.
Oct 23 2008
parent reply Don <nospam nospam.com.au> writes:
Sergey Gromov wrote:

 Wed, 22 Oct 2008 15:56:30 +0200,
 Lars Ivar Igesund wrote:

 In any case, a hierarchy of the type

 common/
   core/
   sys/
   stdc/

 should be highly considered. This would allow a namespace for functionality
 that is truly common, not only the runtime, but math and eventually other
 functionality. In addition it is naive to believe that just because
 druntime is meant to be a common runtime, that it will be the only runtime
 in the long run.


 
 There is no 'truly common' functionality beyond the absolutely necessary 
 core runtime.  The fact that Phobos and Tango share some code only means 
 that such code is ought to be in any stand-alone, general-purpose 
 library.  Not that it must be built-in.


??? Don't understand.
Are you simply saying that there's no need for standard libraries?
Oct 23 2008
parent Sergey Gromov <snake.scaly gmail.com> writes:
Thu, 23 Oct 2008 17:47:46 +0200,
Don wrote:

 Sergey Gromov wrote:

 Wed, 22 Oct 2008 15:56:30 +0200,
 Lars Ivar Igesund wrote:

 In any case, a hierarchy of the type

 common/
   core/
   sys/
   stdc/

 should be highly considered. This would allow a namespace for functionality
 that is truly common, not only the runtime, but math and eventually other
 functionality. In addition it is naive to believe that just because
 druntime is meant to be a common runtime, that it will be the only runtime
 in the long run.


 
 There is no 'truly common' functionality beyond the absolutely necessary 
 core runtime.  The fact that Phobos and Tango share some code only means 
 that such code is ought to be in any stand-alone, general-purpose 
 library.  Not that it must be built-in.


 
 ??? Don't understand.
 Are you simply saying that there's no need for standard libraries?


I can see a reason for a general-purpose library which is supplied with a 
compiler.  It's for faster setup, faster learning, and for quick-n-dirty 
utilities with less dependencies.

I can see why one would want a different general-purpose library instead 
of the default.  It's for more appealing (for that one person) library 
architecture and for different trade-offs.

I can see a reason for a specialized math library, biological, chemical 
library etc.  They're specialized.

But I cannot justify a separate library only because Phobos and Tango 
happen to use the same approach in some parts.  A library without any 
architecture, with only purpose to make Phobos and Tango dependent upon 
it, and to make users wonder where to search for a particular general-
purpose functionality.
Oct 23 2008
prev sibling next sibling parent reply Max Samukha <samukha voliacable.com.removethis> writes:
On Mon, 20 Oct 2008 16:29:36 -0700, Walter Bright
<newshound1 digitalmars.com> wrote:


http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.036.zip

The 2.0 version splits phobos into druntime and phobos libraries (thanks 
to Sean Kelly). This will enable both Tango and Phobos to share a common 
core library.

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

There are a lot of structural changes that go along with this, so expect 
some rough patches with this release. It may take a followup release to 
file them down. There's also some renaming of imports and function 
names, as a compromise with Tango names.


Thank you!
Oct 21 2008
parent Moritz Warning <moritzwarning web.de> writes:
On Tue, 21 Oct 2008 18:40:04 +0300, Max Samukha wrote:


 On Mon, 20 Oct 2008 16:29:36 -0700, Walter Bright
 <newshound1 digitalmars.com> wrote:
 
 

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.036.zip

The 2.0 version splits phobos into druntime and phobos libraries (thanks
to Sean Kelly). This will enable both Tango and Phobos to share a common
core library.

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

There are a lot of structural changes that go along with this, so expect
some rough patches with this release. It may take a followup release to
file them down. There's also some renaming of imports and function
names, as a compromise with Tango names.


 
 Thank you!


Nice! Thank you.
Oct 21 2008
prev sibling next sibling parent reply Max Samukha <samukha voliacable.com.removethis> writes:
On Mon, 20 Oct 2008 16:29:36 -0700, Walter Bright
<newshound1 digitalmars.com> wrote:


http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.036.zip

The 2.0 version splits phobos into druntime and phobos libraries (thanks 
to Sean Kelly). This will enable both Tango and Phobos to share a common 
core library.

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

There are a lot of structural changes that go along with this, so expect 
some rough patches with this release. It may take a followup release to 
file them down. There's also some renaming of imports and function 
names, as a compromise with Tango names.


Please add the compiler versions to bugzilla.
Oct 21 2008
parent Brad Roberts <braddr bellevue.puremagic.com> writes:
On Tue, 21 Oct 2008, Max Samukha wrote:


 Please add the compiler versions to bugzilla. 


Done.
Oct 21 2008
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Bill Baxter Wrote:


 On Tue, Oct 21, 2008 at 8:29 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.036.zip

 The 2.0 version splits phobos into druntime and phobos libraries (thanks to
 Sean Kelly). This will enable both Tango and Phobos to share a common core
 library.

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

 There are a lot of structural changes that go along with this, so expect
 some rough patches with this release. It may take a followup release to file
 them down. There's also some renaming of imports and function names, as a
 compromise with Tango names.


 
 Wao!  Missed this at first:
 
 class Foo
 {
     ref int getref() {
         return m_int;
     }
 private:
     int m_int = 23;
 }
 
 void main() {
     auto foo = new Foo;
 
     writefln(foo.getref);
     foo.getref() = 7;
     writefln(foo.getref);
 }
 //Outputs:
 //23
 //7
 
 It works!  This is maybe even bigger news than cure for TangoPhobia!
 
 But I think maybe more documentation is needed in the Ref returns
 section regarding how this affects opIndex.
 
 class Foo
 {
     this() {
         m_arr.length = 10;
         foreach(i, ref a; m_arr) { a=i;}
     }
     int[] array() {
         return m_arr;
     }
     ref int opIndex(size_t idx) {
         return m_arr[idx];
     }
 
 private:
     int[] m_arr;
 }
 
 void main() {
     auto foo = new Foo;
     foo[3] = -99;
 //hello.d(44): Error: operator [] assignment overload with opIndex(i,
 value) illegal, use opIndexAssign(value, i)
 //hello.d(44): function hello.Foo.opIndex (uint idx) does not match
 parameter types (int,int)
 //hello.d(44): Error: expected 1 arguments, not 2
 }
 
 Apparently using opIndex with ref return is not allowed as a way to
 set an index.
 This works though:
 
     *(&foo[3]) = -99;
 
 Is there a good reason why it shouldn't be possible to use opAssign as
 a replacement for opIndexAssign?
 
 --bb


opindexAssign will still be needed when opindex has a non-ref return type.
Oct 21 2008
next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Oct 22, 2008 at 7:01 AM, Jason House
<jason.james.house gmail.com> wrote:

 Bill Baxter Wrote:


 Is there a good reason why it shouldn't be possible to use opAssign as
 a replacement for opIndexAssign?

 --bb


 opindexAssign will still be needed when opindex has a non-ref return type.


Yep, definitely shouldn't get rid of opIndexAssign.  It's still a nice
advantage of D over C++ when you want to monitor and control all
modifications to an array-like object.

But if the opIndex does return a ref, and an opIndexAssign has not
been defined then I don't see why that opIndex shouldn't allow users
to say   foo[10] = x.   Instead of *(&foo[10])=x;

--bb
Oct 21 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:

 Bill Baxter Wrote:
 

 On Tue, Oct 21, 2008 at 8:29 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.036.zip

 The 2.0 version splits phobos into druntime and phobos libraries (thanks to
 Sean Kelly). This will enable both Tango and Phobos to share a common core
 library.

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

 There are a lot of structural changes that go along with this, so expect
 some rough patches with this release. It may take a followup release to file
 them down. There's also some renaming of imports and function names, as a
 compromise with Tango names.


 Wao!  Missed this at first:

 class Foo
 {
     ref int getref() {
         return m_int;
     }
 private:
     int m_int = 23;
 }

 void main() {
     auto foo = new Foo;

     writefln(foo.getref);
     foo.getref() = 7;
     writefln(foo.getref);
 }
 //Outputs:
 //23
 //7

 It works!  This is maybe even bigger news than cure for TangoPhobia!

 But I think maybe more documentation is needed in the Ref returns
 section regarding how this affects opIndex.

 class Foo
 {
     this() {
         m_arr.length = 10;
         foreach(i, ref a; m_arr) { a=i;}
     }
     int[] array() {
         return m_arr;
     }
     ref int opIndex(size_t idx) {
         return m_arr[idx];
     }

 private:
     int[] m_arr;
 }

 void main() {
     auto foo = new Foo;
     foo[3] = -99;
 //hello.d(44): Error: operator [] assignment overload with opIndex(i,
 value) illegal, use opIndexAssign(value, i)
 //hello.d(44): function hello.Foo.opIndex (uint idx) does not match
 parameter types (int,int)
 //hello.d(44): Error: expected 1 arguments, not 2
 }

 Apparently using opIndex with ref return is not allowed as a way to
 set an index.
 This works though:

     *(&foo[3]) = -99;

 Is there a good reason why it shouldn't be possible to use opAssign as
 a replacement for opIndexAssign?

 --bb


 
 opindexAssign will still be needed when opindex has a non-ref return type.


I think the entire operator paraphernalia is due for a serious overhaul.

Andrei
Oct 21 2008
parent reply John Reimer <terminal.node gmail.com> writes:
Hello Andrei,


 I think the entire operator paraphernalia is due for a serious
 overhaul.
 
 Andrei
 



This may not be a popular opinion, but I agree!

-JJR
Oct 21 2008
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from John Reimer (terminal.node gmail.com)'s article

 Hello Andrei,

 I think the entire operator paraphernalia is due for a serious
 overhaul.

 Andrei


 This may not be a popular opinion, but I agree!
 -JJR


I'll second that.  D's operator overloading is a bit confusing because it's kind
of grown rather than having been designed.  This should be fixed now, while
breaking changes are still considered acceptable.
Oct 21 2008
parent BCS <ao pathlink.com> writes:
Reply to dsimcha,


 == Quote from John Reimer (terminal.node gmail.com)'s article
 

 Hello Andrei,
 

 I think the entire operator paraphernalia is due for a serious
 overhaul.
 
 Andrei
 


 This may not be a popular opinion, but I agree!
 -JJR


 I'll second that.  D's operator overloading is a bit confusing because
 it's kind of grown rather than having been designed.  This should be
 fixed now, while breaking changes are still considered acceptable.
 


Clean it up if you want to. But overall I like the *general* way it work.
Oct 21 2008
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
The change log says:


Improved performance of AAs by rebalancing trees when rehashing.<


I presume such rehashing is done from time to time when the hash grows up, and
when the .rehash method is called too.

I have performed some benchmarks, with both string and int keys, and the
creation (building) of associative arrays in DMD1.036 is about 10-15% slower
than in DMD1.035 (I can show code if you want, but it's the same code I have
used in the past).

I have not tested the key retrieval time, I presume it's faster...

Anyway: often performance isn't absolute, usually you have to tune something
for a specific class of usages. So you want to tune it for the average use
cases, this means for the most common usages of D AAs. This means that before
tuning something you collect a statistically significant base of such usages,
generally from a sizable amount of code. What are the average use cases the
current performance improvements are based on? Where's the people creating such
user cases to base the performance tuning on? I think we need to put a little
more "science" in this tuning business.

Bye,
bearophile
Oct 21 2008
prev sibling next sibling parent Graham St Jack <Graham.StJack internode.on.net> writes:
On Mon, 20 Oct 2008 16:29:36 -0700, Walter Bright wrote:


 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.036.zip
 
 The 2.0 version splits phobos into druntime and phobos libraries (thanks
 to Sean Kelly). This will enable both Tango and Phobos to share a common
 core library.
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.020.zip
 
 There are a lot of structural changes that go along with this, so expect
 some rough patches with this release. It may take a followup release to
 file them down. There's also some renaming of imports and function
 names, as a compromise with Tango names.


This is FANTASTIC news. Many thanks to everyone involved, especially Sean 
for all the hard work.
Oct 21 2008
prev sibling parent reply digited <digited yandex.ru> writes:
Walter Bright Wrote:


 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.036.zip
 


Great!

I failed to compile Tango svn trunk with 1.036, but Tango 0.99.7, compiled with
1.035, works fine.

I got a small fps boost when compiled my graphics engine with new dmd - maybe
some improvements in associative arrays operations?.. Fps stability also
improved.

When I was compiling DWT with 1.035 in a single command to dmd (dmd -lib
modules), it took 11.66 seconds on 2GHz processor, size of lib was 7.6MB. With
1.036 it took 16.74 seconds and lib size became 8.1. I get same results with
"-lib" while compiling derelict opengl and glu - it now takes a bit longer and
produces bigger libs. Have you changed something?
Oct 23 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Oct 24, 2008 at 1:59 AM, digited <digited yandex.ru> wrote:

 Walter Bright Wrote:


 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.036.zip


 Great!

 I failed to compile Tango svn trunk with 1.036, but Tango 0.99.7, compiled
with 1.035, works fine.

 I got a small fps boost when compiled my graphics engine with new dmd - maybe
some improvements in associative arrays operations?.. Fps stability also
improved.

 When I was compiling DWT with 1.035 in a single command to dmd (dmd -lib
modules), it took 11.66 seconds on 2GHz processor, size of lib was 7.6MB. With
1.036 it took 16.74 seconds and lib size became 8.1. I get same results with
"-lib" while compiling derelict opengl and glu - it now takes a bit longer and
produces bigger libs. Have you changed something?


I have no idea why the generated code got bigger again, but it's far
from being the first time.
Check the graph here:
http://www.billbaxter.com/techblog/?p=9


--bb
Oct 23 2008
parent digited <digited yandex.ru> writes:
Bill Baxter Wrote:
 

 I have no idea why the generated code got bigger again, but it's far
 from being the first time.
 Check the graph here:
 http://www.billbaxter.com/techblog/?p=9
 
 
 --bb


I thought this bug was a feature... Back to 1.035 then.
Oct 23 2008
prev sibling parent reply torhu <no spam.invalid> writes:
digited wrote:
...

 When I was compiling DWT with 1.035 in a single command to dmd (dmd -lib
modules), it took 11.66 seconds on 2GHz processor, size of lib was 7.6MB. With
1.036 it took 16.74 seconds and lib size became 8.1. I get same results with
"-lib" while compiling derelict opengl and glu - it now takes a bit longer and
produces bigger libs. Have you changed something?
 
 


I tried building DWT with -lib when that feature was first added.  -lib 
seems to be broken somehow, because just compiling one file at a time 
results in a much smaller .lib file.
Oct 23 2008
parent reply digited <digited yandex.ru> writes:
torhu Wrote:


 
 I tried building DWT with -lib when that feature was first added.  -lib 
 seems to be broken somehow, because just compiling one file at a time 
 results in a much smaller .lib file.


That's normal (really a feature, not a bug) - "-lib" creates more than one
object file from a module to make executables smaller (by linking not the full
module object file, but it's piece that the executable really needs), it also
does not any IO with hdd, all compiling and linking in RAM, so creating static
libs is extremely fast and doesn't produce object files as output.

I've just compared "-lib" results from 1.035 and 1.036, it now works
differently.
Oct 23 2008
parent torhu <no spam.invalid> writes:
digited wrote:

 torhu Wrote:
 

 
 I tried building DWT with -lib when that feature was first added.  -lib 
 seems to be broken somehow, because just compiling one file at a time 
 results in a much smaller .lib file.


 
 That's normal (really a feature, not a bug) - "-lib" creates more than one
object file from a module to make executables smaller (by linking not the full
module object file, but it's piece that the executable really needs), it also
does not any IO with hdd, all compiling and linking in RAM, so creating static
libs is extremely fast and doesn't produce object files as output.
 
 I've just compared "-lib" results from 1.035 and 1.036, it now works
differently.


Sorry, what I meant to say was that the executable ends up bigger when 
using libs created with -lib.
Oct 24 2008