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