From aldoSkipallthisNunez1 at gmail.com Wed Sep 1 23:27:28 2010 From: aldoSkipallthisNunez1 at gmail.com (Aldo Nunez) Date: Wed, 01 Sep 2010 23:27:28 -0700 Subject: Mago Debugger References: Message-ID: It's geared to D 2. To target D 1, you would need to make a few changes to the expression evaluator. Aldo On Tue, 31 Aug 2010 00:50:28 -0700, Nick B wrote: > Hi > > Do you plan to support D1 or is this for D2 only ? > > cheers > Nick B. > > On 23/08/2010 7:16 a.m., Aldo Nunez wrote: >> I've checked in Mago Debugger -- a set of libraries and a Visual Studio >> plug-in for debugging D 2 programs on Windows. >> >> You can find it at: >> http://dsource.org/projects/mago_debugger >> >> Here's a quick set of features: >> >> * Starting and stopping a debug session >> * Source level step-in, step-over, and step-out >> * Breakpoints by source line >> * Module and thread views >> * Callstack >> * Memory and Register views >> * Locals view >> * Watch views >> * Disassembly >> >> It uses the CodeView debug info that DMD puts in exes, not the PDB >> format. But, I do want to support PDB format so that you can step into >> Microsoft C and C++ code from your D code. >> >> It doesn't have a command line interface, but I encourage you to make >> one that can be included with this project. >> >> Try it out and take a look at the source code. I'd like to hear your >> feedback and see your bug reports. >> > -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From newshound2 at digitalmars.com Sat Sep 4 12:16:25 2010 From: newshound2 at digitalmars.com (Walter Bright) Date: Sat, 04 Sep 2010 12:16:25 -0700 Subject: Obama endorses D Message-ID: Obama: "You want to go forward, what do you do? You put it in D. http://voices.washingtonpost.com/44/2010/08/obamas-latest-joke-republicans.html From g.sayol at yahoo.es Sat Sep 4 13:12:36 2010 From: g.sayol at yahoo.es (Jordi Sayol) Date: Sat, 04 Sep 2010 22:12:36 +0200 Subject: Obama endorses D In-Reply-To: References: Message-ID: <4C82A834.5050008@yahoo.es> Al 04/09/10 21:16, En/na Walter Bright ha escrit: > Obama: "You want to go forward, what do you do? You put it in D. > > http://voices.washingtonpost.com/44/2010/08/obamas-latest-joke-republicans.html > > :-) -- Jordi Sayol From dsimcha at yahoo.com Sat Sep 4 14:38:07 2010 From: dsimcha at yahoo.com (dsimcha) Date: Sat, 4 Sep 2010 21:38:07 +0000 (UTC) Subject: Obama endorses D References: Message-ID: == Quote from Walter Bright (newshound2 at digitalmars.com)'s article > Obama: "You want to go forward, what do you do? You put it in D. > http://voices.washingtonpost.com/44/2010/08/obamas-latest-joke-republicans.html This one makes me laugh especially because there's actually an R programming language that I occasionally have to use, and I generally hate it. It's basically a domain specific language for statistics and not well-known outside the statistics community. The biggest problem with it is poor documentation of basic things like builtin data structures. D's documentation looks great in comparison. The other one is that it's too high-level, domain specific and slow (even compared to other interpreted languages) to be easy to think of as a "real" programming language. At the same time it's too low-level and lacking in simple (i.e. GUI or single command) ways to do simple things to be easy to think of as a plain old application. Basically, you have to program to use it, but when you try, if you're used to "real" languages you feel like you're programming with 8 of your fingers crushed. From contact at gamesfromILOVESPAMmars.fr Sat Sep 4 15:19:44 2010 From: contact at gamesfromILOVESPAMmars.fr (ponce) Date: Sat, 04 Sep 2010 18:19:44 -0400 Subject: Vibrant 1.5 Message-ID: Hi, Do you remember Vibrant, the abstract arena shooter I wrote last year? The game has been updated several times since, bringing many enhancements. http://www.gamesfrommars.fr/vibrant Cheers, ponce From nomail at nomail.com Sat Sep 4 17:39:01 2010 From: nomail at nomail.com (some lurker) Date: Sat, 04 Sep 2010 20:39:01 -0400 Subject: Obama endorses D References: Message-ID: dsimcha Wrote: > == Quote from Walter Bright (newshound2 at digitalmars.com)'s article > > Obama: "You want to go forward, what do you do? You put it in D. > > http://voices.washingtonpost.com/44/2010/08/obamas-latest-joke-republicans.html > > This one makes me laugh especially because there's actually an R programming > language that I occasionally have to use, and I generally hate it. It's basically > a domain specific language for statistics and not well-known outside the > statistics community. > > The biggest problem with it is poor documentation of basic things like builtin > data structures. D's documentation looks great in comparison. The other one is > that it's too high-level, domain specific and slow (even compared to other > interpreted languages) to be easy to think of as a "real" programming language. > At the same time it's too low-level and lacking in simple (i.e. GUI or single > command) ways to do simple things to be easy to think of as a plain old > application. Basically, you have to program to use it, but when you try, if > you're used to "real" languages you feel like you're programming with 8 of your > fingers crushed. Sounds a lot like matlab. From nospam at nospam.com Sat Sep 4 20:10:09 2010 From: nospam at nospam.com (JMRyan) Date: Sun, 5 Sep 2010 03:10:09 +0000 (UTC) Subject: Obama endorses D References: Message-ID: dsimcha wrote in news:i5ue7v$1sp0$1 at digitalmars.com: > The biggest problem with it is poor documentation of basic things like > builtin data structures. R and S are approximately the same thing. So checking the documentation for S may help. Maybe you already knew that. S-Plus may be faster and easier to deal with than R. It's probably expensive. If you are associated with a university, you can probably get a site license for under $200. I've never dealt with either language, so I probably know less about all of this than you do. But if you didn't, you may very well want to check into S-Plus. Just be glad you don't have to deal with SAS. From newshound2 at digitalmars.com Sun Sep 5 03:22:08 2010 From: newshound2 at digitalmars.com (Walter Bright) Date: Sun, 05 Sep 2010 03:22:08 -0700 Subject: Sept. 15 - The Many Faces of D Message-ID: I'll be giving a presentation on The Many Faces of D at the Northwest C++ Users' Group meeting on Sept. 15. http://nwcpp.org/ 3 copies of The D Programming Language book autographed by Andrei will be given out as door prizes. Light refreshments, too! See y'all there. From windevguy at hotmail.de Mon Sep 6 13:52:57 2010 From: windevguy at hotmail.de (BLS) Date: Mon, 06 Sep 2010 22:52:57 +0200 Subject: dcollections 2.0b In-Reply-To: References: Message-ID: On 24/08/2010 17:45, Steven Schveighoffer wrote: > dcollections second beta version 2.0b is up. > > This fixes a few bugs, and adds some features such as passing in > elements on construction. See the full changelog here: > > http://www.dsource.org/projects/dcollections/wiki/ChangeLog > > This release is long overdue, sorry to those of you waiting for these > fixes. I've had a very busy summer! > > -Steve Thanks for the update Steve. Once gain, a fantastic collection lib !! Erm....., I hoped for more.. at least for a nitty gritty tutorial - when and how to use cursors - ArrayLists/Arrays Bjoern From foo at bar.com Tue Sep 7 03:02:47 2010 From: foo at bar.com (Mike James) Date: Tue, 7 Sep 2010 11:02:47 +0100 Subject: Sept. 15 - The Many Faces of D In-Reply-To: References: Message-ID: "Walter Bright" wrote in message news:i5vr13$13n9$1 at digitalmars.com... > I'll be giving a presentation on The Many Faces of D at the Northwest C++ > Users' Group meeting on Sept. 15. > > http://nwcpp.org/ > > 3 copies of The D Programming Language book autographed by Andrei will be > given out as door prizes. Light refreshments, too! > > See y'all there. For those of us on different continents - will it be available on youtube :-) -=mike=- From schveiguy at yahoo.com Tue Sep 7 04:31:15 2010 From: schveiguy at yahoo.com (Steven Schveighoffer) Date: Tue, 07 Sep 2010 07:31:15 -0400 Subject: dcollections 2.0b References: Message-ID: On Mon, 06 Sep 2010 16:52:57 -0400, BLS wrote: > On 24/08/2010 17:45, Steven Schveighoffer wrote: >> dcollections second beta version 2.0b is up. >> >> This fixes a few bugs, and adds some features such as passing in >> elements on construction. See the full changelog here: >> >> http://www.dsource.org/projects/dcollections/wiki/ChangeLog >> >> This release is long overdue, sorry to those of you waiting for these >> fixes. I've had a very busy summer! >> >> -Steve > > Thanks for the update Steve. Once gain, a fantastic collection lib !! > > Erm....., I hoped for more.. at least for a nitty gritty tutorial - when > and how to use cursors - ArrayLists/Arrays Sorry, I've been very busy. I've had very little time for D, and I was way late on releasing this version. I didn't want to delay it by adding extra work. I'll bump up the tutorial priority... BTW, I still cannot contact you via your email address, not sure if you read my other NG posts about this... -Steve From newshound2 at digitalmars.com Tue Sep 7 11:16:16 2010 From: newshound2 at digitalmars.com (Walter Bright) Date: Tue, 07 Sep 2010 11:16:16 -0700 Subject: Sept. 15 - The Many Faces of D In-Reply-To: References: Message-ID: Mike James wrote: > For those of us on different continents - will it be available on > youtube :-) I don't know. From sovende at gmail.com Tue Sep 7 12:19:39 2010 From: sovende at gmail.com (Emil Madsen) Date: Tue, 7 Sep 2010 21:19:39 +0200 Subject: Sept. 15 - The Many Faces of D In-Reply-To: References: Message-ID: Would love to see it :) However for at student in europe, its quite far. Hoping for availablity of it, on youtube :) On 7 September 2010 20:16, Walter Bright wrote: > Mike James wrote: > >> For those of us on different continents - will it be available on youtube >> :-) >> > > I don't know. > -- // Yours sincerely // Emil 'Skeen' Madsen -------------- next part -------------- An HTML attachment was scrubbed... URL: From pjdeets2 at gmail.com Tue Sep 7 22:21:46 2010 From: pjdeets2 at gmail.com (Phil Deets) Date: Tue, 07 Sep 2010 22:21:46 -0700 Subject: Sept. 15 - The Many Faces of D References: Message-ID: On Sun, 05 Sep 2010 03:22:08 -0700, Walter Bright wrote: > I'll be giving a presentation on The Many Faces of D at the Northwest > C++ Users' Group meeting on Sept. 15. > > http://nwcpp.org/ > > 3 copies of The D Programming Language book autographed by Andrei will > be given out as door prizes. Light refreshments, too! > > See y'all there. I'll probably be there. What time does it start? From newshound2 at digitalmars.com Tue Sep 7 23:00:02 2010 From: newshound2 at digitalmars.com (Walter Bright) Date: Tue, 07 Sep 2010 23:00:02 -0700 Subject: Sept. 15 - The Many Faces of D In-Reply-To: References: Message-ID: Phil Deets wrote: > On Sun, 05 Sep 2010 03:22:08 -0700, Walter Bright > wrote: > >> I'll be giving a presentation on The Many Faces of D at the Northwest >> C++ Users' Group meeting on Sept. 15. >> >> http://nwcpp.org/ >> >> 3 copies of The D Programming Language book autographed by Andrei will >> be given out as door prizes. Light refreshments, too! >> >> See y'all there. > > I'll probably be there. What time does it start? 7:00 PM From luca at llucax.com.ar Thu Sep 9 20:13:22 2010 From: luca at llucax.com.ar (Leandro Lucarella) Date: Fri, 10 Sep 2010 00:13:22 -0300 Subject: D Concurrent GC Message-ID: <20100910031322.GY4631@llucax.com.ar> Not quite ready for prime-time yet, but I think it's in a stage when it could be interesting anyway (at least for developers or people that want to experiment): http://llucax.com.ar/blog/blog/post/-1a4bdfba If you like history, you can read all the related posts in chronological order here: http://llucax.com.ar/blog/blog/tag/dgc?sort=+date If you only care about concurrency, you probably want to read just this: http://llucax.com.ar/blog/blog/tag/cdgc?sort=+date -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Desde chiquito quer?a ser doctor Pero despu?s me enferm? y me hice m?sico From b.helyer at gmail.com Thu Sep 9 21:49:02 2010 From: b.helyer at gmail.com (Bernard Helyer) Date: Fri, 10 Sep 2010 04:49:02 +0000 (UTC) Subject: D Concurrent GC References: <20100910031322.GY4631@llucax.com.ar> Message-ID: Very nice. I've been reading your posts on this with interest. How much work would be involved in porting this to druntime? From francisco.m.almeida at gmail.com Fri Sep 10 00:31:54 2010 From: francisco.m.almeida at gmail.com (F. Almeida) Date: Fri, 10 Sep 2010 07:31:54 +0000 (UTC) Subject: Sept. 15 - The Many Faces of D References: Message-ID: == Quote from Walter Bright (newshound2 at digitalmars.com)'s article > Phil Deets wrote: > > On Sun, 05 Sep 2010 03:22:08 -0700, Walter Bright > > wrote: > > > >> I'll be giving a presentation on The Many Faces of D at the Northwest > >> C++ Users' Group meeting on Sept. 15. > >> > >> http://nwcpp.org/ > >> > >> 3 copies of The D Programming Language book autographed by Andrei will > >> be given out as door prizes. Light refreshments, too! > >> > >> See y'all there. > > > > I'll probably be there. What time does it start? > 7:00 PM Good to hear about this event. It is not possible for me to attend, but I am very interested in this seminar. Will it be video recorded and uploaded for viewing online? From newshound2 at digitalmars.com Fri Sep 10 01:58:10 2010 From: newshound2 at digitalmars.com (Walter Bright) Date: Fri, 10 Sep 2010 01:58:10 -0700 Subject: Sept. 15 - The Many Faces of D In-Reply-To: References: Message-ID: F. Almeida wrote: > Good to hear about this event. It is not possible for me to attend, > but I am very interested in this seminar. Will it be video recorded > and uploaded for viewing online? I don't know. From luca at llucax.com.ar Fri Sep 10 05:26:02 2010 From: luca at llucax.com.ar (Leandro Lucarella) Date: Fri, 10 Sep 2010 09:26:02 -0300 Subject: D Concurrent GC In-Reply-To: References: <20100910031322.GY4631@llucax.com.ar> Message-ID: <20100910122602.GZ4631@llucax.com.ar> Bernard Helyer, el 10 de septiembre a las 04:49 me escribiste: > Very nice. I've been reading your posts on this with interest. > > How much work would be involved in porting this to druntime? Is hard to tell since I didn't followed druntime development very closely lately, but both are based on the same code, so probably not too much work should be involved. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- In a world without fences, who need gates? From lutger.blijdestijn at gmail.com Sun Sep 12 08:48:19 2010 From: lutger.blijdestijn at gmail.com (Lutger) Date: Sun, 12 Sep 2010 17:48:19 +0200 Subject: bash completion for dmd and rdmd Message-ID: It's ugly but it seems to work: http://dl.dropbox.com/u/6777848/d-completion.sh Put it in /etc/bash_completion.d/ or (preferably) invoke it from ~/.bashrc or ~/.bash_profile: . d-completion.sh It will enable autocomplete for dmd and rdmd in bash. You may need to install the bash-completion package of your distro. From SeeWebsiteForEmail at erdani.org Sun Sep 12 09:54:16 2010 From: SeeWebsiteForEmail at erdani.org (Andrei Alexandrescu) Date: Sun, 12 Sep 2010 11:54:16 -0500 Subject: bash completion for dmd and rdmd In-Reply-To: References: Message-ID: On 9/12/10 10:48 CDT, Lutger wrote: > It's ugly but it seems to work: http://dl.dropbox.com/u/6777848/d-completion.sh > > Put it in /etc/bash_completion.d/ or (preferably) invoke it from ~/.bashrc or > ~/.bash_profile: > > .. d-completion.sh > > It will enable autocomplete for dmd and rdmd in bash. You may need to install > the bash-completion package of your distro. Cool! This should be on D's website. Any zsh completion experts to provide something similar for zsh? Andrei From a at a.a Sun Sep 12 11:27:06 2010 From: a at a.a (Nick Sabalausky) Date: Sun, 12 Sep 2010 14:27:06 -0400 Subject: bash completion for dmd and rdmd References: Message-ID: "Lutger" wrote in message news:i6isov$v0h$1 at digitalmars.com... > It's ugly but it seems to work: > http://dl.dropbox.com/u/6777848/d-completion.sh > > Put it in /etc/bash_completion.d/ or (preferably) invoke it from ~/.bashrc > or > ~/.bash_profile: > > . d-completion.sh > > It will enable autocomplete for dmd and rdmd in bash. You may need to > install > the bash-completion package of your distro. Ahh, cool! I'd often wondered how autocomplete in bash often seems to work even for non-files. (Yea, not exactly a Unix-guru here ;) ) From russel at russel.org.uk Sun Sep 12 09:33:35 2010 From: russel at russel.org.uk (Russel Winder) Date: Sun, 12 Sep 2010 17:33:35 +0100 Subject: bash completion for dmd and rdmd In-Reply-To: References: Message-ID: <1284309215.7096.13.camel@anglides> On Sun, 2010-09-12 at 17:48 +0200, Lutger wrote: > It's ugly but it seems to work: http://dl.dropbox.com/u/6777848/d-completion.sh > > Put it in /etc/bash_completion.d/ or (preferably) invoke it from ~/.bashrc or > ~/.bash_profile: > > . d-completion.sh > > It will enable autocomplete for dmd and rdmd in bash. You may need to install > the bash-completion package of your distro. Any chance of putting it into DVCS so that it can be evolved? Bazaar/Launchpad, Mercurial/BitBucket, Git/GitHub are good options. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder at ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel at russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From repeatedly at gmail.com Sun Sep 12 12:59:49 2010 From: repeatedly at gmail.com (Masahiro Nakagawa) Date: Mon, 13 Sep 2010 04:59:49 +0900 Subject: bash completion for dmd and rdmd References: Message-ID: On Mon, 13 Sep 2010 01:54:16 +0900, Andrei Alexandrescu wrote: > On 9/12/10 10:48 CDT, Lutger wrote: >> It's ugly but it seems to work: >> http://dl.dropbox.com/u/6777848/d-completion.sh >> >> Put it in /etc/bash_completion.d/ or (preferably) invoke it from >> ~/.bashrc or >> ~/.bash_profile: >> >> .. d-completion.sh >> >> It will enable autocomplete for dmd and rdmd in bash. You may need to >> install >> the bash-completion package of your distro. > > Cool! This should be on D's website. Any zsh completion experts to > provide something similar for zsh? > I'm not a zsh completion experts, but I use following script. http://dl.dropbox.com/u/374829/_dmd From lutger.blijdestijn at gmail.com Sun Sep 12 14:34:06 2010 From: lutger.blijdestijn at gmail.com (Lutger) Date: Sun, 12 Sep 2010 23:34:06 +0200 Subject: bash completion for dmd and rdmd References: Message-ID: Andrei Alexandrescu wrote: > On 9/12/10 10:48 CDT, Lutger wrote: >> It's ugly but it seems to work: >> http://dl.dropbox.com/u/6777848/d-completion.sh >> >> Put it in /etc/bash_completion.d/ or (preferably) invoke it from ~/.bashrc or >> ~/.bash_profile: >> >> .. d-completion.sh >> >> It will enable autocomplete for dmd and rdmd in bash. You may need to install >> the bash-completion package of your distro. > > Cool! This should be on D's website. Any zsh completion experts to > provide something similar for zsh? > > Andrei Thanks. As per suggestion of Russel Winder I created a github account: http://github.com/Lutger/d_utils I've added completion for the linker. The script should be cleaned up though before putting it on the D website. I'll try to do it but I don't know bash very well, so it takes some time. From g.sayol at yahoo.es Tue Sep 14 14:37:43 2010 From: g.sayol at yahoo.es (Jordi Sayol) Date: Tue, 14 Sep 2010 23:37:43 +0200 Subject: bash completion for dmd and rdmd In-Reply-To: References: Message-ID: <4C8FEB27.4030903@yahoo.es> Al 12/09/10 17:48, En/na Lutger ha escrit: > It's ugly but it seems to work: http://dl.dropbox.com/u/6777848/d-completion.sh > > Put it in /etc/bash_completion.d/ or (preferably) invoke it from ~/.bashrc or > ~/.bash_profile: > > . d-completion.sh > > It will enable autocomplete for dmd and rdmd in bash. You may need to install > the bash-completion package of your distro. > Can I add it on the next deb/rpm packages? -- Jordi Sayol From sean at invisibleduck.org Tue Sep 14 16:09:18 2010 From: sean at invisibleduck.org (Sean Kelly) Date: Tue, 14 Sep 2010 19:09:18 -0400 Subject: D Concurrent GC References: <20100910031322.GY4631@llucax.com.ar> Message-ID: Leandro Lucarella Wrote: > Not quite ready for prime-time yet, but I think it's in a stage when it > could be interesting anyway (at least for developers or people that want > to experiment): > http://llucax.com.ar/blog/blog/post/-1a4bdfba Nice work! I've gotten this to compile as the GC for druntime using D2 but have ran into a snag. I'm using OSX (ie. no usable debug info) but near as I can tell the issue is: private T locked(T, alias Code)() { if (thread_needLock()) synchronized (gc.lock) return Code(); else return Code(); } void* gc_malloc(size_t size, uint attrs = 0) { if (size == 0) return null; return locked!(void*, () { assert (Invariant()); scope (exit) assert (Invariant()); return malloc(size, attrs, null); })(); } In the code above, it appears that the anonymous delegate being passed as an alias to locked() is having its stack data dynamically allocated (ie. as a dynamic closure). For normal delegate calls this can be avoided by accepting "scope delegate" as the function parameter, but I haven't found an analog when using the alias approach. Obviously, what happens is that a call to gc_malloc() ends up needing GCed memory, so gc_malloc() is recursively called, and on until the stack explodes. I'll see if I can come up with a workaround that continues using the alias template parameter. From lutger.blijdestijn at gmail.com Tue Sep 14 23:50:27 2010 From: lutger.blijdestijn at gmail.com (Lutger) Date: Wed, 15 Sep 2010 08:50:27 +0200 Subject: bash completion for dmd and rdmd References: Message-ID: Jordi Sayol wrote: > Al 12/09/10 17:48, En/na Lutger ha escrit: >> It's ugly but it seems to work: >> http://dl.dropbox.com/u/6777848/d-completion.sh >> >> Put it in /etc/bash_completion.d/ or (preferably) invoke it from ~/.bashrc or >> ~/.bash_profile: >> >> . d-completion.sh >> >> It will enable autocomplete for dmd and rdmd in bash. You may need to install >> the bash-completion package of your distro. >> > > Can I add it on the next deb/rpm packages? > Of course! But please use this version: http://github.com/Lutger/d_utils I'll be happy to know if there are any errors, it's mostly taken from existing completion scripts. I don't think such a small script needs a license but I'll put one in if needed. From schveiguy at yahoo.com Wed Sep 15 05:59:14 2010 From: schveiguy at yahoo.com (Steven Schveighoffer) Date: Wed, 15 Sep 2010 08:59:14 -0400 Subject: D Concurrent GC References: <20100910031322.GY4631@llucax.com.ar> Message-ID: On Tue, 14 Sep 2010 19:09:18 -0400, Sean Kelly wrote: > Leandro Lucarella Wrote: > >> Not quite ready for prime-time yet, but I think it's in a stage when it >> could be interesting anyway (at least for developers or people that want >> to experiment): >> http://llucax.com.ar/blog/blog/post/-1a4bdfba > > Nice work! I've gotten this to compile as the GC for druntime using D2 > but have ran into a snag. I'm using OSX (ie. no usable debug info) but > near as I can tell the issue is: > > private T locked(T, alias Code)() > { > if (thread_needLock()) > synchronized (gc.lock) return Code(); > else > return Code(); > } > > void* gc_malloc(size_t size, uint attrs = 0) > { > if (size == 0) > return null; > return locked!(void*, () { > assert (Invariant()); scope (exit) assert (Invariant()); > return malloc(size, attrs, null); > })(); > } > > In the code above, it appears that the anonymous delegate being passed > as an alias to locked() is having its stack data dynamically allocated > (ie. as a dynamic closure). For normal delegate calls this can be > avoided by accepting "scope delegate" as the function parameter, but I > haven't found an analog when using the alias approach. Obviously, what > happens is that a call to gc_malloc() ends up needing GCed memory, so > gc_malloc() is recursively called, and on until the stack explodes. > I'll see if I can come up with a workaround that continues using the > alias template parameter. What if you passed it through a scope delegate function? i.e. void *lockedproxy(scope void* delegate() dg) { return locked!(void *, dg); } -Steve From sean at invisibleduck.org Wed Sep 15 07:26:35 2010 From: sean at invisibleduck.org (Sean Kelly) Date: Wed, 15 Sep 2010 14:26:35 +0000 (UTC) Subject: D Concurrent GC References: Message-ID: <379204356306253418.535677sean-invisibleduck.org@news.digitalmars.com> "Steven Schveighoffer" wrote: > On Tue, 14 Sep 2010 19:09:18 -0400, Sean Kelly > wrote: > >> Leandro Lucarella Wrote: >> >>> Not quite ready for prime-time yet, but I think it's in a stage when > > > it >>> could be interesting anyway (at least for developers or people that > > > want >>> to experiment): >>> http://llucax.com.ar/blog/blog/post/-1a4bdfba >> >> Nice work! I've gotten this to compile as the GC for druntime using > > D2 > but have ran into a snag. I'm using OSX (ie. no usable debug > > info) but > near as I can tell the issue is: >> >> private T locked(T, alias Code)() >> { >> if (thread_needLock()) >> synchronized (gc.lock) return Code(); >> else >> return Code(); >> } >> >> void* gc_malloc(size_t size, uint attrs = 0) >> { >> if (size == 0) >> return null; >> return locked!(void*, () { >> assert (Invariant()); scope (exit) assert (Invariant()); >> return malloc(size, attrs, null); >> })(); >> } >> >> In the code above, it appears that the anonymous delegate being > > passed > as an alias to locked() is having its stack data > > dynamically allocated > (ie. as a dynamic closure). For normal > > delegate calls this can be > avoided by accepting "scope delegate" > > as the function parameter, but I > haven't found an analog when > > using the alias approach. Obviously, what > happens is that a call > > to gc_malloc() ends up needing GCed memory, so > gc_malloc() is > > recursively called, and on until the stack explodes. > I'll see if > > I can come up with a workaround that continues using the > alias > > template parameter. > > What if you passed it through a scope delegate function? > > i.e. > > void *lockedproxy(scope void* delegate() dg) > { > return locked!(void *, dg); > } I could simply change it to a function that accepts a scope delegate. It just isn't as efficient as the alias approach. But an indirect call is pretty small potatoes in this case anyway. I tried this and it worked, and the I ran into an issue where the object used for the lock (classinfo for GCLock) was apparently null. I'll look into that today. From schveiguy at yahoo.com Wed Sep 15 07:32:21 2010 From: schveiguy at yahoo.com (Steven Schveighoffer) Date: Wed, 15 Sep 2010 10:32:21 -0400 Subject: D Concurrent GC References: <379204356306253418.535677sean-invisibleduck.org@news.digitalmars.com> Message-ID: On Wed, 15 Sep 2010 10:26:35 -0400, Sean Kelly wrote: > "Steven Schveighoffer" wrote: >> On Tue, 14 Sep 2010 19:09:18 -0400, Sean Kelly >> wrote: >> >>> Leandro Lucarella Wrote: >>> >>>> Not quite ready for prime-time yet, but I think it's in a stage when >> > > it >>>> could be interesting anyway (at least for developers or people that >> > > want >>>> to experiment): >>>> http://llucax.com.ar/blog/blog/post/-1a4bdfba >>> >>> Nice work! I've gotten this to compile as the GC for druntime using >> > D2 > but have ran into a snag. I'm using OSX (ie. no usable debug >> > info) but > near as I can tell the issue is: >>> >>> private T locked(T, alias Code)() >>> { >>> if (thread_needLock()) >>> synchronized (gc.lock) return Code(); >>> else >>> return Code(); >>> } >>> >>> void* gc_malloc(size_t size, uint attrs = 0) >>> { >>> if (size == 0) >>> return null; >>> return locked!(void*, () { >>> assert (Invariant()); scope (exit) assert (Invariant()); >>> return malloc(size, attrs, null); >>> })(); >>> } >>> >>> In the code above, it appears that the anonymous delegate being >> > passed > as an alias to locked() is having its stack data >> > dynamically allocated > (ie. as a dynamic closure). For normal >> > delegate calls this can be > avoided by accepting "scope delegate" >> > as the function parameter, but I > haven't found an analog when >> > using the alias approach. Obviously, what > happens is that a call >> > to gc_malloc() ends up needing GCed memory, so > gc_malloc() is >> > recursively called, and on until the stack explodes. > I'll see if >> > I can come up with a workaround that continues using the > alias >> > template parameter. >> >> What if you passed it through a scope delegate function? >> >> i.e. >> >> void *lockedproxy(scope void* delegate() dg) >> { >> return locked!(void *, dg); >> } > > I could simply change it to a function that accepts a scope delegate. It > just isn't as efficient as the alias approach. But an indirect call is > pretty small potatoes in this case anyway. I tried this and it worked, > and the I ran into an issue where the object used for the lock > (classinfo for GCLock) was apparently null. I'll look into that today. Well, the alias version could be used for other callable types, whereas a delegate version can only be used for delegates. Not sure how important it is. -Steve From sean at invisibleduck.org Wed Sep 15 10:13:07 2010 From: sean at invisibleduck.org (Sean Kelly) Date: Wed, 15 Sep 2010 13:13:07 -0400 Subject: D Concurrent GC References: <379204356306253418.535677sean-invisibleduck.org@news.digitalmars.com> Message-ID: Steven Schveighoffer Wrote: > On Wed, 15 Sep 2010 10:26:35 -0400, Sean Kelly > wrote: > > > > > I could simply change it to a function that accepts a scope delegate. It > > just isn't as efficient as the alias approach. But an indirect call is > > pretty small potatoes in this case anyway. I tried this and it worked, > > and the I ran into an issue where the object used for the lock > > (classinfo for GCLock) was apparently null. I'll look into that today. > > Well, the alias version could be used for other callable types, whereas a > delegate version can only be used for delegates. Not sure how important > it is. I think there needs to be a solution for this in the general case, but for this specific application it doesn't matter. From sean at invisibleduck.org Wed Sep 15 11:55:28 2010 From: sean at invisibleduck.org (Sean Kelly) Date: Wed, 15 Sep 2010 14:55:28 -0400 Subject: D Concurrent GC References: <20100910031322.GY4631@llucax.com.ar> Message-ID: Sean Kelly Wrote: > Leandro Lucarella Wrote: > > > Not quite ready for prime-time yet, but I think it's in a stage when it > > could be interesting anyway (at least for developers or people that want > > to experiment): > > http://llucax.com.ar/blog/blog/post/-1a4bdfba > > Nice work! I've gotten this to compile as the GC for druntime using D2 but have ran into a snag. Okay, all fixed. Porting the GC to D2 was more work than porting it to druntime specifically. There are still a few hacks in place to work around const issues and I faked the PointerMap stuff, but the GC seems to work just great. I'll have to find a reasonable performance test for comparison. Oh, I'll send you the modified code as well. From lutger.blijdestijn at gmail.com Wed Sep 15 14:50:20 2010 From: lutger.blijdestijn at gmail.com (Lutger) Date: Wed, 15 Sep 2010 23:50:20 +0200 Subject: D Concurrent GC References: <20100910031322.GY4631@llucax.com.ar> Message-ID: Sean Kelly wrote: > Sean Kelly Wrote: > >> Leandro Lucarella Wrote: >> >> > Not quite ready for prime-time yet, but I think it's in a stage when it >> > could be interesting anyway (at least for developers or people that want >> > to experiment): >> > http://llucax.com.ar/blog/blog/post/-1a4bdfba >> >> Nice work! I've gotten this to compile as the GC for druntime using D2 but >> have ran into a snag. > > Okay, all fixed. Porting the GC to D2 was more work than porting it to > druntime specifically. There are still a few hacks in place to work around > const issues and I faked the PointerMap stuff, but the GC seems to work just > great. I'll have to find a reasonable performance test for comparison. Oh, > I'll send you the modified code as well. Are you going to integrate it in druntime? From sean at invisibleduck.org Wed Sep 15 17:00:19 2010 From: sean at invisibleduck.org (Sean Kelly) Date: Wed, 15 Sep 2010 20:00:19 -0400 Subject: D Concurrent GC References: <20100910031322.GY4631@llucax.com.ar> Message-ID: Lutger Wrote: > Sean Kelly wrote: > > > Sean Kelly Wrote: > > > >> Leandro Lucarella Wrote: > >> > >> > Not quite ready for prime-time yet, but I think it's in a stage when it > >> > could be interesting anyway (at least for developers or people that want > >> > to experiment): > >> > http://llucax.com.ar/blog/blog/post/-1a4bdfba > >> > >> Nice work! I've gotten this to compile as the GC for druntime using D2 but > >> have ran into a snag. > > > > Okay, all fixed. Porting the GC to D2 was more work than porting it to > > druntime specifically. There are still a few hacks in place to work around > > const issues and I faked the PointerMap stuff, but the GC seems to work just > > great. I'll have to find a reasonable performance test for comparison. Oh, > > I'll send you the modified code as well. > > Are you going to integrate it in druntime? Dunno. For now, I've just sent my modified copy to Leandro and the druntime list for people to play with. It seems quite promising though. From dsimcha at yahoo.com Wed Sep 15 20:14:23 2010 From: dsimcha at yahoo.com (dsimcha) Date: Thu, 16 Sep 2010 03:14:23 +0000 (UTC) Subject: D Concurrent GC References: <20100910031322.GY4631@llucax.com.ar> Message-ID: == Quote from Sean Kelly (sean at invisibleduck.org)'s article > Lutger Wrote: > > Sean Kelly wrote: > > > > > Sean Kelly Wrote: > > > > > >> Leandro Lucarella Wrote: > > >> > > >> > Not quite ready for prime-time yet, but I think it's in a stage when it > > >> > could be interesting anyway (at least for developers or people that want > > >> > to experiment): > > >> > http://llucax.com.ar/blog/blog/post/-1a4bdfba > > >> > > >> Nice work! I've gotten this to compile as the GC for druntime using D2 but > > >> have ran into a snag. > > > > > > Okay, all fixed. Porting the GC to D2 was more work than porting it to > > > druntime specifically. There are still a few hacks in place to work around > > > const issues and I faked the PointerMap stuff, but the GC seems to work just > > > great. I'll have to find a reasonable performance test for comparison. Oh, > > > I'll send you the modified code as well. > > > > Are you going to integrate it in druntime? > Dunno. For now, I've just sent my modified copy to Leandro and the druntime list for people to play with. It seems quite promising though. Been meaning to ask, what does this GC do with regard to precise scanning? Is it substantially less conservative than the current D2 GC? From SeeWebsiteForEmail at erdani.org Wed Sep 15 20:22:18 2010 From: SeeWebsiteForEmail at erdani.org (Andrei Alexandrescu) Date: Wed, 15 Sep 2010 22:22:18 -0500 Subject: D Concurrent GC In-Reply-To: References: <20100910031322.GY4631@llucax.com.ar> Message-ID: On 09/15/2010 07:00 PM, Sean Kelly wrote: > Lutger Wrote: > >> Sean Kelly wrote: >> >>> Sean Kelly Wrote: >>> >>>> Leandro Lucarella Wrote: >>>> >>>>> Not quite ready for prime-time yet, but I think it's in a stage when it >>>>> could be interesting anyway (at least for developers or people that want >>>>> to experiment): >>>>> http://llucax.com.ar/blog/blog/post/-1a4bdfba >>>> >>>> Nice work! I've gotten this to compile as the GC for druntime using D2 but >>>> have ran into a snag. >>> >>> Okay, all fixed. Porting the GC to D2 was more work than porting it to >>> druntime specifically. There are still a few hacks in place to work around >>> const issues and I faked the PointerMap stuff, but the GC seems to work just >>> great. I'll have to find a reasonable performance test for comparison. Oh, >>> I'll send you the modified code as well. >> >> Are you going to integrate it in druntime? > > Dunno. For now, I've just sent my modified copy to Leandro and the druntime list for people to play with. It seems quite promising though. There's a discussion on digitalmars.D about a D program being slower than the equivalent Python script because of the GC. Would be a good test bed! Andrei From SeeWebsiteForEmail at erdani.org Thu Sep 16 07:00:45 2010 From: SeeWebsiteForEmail at erdani.org (Andrei Alexandrescu) Date: Thu, 16 Sep 2010 09:00:45 -0500 Subject: D Concurrent GC In-Reply-To: References: <20100910031322.GY4631@llucax.com.ar> Message-ID: On 9/15/10 22:22 CDT, Andrei Alexandrescu wrote: > On 09/15/2010 07:00 PM, Sean Kelly wrote: >> Lutger Wrote: >> >>> Sean Kelly wrote: >>> >>>> Sean Kelly Wrote: >>>> >>>>> Leandro Lucarella Wrote: >>>>> >>>>>> Not quite ready for prime-time yet, but I think it's in a stage >>>>>> when it >>>>>> could be interesting anyway (at least for developers or people >>>>>> that want >>>>>> to experiment): >>>>>> http://llucax.com.ar/blog/blog/post/-1a4bdfba >>>>> >>>>> Nice work! I've gotten this to compile as the GC for druntime using >>>>> D2 but >>>>> have ran into a snag. >>>> >>>> Okay, all fixed. Porting the GC to D2 was more work than porting it to >>>> druntime specifically. There are still a few hacks in place to work >>>> around >>>> const issues and I faked the PointerMap stuff, but the GC seems to >>>> work just >>>> great. I'll have to find a reasonable performance test for >>>> comparison. Oh, >>>> I'll send you the modified code as well. >>> >>> Are you going to integrate it in druntime? >> >> Dunno. For now, I've just sent my modified copy to Leandro and the >> druntime list for people to play with. It seems quite promising though. > > There's a discussion on digitalmars.D about a D program being slower > than the equivalent Python script because of the GC. Would be a good > test bed! This is what I was referring to. http://rounin.livejournal.com/21815.html The author makes quite a few good points comparing D and Python in expressiveness and performance. Andrei From spambox at d-coding.com Thu Sep 16 07:22:55 2010 From: spambox at d-coding.com (Max Samukha) Date: Thu, 16 Sep 2010 17:22:55 +0300 Subject: QtD is suspended Message-ID: After a good amount of hesitation, we have decided to put the QtD project on hold. QtD has a potential to become a complete and effective development platform for D but it is not going to happen soon (unless people with harder hearts take it over). We have spent half of the day hunting yet another dmd bug-o-feature and that is the last straw. We offer our apologies to people who put their hope upon the project. Please come back in a year or two when the language has a stable compiler with the features fully specified, implemented and debugged. From doob at me.com Thu Sep 16 07:56:24 2010 From: doob at me.com (Jacob Carlborg) Date: Thu, 16 Sep 2010 16:56:24 +0200 Subject: DWT2 updated to latest compiler and Tango Message-ID: Just a note: I've updated DWT2 to work on the latest compiler and with the latest Tango. Both windows and linux ports are updated. No update for D2 yet, I notice that the language is not ready yet, I hit too many bugs. Link to DWT project page: http://dsource.org/projects/dwt Link to DWT2 Mercurial repository: http://hg.dsource.org/projects/dwt2 -- /Jacob Carlborg From sean at invisibleduck.org Thu Sep 16 08:17:58 2010 From: sean at invisibleduck.org (Sean Kelly) Date: Thu, 16 Sep 2010 11:17:58 -0400 Subject: D Concurrent GC References: <20100910031322.GY4631@llucax.com.ar> Message-ID: Andrei Alexandrescu Wrote: > > There's a discussion on digitalmars.D about a D program being slower > than the equivalent Python script because of the GC. Would be a good > test bed! I was playing with that yesterday, but there was too much setup required for a quick test (it compared an MD5 has of a directory tree to the current directory tree). I'll revisit it though, since it seems a good starting point. From SeeWebsiteForEmail at erdani.org Thu Sep 16 08:44:51 2010 From: SeeWebsiteForEmail at erdani.org (Andrei Alexandrescu) Date: Thu, 16 Sep 2010 10:44:51 -0500 Subject: QtD is suspended In-Reply-To: References: Message-ID: On 9/16/10 9:22 CDT, Max Samukha wrote: > After a good amount of hesitation, we have decided to put the QtD > project on hold. QtD has a potential to become a complete and effective > development platform for D but it is not going to happen soon (unless > people with harder hearts take it over). We have spent half of the day > hunting yet another dmd bug-o-feature and that is the last straw. > > We offer our apologies to people who put their hope upon the project. > Please come back in a year or two when the language has a stable > compiler with the features fully specified, implemented and debugged. Hi Max, Sorry to hear that. Was this an issue of many small annoyances or a few big ones? Thanks, Andrei From sean at invisibleduck.org Thu Sep 16 10:23:09 2010 From: sean at invisibleduck.org (Sean Kelly) Date: Thu, 16 Sep 2010 13:23:09 -0400 Subject: D Concurrent GC References: <20100910031322.GY4631@llucax.com.ar> Message-ID: dsimcha Wrote: > == Quote from Sean Kelly (sean at invisibleduck.org)'s article > > > Dunno. For now, I've just sent my modified copy to Leandro and the druntime > list for people to play with. It seems quite promising though. > > Been meaning to ask, what does this GC do with regard to precise scanning? Is it > substantially less conservative than the current D2 GC? Its gc_malloc, etc, accept a PointerMap type which I assume is used for precise scanning, but I couldn't find a definition of PointerMap in the GC code or other obvious locations so I disabled it for now. I assume it's from the precise scanning patch and that I can get whatever else is needed from there. For now, I just wanted a functional port to test. From moritzwarning at web.de Thu Sep 16 11:31:03 2010 From: moritzwarning at web.de (mwarning) Date: Thu, 16 Sep 2010 18:31:03 +0000 (UTC) Subject: DWT2 updated to latest compiler and Tango References: Message-ID: On Thu, 16 Sep 2010 16:56:24 +0200, Jacob Carlborg wrote: > Just a note: I've updated DWT2 to work on the latest compiler and with > the latest Tango. Both windows and linux ports are updated. No update > for D2 yet, I notice that the language is not ready yet, I hit too many > bugs. > > Link to DWT project page: http://dsource.org/projects/dwt Link to DWT2 > Mercurial repository: http://hg.dsource.org/projects/dwt2 Thanks! :) From spambox at d-coding.com Thu Sep 16 12:37:00 2010 From: spambox at d-coding.com (Max Samukha) Date: Thu, 16 Sep 2010 22:37:00 +0300 Subject: QtD is suspended In-Reply-To: References: Message-ID: On 09/16/2010 06:44 PM, Andrei Alexandrescu wrote: > On 9/16/10 9:22 CDT, Max Samukha wrote: >> After a good amount of hesitation, we have decided to put the QtD >> project on hold. QtD has a potential to become a complete and effective >> development platform for D but it is not going to happen soon (unless >> people with harder hearts take it over). We have spent half of the day >> hunting yet another dmd bug-o-feature and that is the last straw. >> >> We offer our apologies to people who put their hope upon the project. >> Please come back in a year or two when the language has a stable >> compiler with the features fully specified, implemented and debugged. > > Hi Max, > > Sorry to hear that. Was this an issue of many small annoyances or a few > big ones? > > Thanks, > > Andrei Hi Andrei, Both, I guess. The recent big one is the unspecified behavior of postblit on const/immutable structs and overloading by rvalue/lvalue. Specifically, we were bending the generator into generating Qt value types as structs and hit two problems: 1. The generated __cpctor (which does the blit and calls the postblit) is always non-const and takes a non-const reference to the original. That means copy-construction of const objects is impossible without casts. To proceed, we had to hack the compiler so that __cpctor took a const original reference and was called on a mutable target reference. That seemed to work but left us in uncertainty: how it actually should and will work? 2. A bug in the compiler doesn't allow us to overload struct parameters by ref-ness. So we had to generate by-value parameters where Qt has them by reference. And today we've encountered two other bugs in sequence. One was about the impossibility to access a template instance member from within a struct nested in another struct and the second didn't give any line/file information. We could probably work around or ignore all these problems but I think it is starting to take more time and nerve than we can afford. From lutger.blijdestijn at gmail.com Thu Sep 16 15:01:13 2010 From: lutger.blijdestijn at gmail.com (Lutger) Date: Fri, 17 Sep 2010 00:01:13 +0200 Subject: QtD is suspended References: Message-ID: Max Samukha wrote: > After a good amount of hesitation, we have decided to put the QtD > project on hold. QtD has a potential to become a complete and effective > development platform for D but it is not going to happen soon (unless > people with harder hearts take it over). We have spent half of the day > hunting yet another dmd bug-o-feature and that is the last straw. > > We offer our apologies to people who put their hope upon the project. > Please come back in a year or two when the language has a stable > compiler with the features fully specified, implemented and debugged. This is a loss, it must be frustrating for you spending so much time on it. Thank you anyway for the effort, it was quite exciting to see QtD almost come to be! I hope it will be continued some day. From lutger.blijdestijn at gmail.com Thu Sep 16 15:25:07 2010 From: lutger.blijdestijn at gmail.com (Lutger) Date: Fri, 17 Sep 2010 00:25:07 +0200 Subject: QtD is suspended References: Message-ID: Is the most recent flavor of QtD the repositoy at bitbucket? From see at klickverbot.at Thu Sep 16 16:16:55 2010 From: see at klickverbot.at (klickverbot) Date: Fri, 17 Sep 2010 01:16:55 +0200 Subject: QtD is suspended In-Reply-To: References: Message-ID: On 9/17/10 12:25 AM, Lutger wrote: > Is the most recent flavor of QtD the repositoy at bitbucket? Yes, it is. Reminds me that someone should probably update the Wiki page at dsource? From michel.fortin at michelf.com Thu Sep 16 16:46:44 2010 From: michel.fortin at michelf.com (Michel Fortin) Date: Thu, 16 Sep 2010 19:46:44 -0400 Subject: D/Objective-C: hit a dead end, start anew Message-ID: The D/Objective-C bridge is a project that was aiming at making Cocoa usable from D. It's somewhat similar to QtD. The timing of this announcement isn't entirely coincidental with today's announcement about QtD: my announcement was ready, QtD's was the trigger for my Publish button. Even though the problems are probably quite different between the two projects, they both share a common need for runtime-reflection, playing with the object model from another language, static initialization from within mixins that shouldn't create circular module dependency, and probably a couple others. It is my feeling that for dealing with Objective-C, things will be much cleaner by working directly inside of the compiler. D templates are fabulous, and I'm quite amazed that I could do what I did, but the bridge creates just too much generated code to make the whole thing usable. So I think it's time for a new approach. -- Michel Fortin michel.fortin at michelf.com http://michelf.com/ From Georg.Wrede at iki.fi Thu Sep 16 16:48:09 2010 From: Georg.Wrede at iki.fi (Georg Wrede) Date: Fri, 17 Sep 2010 02:48:09 +0300 Subject: QtD is suspended In-Reply-To: References: Message-ID: On 09/17/2010 01:01 AM, Lutger wrote: > Max Samukha wrote: > >> After a good amount of hesitation, we have decided to put the QtD >> project on hold. QtD has a potential to become a complete and effective >> development platform for D but it is not going to happen soon (unless >> people with harder hearts take it over). We have spent half of the day >> hunting yet another dmd bug-o-feature and that is the last straw. >> >> We offer our apologies to people who put their hope upon the project. >> Please come back in a year or two when the language has a stable >> compiler with the features fully specified, implemented and debugged. > > This is a loss, it must be frustrating for you spending so much time on it. > Thank you anyway for the effort, it was quite exciting to see QtD almost come to > be! I hope it will be continued some day. Having some experience in this, I really don't think other people can even begin to think what Max feels at this point. I could go on-and-on about this, but those who've never invested enough to break their back and then simply be met by folks who !believe! they have any way of understanding, I really think they should stay shut up. I left the language because of a personal quarrel with Andrei. And that was long after vigorously defending him in the Big Battle. But that should not mean I have any second thoughts about what should be done, or whether we can pull it off. The language as such, has a niche way bigger than it'd seem, in spite of reading this NG or the random outside article (found with Google). Man, I'd love to become an evangelist for D, and I really have a few ideas (that presumably, most of our long-time contributors recognize), that would help D in carving its own footprint on the map. The place and position are now very much clearer to me, than they were six months ago. This would mean establishing a place that doesn't necessarily challenge ASM, C, C++, or Python or Java. And, within this particular place, none of them can possibly challenge D. (!!) From SeeWebsiteForEmail at erdani.org Thu Sep 16 17:46:49 2010 From: SeeWebsiteForEmail at erdani.org (Andrei Alexandrescu) Date: Thu, 16 Sep 2010 19:46:49 -0500 Subject: QtD is suspended In-Reply-To: References: Message-ID: On 9/16/10 18:48 CDT, Georg Wrede wrote: > On 09/17/2010 01:01 AM, Lutger wrote: >> Max Samukha wrote: >> >>> After a good amount of hesitation, we have decided to put the QtD >>> project on hold. QtD has a potential to become a complete and effective >>> development platform for D but it is not going to happen soon (unless >>> people with harder hearts take it over). We have spent half of the day >>> hunting yet another dmd bug-o-feature and that is the last straw. >>> >>> We offer our apologies to people who put their hope upon the project. >>> Please come back in a year or two when the language has a stable >>> compiler with the features fully specified, implemented and debugged. >> >> This is a loss, it must be frustrating for you spending so much time >> on it. >> Thank you anyway for the effort, it was quite exciting to see QtD >> almost come to >> be! I hope it will be continued some day. > > Having some experience in this, I really don't think other people can > even begin to think what Max feels at this point. > > I could go on-and-on about this, but those who've never invested enough > to break their back and then simply be met by folks who !believe! they > have any way of understanding, I really think they should stay shut up. Well I've used D for my thesis work since 2007, and indeed bugs can be very frustrating particularly when you're pressured to achieve something else than just finding your way around issues. > I left the language because of a personal quarrel with Andrei. I do recall you were annoyed at some point but I failed to perceive the extent. If there's anything I can do at this point to make things straight, please let me know. > And that > was long after vigorously defending him in the Big Battle. But that > should not mean I have any second thoughts about what should be done, or > whether we can pull it off. > > The language as such, has a niche way bigger than it'd seem, in spite of > reading this NG or the random outside article (found with Google). Man, > I'd love to become an evangelist for D, and I really have a few ideas > (that presumably, most of our long-time contributors recognize), that > would help D in carving its own footprint on the map. > > The place and position are now very much clearer to me, than they were > six months ago. This would mean establishing a place that doesn't > necessarily challenge ASM, C, C++, or Python or Java. And, within this > particular place, none of them can possibly challenge D. (!!) I'm sure we all here would be interested to hear more of your ideas. Thanks, Andrei From newshound2 at digitalmars.com Thu Sep 16 20:58:56 2010 From: newshound2 at digitalmars.com (Walter Bright) Date: Thu, 16 Sep 2010 20:58:56 -0700 Subject: dmd 1.064 and 2.049 release Message-ID: This is primarily a bug fix release. http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.064.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.049.zip From none at anon.com Thu Sep 16 21:48:58 2010 From: none at anon.com (BCS) Date: Fri, 17 Sep 2010 04:48:58 +0000 (UTC) Subject: dmd 1.064 and 2.049 release References: Message-ID: Hello Walter, > This is primarily a bug fix release. And that it is! Great job! -- ... < From a at a.a Fri Sep 17 00:09:38 2010 From: a at a.a (Nick Sabalausky) Date: Fri, 17 Sep 2010 03:09:38 -0400 Subject: dmd 1.064 and 2.049 release References: Message-ID: "Walter Bright" wrote in message news:i6up2t$19cp$1 at digitalmars.com... > This is primarily a bug fix release. > > http://www.digitalmars.com/d/1.0/changelog.html > http://ftp.digitalmars.com/dmd.1.064.zip > > http://www.digitalmars.com/d/2.0/changelog.html > http://ftp.digitalmars.com/dmd.2.049.zip Excellent, I see the current RDMD has been included :) Now maybe we can get these applied ("squeak" says the wheel...): http://d.puremagic.com/issues/show_bug.cgi?id=4672 http://d.puremagic.com/issues/show_bug.cgi?id=4683 http://d.puremagic.com/issues/show_bug.cgi?id=4684 http://d.puremagic.com/issues/show_bug.cgi?id=4688 From SeeWebsiteForEmail at erdani.org Fri Sep 17 01:15:31 2010 From: SeeWebsiteForEmail at erdani.org (Andrei Alexandrescu) Date: Fri, 17 Sep 2010 03:15:31 -0500 Subject: QtD is suspended In-Reply-To: References: Message-ID: On 9/16/10 14:37 CDT, Max Samukha wrote: > On 09/16/2010 06:44 PM, Andrei Alexandrescu wrote: >> On 9/16/10 9:22 CDT, Max Samukha wrote: >>> After a good amount of hesitation, we have decided to put the QtD >>> project on hold. QtD has a potential to become a complete and effective >>> development platform for D but it is not going to happen soon (unless >>> people with harder hearts take it over). We have spent half of the day >>> hunting yet another dmd bug-o-feature and that is the last straw. >>> >>> We offer our apologies to people who put their hope upon the project. >>> Please come back in a year or two when the language has a stable >>> compiler with the features fully specified, implemented and debugged. >> >> Hi Max, >> >> Sorry to hear that. Was this an issue of many small annoyances or a few >> big ones? >> >> Thanks, >> >> Andrei > > Hi Andrei, > > Both, I guess. Thanks for replying. This is very helpful. I'll make some points below, definitely not as an attempt to revisit the decision you've already made. > The recent big one is the unspecified behavior of > postblit on const/immutable structs and overloading by rvalue/lvalue. > Specifically, we were bending the generator into generating Qt value > types as structs and hit two problems: > > 1. The generated __cpctor (which does the blit and calls the postblit) > is always non-const and takes a non-const reference to the original. > That means copy-construction of const objects is impossible without casts. > > To proceed, we had to hack the compiler so that __cpctor took a const > original reference and was called on a mutable target reference. That > seemed to work but left us in uncertainty: how it actually should and > will work? Walter and I discussed a fair amount about copying objects with different qualifiers. The syntax we discussed was this(this) const { ... } which would be called after you copy a const or non-const object into a const object. Certain special typechecking applies inside that constructor, but nothing really difficult; it does entail a fair amount of work in the front end, which Walter hasn't find the time to put in. On a funny note, we figured that for a number of reasons it would help to allow C++-style constructors that offer access to the source; it just turns out some idioms need to modify the source as well as the destination. One obvious example is the built-in hashtable that is not shared properly when it's null. Making the copy constructor spring the hashtable to life would make it more uniform in behavior. The situation is a bit ironic - we worked on improving upon C++ constructors but it turns out something similar is still needed in certain situations. Anyway, regardless of whether C++-style constructors will be supported (as an alternative to postblit), the issue you mention is serious. But by and large I think the matter could gave have be settled in a different manner: by not catering for const in the first release. D has a lot to offer besides const, and its const subsystem is a good bit more restrictive than e.g. C++'s, mainly to help with concurrency. So until the typical D idioms for using const become established, it's not a crime to have QtD work without const. I wouldn't go back from a Lexus to a Yugo because the Lexus doesn't have a butt warmer :o). > 2. A bug in the compiler doesn't allow us to overload struct parameters > by ref-ness. So we had to generate by-value parameters where Qt has them > by reference. > > And today we've encountered two other bugs in sequence. One was about > the impossibility to access a template instance member from within a > struct nested in another struct and the second didn't give any line/file > information. > > We could probably work around or ignore all these problems but I think > it is starting to take more time and nerve than we can afford. I understand. Let me ask you this - if your bugs had #1 priority, would that have helped? I mean, is the slow response time to bug submissions a large annoyance factor? Thanks, Andrei From doob at me.com Fri Sep 17 02:06:24 2010 From: doob at me.com (Jacob Carlborg) Date: Fri, 17 Sep 2010 11:06:24 +0200 Subject: D/Objective-C: hit a dead end, start anew In-Reply-To: References: Message-ID: On 2010-09-17 01:46, Michel Fortin wrote: > > > The D/Objective-C bridge is a project that was aiming at making Cocoa > usable from D. > > It's somewhat similar to QtD. The timing of this announcement isn't > entirely coincidental with today's announcement about QtD: my > announcement was ready, QtD's was the trigger for my Publish button. > Even though the problems are probably quite different between the two > projects, they both share a common need for runtime-reflection, playing > with the object model from another language, static initialization from > within mixins that shouldn't create circular module dependency, and > probably a couple others. Are referring to the need for calling a static method on a class that should be able to be loaded from a nib? In that case have you tried, at runtime, inspecting the symbol table in the loaded binary and getting the address to the necessary functions and calling them. > It is my feeling that for dealing with Objective-C, things will be much > cleaner by working directly inside of the compiler. D templates are > fabulous, and I'm quite amazed that I could do what I did, but the > bridge creates just too much generated code to make the whole thing > usable. So I think it's time for a new approach. I noted this as well, it creates an insanely amount of code. I also noted that compiling as a dynamic library reduces the size about 50%. I've actually been working on my own implementation of an Objective-C/D bridge based on your blog posts and documentation. I've never released or announcement anything but I have a project at dsource: http://dsource.org/projects/dstep . I started this before your bridge supported DMD because of no support for DMD or Tango and I was not happy with the GPL license. I also added small enhancements in some places. I also have ruby scripts (based on bridgesupprt) for automatically creating bindings with results that are ok but not perfect. I was thinking about create a tool using Clang and hopefully have a completely automatic process when creating bindings. What would you say about working together on an Objective-C/D bridge? -- /Jacob Carlborg From michel.fortin at michelf.com Fri Sep 17 04:25:44 2010 From: michel.fortin at michelf.com (Michel Fortin) Date: Fri, 17 Sep 2010 07:25:44 -0400 Subject: D/Objective-C: hit a dead end, start anew References: Message-ID: On 2010-09-17 05:06:24 -0400, Jacob Carlborg said: > On 2010-09-17 01:46, Michel Fortin wrote: >> >> >> The D/Objective-C bridge is a project that was aiming at making Cocoa >> usable from D. >> >> It's somewhat similar to QtD. The timing of this announcement isn't >> entirely coincidental with today's announcement about QtD: my >> announcement was ready, QtD's was the trigger for my Publish button. >> Even though the problems are probably quite different between the two >> projects, they both share a common need for runtime-reflection, playing >> with the object model from another language, static initialization from >> within mixins that shouldn't create circular module dependency, and >> probably a couple others. > > Are referring to the need for calling a static method on a class that > should be able to be loaded from a nib? In that case have you tried, at > runtime, inspecting the symbol table in the loaded binary and getting > the address to the necessary functions and calling them. Do you mean creating my own parallel implementation of static constructors that disregards module dependencies? That could have worked indeed, but I had more pressing problems to handle. Lazy initialization worked as a replacement, it just was just suboptimal. >> It is my feeling that for dealing with Objective-C, things will be much >> cleaner by working directly inside of the compiler. D templates are >> fabulous, and I'm quite amazed that I could do what I did, but the >> bridge creates just too much generated code to make the whole thing >> usable. So I think it's time for a new approach. > > I noted this as well, it creates an insanely amount of code. I also > noted that compiling as a dynamic library reduces the size about 50%. But even a size reduction of 50% doesn't make it much more attractive, it's still too big. That's basically why I've changed my approach. > I've actually been working on my own implementation of an Objective-C/D > bridge based on your blog posts and documentation. I've never released > or announcement anything but I have a project at dsource: > http://dsource.org/projects/dstep . I started this before your bridge > supported DMD because of no support for DMD or Tango and I was not > happy with the GPL license. I also added small enhancements in some > places. > > I also have ruby scripts (based on bridgesupprt) for automatically > creating bindings with results that are ok but not perfect. I was > thinking about create a tool using Clang and hopefully have a > completely automatic process when creating bindings. > > What would you say about working together on an Objective-C/D bridge? That'd be great. I'm probably not going to call it a bridge for long though: calling it a bridge won't make much sense once the object model is supported natively instead of through some abstraction. You seem well ahead of me about generating bindings. Once I have something usable inside the compiler, it shouldn't be too hard to change the output of your scripts so they generate something compatible with it. Or maybe you want to hack the compiler source with me? :-) One thing I'll have to figure out is how to share the modified compiler source code. I could publish patches against various versions of DMD, or I could provide the modified frontend source stripped from the backend, but I have no license to redistribute the backend so I can't expose directly my Git repository. I should probably ask Walter, perhaps he'll agree about having a second copy of DMD being hosted on dsource for this project. -- Michel Fortin michel.fortin at michelf.com http://michelf.com/ From b.helyer at gmail.com Fri Sep 17 04:45:15 2010 From: b.helyer at gmail.com (Bernard Helyer) Date: Fri, 17 Sep 2010 11:45:15 +0000 (UTC) Subject: dmd 1.064 and 2.049 release References: Message-ID: On Thu, 16 Sep 2010 20:58:56 -0700, Walter Bright wrote: > This is primarily a bug fix release. > > http://www.digitalmars.com/d/1.0/changelog.html > http://ftp.digitalmars.com/dmd.1.064.zip > > http://www.digitalmars.com/d/2.0/changelog.html > http://ftp.digitalmars.com/dmd.2.049.zip Looks solid, but it appears to have broken debugging info. (Linux) Looking through the bug tracker now. From b.helyer at gmail.com Fri Sep 17 04:48:58 2010 From: b.helyer at gmail.com (Bernard Helyer) Date: Fri, 17 Sep 2010 11:48:58 +0000 (UTC) Subject: dmd 1.064 and 2.049 release References: Message-ID: On Fri, 17 Sep 2010 11:45:15 +0000, Bernard Helyer wrote: > Looks solid, but it appears to have broken debugging info. (Linux) > > Looking through the bug tracker now. Uhhhh disregard that, PEBKAC. ^^; From spambox at d-coding.com Fri Sep 17 07:02:07 2010 From: spambox at d-coding.com (Max Samukha) Date: Fri, 17 Sep 2010 17:02:07 +0300 Subject: QtD is suspended In-Reply-To: References: Message-ID: On 09/17/2010 11:15 AM, Andrei Alexandrescu wrote: > > Thanks for replying. This is very helpful. I'll make some points below, > definitely not as an attempt to revisit the decision you've already made. > >> The recent big one is the unspecified behavior of >> postblit on const/immutable structs and overloading by rvalue/lvalue. >> Specifically, we were bending the generator into generating Qt value >> types as structs and hit two problems: >> >> 1. The generated __cpctor (which does the blit and calls the postblit) >> is always non-const and takes a non-const reference to the original. >> That means copy-construction of const objects is impossible without >> casts. >> >> To proceed, we had to hack the compiler so that __cpctor took a const >> original reference and was called on a mutable target reference. That >> seemed to work but left us in uncertainty: how it actually should and >> will work? > > Walter and I discussed a fair amount about copying objects with > different qualifiers. The syntax we discussed was > > this(this) const { ... } > > which would be called after you copy a const or non-const object into a > const object. Certain special typechecking applies inside that > constructor, but nothing really difficult; it does entail a fair amount > of work in the front end, which Walter hasn't find the time to put in. Nice to hear that the problem is being worked on. What kind of typechecking will be performed in const/immutable postblit? > > On a funny note, we figured that for a number of reasons it would help > to allow C++-style constructors that offer access to the source; it just > turns out some idioms need to modify the source as well as the destination. Funny. We seem to be in the opposite situation. We originally thought that postblit won't be enough for QtD but it looks like copying most (or all, not sure) value types in Qt do not need access to the source object. > > One obvious example is the built-in hashtable that is not shared > properly when it's null. Making the copy constructor spring the > hashtable to life would make it more uniform in behavior. > > The situation is a bit ironic - we worked on improving upon C++ > constructors but it turns out something similar is still needed in > certain situations. > > Anyway, regardless of whether C++-style constructors will be supported > (as an alternative to postblit), the issue you mention is serious. But > by and large I think the matter could gave have be settled in a > different manner: by not catering for const in the first release. D has > a lot to offer besides const, and its const subsystem is a good bit more > restrictive than e.g. C++'s, mainly to help with concurrency. So until > the typical D idioms for using const become established, it's not a > crime to have QtD work without const. The thing is that D's const looked well suited for our purpose. Postblit and const were discussed in TDPL so we concluded that their design and implementation were more or less complete and harmonized. We took the effort to change the generator to properly generate const qualifiers and only after that discovered the postblit issues. > I wouldn't go back from a Lexus to > a Yugo because the Lexus doesn't have a butt warmer :o). :) The Lexus doesn't start and has an obscenity scratched on its hood. A butt warmer would double its resale price. > >> 2. A bug in the compiler doesn't allow us to overload struct parameters >> by ref-ness. So we had to generate by-value parameters where Qt has them >> by reference. >> >> And today we've encountered two other bugs in sequence. One was about >> the impossibility to access a template instance member from within a >> struct nested in another struct and the second didn't give any line/file >> information. >> >> We could probably work around or ignore all these problems but I think >> it is starting to take more time and nerve than we can afford. > > I understand. Let me ask you this - if your bugs had #1 priority, would > that have helped? I mean, is the slow response time to bug submissions a > large annoyance factor? Definitely. The notorious one (http://d.puremagic.com/issues/show_bug.cgi?id=424), which hindered QtD development on Windows, drove a couple of good users away from D and became a powerful FUD generator, was submitted 4 years ago. > > > Thanks, > > Andrei I think one of the big factors causing annoyances is miscommunication. While you have immediate access to Walter, most of us have to settle for this NG and #d IRC channel (the latter has become a source of nothing but discouragement). We carefully follow discussions (at least we try to) in the mail-lists and NG but often do not know what is the final decision on a problem having been discussed. One example is the semantics of clear() and scoped(). As I understood from one of your posts, you agree that resurrecting the destroyed object by calling its default constructor is objectionable. However, no further action followed. So we are at a loss whether you have a better solution, are still thinking about one, don't have time to change the implementation or don't want to change the thing because it is engraved in TDPL. The same applies to 'scoped' moving the object. Another example is half-implemented 'inout'. Is a correct implementation fundamentally impossible or Walter haven't had time for it? Such unterminated discussions tend to stack up in our minds creating a possibly very exaggerated image of instability. From doob at me.com Fri Sep 17 07:06:27 2010 From: doob at me.com (Jacob Carlborg) Date: Fri, 17 Sep 2010 16:06:27 +0200 Subject: D/Objective-C: hit a dead end, start anew In-Reply-To: References: Message-ID: On 2010-09-17 13:25, Michel Fortin wrote: > On 2010-09-17 05:06:24 -0400, Jacob Carlborg said: > >> On 2010-09-17 01:46, Michel Fortin wrote: >>> >>> >>> The D/Objective-C bridge is a project that was aiming at making Cocoa >>> usable from D. >>> >>> It's somewhat similar to QtD. The timing of this announcement isn't >>> entirely coincidental with today's announcement about QtD: my >>> announcement was ready, QtD's was the trigger for my Publish button. >>> Even though the problems are probably quite different between the two >>> projects, they both share a common need for runtime-reflection, playing >>> with the object model from another language, static initialization from >>> within mixins that shouldn't create circular module dependency, and >>> probably a couple others. >> >> Are referring to the need for calling a static method on a class that >> should be able to be loaded from a nib? In that case have you tried, >> at runtime, inspecting the symbol table in the loaded binary and >> getting the address to the necessary functions and calling them. > > Do you mean creating my own parallel implementation of static > constructors that disregards module dependencies? That could have worked > indeed, but I had more pressing problems to handle. Lazy initialization > worked as a replacement, it just was just suboptimal. Yes I also used lazy initialization as much as possible to solve the circular dependencies problem with the module constructors. But in this case I was referring to the following code example: static this () { AppController.objcClass; } class AppControler : NSObject { .... } I used the same approach as flectioned (http://dsource.org/projects/flectioned/) which is: * Load the currently running binary * Traverse the symbol table * Collect the address of all D symbols ending with "objcClass" * Covert all the collected addresses an convert them to function pointers and then call them. Then the user of the library doesn't have to manually call the objcClass method. >>> It is my feeling that for dealing with Objective-C, things will be much >>> cleaner by working directly inside of the compiler. D templates are >>> fabulous, and I'm quite amazed that I could do what I did, but the >>> bridge creates just too much generated code to make the whole thing >>> usable. So I think it's time for a new approach. >> >> I noted this as well, it creates an insanely amount of code. I also >> noted that compiling as a dynamic library reduces the size about 50%. > > But even a size reduction of 50% doesn't make it much more attractive, > it's still too big. That's basically why I've changed my approach. > >> I've actually been working on my own implementation of an >> Objective-C/D bridge based on your blog posts and documentation. I've >> never released or announcement anything but I have a project at >> dsource: http://dsource.org/projects/dstep . I started this before >> your bridge supported DMD because of no support for DMD or Tango and I >> was not happy with the GPL license. I also added small enhancements in >> some places. >> >> I also have ruby scripts (based on bridgesupprt) for automatically >> creating bindings with results that are ok but not perfect. I was >> thinking about create a tool using Clang and hopefully have a >> completely automatic process when creating bindings. >> >> What would you say about working together on an Objective-C/D bridge? > > That'd be great. I'm probably not going to call it a bridge for long > though: calling it a bridge won't make much sense once the object model > is supported natively instead of through some abstraction. No I guess, I was not completely sure which approach you were going to take and I had to call it something. > You seem well ahead of me about generating bindings. Once I have > something usable inside the compiler, it shouldn't be too hard to change > the output of your scripts so they generate something compatible with it. No, that would be the easy part :) > Or maybe you want to hack the compiler source with me? :-) One thing > I'll have to figure out is how to share the modified compiler source > code. I could publish patches against various versions of DMD, or I > could provide the modified frontend source stripped from the backend, > but I have no license to redistribute the backend so I can't expose > directly my Git repository. I should probably ask Walter, perhaps he'll > agree about having a second copy of DMD being hosted on dsource for this > project. Hm, I don't know which approach would be the best. There's also ddmd, the D port of the frontend. They only distribute the frontend and makefiles for building the backend as a library and then they link it all together. I know that several other people/projects have got Walter's permission to distribute at least the compiler, as a binary. Have you thought about what needs to be modified/added yet? Is it basically better support for runtime reflection? -- /Jacob Carlborg From doob at me.com Fri Sep 17 07:11:12 2010 From: doob at me.com (Jacob Carlborg) Date: Fri, 17 Sep 2010 16:11:12 +0200 Subject: D/Objective-C: hit a dead end, start anew In-Reply-To: References: Message-ID: On 2010-09-17 16:06, Jacob Carlborg wrote: > On 2010-09-17 13:25, Michel Fortin wrote: >> On 2010-09-17 05:06:24 -0400, Jacob Carlborg said: >> >>> On 2010-09-17 01:46, Michel Fortin wrote: >>>> >>>> >>>> The D/Objective-C bridge is a project that was aiming at making Cocoa >>>> usable from D. >>>> >>>> It's somewhat similar to QtD. The timing of this announcement isn't >>>> entirely coincidental with today's announcement about QtD: my >>>> announcement was ready, QtD's was the trigger for my Publish button. >>>> Even though the problems are probably quite different between the two >>>> projects, they both share a common need for runtime-reflection, playing >>>> with the object model from another language, static initialization from >>>> within mixins that shouldn't create circular module dependency, and >>>> probably a couple others. >>> >>> Are referring to the need for calling a static method on a class that >>> should be able to be loaded from a nib? In that case have you tried, >>> at runtime, inspecting the symbol table in the loaded binary and >>> getting the address to the necessary functions and calling them. >> >> Do you mean creating my own parallel implementation of static >> constructors that disregards module dependencies? That could have worked >> indeed, but I had more pressing problems to handle. Lazy initialization >> worked as a replacement, it just was just suboptimal. > > Yes I also used lazy initialization as much as possible to solve the > circular dependencies problem with the module constructors. But in this > case I was referring to the following code example: > > static this () > { > AppController.objcClass; > } > > class AppControler : NSObject > { > .... > } > > I used the same approach as flectioned > (http://dsource.org/projects/flectioned/) which is: > > * Load the currently running binary > * Traverse the symbol table > * Collect the address of all D symbols ending with "objcClass" > * Covert all the collected addresses an convert them to function > pointers and then call them. > > Then the user of the library doesn't have to manually call the objcClass > method. > >>>> It is my feeling that for dealing with Objective-C, things will be much >>>> cleaner by working directly inside of the compiler. D templates are >>>> fabulous, and I'm quite amazed that I could do what I did, but the >>>> bridge creates just too much generated code to make the whole thing >>>> usable. So I think it's time for a new approach. >>> >>> I noted this as well, it creates an insanely amount of code. I also >>> noted that compiling as a dynamic library reduces the size about 50%. >> >> But even a size reduction of 50% doesn't make it much more attractive, >> it's still too big. That's basically why I've changed my approach. >> >>> I've actually been working on my own implementation of an >>> Objective-C/D bridge based on your blog posts and documentation. I've >>> never released or announcement anything but I have a project at >>> dsource: http://dsource.org/projects/dstep . I started this before >>> your bridge supported DMD because of no support for DMD or Tango and I >>> was not happy with the GPL license. I also added small enhancements in >>> some places. >>> >>> I also have ruby scripts (based on bridgesupprt) for automatically >>> creating bindings with results that are ok but not perfect. I was >>> thinking about create a tool using Clang and hopefully have a >>> completely automatic process when creating bindings. >>> >>> What would you say about working together on an Objective-C/D bridge? >> >> That'd be great. I'm probably not going to call it a bridge for long >> though: calling it a bridge won't make much sense once the object model >> is supported natively instead of through some abstraction. > > No I guess, I was not completely sure which approach you were going to > take and I had to call it something. > >> You seem well ahead of me about generating bindings. Once I have >> something usable inside the compiler, it shouldn't be too hard to change >> the output of your scripts so they generate something compatible with it. > > No, that would be the easy part :) > >> Or maybe you want to hack the compiler source with me? :-) One thing >> I'll have to figure out is how to share the modified compiler source >> code. I could publish patches against various versions of DMD, or I >> could provide the modified frontend source stripped from the backend, >> but I have no license to redistribute the backend so I can't expose >> directly my Git repository. I should probably ask Walter, perhaps he'll >> agree about having a second copy of DMD being hosted on dsource for this >> project. > > Hm, I don't know which approach would be the best. There's also ddmd, > the D port of the frontend. They only distribute the frontend and > makefiles for building the backend as a library and then they link it > all together. I know that several other people/projects have got > Walter's permission to distribute at least the compiler, as a binary. > > Have you thought about what needs to be modified/added yet? Is it > basically better support for runtime reflection? I can also add that I can both try to work on the compiler or the bindings scripts, doesn't matter. But it feels like I hit a dead end with the scripts, I don't think they will produce any better result than they currently are without a proper Objective-C/C frontend. -- /Jacob Carlborg From michel.fortin at michelf.com Fri Sep 17 07:18:12 2010 From: michel.fortin at michelf.com (Michel Fortin) Date: Fri, 17 Sep 2010 10:18:12 -0400 Subject: QtD is suspended References: Message-ID: On 2010-09-17 04:15:31 -0400, Andrei Alexandrescu said: > On a funny note, we figured that for a number of reasons it would help > to allow C++-style constructors that offer access to the source; it > just turns out some idioms need to modify the source as well as the > destination. > > One obvious example is the built-in hashtable that is not shared > properly when it's null. Making the copy constructor spring the > hashtable to life would make it more uniform in behavior. At the basic level I feel uneasy with this whole idea of modifying the source while copying. It means that you can't copy the source if it is const. Do you really want to make const containers uncopyable? -- Michel Fortin michel.fortin at michelf.com http://michelf.com/ From michel.fortin at michelf.com Fri Sep 17 07:56:23 2010 From: michel.fortin at michelf.com (Michel Fortin) Date: Fri, 17 Sep 2010 10:56:23 -0400 Subject: D/Objective-C: hit a dead end, start anew References: Message-ID: On 2010-09-17 10:06:27 -0400, Jacob Carlborg said: > Have you thought about what needs to be modified/added yet? Is it > basically better support for runtime reflection? Basically I'm adding the necessary pieces so that DMD can generate object files containing the exact same things an the Objective-C compiler would generate. I am also adding the few necessary syntactic additions to support this. The end result should be as efficient as the Objective-C compiler itself. One thing I am *not* doing is adding the alien Objective-C syntax to D. Declaring an Objective-C class will look like this: extern (Objective-C) class NSObject { NSString description() @property; void perform(SEL selector, NSObject object) [performSelector:withObject:]; } and for the most part should be semantically equivalent to a regular D class. The only cases where I'm adding to the syntax are those where special things need to be expressed, such as the Objective-C selector when necessary for one of the two methods above. Most of the work is being done in the glue code that links the frontend to the backend. I'm trying to not affect the semantics of any D construct, simply binding them to the Objective-C runtime where appropriate. -- Michel Fortin michel.fortin at michelf.com http://michelf.com/ From SeeWebsiteForEmail at erdani.org Fri Sep 17 08:14:21 2010 From: SeeWebsiteForEmail at erdani.org (Andrei Alexandrescu) Date: Fri, 17 Sep 2010 10:14:21 -0500 Subject: QtD is suspended In-Reply-To: References: Message-ID: On 9/17/10 9:18 CDT, Michel Fortin wrote: > On 2010-09-17 04:15:31 -0400, Andrei Alexandrescu > said: > >> On a funny note, we figured that for a number of reasons it would help >> to allow C++-style constructors that offer access to the source; it >> just turns out some idioms need to modify the source as well as the >> destination. >> >> One obvious example is the built-in hashtable that is not shared >> properly when it's null. Making the copy constructor spring the >> hashtable to life would make it more uniform in behavior. > > At the basic level I feel uneasy with this whole idea of modifying the > source while copying. It means that you can't copy the source if it is > const. Do you really want to make const containers uncopyable? Again, the scenario is motivated by this: void main() { int[int] hash; fun(hash); assert(!(42 in hash)); hash[0] = 10; fun(hash); assert(42 in hash); } void fun(int[int] hash) { hash[42] = 42; } Walter's idea was as follows. If the hash's copy constructor has access to the source, then that constructor could lazily initialize the pointer internally shared by the existing instance (the one in main()) and the one being created (the one passed to fun()). Then, the program would behave more predictably and also stay efficient - lazy initialization for the win. Note that const objects don't have this problem. Also note that the non-null reference matter is related to this one. Andrei From michel.fortin at michelf.com Fri Sep 17 08:48:13 2010 From: michel.fortin at michelf.com (Michel Fortin) Date: Fri, 17 Sep 2010 11:48:13 -0400 Subject: QtD is suspended References: Message-ID: On 2010-09-17 11:14:21 -0400, Andrei Alexandrescu said: > On 9/17/10 9:18 CDT, Michel Fortin wrote: >> On 2010-09-17 04:15:31 -0400, Andrei Alexandrescu >> said: >> >>> On a funny note, we figured that for a number of reasons it would help >>> to allow C++-style constructors that offer access to the source; it >>> just turns out some idioms need to modify the source as well as the >>> destination. >>> >>> One obvious example is the built-in hashtable that is not shared >>> properly when it's null. Making the copy constructor spring the >>> hashtable to life would make it more uniform in behavior. >> >> At the basic level I feel uneasy with this whole idea of modifying the >> source while copying. It means that you can't copy the source if it is >> const. Do you really want to make const containers uncopyable? > > Again, the scenario is motivated by this: > > void main() > { > int[int] hash; > fun(hash); > assert(!(42 in hash)); > hash[0] = 10; > fun(hash); > assert(42 in hash); > } > > void fun(int[int] hash) > { > hash[42] = 42; > } > > Walter's idea was as follows. If the hash's copy constructor has access > to the source, then that constructor could lazily initialize the > pointer internally shared by the existing instance (the one in main()) > and the one being created (the one passed to fun()). Then, the program > would behave more predictably and also stay efficient - lazy > initialization for the win. I understand the intent quite well. I'm talking about what happens if the source is const? As in: struct A { int[int] hash; int[int] fun() { return hash; // hash can be altered, can copy } const const(int[int]) fun() { return hash; // here hash is const, what happens? } } With the second accessor the hash is const, so how can you copy it anywhere if copying requires altering the original? Should it be an error? Should the copy be detached when the source is const, breaking reference semantics? Or should we add logical-const (in addition to C++-style constructors)? Now that I think of it, you don't need a fancy struct to make this problem appear, you just need two layers of functions: void fun(const(int[int]) hash) { fun(hash); // calling ourself, how can we copy hash? } Although in this case we could probably assert() that hash is already initialized. In my mind it's simpler to just explain the notion that an uninitialized hash is null and detached from anything else until initialized. Objects works like this (minus the implicit initialization part), so it shouldn't be too hard to understand. Better have pragmatic semantics that work rather than idealistic semantics that fail at a number of cases. -- Michel Fortin michel.fortin at michelf.com http://michelf.com/ From doob at me.com Fri Sep 17 08:50:51 2010 From: doob at me.com (Jacob Carlborg) Date: Fri, 17 Sep 2010 17:50:51 +0200 Subject: D/Objective-C: hit a dead end, start anew In-Reply-To: References: Message-ID: On 2010-09-17 16:56, Michel Fortin wrote: > On 2010-09-17 10:06:27 -0400, Jacob Carlborg said: > >> Have you thought about what needs to be modified/added yet? Is it >> basically better support for runtime reflection? > > Basically I'm adding the necessary pieces so that DMD can generate > object files containing the exact same things an the Objective-C > compiler would generate. I am also adding the few necessary syntactic > additions to support this. The end result should be as efficient as the > Objective-C compiler itself. > > One thing I am *not* doing is adding the alien Objective-C syntax to D. > Declaring an Objective-C class will look like this: > > extern (Objective-C) > class NSObject { > NSString description() @property; > void perform(SEL selector, NSObject object) [performSelector:withObject:]; > } > > and for the most part should be semantically equivalent to a regular D > class. The only cases where I'm adding to the syntax are those where > special things need to be expressed, such as the Objective-C selector > when necessary for one of the two methods above. > > Most of the work is being done in the glue code that links the frontend > to the backend. I'm trying to not affect the semantics of any D > construct, simply binding them to the Objective-C runtime where > appropriate. Sounds good, I also once thought about adding extern (Objective-C) to the language. About the selector syntax, wouldn't it be better to have the same syntax as in Objective-C, @selector(performSelector:withObject:). I mean D already has the @annotation syntax for annotations/attributes I don't think we need yet another one. I would also be nice to use @selector(performSelector:withObject:) as an expression (or what is called) to get the selector to a method just like in Objective-C. Have you thought anything about the blocks that Apple added in Snow Leopard, if those could be supported as well? What about Objective-C categories? -- /Jacob Carlborg From spambox at d-coding.com Fri Sep 17 09:23:19 2010 From: spambox at d-coding.com (Max Samukha) Date: Fri, 17 Sep 2010 19:23:19 +0300 Subject: QtD is suspended In-Reply-To: References: Message-ID: On 09/17/2010 06:48 PM, Michel Fortin wrote: > On 2010-09-17 11:14:21 -0400, Andrei Alexandrescu > said: > > Now that I think of it, you don't need a fancy struct to make this > problem appear, you just need two layers of functions: > > void fun(const(int[int]) hash) { > fun(hash); // calling ourself, how can we copy hash? > } > > Although in this case we could probably assert() that hash is already > initialized. > > In my mind it's simpler to just explain the notion that an uninitialized > hash is null and detached from anything else until initialized. Objects > works like this (minus the implicit initialization part), so it > shouldn't be too hard to understand. Better have pragmatic semantics > that work rather than idealistic semantics that fail at a number of cases. > Another difference between object and AA - if one wants to initialize a class object reference, he does it with a sane syntax. To eagerly initialize an empty AA, woodoo is needed. From lutger.blijdestijn at gmail.com Fri Sep 17 09:37:45 2010 From: lutger.blijdestijn at gmail.com (Lutger) Date: Fri, 17 Sep 2010 18:37:45 +0200 Subject: QtD is suspended References: Message-ID: Georg Wrede wrote: > On 09/17/2010 01:01 AM, Lutger wrote: >> Max Samukha wrote: >> >>> After a good amount of hesitation, we have decided to put the QtD >>> project on hold. QtD has a potential to become a complete and effective >>> development platform for D but it is not going to happen soon (unless >>> people with harder hearts take it over). We have spent half of the day >>> hunting yet another dmd bug-o-feature and that is the last straw. >>> >>> We offer our apologies to people who put their hope upon the project. >>> Please come back in a year or two when the language has a stable >>> compiler with the features fully specified, implemented and debugged. >> >> This is a loss, it must be frustrating for you spending so much time on it. >> Thank you anyway for the effort, it was quite exciting to see QtD almost come >> to be! I hope it will be continued some day. > > Having some experience in this, I really don't think other people can > even begin to think what Max feels at this point. > > I could go on-and-on about this, but those who've never invested enough > to break their back and then simply be met by folks who !believe! they > have any way of understanding, I really think they should stay shut up. I take it this is directed at me. Look, it was a gut reaction. I don't understand why, but if anyone takes offense I'm sorry, I didn't want to provoke that. From SeeWebsiteForEmail at erdani.org Fri Sep 17 09:39:06 2010 From: SeeWebsiteForEmail at erdani.org (Andrei Alexandrescu) Date: Fri, 17 Sep 2010 11:39:06 -0500 Subject: QtD is suspended In-Reply-To: References: Message-ID: On 09/17/2010 09:02 AM, Max Samukha wrote: > On 09/17/2010 11:15 AM, Andrei Alexandrescu wrote: > Nice to hear that the problem is being worked on. What kind of > typechecking will be performed in const/immutable postblit? The tricky part in that constructor is that you must be able to assign the fields, so they are effectively non-const, but you must NOT escape outside the constructor as modifiable lvalues. Consider: int * global; void foo(ref int x) { global = &x; } struct S { int a; this(this) immutable { a = 5; foo(a); } } The program should not compile. If it did, global would be a backdoor for modifying an immutable object. Replacing const with immutable seems to make things less stringent, but not in reality. The same typechecking must be applied to const postblit because const is a subtype of immutable. >> On a funny note, we figured that for a number of reasons it would help >> to allow C++-style constructors that offer access to the source; it just >> turns out some idioms need to modify the source as well as the >> destination. > > Funny. We seem to be in the opposite situation. We originally thought > that postblit won't be enough for QtD but it looks like copying most (or > all, not sure) value types in Qt do not need access to the source object. Yah, it's a relatively rare situation. I enjoy the robustness of this(this), but see my most recent post. > The thing is that D's const looked well suited for our purpose. Postblit > and const were discussed in TDPL so we concluded that their design and > implementation were more or less complete and harmonized. We took the > effort to change the generator to properly generate const qualifiers and > only after that discovered the postblit issues. I understand. Were it not for that particular issue, it's not impossible you would have run into some others. D's immutability subsystem is not new, but it's one of the first deployed in a practical language. Just like with other features (exceptions, templates, lambdas, AOP...), some time is needed for the appropriate idioms to emerge. QtD was the first large-scale deployment of const, and it was expected to run into practical as well as theoretical matters. We haven't deployed const into Phobos yet for the same reason, and there is ongoing discussion on how to best go about it. Bottom line, I have a few thoughts on the matter. First, at this point in const's maturity, it's easier to convert a working codebase to using const than to design one from scratch for const. This is counter-intuitive, but it's dictated by const's immaturity. I'm sure the trend will reverse in a couple of years. (Come to think of this: it took over 15 years for C++'s exceptions to achieve any sign of idiomatic usage, and even now very few people know e.g. how to transport one exception from a thread to another. Java has made obvious-in-hindsight errors in designing its exception subsystem, even though it already had a large body of experience with C++ at its disposal.) Second thought is, I am sure the use of D's const, even after it matures, will be less pervasive than the use of const in C++. This inescapably follows from the fact that D const guarantees more and is more restrictive than C++'s const. In C++ I slap const on anything that comes in sight: function parameters, stack variables, member functions... At the same time, I fully realize that the assurance I get in return is quite weak. In D, I afford only a subset of uses of const, but the payout is much more powerful. Third thought is, we did not find the design for immutable and const as much as the design found us. What we wanted was a guarantee that you get to share immutable data, which we always believed is fundamental. Everything else was aftermath. >> I wouldn't go back from a Lexus to >> a Yugo because the Lexus doesn't have a butt warmer :o). > > :) The Lexus doesn't start and has an obscenity scratched on its hood. A > butt warmer would double its resale price. And a tank full of gas would triple it :o). >> I understand. Let me ask you this - if your bugs had #1 priority, would >> that have helped? I mean, is the slow response time to bug submissions a >> large annoyance factor? > > Definitely. The notorious one > (http://d.puremagic.com/issues/show_bug.cgi?id=424), which hindered QtD > development on Windows, drove a couple of good users away from D and > became a powerful FUD generator, was submitted 4 years ago. That bug comes often in my chats with Walter. The fact of the matter is that that is a difficult bug to find and fix in an assembly program. Walter is working slowly on translating the linker into C, which should simplify a lot of things. I'll also add that he did fix two comparably pernicious linker bugs, one recently. > I think one of the big factors causing annoyances is miscommunication. > While you have immediate access to Walter, most of us have to settle for > this NG and #d IRC channel (the latter has become a source of nothing > but discouragement). Yah :o). I occasionally lurk there. It's amusing but hardly productive. > We carefully follow discussions (at least we try to) in the mail-lists > and NG but often do not know what is the final decision on a problem > having been discussed. I understand. At the same time, only this post took me quite a long time. Just like you all, most of my time of day is already spoken for. Doing my best. > One example is the semantics of clear() and scoped(). As I understood > from one of your posts, you agree that resurrecting the destroyed object > by calling its default constructor is objectionable. However, no further > action followed. So we are at a loss whether you have a better solution, > are still thinking about one, don't have time to change the > implementation or don't want to change the thing because it is engraved > in TDPL. The same applies to 'scoped' moving the object. Good point. Also, clear() has been a favorite topic on #d because it's good evidence of my incompetence. The intent of clear(obj) is rather simple. It's supposed to put obj in a well-defined, destroyable state that does not allocate resources. It's the type system's last-ditch effort to preserve safety while at the same time releasing all object state. Currently, clear() works incorrectly for classes, where it invokes the default constructor. SVN doesn't assign the blame to me, but the decision does originate in discussions I took part in. clear() shouldn't call the default constructor of the class because then the class object is free to allocate resources once again. What it should do is to blast the default initializer for each field in the class. That's a well-defined state that doesn't allocate resources - great. There are two problems with that state. One, the state might fail the invariant of the object, but that's expected - once you called clear(), you leave an empty shell behind that's unusable unless you reseat something into it. Second, calling the destructor again from that state is problematic (because of failing the invariant) and the GC calls the destructor. This is also solvable: the GC might memcmp() the state of the object against its default state. If comparison comes positive, the destructor is not invoked. We need to be careful that doesn't impact collection times. > Another example is half-implemented 'inout'. Is a correct implementation > fundamentally impossible or Walter haven't had time for it? A correct implementation is possible and we have a good understanding of what it takes. Walter didn't get around to it yet. > Such unterminated discussions tend to stack up in our minds creating a > possibly very exaggerated image of instability. I understand. Oddly enough, we only now have such a productive discussion, after the destructor has been called :o). Andrei From SeeWebsiteForEmail at erdani.org Fri Sep 17 09:44:30 2010 From: SeeWebsiteForEmail at erdani.org (Andrei Alexandrescu) Date: Fri, 17 Sep 2010 11:44:30 -0500 Subject: QtD is suspended In-Reply-To: References: Message-ID: On 9/17/10 10:48 CDT, Michel Fortin wrote: > I understand the intent quite well. I'm talking about what happens if > the source is const? The whole point is, mutation is the motivator. If you copy an empty hash, no problem because the receiver can't mutate it. > In my mind it's simpler to just explain the notion that an uninitialized > hash is null and detached from anything else until initialized. Objects > works like this (minus the implicit initialization part), so it > shouldn't be too hard to understand. Better have pragmatic semantics > that work rather than idealistic semantics that fail at a number of cases. That's a fair point. Andrei From schveiguy at yahoo.com Fri Sep 17 10:01:08 2010 From: schveiguy at yahoo.com (Steven Schveighoffer) Date: Fri, 17 Sep 2010 13:01:08 -0400 Subject: QtD is suspended References: Message-ID: On Fri, 17 Sep 2010 12:39:06 -0400, Andrei Alexandrescu wrote: > On 09/17/2010 09:02 AM, Max Samukha wrote: >> One example is the semantics of clear() and scoped(). As I understood >> from one of your posts, you agree that resurrecting the destroyed object >> by calling its default constructor is objectionable. However, no further >> action followed. So we are at a loss whether you have a better solution, >> are still thinking about one, don't have time to change the >> implementation or don't want to change the thing because it is engraved >> in TDPL. The same applies to 'scoped' moving the object. > > Good point. Also, clear() has been a favorite topic on #d because it's > good evidence of my incompetence. One bad decision does not mean incompetence unless you're in politics... > The intent of clear(obj) is rather simple. It's supposed to put obj in a > well-defined, destroyable state that does not allocate resources. It's > the type system's last-ditch effort to preserve safety while at the same > time releasing all object state. > > Currently, clear() works incorrectly for classes, where it invokes the > default constructor. SVN doesn't assign the blame to me, but the > decision does originate in discussions I took part in. clear() shouldn't > call the default constructor of the class because then the class object > is free to allocate resources once again. What it should do is to blast > the default initializer for each field in the class. That's a > well-defined state that doesn't allocate resources - great. > > There are two problems with that state. One, the state might fail the > invariant of the object, but that's expected - once you called clear(), > you leave an empty shell behind that's unusable unless you reseat > something into it. > > Second, calling the destructor again from that state is problematic > (because of failing the invariant) and the GC calls the destructor. This > is also solvable: the GC might memcmp() the state of the object against > its default state. If comparison comes positive, the destructor is not > invoked. We need to be careful that doesn't impact collection times. Slightly OT here, but memcmp isn't necessary. We have a couple easy tools at our disposal. One I've suggested in the past -- zero out the vtable. This makes a loud error if you try to use the object again (and I even think Sean added stack traces to null pointer violations recently), plus gives no access to the destructor (easily detectable by the GC). The other I just thought of, each object memory block has a GC flag (FINALIZE?) that indicates it should run a destructor. Just clear that flag. This may need some optimization, I think at the moment you need to take the GC lock. If you want to continue this discussion, move to D newsgroup probably... -Steve From schveiguy at yahoo.com Fri Sep 17 10:04:08 2010 From: schveiguy at yahoo.com (Steven Schveighoffer) Date: Fri, 17 Sep 2010 13:04:08 -0400 Subject: QtD is suspended References: Message-ID: On Fri, 17 Sep 2010 12:44:30 -0400, Andrei Alexandrescu wrote: > On 9/17/10 10:48 CDT, Michel Fortin wrote: >> I understand the intent quite well. I'm talking about what happens if >> the source is const? > > The whole point is, mutation is the motivator. If you copy an empty > hash, no problem because the receiver can't mutate it. yeah, but he can read it: struct S { int[int] hash; const(int[int]) getHash() const { return hash; } } void main() { S s; auto h = s.getHash(); s.hash[1] = 1; assert(1 in h); // fails } -Steve From SeeWebsiteForEmail at erdani.org Fri Sep 17 10:23:50 2010 From: SeeWebsiteForEmail at erdani.org (Andrei Alexandrescu) Date: Fri, 17 Sep 2010 12:23:50 -0500 Subject: QtD is suspended In-Reply-To: References: Message-ID: On 9/17/10 12:04 CDT, Steven Schveighoffer wrote: > On Fri, 17 Sep 2010 12:44:30 -0400, Andrei Alexandrescu > wrote: > >> On 9/17/10 10:48 CDT, Michel Fortin wrote: >>> I understand the intent quite well. I'm talking about what happens if >>> the source is const? >> >> The whole point is, mutation is the motivator. If you copy an empty >> hash, no problem because the receiver can't mutate it. > > yeah, but he can read it: > > struct S > { > int[int] hash; > const(int[int]) getHash() const { return hash; } > } > > void main() > { > S s; > auto h = s.getHash(); > s.hash[1] = 1; > assert(1 in h); // fails > } > > -Steve Good point! Andrei From michel.fortin at michelf.com Fri Sep 17 10:45:46 2010 From: michel.fortin at michelf.com (Michel Fortin) Date: Fri, 17 Sep 2010 13:45:46 -0400 Subject: D/Objective-C: hit a dead end, start anew References: Message-ID: On 2010-09-17 11:50:51 -0400, Jacob Carlborg said: > Sounds good, I also once thought about adding extern (Objective-C) to > the language. About the selector syntax, wouldn't it be better to have > the same syntax as in Objective-C, > @selector(performSelector:withObject:). I mean D already has the > @annotation syntax for annotations/attributes I don't think we need yet > another one. I would also be nice to use > @selector(performSelector:withObject:) as an expression (or what is > called) to get the selector to a method just like in Objective-C. I though about it, but decided against it. The @attribute syntax in D isn't meant *at this time* to accept arguments. Nor is the DMD front end ready to accept arguments for attributes. I don't want to inject my code in the parsing of attributes and their propagation through the frontend. Perhaps one day attributes will accept arguments and we could reconsider. But in the meanwhile I try to avoid touching things which are good candidates for possible future extensions to the regular D language. Also note that member functions of an extern (Objective-C) class or interface always have implicitly a selector (made from the function's name followed by as many colons as there are arguments). The special selector syntax is only needed to specify a different selector than the original. I'm not sure if this kind of implicit thing that you can override fit very well with the notion of an attribute (certainly not the current notion which is basically a binary flag). For the same reason, I don't think reusing Objective-C's "@selector(setObject:forKey:)" syntax for selector literals is a very good idea. I'm not exactly sure what selector literals should look like, but I'm currently leaning about simply making it a function intrinsic: import objc; SEL s = objc.selector("setObject:forKey:"); > Have you thought anything about the blocks that Apple added in Snow > Leopard, if those could be supported as well? > > What about Objective-C categories? Ideally blocks would be the same as delegates, but I hadn't given them much thought yet. I'm not sure whether I want to support creating new categories in D; categories are quite "un-D-like" and despite their usefulness they're clash-prone. But I sure want to be able to access categories from existing Objective-C frameworks. So how exactly this would work? I don't know. In any case, I have much work to do before it's time to think about categories and blocks. The most basic problem to solve in this all new Objective-C "bridge" is the memory management. But I don't want to look at this too much until I get the basics working. -- Michel Fortin michel.fortin at michelf.com http://michelf.com/ From doob at me.com Fri Sep 17 11:48:54 2010 From: doob at me.com (Jacob Carlborg) Date: Fri, 17 Sep 2010 20:48:54 +0200 Subject: D/Objective-C: hit a dead end, start anew In-Reply-To: References: Message-ID: On 2010-09-17 19:45, Michel Fortin wrote: > On 2010-09-17 11:50:51 -0400, Jacob Carlborg said: > >> Sounds good, I also once thought about adding extern (Objective-C) to >> the language. About the selector syntax, wouldn't it be better to have >> the same syntax as in Objective-C, >> @selector(performSelector:withObject:). I mean D already has the >> @annotation syntax for annotations/attributes I don't think we need >> yet another one. I would also be nice to use >> @selector(performSelector:withObject:) as an expression (or what is >> called) to get the selector to a method just like in Objective-C. > > I though about it, but decided against it. The @attribute syntax in D > isn't meant *at this time* to accept arguments. Nor is the DMD front end > ready to accept arguments for attributes. I don't want to inject my code > in the parsing of attributes and their propagation through the frontend. > Perhaps one day attributes will accept arguments and we could > reconsider. But in the meanwhile I try to avoid touching things which > are good candidates for possible future extensions to the regular D > language. > > Also note that member functions of an extern (Objective-C) class or > interface always have implicitly a selector (made from the function's > name followed by as many colons as there are arguments). Will it use the parameter names to build the selector as well? > The special selector syntax is only needed to specify a different selector than the > original. I'm not sure if this kind of implicit thing that you can > override fit very well with the notion of an attribute (certainly not > the current notion which is basically a binary flag). Ok, that make sense. > For the same reason, I don't think reusing Objective-C's > "@selector(setObject:forKey:)" syntax for selector literals is a very > good idea. I'm not exactly sure what selector literals should look like, > but I'm currently leaning about simply making it a function intrinsic: > > import objc; > > SEL s = objc.selector("setObject:forKey:"); I also made a selector method that takes an alias as a parameter and automcatcally builds a selector based on the name of the method and the parameter names. >> Have you thought anything about the blocks that Apple added in Snow >> Leopard, if those could be supported as well? >> >> What about Objective-C categories? > > Ideally blocks would be the same as delegates, but I hadn't given them > much thought yet. Exactly, but I assume that would make them incompatible with existing D delegates. > I'm not sure whether I want to support creating new categories in D; > categories are quite "un-D-like" and despite their usefulness they're > clash-prone. But I sure want to be able to access categories from > existing Objective-C frameworks. So how exactly this would work? I don't > know. Well, most of the stuff that makes Objective-C what it is, is not very D-like. D and Objective-C has different object models, D is Simula based and Objective-C is based on Smalltalk. But categories are a must, I mean a large part of the standard classes (i.e. NSObject) is split in categories. With the standard frameworks that wouldn't be such a big problem, just make regular methods of it in the class it extends, but when a non-standard framework have categories extending standard classes we start to have a problem. > In any case, I have much work to do before it's time to think about > categories and blocks. The most basic problem to solve in this all new > Objective-C "bridge" is the memory management. But I don't want to look > at this too much until I get the basics working. What about using AutoZone, the Objective-C garbage collector? But that would require memory barriers I assume. Please let me know when you start to think more about all this. -- /Jacob Carlborg From osa at aso.osa Fri Sep 17 13:08:19 2010 From: osa at aso.osa (osa) Date: Fri, 17 Sep 2010 15:08:19 -0500 Subject: dmd 1.064 and 2.049 release In-Reply-To: References: Message-ID: After upgrading to 2.049, trying to compile this code: ---- import std.traits; void foo() {} void main() { static assert( ! hasUnsharedAliasing!foo ); } ---- gives this error: dmd2/linux/bin/../../src/phobos/std/traits.d(971): Error: template instance isAssociativeArray!(foo) does not match template declaration isAssociativeArray(T) dmd2/linux/bin/../../src/phobos/std/traits.d(971): Error: expression isAssociativeArray!(foo) is not constant or does not evaluate to a bool It used to work with 2.048 so it is probably caused by fixing bug 4834. Also, error message points to the guts of std.traits and does not give any clue about actual instantiation of hasUnsharedAliasing which caused this. It was not easy to reduce the problem to the small test case. From dsimcha at yahoo.com Fri Sep 17 13:22:21 2010 From: dsimcha at yahoo.com (dsimcha) Date: Fri, 17 Sep 2010 20:22:21 +0000 (UTC) Subject: dmd 1.064 and 2.049 release References: Message-ID: == Quote from osa (osa at aso.osa)'s article > After upgrading to 2.049, trying to compile this code: > ---- > import std.traits; > void foo() {} > void main() { > static assert( ! hasUnsharedAliasing!foo ); > } > ---- > gives this error: > dmd2/linux/bin/../../src/phobos/std/traits.d(971): Error: template > instance isAssociativeArray!(foo) does not match template declaration > isAssociativeArray(T) > dmd2/linux/bin/../../src/phobos/std/traits.d(971): Error: expression > isAssociativeArray!(foo) is not constant or does not evaluate to a bool > It used to work with 2.048 so it is probably caused by fixing bug 4834. > Also, error message points to the guts of std.traits and does not give > any clue about actual instantiation of hasUnsharedAliasing which caused > this. It was not easy to reduce the problem to the small test case. I agree the error message is obtuse, but I don't think this code is supposed to work because foo is not a type. This code does work: import std.traits; void foo() {} void main() { static assert( ! hasUnsharedAliasing!(typeof(foo)) ); } From osa at aso.osa Fri Sep 17 13:47:00 2010 From: osa at aso.osa (osa) Date: Fri, 17 Sep 2010 15:47:00 -0500 Subject: dmd 1.064 and 2.049 release In-Reply-To: References: Message-ID: On 09/17/2010 03:22 PM, dsimcha wrote: > I agree the error message is obtuse, but I don't think this code is supposed to > work because foo is not a type. This code does work: > > import std.traits; > void foo() {} > void main() { > static assert( ! hasUnsharedAliasing!(typeof(foo)) ); > } My bad. However, old code used to work with 2.048, with hasLocalAliasing. Now the next problem. I do not think there is unshared aliasing here: ---- import std.traits; struct Foo { void function() func; } void main() { static assert( ! hasUnsharedAliasing!Foo, "struct Foo has unshared aliasing" ); } ---- but it fails to compile. As far as I understand, functions (unlike delegates) do not have any shared aliasing but hasUnsharedAliasing thinks they do. From dsimcha at yahoo.com Fri Sep 17 14:05:05 2010 From: dsimcha at yahoo.com (dsimcha) Date: Fri, 17 Sep 2010 21:05:05 +0000 (UTC) Subject: dmd 1.064 and 2.049 release References: Message-ID: == Quote from osa (osa at aso.osa)'s article > On 09/17/2010 03:22 PM, dsimcha wrote: > > I agree the error message is obtuse, but I don't think this code is supposed to > > work because foo is not a type. This code does work: > > > > import std.traits; > > void foo() {} > > void main() { > > static assert( ! hasUnsharedAliasing!(typeof(foo)) ); > > } > My bad. However, old code used to work with 2.048, with hasLocalAliasing. > Now the next problem. I do not think there is unshared aliasing here: > ---- > import std.traits; > struct Foo > { > void function() func; > } > void main() > { > static assert( ! hasUnsharedAliasing!Foo, "struct Foo has unshared > aliasing" ); > } > ---- > but it fails to compile. As far as I understand, functions (unlike > delegates) do not have any shared aliasing but hasUnsharedAliasing > thinks they do. This is a real bug. Please file a bug report. I'll look into it soon. From osa at aso.osa Fri Sep 17 14:20:55 2010 From: osa at aso.osa (osa) Date: Fri, 17 Sep 2010 16:20:55 -0500 Subject: dmd 1.064 and 2.049 release In-Reply-To: References: Message-ID: On 09/17/2010 04:05 PM, dsimcha wrote: > This is a real bug. Please file a bug report. I'll look into it soon. Done: http://d.puremagic.com/issues/show_bug.cgi?id=4882 From michel.fortin at michelf.com Fri Sep 17 17:18:02 2010 From: michel.fortin at michelf.com (Michel Fortin) Date: Fri, 17 Sep 2010 20:18:02 -0400 Subject: D/Objective-C: hit a dead end, start anew References: Message-ID: On 2010-09-17 14:48:54 -0400, Jacob Carlborg said: > On 2010-09-17 19:45, Michel Fortin wrote: >> Also note that member functions of an extern (Objective-C) class or >> interface always have implicitly a selector (made from the function's >> name followed by as many colons as there are arguments). > > Will it use the parameter names to build the selector as well? No. This would be changing D's semantics. D, like C, does not require names for parameters in function prototypes, nor does it require names to be the same in overridden functions. And it's the same for Objective-C: parameters names are distinct from the selector and can be changed at will without changing the method's name. This Objective-C method: - (id)getObject:(id)anObject forKey:(id)aKey; becomes NSObject getObject(NSObject anObject, NSObject aKey) [getObject:forKey:]; In both cases, anObject and aKey can be changed without breaking compatibility. They're basically just names for local variables inside the function. >> Ideally blocks would be the same as delegates, but I hadn't given them >> much thought yet. > > Exactly, but I assume that would make them incompatible with existing D > delegates. You misunderstood. I have no intention of changing the ABI for D delegates or anything already existing in D. But it shouldn't be too hard to wrap delegates in blocks. You probably don't even need help from the compiler to do this (unless you want it to be implicit). Take a look at the spec for blocks: >> I'm not sure whether I want to support creating new categories in D; >> categories are quite "un-D-like" and despite their usefulness they're >> clash-prone. But I sure want to be able to access categories from >> existing Objective-C frameworks. So how exactly this would work? I don't >> know. > > Well, most of the stuff that makes Objective-C what it is, is not very > D-like. D and Objective-C has different object models, D is Simula > based and Objective-C is based on Smalltalk. But categories are a must, > I mean a large part of the standard classes (i.e. NSObject) is split in > categories. With the standard frameworks that wouldn't be such a big > problem, just make regular methods of it in the class it extends, but > when a non-standard framework have categories extending standard > classes we start to have a problem. I know the importance of categories. I believe there should be a way to declare categories from existing Objective-C frameworks and use them. What I'm unsure of is if you should be allowed to *define* your own, but I admit being able to declare them but not define them would be strange. >> In any case, I have much work to do before it's time to think about >> categories and blocks. The most basic problem to solve in this all new >> Objective-C "bridge" is the memory management. But I don't want to look >> at this too much until I get the basics working. > > What about using AutoZone, the Objective-C garbage collector? But that > would require memory barriers I assume. An idea would be to substitute the GC in druntime with AutoZone and have it manage every piece of memory, but Apple's garbage collector doesn't support pointers to interior of blocks so it's impossible to use for regular D even if we were to add the memory barriers it wants. And having two collectors running at the same time sounds like trouble. > Please let me know when you start to think more about all this. I suggest you subscribe to my d-objc mailing list. I'll be posting about my progress there. -- Michel Fortin michel.fortin at michelf.com http://michelf.com/ From newshound2 at digitalmars.com Fri Sep 17 18:08:29 2010 From: newshound2 at digitalmars.com (Walter Bright) Date: Fri, 17 Sep 2010 18:08:29 -0700 Subject: QtD is suspended In-Reply-To: References: Message-ID: Andrei Alexandrescu wrote: > On 9/17/10 10:48 CDT, Michel Fortin wrote: >> I understand the intent quite well. I'm talking about what happens if >> the source is const? > > The whole point is, mutation is the motivator. If you copy an empty > hash, no problem because the receiver can't mutate it. Wouldn't copying a ref counted object require mutating the original? From michel.fortin at michelf.com Fri Sep 17 18:41:55 2010 From: michel.fortin at michelf.com (Michel Fortin) Date: Fri, 17 Sep 2010 21:41:55 -0400 Subject: QtD is suspended References: Message-ID: On 2010-09-17 21:08:29 -0400, Walter Bright said: > Andrei Alexandrescu wrote: >> On 9/17/10 10:48 CDT, Michel Fortin wrote: >>> I understand the intent quite well. I'm talking about what happens if >>> the source is const? >> >> The whole point is, mutation is the motivator. If you copy an empty >> hash, no problem because the receiver can't mutate it. > > Wouldn't copying a ref counted object require mutating the original? This is an interesting point. Reference counting requires updating the reference counter which lives alongside the referenced memory. So if you have a const reference-counting struct, you can't make a copy of it because const will transitively apply to the counter too, preventing it from being incremented. I'm not sure why you're talking about mutating "the original" though. You don't need to update the original smart pointer struct as the reference counter lives with the referenced memory to which you have access in postblit. -- Michel Fortin michel.fortin at michelf.com http://michelf.com/ From sybrandy at gmail.com Fri Sep 17 19:11:49 2010 From: sybrandy at gmail.com (sybrandy) Date: Fri, 17 Sep 2010 22:11:49 -0400 Subject: BareMetal OS Message-ID: Not D related, but a cool sounding project. In short, it's a functional OS written in assembly and has an extremely small kernel. http://www.returninfinity.com/baremetal.html Casey From doob at me.com Sat Sep 18 03:10:53 2010 From: doob at me.com (Jacob Carlborg) Date: Sat, 18 Sep 2010 12:10:53 +0200 Subject: D/Objective-C: hit a dead end, start anew In-Reply-To: References: Message-ID: On 2010-09-18 02:18, Michel Fortin wrote: > On 2010-09-17 14:48:54 -0400, Jacob Carlborg said: > >> On 2010-09-17 19:45, Michel Fortin wrote: >>> Also note that member functions of an extern (Objective-C) class or >>> interface always have implicitly a selector (made from the function's >>> name followed by as many colons as there are arguments). >> >> Will it use the parameter names to build the selector as well? > > No. This would be changing D's semantics. D, like C, does not require > names for parameters in function prototypes, nor does it require names > to be the same in overridden functions. And it's the same for > Objective-C: parameters names are distinct from the selector and can be > changed at will without changing the method's name. > > This Objective-C method: > > - (id)getObject:(id)anObject forKey:(id)aKey; > > becomes > > NSObject getObject(NSObject anObject, NSObject aKey) [getObject:forKey:]; > > In both cases, anObject and aKey can be changed without breaking > compatibility. They're basically just names for local variables inside > the function. Ok, now I'm not sure I understand. If you don't specify a selector for a declared method, how will the selector look like? In your example above, if you don't specify the selector how will it be something like: getObject:: ? >>> Ideally blocks would be the same as delegates, but I hadn't given them >>> much thought yet. >> >> Exactly, but I assume that would make them incompatible with existing >> D delegates. > > You misunderstood. I have no intention of changing the ABI for D > delegates or anything already existing in D. > > But it shouldn't be too hard to wrap delegates in blocks. You probably > don't even need help from the compiler to do this (unless you want it to > be implicit). Take a look at the spec for blocks: > Ok. >>> I'm not sure whether I want to support creating new categories in D; >>> categories are quite "un-D-like" and despite their usefulness they're >>> clash-prone. But I sure want to be able to access categories from >>> existing Objective-C frameworks. So how exactly this would work? I don't >>> know. >> >> Well, most of the stuff that makes Objective-C what it is, is not very >> D-like. D and Objective-C has different object models, D is Simula >> based and Objective-C is based on Smalltalk. But categories are a >> must, I mean a large part of the standard classes (i.e. NSObject) is >> split in categories. With the standard frameworks that wouldn't be >> such a big problem, just make regular methods of it in the class it >> extends, but when a non-standard framework have categories extending >> standard classes we start to have a problem. > > I know the importance of categories. I believe there should be a way to > declare categories from existing Objective-C frameworks and use them. > What I'm unsure of is if you should be allowed to *define* your own, but > I admit being able to declare them but not define them would be strange. Ok. >>> In any case, I have much work to do before it's time to think about >>> categories and blocks. The most basic problem to solve in this all new >>> Objective-C "bridge" is the memory management. But I don't want to look >>> at this too much until I get the basics working. >> >> What about using AutoZone, the Objective-C garbage collector? But that >> would require memory barriers I assume. > > An idea would be to substitute the GC in druntime with AutoZone and have > it manage every piece of memory, but Apple's garbage collector doesn't > support pointers to interior of blocks so it's impossible to use for > regular D even if we were to add the memory barriers it wants. And > having two collectors running at the same time sounds like trouble. Ok. >> Please let me know when you start to think more about all this. > > I suggest you subscribe to my d-objc mailing list. I'll be posting about > my progress there. > Done. -- /Jacob Carlborg From michel.fortin at michelf.com Sat Sep 18 07:36:53 2010 From: michel.fortin at michelf.com (Michel Fortin) Date: Sat, 18 Sep 2010 10:36:53 -0400 Subject: D/Objective-C: hit a dead end, start anew References: Message-ID: On 2010-09-18 06:10:53 -0400, Jacob Carlborg said: > Ok, now I'm not sure I understand. If you don't specify a selector for > a declared method, how will the selector look like? In your example > above, if you don't specify the selector how will it be something like: > > getObject:: ? Exactly. Note that this is a valid selector name. Though I might decide on something else later. I'm thinking about mangling the argument types in the selector to make it work better with overloading. -- Michel Fortin michel.fortin at michelf.com http://michelf.com/ From doob at me.com Sat Sep 18 14:49:31 2010 From: doob at me.com (Jacob Carlborg) Date: Sat, 18 Sep 2010 23:49:31 +0200 Subject: D/Objective-C: hit a dead end, start anew In-Reply-To: References: Message-ID: On 2010-09-18 16:36, Michel Fortin wrote: > On 2010-09-18 06:10:53 -0400, Jacob Carlborg said: > >> Ok, now I'm not sure I understand. If you don't specify a selector for >> a declared method, how will the selector look like? In your example >> above, if you don't specify the selector how will it be something like: >> >> getObject:: ? > > Exactly. Note that this is a valid selector name. > > Though I might decide on something else later. I'm thinking about > mangling the argument types in the selector to make it work better with > overloading. Yes, I know it's a valid selector name, I've seen it in a few places. But as I see it, in most cases where there is more than one parameter you will have to declare the selector explicitly. -- /Jacob Carlborg From aldoSkipallthisNunez1 at gmail.com Sun Sep 19 11:05:48 2010 From: aldoSkipallthisNunez1 at gmail.com (Aldo Nunez) Date: Sun, 19 Sep 2010 11:05:48 -0700 Subject: dmd 1.064 and 2.049 release References: Message-ID: Bernard Helyer wrote: > On Fri, 17 Sep 2010 11:45:15 +0000, Bernard Helyer wrote: >> Looks solid, but it appears to have broken debugging info. (Linux) >> >> Looking through the bug tracker now. > > Uhhhh disregard that, PEBKAC. ^^; Actually, something went wrong in the debugging info on Windows. It seems to be a problem with the new linker (8.00.7). Using an older one, like from DMD release 2.048, works well. I filed bug report 4897. From newshound2 at digitalmars.com Sun Sep 19 19:28:50 2010 From: newshound2 at digitalmars.com (Walter Bright) Date: Sun, 19 Sep 2010 19:28:50 -0700 Subject: dmd 1.064 and 2.049 release In-Reply-To: References: Message-ID: Aldo Nunez wrote: > I filed bug report 4897. http://ftp.digitalmars.com/link.8.00.8.zip From doob at me.com Mon Sep 20 01:23:38 2010 From: doob at me.com (Jacob Carlborg) Date: Mon, 20 Sep 2010 10:23:38 +0200 Subject: D/Objective-C: hit a dead end, start anew In-Reply-To: References: Message-ID: On 2010-09-18 16:36, Michel Fortin wrote: > On 2010-09-18 06:10:53 -0400, Jacob Carlborg said: > >> Ok, now I'm not sure I understand. If you don't specify a selector for >> a declared method, how will the selector look like? In your example >> above, if you don't specify the selector how will it be something like: >> >> getObject:: ? > > Exactly. Note that this is a valid selector name. > > Though I might decide on something else later. I'm thinking about > mangling the argument types in the selector to make it work better with > overloading. What about two methods that take the same number of parameters and of the same types but have two distinct selectors in Objective-C, like insertSublayer:below: and insertSublayer:above: in the CALayer class in the QuartzCore framework. Should those be translated to insertSublayerBelow or insertSublayer_below_ or something like that? Or have you planed a syntax that will solve this some other way? -- /Jacob Carlborg From bearophileHUGS at lycos.com Mon Sep 20 05:11:57 2010 From: bearophileHUGS at lycos.com (bearophile) Date: Mon, 20 Sep 2010 08:11:57 -0400 Subject: dmd 1.064 and 2.049 release Message-ID: Walter Bright: > This is primarily a bug fix release. I was away. Thank you for all the work. For the close future I suggest to focus a bit more on fixing language/design corner cases, instead of just on normal dmd/Phobos/druntime bugs (as done in this release). The Changelog of 2.049 says: Bugzilla 4603: array(iota(1, 0)) error. But it's not closed, here time ago I have explained why: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=115725 See also: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=117461 ----------------------- Regarding bug 3554/3957: http://d.puremagic.com/issues/show_bug.cgi?id=3554 It doesn't seem fixed in dmd 2.049. This program: /// Return a random number in [0, 10 $(LPAREN) void foo() {} void main() {} Generates an html that doesn't show the closing left parenthesis: ...
Return a random number in [0, 10

... So if I am not mistaken I may reopen bug 3554. Bye, bearophile From michel.fortin at michelf.com Mon Sep 20 07:19:37 2010 From: michel.fortin at michelf.com (Michel Fortin) Date: Mon, 20 Sep 2010 10:19:37 -0400 Subject: D/Objective-C: hit a dead end, start anew References: Message-ID: On 2010-09-20 04:23:38 -0400, Jacob Carlborg said: > On 2010-09-18 16:36, Michel Fortin wrote: >> Though I might decide on something else later. I'm thinking about >> mangling the argument types in the selector to make it work better with >> overloading. > > What about two methods that take the same number of parameters and of > the same types but have two distinct selectors in Objective-C, like > insertSublayer:below: and insertSublayer:above: in the CALayer class in > the QuartzCore framework. Should those be translated to > insertSublayerBelow or insertSublayer_below_ or something like that? Or > have you planed a syntax that will solve this some other way? There is no automatic conversion from a selector to a D method name: you specify the method name (as usual) and you specify the selector (if you care about the selector, like in bindings). If you have a script that automatically creates bindings, then that script is the one that must figure out what method name to use for what selector. Because of this, there is no need for the D method name to be related to the selector. When you call a method, the method name is used to find the method declaration; and the declaration contains the selector to use. Calling undeclared methods is unsupported (unlike in Objective-C). -- Michel Fortin michel.fortin at michelf.com http://michelf.com/ From nospam at nospam.com Mon Sep 20 07:39:12 2010 From: nospam at nospam.com (Don) Date: Mon, 20 Sep 2010 16:39:12 +0200 Subject: dmd 1.064 and 2.049 release In-Reply-To: References: Message-ID: bearophile wrote: > Walter Bright: > >> This is primarily a bug fix release. > > I was away. Thank you for all the work. > For the close future I suggest to focus a bit more on fixing language/design corner cases, instead of just on normal dmd/Phobos/druntime bugs (as done in this release). Sorry bearophile, regressions and wrong-code bugs will ALWAYS have top priority. There will be no apology for fixing bugs like 3996, 4681, and 4009. . From bearophileHUGS at lycos.com Mon Sep 20 12:52:58 2010 From: bearophileHUGS at lycos.com (bearophile) Date: Mon, 20 Sep 2010 15:52:58 -0400 Subject: dmd 1.064 and 2.049 release References: Message-ID: Don: > Sorry bearophile, regressions and wrong-code bugs will ALWAYS have top > priority. There will be no apology for fixing bugs like 3996, 4681, and > 4009. . I see. On the other hand little design bugs are important too because despite they now look temporary, they risk becoming permanent, I have some past experience on this. This is why I am using all the chances I have to put them under attention. So far only two of the ones I have listed have being discussed and only one of them was fixed (the one about a|b>c). Unrelated: in Bugzilla I have few small Phobos patches. If no one finds time or interest in them, then I may eventually desire to apply those patches myself. Bye, bearophile From contact at gamBOOMesfrommars.fr Mon Sep 20 16:57:47 2010 From: contact at gamBOOMesfrommars.fr (ponce) Date: Mon, 20 Sep 2010 19:57:47 -0400 Subject: Vibrant 1.5 References: Message-ID: Vibrant has been open source'd (again): http://bitbucket.org/ponce/vibrant From bearophileHUGS at lycos.com Mon Sep 20 19:38:37 2010 From: bearophileHUGS at lycos.com (bearophile) Date: Mon, 20 Sep 2010 22:38:37 -0400 Subject: Vibrant 1.5 References: Message-ID: ponce: > Vibrant has been open source'd (again): > http://bitbucket.org/ponce/vibrant Very good. I have seen 2D vectors implemented something like ten times in D code, so I think it's time to stop this. They need to go in the standard library: http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vec2.d http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vec3.d http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vec4.d http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vectorop.d Useful math, fast too: http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/common.d http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/rounding.d Half floats, I don't know if they are better than user defined floats of Phobos2: http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/half.d Quaternions: http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/quat.d A color module is useful: http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/misc/colors.d Python std lib has colorsys: http://docs.python.org/library/colorsys.html More useful general matrix code: http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/mat4.d Some very basic geometry code fit for a std.geometry module: http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/math2d.d I think all those things (maybe with a little more docs, improvements, unittests, contracts) are fit to be added to Phobos, because: - they are basic things that are commonly useful; - they aren't a lot of code; - they will be useful ten years from now too, they will not become obsolete; - I have seen them implemented in user D code several times; - Some of them are present in my dlibs1 and I have used them several times. Advanced modules for computational geometry, colorimetry, statistics, etc, are beyond the scope of Phobos2. But short, simple to use, frequently useful functions are fit for the standard library. So I think there are modules that should be added to Phobos: std.geometry std.color std.quaternions std.halffloats std.vectors std.combinatorics (or std.comb) for permutations, combiantions, subsets, and few more. Plus more code for std.math and std.array (for the matrix code) and std.numerics. Eventually I'd like to write a basic std.combinatorics module for Phobos2. Bye, bearophile From aldoSkipallthisNunez1 at gmail.com Mon Sep 20 21:28:44 2010 From: aldoSkipallthisNunez1 at gmail.com (Aldo Nunez) Date: Mon, 20 Sep 2010 21:28:44 -0700 Subject: dmd 1.064 and 2.049 release References: Message-ID: Walter Bright wrote: > Aldo Nunez wrote: >> I filed bug report 4897. > > http://ftp.digitalmars.com/link.8.00.8.zip Looks good. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From lijat.meREM at OVEgmail.com Tue Sep 21 00:21:50 2010 From: lijat.meREM at OVEgmail.com (Johan Granberg) Date: Tue, 21 Sep 2010 09:21:50 +0200 Subject: Vibrant 1.5 References: Message-ID: bearophile wrote: > ponce: > >> Vibrant has been open source'd (again): >> http://bitbucket.org/ponce/vibrant > > Very good. I have seen 2D vectors implemented something like ten times in > D code, so I think it's time to stop this. They need to go in the standard > library: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vec2.d > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vec3.d > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vec4.d > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vectorop.d > > Useful math, fast too: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/common.d > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/rounding.d > > Half floats, I don't know if they are better than user defined floats of > Phobos2: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/half.d > > Quaternions: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/quat.d > > A color module is useful: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/misc/colors.d > Python std lib has colorsys: > http://docs.python.org/library/colorsys.html > > More useful general matrix code: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/mat4.d > > Some very basic geometry code fit for a std.geometry module: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/math2d.d > > I think all those things (maybe with a little more docs, improvements, > unittests, contracts) are fit to be added to Phobos, because: - they are > basic things that are commonly useful; - they aren't a lot of code; > - they will be useful ten years from now too, they will not become > obsolete; - I have seen them implemented in user D code several times; > - Some of them are present in my dlibs1 and I have used them several > times. I second that, if we should learn something from looking at 3D libs written in c++ it is that they all reimplement vectors and that this make it a pain to move code betwean them because of incompatible vector implementations. So adding this would be a huge step forward for phobos. > Advanced modules for computational geometry, colorimetry, statistics, etc, > are beyond the scope of Phobos2. But short, simple to use, frequently > useful functions are fit for the standard library. So I think there are > modules that should be added to Phobos: > > std.geometry > std.color > std.quaternions > std.halffloats > std.vectors > std.combinatorics (or std.comb) for permutations, combiantions, subsets, > and few more. Plus more code for std.math and std.array (for the matrix > code) and std.numerics. > > Eventually I'd like to write a basic std.combinatorics module for Phobos2. > > Bye, > bearophile From spambox at d-coding.com Tue Sep 21 01:33:58 2010 From: spambox at d-coding.com (Max Samukha) Date: Tue, 21 Sep 2010 11:33:58 +0300 Subject: QtD is suspended In-Reply-To: References: Message-ID: On 09/17/2010 07:37 PM, Lutger wrote: > Georg Wrede wrote: > > I take it this is directed at me. Look, it was a gut reaction. I don't > understand why, but if anyone takes offense I'm sorry, I didn't want to provoke > that. I don't see why anybody should take offense from what you said. Quite the opposite - thanks for being around. I think Georg directed those words to somebody else. From nospam at nospam.com Tue Sep 21 01:59:51 2010 From: nospam at nospam.com (Don) Date: Tue, 21 Sep 2010 10:59:51 +0200 Subject: Vibrant 1.5 In-Reply-To: References: Message-ID: bearophile wrote: > ponce: > >> Vibrant has been open source'd (again): >> http://bitbucket.org/ponce/vibrant > > Very good. I have seen 2D vectors implemented something like ten times in D code, so I think it's time to stop this. They need to go in the standard library: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vec2.d > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vec3.d > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vec4.d > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vectorop.d Definitely we need vectors in Phobos. > > Useful math, fast too: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/common.d > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/rounding.d Actually, I don't see any functions which are faster than std.math. std.math.exp2() is *much* faster than common.pow2() (one slow instruction, vs five!!!) And exp2 sets the flags correctly. expi() is faster than sincos(). > Half floats, I don't know if they are better than user defined floats of Phobos2: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/half.d > > Quaternions: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/quat.d > > A color module is useful: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/misc/colors.d > Python std lib has colorsys: > http://docs.python.org/library/colorsys.html > > More useful general matrix code: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/mat4.d > > Some very basic geometry code fit for a std.geometry module: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/math2d.d > > I think all those things (maybe with a little more docs, improvements, unittests, contracts) are fit to be added to Phobos, because: > - they are basic things that are commonly useful; > - they aren't a lot of code; > - they will be useful ten years from now too, they will not become obsolete; > - I have seen them implemented in user D code several times; > - Some of them are present in my dlibs1 and I have used them several times. I agree. There's some useful stuff here. From contact at gamCOOKIESesfrommars.fr Tue Sep 21 02:31:35 2010 From: contact at gamCOOKIESesfrommars.fr (#ponce) Date: Tue, 21 Sep 2010 05:31:35 -0400 Subject: Vibrant 1.5 References: Message-ID: > Very good. I have seen 2D vectors implemented something like ten times in D code, so I think it's time to stop this. They need to go in the standard library: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vec2.d > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vec3.d > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vec4.d > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vectorop.d > Those are pretty useful to me but the use a template mixin (sheduled for deprecation ?) > Useful math, fast too: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/common.d A lot of functions here do not behave well (especially the pow/exp variants) > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/rounding.d > This is plain ugly stuff, the rounding affect the FPU control word and do not restore it. A good conversion rounding routines should be based on > Half floats, I don't know if they are better than user defined floats of Phobos2: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/half.d half float are useful for 3D because it saves bandwidth with the graphic cards. Less for other purposes. I think common2 allow to use vec3!(half) but lack of implicit conversion makes it less useful than the same design in C++. > Quaternions: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/quat.d Those are mostly untested. > > A color module is useful: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/misc/colors.d > Python std lib has colorsys: > http://docs.python.org/library/colorsys.html No this one is not good. > > More useful general matrix code: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/mat4.d > this stuff is well tested now. > Some very basic geometry code fit for a std.geometry module: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/math2d.d > not really usable. > I think all those things (maybe with a little more docs, improvements, unittests, contracts) are fit to be added to Phobos, because: > - they are basic things that are commonly useful; > - they aren't a lot of code; > - they will be useful ten years from now too, they will not become obsolete; > - I have seen them implemented in user D code several times; > - Some of them are present in my dlibs1 and I have used them several times. > The obvious problem is that all of this is currently - for D1 - not elegant "D-style" - too much assembly - not very reliable (I figured out my 4x4 matrix inversion was false 1 month ago, after using the code for two years) - written for ease of use and conciseness rather than correctness The only part that could be saved is half-floats and perhaps quaternions but this is specific to 3D graphics. There was a discussion a while ago on adding small vectors to D2 and I think it's a good idea. A good small vector type should use the new D2 capabilities like opDispatch for swizzling, be parameterized by size and type, and not be much slower in debug mode. I plan to convert the good stuff to D2 (in fact it already begun) but I'm on a lot of projects right now. From contact at gamCOOKIESesfrommars.fr Tue Sep 21 02:33:23 2010 From: contact at gamCOOKIESesfrommars.fr (#ponce) Date: Tue, 21 Sep 2010 05:33:23 -0400 Subject: Vibrant 1.5 References: Message-ID: Errata: A good rounding routine should be based on FISTTP which avoid messing with the rounding mode entirely. From contact at gamCOOKIESesfrommars.fr Tue Sep 21 02:36:32 2010 From: contact at gamCOOKIESesfrommars.fr (#ponce) Date: Tue, 21 Sep 2010 05:36:32 -0400 Subject: Vibrant 1.5 References: Message-ID: > > Actually, I don't see any functions which are faster than std.math. > std.math.exp2() is *much* faster than common.pow2() (one slow > instruction, vs five!!!) And exp2 sets the flags correctly. > expi() is faster than sincos(). > I wrote that years ago because Pascal didn't have those ;) I refused to use std.math function because they were taking a real argument. is that optimized ? I've strong NIH syndrom. ;) From nospam at nospam.com Tue Sep 21 05:06:24 2010 From: nospam at nospam.com (Don) Date: Tue, 21 Sep 2010 14:06:24 +0200 Subject: Vibrant 1.5 In-Reply-To: References: Message-ID: #ponce wrote: >> Half floats, I don't know if they are better than user defined floats of Phobos2: >> http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/half.d > > half float are useful for 3D because it saves bandwidth with the graphic cards. Less for other purposes. > I think common2 allow to use vec3!(half) but lack of implicit conversion makes it less useful than the same design in C++. My guess is that what you really want, is pack-and-unpack routines for whole arrays. half[0..n*2] <--> float[0..n] It's a fascinating problem. I bet it can be done very efficiently. From contact at gamCOOKIESesfrommars.fr Tue Sep 21 06:52:23 2010 From: contact at gamCOOKIESesfrommars.fr (#ponce) Date: Tue, 21 Sep 2010 09:52:23 -0400 Subject: Vibrant 1.5 References: Message-ID: > My guess is that what you really want, is pack-and-unpack routines for > whole arrays. half[0..n*2] <--> float[0..n] What I would like is the ability to take a custom type and make a small vector out of it. alias vec3 vec3h; but as D doesn't have conversion function like C++, here is how to create such small vectors : vec3h a = vec3h(cast(half)1.f, cast(half)2.f, cast(half)3.f); Granted, hardly a problem and dropping conversion functions is a gain. > It's a fascinating problem. I bet it can be done very efficiently. I heard stories of half-float => float conversions being the bottleneck while filling mapped GPU buffers. The other one being using anything else than memcpy. From contact at gamCOOKIESesfrommars.fr Tue Sep 21 06:55:09 2010 From: contact at gamCOOKIESesfrommars.fr (#ponce) Date: Tue, 21 Sep 2010 09:55:09 -0400 Subject: Vibrant 1.5 References: Message-ID: > vec3h a = vec3h(cast(half)1.f, cast(half)2.f, cast(half)3.f); In C++ I can make the half type and create vec3h with vec3h a = vec3h(1, 2.f, 3); because so much thing are implicit. > I heard stories of half-float => float conversions being the bottleneck I meant float -> half-float From nospam at nospam.com Tue Sep 21 07:45:58 2010 From: nospam at nospam.com (Don) Date: Tue, 21 Sep 2010 16:45:58 +0200 Subject: Vibrant 1.5 In-Reply-To: References: Message-ID: #ponce wrote: >> vec3h a = vec3h(cast(half)1.f, cast(half)2.f, cast(half)3.f); > > In C++ I can make the half type and create vec3h with > > vec3h a = vec3h(1, 2.f, 3); > > because so much thing are implicit. > >> I heard stories of half-float => float conversions being the bottleneck > > I meant float -> half-float > My friend Google found some SSE2 code which does float->half in 3.5 cycles. Not too bad. http://www.devmaster.net/forums/showthread.php?t=10924 From spam at extrawurst.org Tue Sep 21 08:06:45 2010 From: spam at extrawurst.org (Stephan) Date: Tue, 21 Sep 2010 17:06:45 +0200 Subject: d bindings for enet Message-ID: enet (http://enet.bespin.org/) is a thin network layer based on UDP. i post here in case anybody else finds it useful. is there any appropriate dsource project i can add these ? Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: enet_for_d.zip Type: application/x-zip-compressed Size: 8510 bytes Desc: not available URL: From blinov at loniir.ru Tue Sep 21 08:38:24 2010 From: blinov at loniir.ru (Stanislav Blinov) Date: Tue, 21 Sep 2010 19:38:24 +0400 Subject: d bindings for enet In-Reply-To: References: Message-ID: <4C98D170.50903@loniir.ru> 21.09.2010 19:06, Stephan wrote: > enet (http://enet.bespin.org/) is a thin network layer based on UDP. > > i post here in case anybody else finds it useful. is there any > appropriate dsource project i can add these ? > > Stephan Nice, thanks! You could try convincing aldacron (author and maintainer of Derelict, see dsource.org/projects/derelict) to add these, though I have an impression that he didn't want to add more bindings at some point. Anyway, Derelict uses run-time dynamic linking (e.g. manually loads .dll/.so and binds function pointers) instead of load-time one, so these bindings as they are would require Derelictifying first if they are to be added to that project. Can't think of any other project off the top of my head. From lutger.blijdestijn at gmail.com Tue Sep 21 10:46:52 2010 From: lutger.blijdestijn at gmail.com (Lutger) Date: Tue, 21 Sep 2010 19:46:52 +0200 Subject: d bindings for enet References: Message-ID: Stephan wrote: > enet (http://enet.bespin.org/) is a thin network layer based on UDP. > > i post here in case anybody else finds it useful. is there any > appropriate dsource project i can add these ? > > Stephan I believe this is the place, and anybody with a dsource account can commit here: http://www.dsource.org/projects/bindings From doob at me.com Wed Sep 22 08:22:00 2010 From: doob at me.com (Jacob Carlborg) Date: Wed, 22 Sep 2010 17:22:00 +0200 Subject: D/Objective-C: hit a dead end, start anew In-Reply-To: References: Message-ID: On 2010-09-20 16:19, Michel Fortin wrote: >> What about two methods that take the same number of parameters and of >> the same types but have two distinct selectors in Objective-C, like >> insertSublayer:below: and insertSublayer:above: in the CALayer class >> in the QuartzCore framework. Should those be translated to >> insertSublayerBelow or insertSublayer_below_ or something like that? >> Or have you planed a syntax that will solve this some other way? > > There is no automatic conversion from a selector to a D method name: you > specify the method name (as usual) and you specify the selector (if you > care about the selector, like in bindings). If you have a script that > automatically creates bindings, then that script is the one that must > figure out what method name to use for what selector. > > Because of this, there is no need for the D method name to be related to > the selector. When you call a method, the method name is used to find > the method declaration; and the declaration contains the selector to > use. Calling undeclared methods is unsupported (unlike in Objective-C). Makes sense. -- /Jacob Carlborg From sovende at gmail.com Wed Sep 22 14:26:10 2010 From: sovende at gmail.com (Emil Madsen) Date: Wed, 22 Sep 2010 23:26:10 +0200 Subject: the bit[] type Message-ID: Okay I'm interresting in getting more infomation about the bit[] type; - is it still implemented in D1? - and why was it removed? - is it possible to get a link to the design considerations of removing it, and such? - any source of info, on the design phase about it, will be in my interrest -- // Yours sincerely // Emil 'Skeen' Madsen -------------- next part -------------- An HTML attachment was scrubbed... URL: From bearophileHUGS at lycos.com Wed Sep 22 15:32:31 2010 From: bearophileHUGS at lycos.com (bearophile) Date: Wed, 22 Sep 2010 18:32:31 -0400 Subject: the bit[] type References: Message-ID: Emil Madsen: > Okay I'm interresting in getting more infomation about the bit[] type; > - is it still implemented in D1? - and why was it removed? > - is it possible to get a link to the design considerations of removing it, > and such? > - any source of info, on the design phase about it, will be in my interrest D.learn is a better place to ask such questions. In D1 now the bit type exists just as an alias. I think it was removed because you can't get the address of a bit. D1 Phobos has functions in std.intrinsic to manage bit arrays, and D2 Phobos has a module that implements a bit array and a way to build struct bit fields. Bye, bearophile From sovende at gmail.com Wed Sep 22 15:42:07 2010 From: sovende at gmail.com (Emil Madsen) Date: Thu, 23 Sep 2010 00:42:07 +0200 Subject: the bit[] type In-Reply-To: References: Message-ID: Didn't knew about D.learn :) - I'll head over there, to ask questions alike this one, instead of polluting here. the bit type in D1, is just an alias for bool I take it, for backwards compatibility`? - is it deprecated? Yet again, thanks you :) On 23 September 2010 00:32, bearophile wrote: > Emil Madsen: > > > Okay I'm interresting in getting more infomation about the bit[] type; > > - is it still implemented in D1? - and why was it removed? > > - is it possible to get a link to the design considerations of removing > it, > > and such? > > - any source of info, on the design phase about it, will be in my > interrest > > D.learn is a better place to ask such questions. > In D1 now the bit type exists just as an alias. > I think it was removed because you can't get the address of a bit. D1 > Phobos has functions in std.intrinsic to manage bit arrays, and D2 Phobos > has a module that implements a bit array and a way to build struct bit > fields. > > Bye, > bearophile > -- // Yours sincerely // Emil 'Skeen' Madsen -------------- next part -------------- An HTML attachment was scrubbed... URL: From bearophileHUGS at lycos.com Wed Sep 22 15:51:18 2010 From: bearophileHUGS at lycos.com (bearophile) Date: Wed, 22 Sep 2010 18:51:18 -0400 Subject: the bit[] type References: Message-ID: Emil Madsen: > the bit type in D1, is just an alias for bool I take it, for backwards > compatibility`? I think so. But it's only a partial semantic compatibility. >- is it deprecated? bit as alias of bool is not deprecated, because I presume this alias will never be removed from D1, but there's no need to use it in new D1 code. And in a sense the whole D1 language is deprecated :-) Bye, bearophile From smjg_1998 at yahoo.com Thu Sep 23 05:22:20 2010 From: smjg_1998 at yahoo.com (Stewart Gordon) Date: Thu, 23 Sep 2010 13:22:20 +0100 Subject: the bit[] type In-Reply-To: References: Message-ID: On 22/09/2010 22:26, Emil Madsen wrote: > Okay I'm interresting in getting more infomation about the bit[] type; > - is it still implemented in D1? bit is now just an alias of bool, defined in object. > - and why was it removed? I think because there were too many complaints of bugs with it, and the conclusion was reached that it's too difficult to implement without bugs. > - is it possible to get a link to the design considerations of removing > it, and such? There must have been a discussion that led to it, but I can't find it at the moment. Stewart. From jccalvarese at gmail.com Thu Sep 23 06:57:41 2010 From: jccalvarese at gmail.com (jcc7) Date: Thu, 23 Sep 2010 13:57:41 +0000 (UTC) Subject: the bit[] type References: Message-ID: == Quote from Stewart Gordon (smjg_1998 at yahoo.com)'s article > On 22/09/2010 22:26, Emil Madsen wrote: > > Okay I'm interresting in getting more infomation about the bit[] type; > > - is it still implemented in D1? > bit is now just an alias of bool, defined in object. > > - and why was it removed? > I think because there were too many complaints of bugs with it, and the > conclusion was reached that it's too difficult to implement without bugs. > > - is it possible to get a link to the design considerations of removing > > it, and such? > > There must have been a discussion that led to it, but I can't find it at > the moment. > Stewart. I don't remember the details, but from the changelog (http://www.digitalmars.com/d/1.0/changelog2.html), it looks like Version D 0.148 (Feb 25, 2006) was when the last big change happened: * Removed bit basic type. * Added bool basic type. * Added BitArray. These page covers some of the early controversy: http://www.prowiki.org/wiki4d/wiki.cgi?BooleanNotEquBit http://www.prowiki.org/wiki4d/wiki.cgi?BooleanNotEquBit/PostsByWalter I don't think the pages has been updated with much (if any) detail about how and why the change finally happened removing "bit", but it does looks like the "bool" alias was added in D 0.69 (August 11, 2003). As you can see from the links to newsgroup threads at the bottom of the first page, the topic was discussed over many years. Perhaps the discussions have tapered off in recent years because the current approach is right. jcc7 From newshound2 at digitalmars.com Thu Sep 23 09:35:55 2010 From: newshound2 at digitalmars.com (Walter Bright) Date: Thu, 23 Sep 2010 09:35:55 -0700 Subject: the bit[] type In-Reply-To: References: Message-ID: jcc7 wrote: > As you can see from the links to newsgroup threads at the bottom of the first > page, the topic was discussed over many years. Perhaps the discussions have > tapered off in recent years because the current approach is right. BTW, C++ ran into the same problems with vector. From bearophileHUGS at lycos.com Thu Sep 23 10:32:45 2010 From: bearophileHUGS at lycos.com (bearophile) Date: Thu, 23 Sep 2010 13:32:45 -0400 Subject: the bit[] type References: Message-ID: jcc7: > As you can see from the links to newsgroup threads at the bottom of the first > page, the topic was discussed over many years. Perhaps the discussions have > tapered off in recent years because the current approach is right. It's an interesting read, thank you (I was present only at the tail of it). It's a good example of how even an "obviously simple" feature like a bool/bit type may hide complexities, design difficulties, requires engineering trade-offs, and in the end may produce something with some inevitable design defects. ~bool is forbidden, but in DMD a bool is represented with 8 bits, so it has 255 ways to be true and 1 to be false. A boolean like this: bool b = void; May contain something different from 0 or 1, this may cause some surprise. In those discussions I have seen Walter against the usage of bool as return type for opEquals, because a cast(bool)some_int is equivalent to: n ? 1 : 0 That requires some instructions, so it isn't fully efficient. In the pages (operatoroverloading.html and hash-map.html) about the D2 language I have seen different signatures for the struct opEquals, so I may add a little documentation bug report about it: int opEquals(ref const S s); const bool opEquals(ref const KeyType s); P. 258 of TDPL shows a struct opEquals that returns a bool, so I presume the efficiency considerations have left space for a more semantically clean implementation. Isn't DMD able to optimize away (when inlining is present) the slowdown caused by the n?1:0 ? Bye, bearophile From sovende at gmail.com Fri Sep 24 02:46:39 2010 From: sovende at gmail.com (Emil Madsen) Date: Fri, 24 Sep 2010 11:46:39 +0200 Subject: the bit[] type In-Reply-To: References: Message-ID: Now I'm just curious, how does D represent a bool type as false and true, I take it that false is 0b00000000, is true anything but that? - or will the compiler make sure, that its always 0b11111111 or would it be 0b00000001? (as 0b11111111 would be -1 if signed) - is there a given standard for this, or is this up to the implementer of the compiler? About the bit type, and the bitarray, if I'm interresting in doing anything alike this, I'm off to allocating an array of chars? - and bitwise accessing them, to change them? And now another piece of curiousity, how did this align in memory, would the compiler couple up bit types, to fill out a byte? - and if so, in how large a scope would it do this? - current scope? On 23 September 2010 19:32, bearophile wrote: > jcc7: > > > As you can see from the links to newsgroup threads at the bottom of the > first > > page, the topic was discussed over many years. Perhaps the discussions > have > > tapered off in recent years because the current approach is right. > > It's an interesting read, thank you (I was present only at the tail of it). > > It's a good example of how even an "obviously simple" feature like a > bool/bit type may hide complexities, design difficulties, requires > engineering trade-offs, and in the end may produce something with some > inevitable design defects. > > ~bool is forbidden, but in DMD a bool is represented with 8 bits, so it has > 255 ways to be true and 1 to be false. A boolean like this: > > bool b = void; > > May contain something different from 0 or 1, this may cause some surprise. > > In those discussions I have seen Walter against the usage of bool as return > type for opEquals, because a cast(bool)some_int is equivalent to: > n ? 1 : 0 > That requires some instructions, so it isn't fully efficient. > > In the pages (operatoroverloading.html and hash-map.html) about the D2 > language I have seen different signatures for the struct opEquals, so I may > add a little documentation bug report about it: > int opEquals(ref const S s); > const bool opEquals(ref const KeyType s); > > P. 258 of TDPL shows a struct opEquals that returns a bool, so I presume > the efficiency considerations have left space for a more semantically clean > implementation. Isn't DMD able to optimize away (when inlining is present) > the slowdown caused by the n?1:0 ? > > Bye, > bearophile > -- // Yours sincerely // Emil 'Skeen' Madsen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmdavisProg at gmx.com Fri Sep 24 02:57:46 2010 From: jmdavisProg at gmx.com (Jonathan M Davis) Date: Fri, 24 Sep 2010 02:57:46 -0700 Subject: the bit[] type In-Reply-To: References: Message-ID: <201009240257.46874.jmdavisProg@gmx.com> On Friday 24 September 2010 02:46:39 Emil Madsen wrote: > Now I'm just curious, how does D represent a bool type as false and true, I > take it that false is 0b00000000, is true anything but that? - or will the > compiler make sure, that its always 0b11111111 or would it be 0b00000001? > (as 0b11111111 would be -1 if signed) - is there a given standard for this, > or is this up to the implementer of the compiler? I believe that when you cast a bool to an integral type, false is *always* 0, and true is *always* 1. However, when casting an integral type *to* bool, any non-zero value is true. Whether the compiler bothers to always make the actual byte value of the bool 0x01 for true when casting to bool, I don't know. If you want to know for sure, I believe that you'll have to look at the generated assembly code. - Jonathan M Davis From sovende at gmail.com Fri Sep 24 03:42:44 2010 From: sovende at gmail.com (Emil Madsen) Date: Fri, 24 Sep 2010 12:42:44 +0200 Subject: the bit[] type In-Reply-To: <201009240257.46874.jmdavisProg@gmx.com> References: <201009240257.46874.jmdavisProg@gmx.com> Message-ID: I know that I'm able to check the assembly out, or even just write out each bit, but I'm more interresting in knowing if its the same over more compilers, aka, if theres given a standard for it. I really must admit I were really 'happy*', when I read that D1 had the bit type, and immediately I tried to compile a D2 program, to check if it had it bit type, and I must admit, I were somewhat disappointed, because I think the bit type, should be in the language, not to replace the bool type, but to be the type it is, for those special cases where you want it. A recent example where I could have used it, is dragging out data from the CPUID instruction, wheres currently one will have to do a lot of bitfiddling, it really could just be replaced with a union alike: union { int i; bit[32] b; } Which would allow one, to directly interact and check each bit. I dont know if I could use bitArray for this matter, by putting it in a union, I havn't tried, because in C++, you cant do it with a vector, as the vector has a constructor (which is not allowed within unions (I think its allow in D, isn't it?)) and because the size of a vector with 8 elements != 1byte. And other example where I think the bittype would be valuable is on embedded systems, where you could be interrested in the bit/speed trade off, I take that comes with accessing each bit. - and I do know that I could just write a bittype myself, and do bitwise operations on it, to get the behavior I wont, my opinion however, is, that it wont ever get as pretty as a native language bit type. An other feature with would be really amazing is if the fabulous arrayslicing feature, was defined for the bittype (dont know if it ever were), but if it was, this would open up a hole new way of writing actually readable bitfiddling code. In my opinion then D should offer both types, wheres bool should be used as the main bool type, and bit should be this rarely used type, which should be accessable, when one really wants it and needs it. Thats my opinion atleast. Emil 'Skeen' Madsen *my english isn't really that good, couldn't come up with anything better On 24 September 2010 11:57, Jonathan M Davis wrote: > On Friday 24 September 2010 02:46:39 Emil Madsen wrote: > > Now I'm just curious, how does D represent a bool type as false and true, > I > > take it that false is 0b00000000, is true anything but that? - or will > the > > compiler make sure, that its always 0b11111111 or would it be 0b00000001? > > (as 0b11111111 would be -1 if signed) - is there a given standard for > this, > > or is this up to the implementer of the compiler? > > I believe that when you cast a bool to an integral type, false is *always* > 0, > and true is *always* 1. However, when casting an integral type *to* bool, > any > non-zero value is true. Whether the compiler bothers to always make the > actual > byte value of the bool 0x01 for true when casting to bool, I don't know. If > you > want to know for sure, I believe that you'll have to look at the generated > assembly code. > > - Jonathan M Davis > -- // Yours sincerely // Emil 'Skeen' Madsen -------------- next part -------------- An HTML attachment was scrubbed... URL: From sovende at gmail.com Fri Sep 24 03:53:43 2010 From: sovende at gmail.com (Emil Madsen) Date: Fri, 24 Sep 2010 12:53:43 +0200 Subject: the bit[] type In-Reply-To: References: <201009240257.46874.jmdavisProg@gmx.com> Message-ID: Just because my last message, wasn't long enough I wanted to add more: The real issue for me, is that the debate about bool and bit, has been about if one of the other should be implemented, thats not the debate for me, as I really do think, these types are quite different, even tho they represent the same thing. Now what I'm interested in knowing, is if it's really worth implementing arrayslicing and such for the bit type, because in my opinion I think the trade-off between usage and implementation cost of the feature, might not be worth it, but if all of the features has been developed, when it was in use, then I think its a shame, not allowing us application writes from using it. - and in case its not stable or whatever, wouldn't it be possible to have it in a snapshot version, till its stabile? -- // Yours sincerely // Emil 'Skeen' Madsen -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.sagitario at gmx.de Fri Sep 24 06:06:20 2010 From: r.sagitario at gmx.de (Rainer Schuetze) Date: Fri, 24 Sep 2010 15:06:20 +0200 Subject: Visual D 0.3.16 released Message-ID: Hi, as the new version of Visual D sports some interesting new features, I'd like to announce it here for a wider public. Some of the highlights are * now supports and installs the Mago debugger (http://dsource.org/projects/mago_debugger) * new profiler window to browse trace.log (see http://www.dsource.org/projects/visuald/wiki/Tour/Profiling for screenshot) * new command "Build phobos browse info" * now supports command comment/uncomment selected lines * improved smart indentation * fixed installation and execution on Windows Server 2003 Visual D is a Visual Studio package providing both project management and language services for the D programming language. It works with Visual Studio 2005, 2008 and 2010 as well as the free Visual Studio Shells. Visual D comes with an easy installer and can be downloaded here: http://www.dsource.org/projects/visuald Rainer From dsimcha at yahoo.com Fri Sep 24 10:09:56 2010 From: dsimcha at yahoo.com (dsimcha) Date: Fri, 24 Sep 2010 17:09:56 +0000 (UTC) Subject: Visual D 0.3.16 released References: Message-ID: == Quote from Rainer Schuetze (r.sagitario at gmx.de)'s article > Hi, > as the new version of Visual D sports some interesting new features, I'd > like to announce it here for a wider public. Some of the highlights are > * now supports and installs the Mago debugger > (http://dsource.org/projects/mago_debugger) > * new profiler window to browse trace.log (see > http://www.dsource.org/projects/visuald/wiki/Tour/Profiling for screenshot) > * new command "Build phobos browse info" > * now supports command comment/uncomment selected lines > * improved smart indentation > * fixed installation and execution on Windows Server 2003 > Visual D is a Visual Studio package providing both project management > and language services for the D programming language. It works with > Visual Studio 2005, 2008 and 2010 as well as the free Visual Studio Shells. > Visual D comes with an easy installer and can be downloaded here: > http://www.dsource.org/projects/visuald > Rainer How's D2 support? Is Visual D mostly a D1 IDE, or a D2 IDE? From r.sagitario at gmx.de Fri Sep 24 13:35:28 2010 From: r.sagitario at gmx.de (Rainer Schuetze) Date: Fri, 24 Sep 2010 22:35:28 +0200 Subject: Visual D 0.3.16 released In-Reply-To: References: Message-ID: I'm using it for D2 only, but Visual D is mostly agnostic to the D version. Anything "intelligent" is using the compiler generated JSON files as browse information, and this is available for both versions. The areas that might be incorrect for D1 source code are - syntax highlighting of D2 keywords and some string variants that do not exist in D1 - automatic generation of phobos JSON files is customized to the structure of D2 dsimcha wrote: > == Quote from Rainer Schuetze (r.sagitario at gmx.de)'s article >> Visual D is a Visual Studio package providing both project management >> and language services for the D programming language. It works with >> Visual Studio 2005, 2008 and 2010 as well as the free Visual Studio Shells. >> Visual D comes with an easy installer and can be downloaded here: >> http://www.dsource.org/projects/visuald >> Rainer > > How's D2 support? Is Visual D mostly a D1 IDE, or a D2 IDE? From aldoSkipallthisNunez1 at gmail.com Fri Sep 24 19:05:44 2010 From: aldoSkipallthisNunez1 at gmail.com (Aldo Nunez) Date: Fri, 24 Sep 2010 19:05:44 -0700 Subject: Visual D 0.3.16 released References: Message-ID: Rainer Schuetze wrote: > * now supports and installs the Mago debugger > (http://dsource.org/projects/mago_debugger) Thanks a lot, Rainer, for including the debugger with Visual D. I know you put some work into that, and it's definitely appreciated. > * new profiler window to browse trace.log This is great! Before you ever announced the IDE, I had ideas of putting in a feature like this if I were to write one. So, I'm glad you did it. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From sovende at gmail.com Sun Sep 26 07:36:56 2010 From: sovende at gmail.com (Emil Madsen) Date: Sun, 26 Sep 2010 16:36:56 +0200 Subject: QtD is suspended In-Reply-To: References: Message-ID: Just curious about QtD, how far did the design process go in terms of % before it got suspended? 10% - 25% - 50%? - and what would the time approximations be to finish it? On 16 September 2010 16:22, Max Samukha wrote: > After a good amount of hesitation, we have decided to put the QtD project > on hold. QtD has a potential to become a complete and effective development > platform for D but it is not going to happen soon (unless people with harder > hearts take it over). We have spent half of the day hunting yet another dmd > bug-o-feature and that is the last straw. > > We offer our apologies to people who put their hope upon the project. > Please come back in a year or two when the language has a stable compiler > with the features fully specified, implemented and debugged. > > -- // Yours sincerely // Emil 'Skeen' Madsen -------------- next part -------------- An HTML attachment was scrubbed... URL: From spambox at d-coding.com Sun Sep 26 10:04:43 2010 From: spambox at d-coding.com (Max Samukha) Date: Sun, 26 Sep 2010 20:04:43 +0300 Subject: QtD is suspended In-Reply-To: References: Message-ID: On 09/26/2010 05:36 PM, Emil Madsen wrote: > Just curious about QtD, how far did the design process go in terms of % > before it got suspended? > 10% - 25% - 50%? - and what would the time approximations be to finish it? > > On 16 September 2010 16:22, Max Samukha > wrote: > > After a good amount of hesitation, we have decided to put the QtD > project on hold. QtD has a potential to become a complete and > effective development platform for D but it is not going to happen > soon (unless people with harder hearts take it over). We have spent > half of the day hunting yet another dmd bug-o-feature and that is > the last straw. > > We offer our apologies to people who put their hope upon the > project. Please come back in a year or two when the language has a > stable compiler with the features fully specified, implemented and > debugged. > > > > > -- > // Yours sincerely > // Emil 'Skeen' Madsen I guess it is about 67%. Basic stuff is in place, including cross-language virtual dispatch, partially meta-object system, signals/slots etc, but more advanced features like Q_PROPERTY are to be implemented. A couple of months (very roughly) before we have a stable and feature-compete version. From sovende at gmail.com Sun Sep 26 23:15:42 2010 From: sovende at gmail.com (Emil Madsen) Date: Mon, 27 Sep 2010 08:15:42 +0200 Subject: QtD is suspended In-Reply-To: References: Message-ID: Is there a partly complete release? - that just basic stuff available? On 26 September 2010 19:04, Max Samukha wrote: > On 09/26/2010 05:36 PM, Emil Madsen wrote: > >> Just curious about QtD, how far did the design process go in terms of % >> before it got suspended? >> 10% - 25% - 50%? - and what would the time approximations be to finish it? >> >> On 16 September 2010 16:22, Max Samukha > > wrote: >> >> After a good amount of hesitation, we have decided to put the QtD >> project on hold. QtD has a potential to become a complete and >> effective development platform for D but it is not going to happen >> soon (unless people with harder hearts take it over). We have spent >> half of the day hunting yet another dmd bug-o-feature and that is >> the last straw. >> >> We offer our apologies to people who put their hope upon the >> project. Please come back in a year or two when the language has a >> stable compiler with the features fully specified, implemented and >> debugged. >> >> >> >> >> -- >> >> // Yours sincerely >> // Emil 'Skeen' Madsen >> > > I guess it is about 67%. Basic stuff is in place, including cross-language > virtual dispatch, partially meta-object system, signals/slots etc, but more > advanced features like Q_PROPERTY are to be implemented. A couple of months > (very roughly) before we have a stable and feature-compete version. > -- // Yours sincerely // Emil 'Skeen' Madsen -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at extrawurst.org Mon Sep 27 00:58:47 2010 From: spam at extrawurst.org (Stephan) Date: Mon, 27 Sep 2010 09:58:47 +0200 Subject: Visual D 0.3.16 released In-Reply-To: References: Message-ID: On 25.09.2010 04:05, Aldo Nunez wrote: > Rainer Schuetze wrote: >> * now supports and installs the Mago debugger >> (http://dsource.org/projects/mago_debugger) > > Thanks a lot, Rainer, for including the debugger with Visual D. I know > you put some work into that, and it's definitely appreciated. I'd like to try that one myself but it does not work for me. I dont know why, but the debugger just triggers breakpoints and gives me a callstack, i get no locals,auto or watch variables. is this a bug or is it just not possible with mago yet ? > >> * new profiler window to browse trace.log > > This is great! Before you ever announced the IDE, I had ideas of putting > in a feature like this if I were to write one. So, I'm glad you did it. > Yeah i like that one too. it is so much more readable than the crypy logfile format. still it is quite useless for me cause it does not support multithreaded applications. From sandford at jhu.edu Mon Sep 27 07:55:12 2010 From: sandford at jhu.edu (Robert Jacques) Date: Mon, 27 Sep 2010 10:55:12 -0400 Subject: Visual D 0.3.16 released References: Message-ID: On Mon, 27 Sep 2010 03:58:47 -0400, Stephan wrote: > On 25.09.2010 04:05, Aldo Nunez wrote: >> Rainer Schuetze wrote: >>> * now supports and installs the Mago debugger >>> (http://dsource.org/projects/mago_debugger) >> >> Thanks a lot, Rainer, for including the debugger with Visual D. I know >> you put some work into that, and it's definitely appreciated. > > I'd like to try that one myself but it does not work for me. I dont know > why, but the debugger just triggers breakpoints and gives me a > callstack, i get no locals,auto or watch variables. is this a bug or is > it just not possible with mago yet ? > >> >>> * new profiler window to browse trace.log >> >> This is great! Before you ever announced the IDE, I had ideas of putting >> in a feature like this if I were to write one. So, I'm glad you did it. >> > > Yeah i like that one too. it is so much more readable than the crypy > logfile format. still it is quite useless for me cause it does not > support multithreaded applications. Mago has issues with 2.049. Its website has a work-around. Have you tried that yet? From bearophileHUGS at lycos.com Tue Sep 28 14:52:33 2010 From: bearophileHUGS at lycos.com (bearophile) Date: Tue, 28 Sep 2010 17:52:33 -0400 Subject: dmd 1.064 and 2.049 release References: Message-ID: Don: > Sorry bearophile, regressions and wrong-code bugs will ALWAYS have top > priority. There will be no apology for fixing bugs like 3996, 4681, and > 4009. . Thinking quite more about it, I don't agree. Those are critical implementation bugs, but they are bugs still. Design bugs come before critical implementation bugs because if you don't fix them sooner, they become permanent. Among my list of little design bugs to fix there are things more important than 3996, 4681, and 4009, and the risk of seeing them become permanent is growing at every dmd2 release after TDPL publication. Bye, bearophile From spambox at d-coding.com Wed Sep 29 02:40:38 2010 From: spambox at d-coding.com (Max Samukha) Date: Wed, 29 Sep 2010 12:40:38 +0300 Subject: QtD is suspended In-Reply-To: References: Message-ID: On 09/27/2010 09:15 AM, Emil Madsen wrote: > Is there a partly complete release? - that just basic stuff available? Latest trunk: http://bitbucket.org/qtd/repo Wiki: http://www.dsource.org/projects/qtd I have a local branch that should fix a couple of major problems but it is not ready for a commit. Among other things, it supports generating struct wrappers for Qt value types, making it obvious that the lack of default struct constructors is a disaster.