Re: D 1.076 and 2.061 release
On Thursday, 3 January 2013 at 08:25:41 UTC, Dmitry Olshansky wrote: 1/3/2013 12:22 PM, Russel Winder пишет: On Wed, 2013-01-02 at 13:59 -0800, Walter Bright wrote: […] I finally threw in the towel and don't use Ubuntu to play music anymore. I threw in the towel on Ubuntu when Unity came out as the default UI. Going OT but can't agree more :) I rather like lubuntu (LXDE). I like minimalist interfaces, I don't care about bells and whistles, I want things that plain work, that's all. I don't use Linux for multimedia, only for programming and work. So it runs in a VM on my laptop, and the simpler the better. With this philosophy in mind, I'm quite satisfied. The only thing I regret is, lubuntu is not a LTS release unfortunately.
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On Friday, 11 January 2013 at 06:37:31 UTC, Walter Bright wrote: On 1/10/2013 8:22 PM, deadalnix wrote: I have to concurs with Walter here. I know that must be hard for you, and I admire your sacrifice! :-) Ha, we have disagreement, but remember, people always make more noise when they disagree than when they agree.
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-10 06:18, Walter Bright wrote: On 1/9/2013 11:02 AM, Jacob Carlborg wrote: As I said, I don't know assembly but here's the output: Good time to learn it! Do you have any good books to recommend for this? I will most likely not have time to learn assembly now. I'm busy with other things and I think I could spend my time better by contributing with other D related things. Also you said: No prob. I'll be happy to make compiler mods as necessary, once the exact problems are identified. http://forum.dlang.org/thread/kbvsgo$1po3$1...@digitalmars.com?page=26#post-kcdvjh:242a1f:241:40digitalmars.com -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 1/10/2013 10:30 AM, Jacob Carlborg wrote: On 2013-01-10 06:18, Walter Bright wrote: On 1/9/2013 11:02 AM, Jacob Carlborg wrote: As I said, I don't know assembly but here's the output: Good time to learn it! Do you have any good books to recommend for this? No. But a reasonable way is to just get the instruction set reference from Intel, and single step some D code in assembler mode in the debugger and go instruction by instruction. I will most likely not have time to learn assembly now. I'm busy with other things and I think I could spend my time better by contributing with other D related things. I think you'll be pleasantly surprised at how knowing assembler will improve your high level coding abilities. Also you said: No prob. I'll be happy to make compiler mods as necessary, once the exact problems are identified. http://forum.dlang.org/thread/kbvsgo$1po3$1...@digitalmars.com?page=26#post-kcdvjh:242a1f:241:40digitalmars.com Yes, I did. And I know that the compiler will have to be modified to match with Apple's new scheme.
Re: D 1.076 and 2.061 release
On 13-01-10 12:13 AM, Walter Bright wrote: On 1/4/2013 12:10 PM, r_m_r wrote: I was wondering if it is possible to integrate some javascript in the changelog page to automatically generate the list of fixed issues as suggested by Jonathan (As an example, please see the attached file: jq.html). Thanks for doing this. It's an interesting idea. Some people hate javascript solutions, though :-) Why not create a link to a second page that would contain that javascript so that people can decide to use it or not? Just adding a link to this on the version number for example. Getting the list that was available in previous releases would just be one more click away. I would also be possible to add a count of entries on each of those javascript-generated lists for quickly identifying if something has changed since last looking at them. -- /Pierre Rouleau
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-10 21:13, Walter Bright wrote: No. But a reasonable way is to just get the instruction set reference from Intel, and single step some D code in assembler mode in the debugger and go instruction by instruction. I see, thanks. I think you'll be pleasantly surprised at how knowing assembler will improve your high level coding abilities. Yeah, that's one thing I've learned by reading the newsgroups here. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-11 05:22, deadalnix wrote: I have to concurs with Walter here. Knowing assembly language is a great way to improve you knowledge of programming in general. This is way easier than what most dev think. I personally know assembly for ARM and x86, and it is clearly helpful. I have no doubt that it can be useful and helpful. The time to learn it just competes with so much else. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-07 09:04, Walter Bright wrote:
Please nail down what is necessary first. (BTW, I don't know how the
compiler can tell what image an address comes from. Remember, shared
libraries are loaded at runtime, not compile time.)
I've done some investigation. Currently DMD inserts a call to the
__tls_get_addr function when accessing a TLS variable. This is
implemented in druntime.
In Mac OS X 10.7 it works similar but instead of inserting a call to
__tls_get_addr there's a struct looking like this (written in D) :
struct TLVDescriptor
{
void* function (TLVDescriptor*) thunk;
size_t key;
size_t offset;
}
The dynamic linker will iterate all loaded images and extract the
section containing the TLS data. I guess this section consists of a list
of TLVDescriptor*. The dynamic linker will set the thunk to a function
tlv_get_addrs, implemented in assembly in the dynamic linker. It will
set the key to a key created by pthread_key_create. It will also map
the image with this key. This key is same for all TLVDescriptor of a
given image.
Instead of calling __tls_get_addr I think that the compiler will need
to call the thunk passing in the TLVDescriptor itself to the thunk.
The tlv_get_addrs function will then extract the key and from that key
it can get the image the address belongs to.
Does that make any sens? Is that something the DMD could do, that is
call the thunk instead of __tls_get_addr.?
--
/Jacob Carlborg
Re: D 1.076 and 2.061 release
On Friday, January 04, 2013 14:13:22 Walter Bright wrote: On 1/3/2013 10:44 PM, Jonathan M Davis wrote: P.S. Also, as a future improvement, we _really_ shouldn't be linking to bugzilla for our list. I've never seen a release notes document or changelog do that in my entire life. It would be _far_ more user friendly to list the changes like we did before with the bug number for each entry linking to the bug report (and it's what most projects to do from what I've seen). What we used to do was, literally (and I mean literally) copy/paste the bugzilla entry title and stick it in the changelog. It's THE SAME LIST as in the bugzilla list. It's even in the same order. It's just that the bugzilla generated list is complete. I don't understand your rationale that it's _far_ more user friendly. It's the exact same list, in the exact same order, with the exact same text. Okay, _far_ more friendly is probably an exaggeration, but I definitely think that it's unfriendly to redirect people to bugzilla for the changelog, and several other people have said the same in this thread. The normal thing to do is do what we did before and list all of the changes on a single page which people can look over at a glance without caring one whit about bugzilla (beyond possibly clicking on one of the bug numbers for more details). It also means fewer clicks, because you don't have to click to get at any of the lists. I have _never_ seen any changelog other than ours use bugzilla queries for its contents. They're pretty much always done in a manner that allows them to be put in a text file (one which is frequently provided with the released files themselves or otherwise sitting in the repository along with the README and whatnot). - Jonathan M Davis
Re: D 1.076 and 2.061 release
On 1/9/13 12:43 AM, Jonathan M Davis wrote: On Friday, January 04, 2013 14:13:22 Walter Bright wrote: It's THE SAME LIST as in the bugzilla list. It's even in the same order. It's just that the bugzilla generated list is complete. I don't understand your rationale that it's _far_ more user friendly. It's the exact same list, in the exact same order, with the exact same text. Okay, _far_ more friendly is probably an exaggeration There is something to be said about proportional response. Shall we stop this now? Thanks much, Andrei
Re: D 1.076 and 2.061 release
On Tuesday, January 08, 2013 16:25:10 Nick Sabalausky wrote: So then what's this rvalue ref problem that's still on the front burner? auto ref / the problem that C++'s const deals with. The ability to have a function which takes both lvalues and rvalues without copying them unless it has to. We have a solution for it with templated functions but no solution for non-templated functions. - Jonathan M Davis
Re: D 1.076 and 2.061 release
On Wednesday, January 09, 2013 00:52:32 Andrei Alexandrescu wrote: On 1/9/13 12:43 AM, Jonathan M Davis wrote: On Friday, January 04, 2013 14:13:22 Walter Bright wrote: It's THE SAME LIST as in the bugzilla list. It's even in the same order. It's just that the bugzilla generated list is complete. I don't understand your rationale that it's _far_ more user friendly. It's the exact same list, in the exact same order, with the exact same text. Okay, _far_ more friendly is probably an exaggeration There is something to be said about proportional response. Shall we stop this now? I think that it's important, and other people in this thread have agreed with me (anyone other than Walter who has disagreed has been silent on the issue). But I gather that you don't agree. - Jonathan M Davis
Re: D 1.076 and 2.061 release
We have a solution for it with templated functions but no solution for non-templated functions. We have: https://github.com/D-Programming-Language/dmd/pull/1019 It's ready to merge. So maybe in 2.062 this problem is solved.
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On Wednesday, 9 January 2013 at 07:57:12 UTC, Jacob Carlborg
wrote:
On 2013-01-07 09:04, Walter Bright wrote:
Please nail down what is necessary first. (BTW, I don't know
how the
compiler can tell what image an address comes from. Remember,
shared
libraries are loaded at runtime, not compile time.)
I've done some investigation. Currently DMD inserts a call to
the __tls_get_addr function when accessing a TLS variable. This
is implemented in druntime.
In Mac OS X 10.7 it works similar but instead of inserting a
call to __tls_get_addr there's a struct looking like this
(written in D) :
struct TLVDescriptor
{
void* function (TLVDescriptor*) thunk;
size_t key;
size_t offset;
}
The dynamic linker will iterate all loaded images and extract
the section containing the TLS data. I guess this section
consists of a list of TLVDescriptor*. The dynamic linker will
set the thunk to a function tlv_get_addrs, implemented in
assembly in the dynamic linker. It will set the key to a key
created by pthread_key_create. It will also map the image
with this key. This key is same for all TLVDescriptor of a
given image.
Instead of calling __tls_get_addr I think that the compiler
will need to call the thunk passing in the TLVDescriptor itself
to the thunk.
The tlv_get_addrs function will then extract the key and from
that key it can get the image the address belongs to.
Does that make any sens? Is that something the DMD could do,
that is call the thunk instead of __tls_get_addr.?
Isn't it horrible performancewise ?
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-09 11:26, Jacob Carlborg wrote: I think it sounds like that but I don't know. I'm just trying to figure out how TLS is implemented on Mac OS X 10.7+. Also, there's nothing else that calls this tlv_get_addr function or the thunk so I'm guessing it's the compiler that calls it. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-09 11:00, deadalnix wrote: Isn't it horrible performancewise ? I think it sounds like that but I don't know. I'm just trying to figure out how TLS is implemented on Mac OS X 10.7+. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 1/9/2013 2:28 AM, Jacob Carlborg wrote:
On 2013-01-09 11:26, Jacob Carlborg wrote:
I think it sounds like that but I don't know. I'm just trying to figure
out how TLS is implemented on Mac OS X 10.7+.
Also, there's nothing else that calls this tlv_get_addr function or the thunk so
I'm guessing it's the compiler that calls it.
Watcha do is something like this:
__thread int x;
int foo() { return x; }
Compile, disassemble, and look at the code generated and the fixup records. Then
there's no need to guess :-)
Re: D 1.076 and 2.061 release
On Wed, Jan 9, 2013 at 9:52 AM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: There is something to be said about proportional response. Shall we stop this now? I propose to start another thread, maybe more constructive, where I propose a small text describing what's new in 2.061. Is that OK?
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-09 11:38, Walter Bright wrote:
Watcha do is something like this:
__thread int x;
int foo() { return x; }
Compile, disassemble, and look at the code generated and the fixup
records. Then there's no need to guess :-)
Sure, I've already done that. I compared one version using __thread
and one version without __thread. I do see the differences of the
disassembly but that doesn't help me, I don't know assembly. The only
interesting I could find is that it does perform a call, the version
with __thread.
I don't have access to a machine running Lion+ but you could take a look
at this:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268
That's a bugzilla issue for the same thing for GCC. The comments contain
some disassembly of uses of __thread.
--
/Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On Wednesday, 9 January 2013 at 10:38:33 UTC, Walter Bright wrote:
Watcha do is something like this:
__thread int x;
int foo() { return x; }
Compile, disassemble, and look at the code generated and the
fixup records. Then there's no need to guess :-)
I also think this is the best way of approaching such problems.
If you can, also try to find the source code for the involved
code. In case of trying to understand the OS X TLS mechanism, I
found the following files from dyld to be helpful:
http://opensource.apple.com/source/dyld/dyld-210.2.3/src/threadLocalHelpers.s
http://opensource.apple.com/source/dyld/dyld-210.2.3/src/threadLocalVariables.c
David
Re: D 1.076 and 2.061 release
On Wed, 09 Jan 2013 01:09:21 -0800 Jonathan M Davis jmdavisp...@gmx.com wrote: On Wednesday, January 09, 2013 00:52:32 Andrei Alexandrescu wrote: On 1/9/13 12:43 AM, Jonathan M Davis wrote: On Friday, January 04, 2013 14:13:22 Walter Bright wrote: It's THE SAME LIST as in the bugzilla list. It's even in the same order. It's just that the bugzilla generated list is complete. I don't understand your rationale that it's _far_ more user friendly. It's the exact same list, in the exact same order, with the exact same text. Okay, _far_ more friendly is probably an exaggeration There is something to be said about proportional response. Shall we stop this now? I think that it's important, and other people in this thread have agreed with me (anyone other than Walter who has disagreed has been silent on the issue). But I gather that you don't agree. - Jonathan M Davis Yea, this change is definitely a notable step backwards in presentation and usability.
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On Wednesday, 9 January 2013 at 10:38:33 UTC, Walter Bright wrote:
On 1/9/2013 2:28 AM, Jacob Carlborg wrote:
On 2013-01-09 11:26, Jacob Carlborg wrote:
I think it sounds like that but I don't know. I'm just trying
to figure
out how TLS is implemented on Mac OS X 10.7+.
Also, there's nothing else that calls this tlv_get_addr
function or the thunk so
I'm guessing it's the compiler that calls it.
Watcha do is something like this:
__thread int x;
int foo() { return x; }
Compile, disassemble, and look at the code generated and the
fixup records. Then there's no need to guess :-)
Surely __thread is redundant there, seeing as x will be TLS by
default?
I tried disassembling this on os x 10.7.5
otool (the default tool for this on os x) just gave me this:
tls_test.o:
indirect symbol table offset is past end of file
(__TEXT,__text) section
It couldn't see any instructions at all.
gdb disas gives this:
0x0024 D8tls_test3fooFZi+0: push rbp
0x0025 D8tls_test3fooFZi+1: movrbp,rsp
0x0028 D8tls_test3fooFZi+4: movrdi,QWORD
PTR [rip+0x0]# 0x30 D8tls_test3fooFZi+12
0x0030 D8tls_test3fooFZi+12: call 0x35
D8tls_test3fooFZi+17
0x0035 D8tls_test3fooFZi+17: moveax,DWORD
PTR [rax]
0x0037 D8tls_test3fooFZi+19:poprbp
0x0038 D8tls_test3fooFZi+20:ret
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-09 19:53, John Colvin wrote: Surely __thread is redundant there, seeing as x will be TLS by default? We're talking C here and it's not default in C. -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On Wed, 9 Jan 2013 12:54:54 -0500 Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: Yea, this change is definitely a notable step backwards in presentation and usability. And it doesn't help that, once again, the changelog is showing the *next* release with no indication that it hasn't actually been released.
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-09 11:38, Walter Bright wrote:
Watcha do is something like this:
__thread int x;
int foo() { return x; }
Compile, disassemble, and look at the code generated and the fixup
records. Then there's no need to guess :-)
As I said, I don't know assembly but here's the output:
Original code: http://pastebin.com/UKb6etWD
Disassembly with TLS: http://pastebin.com/nkdnE9w6
Disassembly without TLS: http://pastebin.com/vuvEBWWH
Object dump with TLS: http://pastebin.com/PqpPw56a
Object dump without TLS: http://pastebin.com/ki6atzEm
--
/Jacob Carlborg
Re: D 1.076 and 2.061 release
On 1/4/2013 12:10 PM, r_m_r wrote: I was wondering if it is possible to integrate some javascript in the changelog page to automatically generate the list of fixed issues as suggested by Jonathan (As an example, please see the attached file: jq.html). Thanks for doing this. It's an interesting idea. Some people hate javascript solutions, though :-)
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 1/9/2013 11:02 AM, Jacob Carlborg wrote: As I said, I don't know assembly but here's the output: Good time to learn it! And I'm not kidding.
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On Tuesday, 8 January 2013 at 07:30:55 UTC, Jacob Carlborg wrote: On 2013-01-07 21:30, David Nadlinger wrote: I don't know the current relative market share of the different OS X versions on top of my head either, but as we were getting a couple of bug reports from people who had tried to use LDC 2 on 10.6 (before we figured out that LLVM doesn't emulate TLS there), I guess it's too soon to drop support for it still. However, when finally somebody finds the time to implement shared library support in the runtime, the situation might have already changed anyway. In general Apple tries to push you to have always have the latest software. There are very few reasons to not have the latest OS, they are pretty darn cheap. Mandatory : http://www.gizmodo.fr/wp-content/uploads/2011/02/update_for_your_computer.jpg
Re: D 1.076 and 2.061 release
On 1/7/2013 8:17 PM, Pierre Rouleau wrote: And now I understand that D1 is no longer officially supported. If I understand properly D1 first release was 6 years ago. Lets assume I would have started a product development with it say 2 years ago because it was deemed relatively stable then. And now I want to support 64-bit Windows and my customers are starting to ask for Windows-8 support. Or some other things gets in the way (a bug somewhere, Windows 9 getting released sooner because Windows 8 is not as popular as Microsoft would have hoped.) What would be my alternatives? Port all the code to D2? Is this what will happen to D2? I'd like to know before I commit people and convince others. The moment D1 was stabilized, work began on D2. It was always understood that D2 was the future, and D1 was the stable version. Supporting it for 6 years is a pretty long time in the software business. At some point, you'll need to make a decision: 1. move to D2 2. merge things from D2 into the D1 you've forked 3. buy a support contract from Digital Mars or from any of the many other competent people in the community to help you with D1 It's pretty much the same with any software product. We were just talking about how Apple pretty much has deprecated OS X 10.6, Microsoft regularly abandons old versions of its operating systems, and I just found out that my Ubuntu is no longer supported.
Re: D 1.076 and 2.061 release
On 2013-01-08 09:57, Walter Bright wrote: The moment D1 was stabilized, work began on D2. It was always understood that D2 was the future, and D1 was the stable version. Supporting it for 6 years is a pretty long time in the software business. At some point, you'll need to make a decision: 1. move to D2 2. merge things from D2 into the D1 you've forked 3. buy a support contract from Digital Mars or from any of the many other competent people in the community to help you with D1 4. There's also Amber now which seems to be basically the same as D1 http://forum.dlang.org/thread/zflwhizhppbdqfioz...@forum.dlang.org -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On Tue, 2013-01-08 at 08:27 +0100, Jacob Carlborg wrote: I'm running 10.7 on my white MacBook from 2006. Interesting, I was told not to try upgrading to Lion, but to stay with Snow Leopard. MacBook2.1, Core 2 Duo, 2GB. This has a 64-bit processor, but 32-bit boot PROM, which means OS X will only run in 32-bit mode. This causes great pain since OS and processor report different states of being, leading to real pain building stuff. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
Looks like Apple are turning Snow Leopard 10.6 into their equivalent of XP: http://www.computerworld.com/s/article/9233244/OS_X_Snow_Leopard_shows_signs_of_becoming_Apple_s_XP From the list on http://www.apple.com/osx/how-to-upgrade/ I cannot upgrade to Mountain Lion 10.8, and Apple provide no way of upgrading to Lion 10.7. Thus I am forced to be Snow Leopard 10.6 for ever more. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D 1.076 and 2.061 release
Walter Bright, el 7 de January a las 13:27 me escribiste: On 1/7/2013 11:40 AM, Leandro Lucarella wrote: Andrei Alexandrescu, el 7 de January a las 08:31 me escribiste: One thing I want to do is enshrine a vetting mechanism that would allow Walter and myself to pre-approve enhancement requests. Someone (including us) would submit an enhancement request to Bugzilla, and then Walter and I add the tag preapproved to it. That means an implementation of the request has our approval assuming it has the appropriate quality. BTW, I wouldn't mind if you like to try this out with issue 7044 (see the pull request for more comments), which is really annoying us at work but I never got to fix because the lack of feedback (a perfect example of somebody willing, almost craving, to fix something and not doing it because of the lack of feedback). At this point, reading the discussions in the links, I don't know just what the latest proposal is. https://github.com/D-Programming-Language/dmd/pull/497 http://d.puremagic.com/issues/show_bug.cgi?id=7044 http://forum.dlang.org/thread/mailman.1605.1334108859.4860.digitalmar...@puremagic.com The latest proposal is: http://d.puremagic.com/issues/show_bug.cgi?id=7044#c3 You commented about it, I replied to your comments, and you never commented back. I also added me as assignee, I think it would be a good idea for people wanting to implement something (seriously), to add themselves as assignee. Doing so would mean that person is assuming a commitment to implement the feature if consensus is achieved. It would be the same as preapproved but from the other side. You could also prioritize and give feedback to issues with somebody assigned first. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Creativity is great but plagiarism is faster
Re: D 1.076 and 2.061 release
Walter Bright, el 8 de January a las 00:57 me escribiste: On 1/7/2013 8:17 PM, Pierre Rouleau wrote: And now I understand that D1 is no longer officially supported. If I understand properly D1 first release was 6 years ago. Lets assume I would have started a product development with it say 2 years ago because it was deemed relatively stable then. And now I want to support 64-bit Windows and my customers are starting to ask for Windows-8 support. Or some other things gets in the way (a bug somewhere, Windows 9 getting released sooner because Windows 8 is not as popular as Microsoft would have hoped.) What would be my alternatives? Port all the code to D2? Is this what will happen to D2? I'd like to know before I commit people and convince others. The moment D1 was stabilized, work began on D2. It was always understood that D2 was the future, and D1 was the stable version. Supporting it for 6 years is a pretty long time in the software business. At some point, you'll need to make a decision: 1. move to D2 2. merge things from D2 into the D1 you've forked What about licensing issues, is it even legal to for D1's backend? I mean, I don't mind doing it personally, because I believe I won't have any problems. But company lawyers don't think so positively :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Es erróneo pensar que el repollo es una afirmación de personalidad del volátil, es una verdura, es una verdura. -- Ricardo Vaporeso
Re: D 1.076 and 2.061 release
Pierre Rouleau, el 7 de January a las 23:17 me escribiste: I agree that feature releases mostly also contain bug fixes. I should have said, and I was thinking about proposing a process where minor releases that would only include bug fixes, and where major releases would mainly introduce new features but would also include some bug fixes. At work this is exactly what we do. And today, at work, I was just in a meeting evaluating bugs to identify bugs that will be fixed in a release of our product that will only contain bug fixes. The fixes that are selected where selected based on their severity, the impact they have on end-users and the time it takes to fix them. This is how most software projects works (specially open source projects). Major, minor and patchlevel version numbers, and have been explained and suggested here for ages. At this point I would be happy if we only get minor releases from time to time fixing only regressions and critical/security bugs that can't wait for a next release. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- You can try the best you can If you try the best you can The best you can is good enough
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-08 13:52, Russel Winder wrote: On Tue, 2013-01-08 at 08:27 +0100, Jacob Carlborg wrote: Interesting, I was told not to try upgrading to Lion, but to stay with Snow Leopard. I just did. MacBook2.1, Core 2 Duo, 2GB. I think mine is from late 2006. This has a 64-bit processor, but 32-bit boot PROM, which means OS X will only run in 32-bit mode. This causes great pain since OS and processor report different states of being, leading to real pain building stuff. I haven't noticed any problems. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-08 14:05, Russel Winder wrote: Looks like Apple are turning Snow Leopard 10.6 into their equivalent of XP: http://www.computerworld.com/s/article/9233244/OS_X_Snow_Leopard_shows_signs_of_becoming_Apple_s_XP From the list on http://www.apple.com/osx/how-to-upgrade/ I cannot upgrade to Mountain Lion 10.8, and Apple provide no way of upgrading to Lion 10.7. Thus I am forced to be Snow Leopard 10.6 for ever more. They don't sell USB sticks anymore? -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-08 14:05, Russel Winder wrote: Looks like Apple are turning Snow Leopard 10.6 into their equivalent of XP: http://www.computerworld.com/s/article/9233244/OS_X_Snow_Leopard_shows_signs_of_becoming_Apple_s_XP From the list on http://www.apple.com/osx/how-to-upgrade/ I cannot upgrade to Mountain Lion 10.8, and Apple provide no way of upgrading to Lion 10.7. Thus I am forced to be Snow Leopard 10.6 for ever more. Actually, I have the installation for Lion left on my hard drive. -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On 1/8/2013 4:34 AM, Leandro Lucarella wrote: What about licensing issues, is it even legal to for D1's backend? I mean, I don't mind doing it personally, because I believe I won't have any problems. But company lawyers don't think so positively :) If you've got a licensing issue, talk to me and I'll do my best to get it resolved for you to the satisfaction of your lawyers.
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 1/8/2013 4:52 AM, Russel Winder wrote: On Tue, 2013-01-08 at 08:27 +0100, Jacob Carlborg wrote: I'm running 10.7 on my white MacBook from 2006. Interesting, I was told not to try upgrading to Lion, but to stay with Snow Leopard. MacBook2.1, Core 2 Duo, 2GB. This has a 64-bit processor, but 32-bit boot PROM, which means OS X will only run in 32-bit mode. This causes great pain since OS and processor report different states of being, leading to real pain building stuff. So it won't run any 64 bit software? For at least a couple releases now, dmd for OS X has only included the 64 bit binaries for dmd. Not a single person has noticed (at least nobody has commented on it). We do build and test the OS X 32 bit dmd binaries, but left them off of the install package.
Re: D 1.076 and 2.061 release
On Tue, 08 Jan 2013 07:11:30 +0100
deadalnix deadal...@gmail.com wrote:
On Tuesday, 8 January 2013 at 05:29:15 UTC, Nick Sabalausky wrote:
On Mon, 07 Jan 2013 17:18:11 -0800
Walter Bright newshou...@digitalmars.com wrote:
On 1/7/2013 3:19 PM, Nick Sabalausky wrote:
On Thu, 03 Jan 2013 17:08:58 +0100
deadalnix deadal...@gmail.com wrote:
However, it is just to discover that this do not work :
struct Bar {}
auto foo(ref Bar bar) {}
foo(Bar()); // Now this is an error !
I still have code broken all over the place.
IIRC, they tried to include this change in 2.060 (or was it
2.059?),
but due to the major problems it causes, and the fact that
it *does*
make sense to use a temporary as an lvalue if you don't
intend to
use it again afterwords, there was a big discussion about it
on the
beta list and it was ultimately nixed. I'm disappointed to
see that
it snuck back.
Well, fixing the rvalue ref problem is still on the front
burner.
Wait, so are you saying that the above code which stopped
working in
2.061 will start working again in a later version?
No, I think he meant that breaking that code was actually fixing
the language because it shouldn't have worked in a first place
(thing I disagree with but I understand the reasoning).
So then what's this rvalue ref problem that's still on the front
burner?
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-08 21:49, Walter Bright wrote: So it won't run any 64 bit software? It can run 64bit software just fine. Mac OS X has been able to do that for a long time. 10.6 was the first version the kernel tries to run in 64bit mode (depends on the computer). Just because the kernel doesn't run in 64bit doesn't mean that the rest of the software can't run in 64bit. For at least a couple releases now, dmd for OS X has only included the 64 bit binaries for dmd. Not a single person has noticed (at least nobody has commented on it). We do build and test the OS X 32 bit dmd binaries, but left them off of the install package. There is no problem. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-07 13:41, David Nadlinger wrote: Yes, it is not supported by linker and dyld versions shipping with OS X 10.7. This is also the reason why LDC 2 only supports OS X 10.7+, as LLVM does not implement a workaround for older versions (although implementing one up to the point where it is good enough for D should be doable without too much effort). I've looked a bit at this and if we want to emulate TLS and support dynamic libraries on Mac OS X 10.6 I think we basically need to do what the dynamic linker does on 10.7. -- /Jacob Carlborg
Re: Managing email [ was Re: D 1.076 and 2.061 release ]
On Sun, 6 Jan 2013 11:42:53 -0500 Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: Like browsers, for instance. When Microsoft had their browser merely uninstallable... Erm... s/uninstallable/non-uninstallable/ (unless I'm remembering wrong)
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-07 01:25, Walter Bright wrote: Sean would be the main one, but really anyone who is willing to get down and dirty with threads and such can do it. Martin Nowak has already started on this, it seems he know what he's doing: https://github.com/dawgfoto/druntime/tree/SharedRuntime -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 1/6/2013 11:57 PM, Jacob Carlborg wrote: On 2013-01-07 01:25, Walter Bright wrote: Sean would be the main one, but really anyone who is willing to get down and dirty with threads and such can do it. Martin Nowak has already started on this, it seems he know what he's doing: https://github.com/dawgfoto/druntime/tree/SharedRuntime That's good to hear.
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 1/6/2013 11:57 PM, Jacob Carlborg wrote: On 2013-01-07 00:14, Walter Bright wrote: Where it is not implemented is in druntime. The folks who work on druntime are the ones that need convincing. I didn't know you had stopped working on the runtime. I now focus on the compiler, though I'll contribute now and then on the library.
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 1/6/2013 11:51 PM, Jacob Carlborg wrote: On 2013-01-07 00:19, Walter Bright wrote: I have fixed every single PIC implementation compiler problem that has been brought to my attention. If there are others, I am not aware of them. Please let me know the bugzilla issue numbers for any I have missed. I know you have. The problem is that there might be necessary to do some changes to the compiler. That doesn't mean there is a bug. I'm sorry, but I can't do anything with that statement. The OS X TLS implementation is all done in druntime. Not 100%. I'm thinking of the __tls_get_addr function which the compiler calls: https://github.com/D-Programming-Language/druntime/blob/master/src/core/thread.d#L4549 Yes, it defers it all to druntime by calling a druntime function. That function needs to know which image the given address belongs to. I think that the compiler needs to supply that, in addition to the address, but I'm not sure. If it does it requires a change in the compiler. I can add this to bugzilla. Please nail down what is necessary first. (BTW, I don't know how the compiler can tell what image an address comes from. Remember, shared libraries are loaded at runtime, not compile time.) Nevertheless, this does not impact Linux nor FreeBSD. Mac OS X is my main platform. It's natural that I try to get it to work there first. No prob. I'll be happy to make compiler mods as necessary, once the exact problems are identified.
Re: D 1.076 and 2.061 release
On 2013-01-07 01:36, Walter Bright wrote: The thing is, roadmaps are a lot like planning for a war. The moment the first shot is fired, all the plans go out the window. What we need to get done next is a constantly evolving situation, based on: On occasion developer are asking what they can work on and then we don't have a roadmap to point to. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On Sunday, 6 January 2013 at 23:19:48 UTC, Walter Bright wrote:
DMD implements its own TLS on OS X because the OS X C compiler
says not implemented when you try to create TLS variables. I
had no other option.
Note that this no longer appears to be the case, at least with
clang (OS X 10.7.5):
#include stdio.h
__thread int foo;
int main(){
foo = 4;
printf(%d\n, foo);
}
$ clang test.c
$ ./a.out
4
$ clang --version
Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on
LLVM 3.1svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix
(llvm-)gcc still complains:
$ gcc test.c
test.c:2: error: thread-local storage not supported for this
target
$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc.
build 5658) (LLVM build 2336.11.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Though I believe it will probably fail with older OS X versions
which don't have TLS support.
Robert
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-07 11:14, Robert Clipsham wrote: Note that this no longer appears to be the case, at least with clang (OS X 10.7.5): Mac OS X Lion (10.7) got support for TLS. But that means that the whole TLS needs to be redone in the compiler (output data to correct segments and similar) and in the runtime. The compiler would also need to be able to fallback to emulating as it currently does or we will loose the support for Mac OS X 10.6. Alternatively it might be possible to run the real TLS on Mac OS X 10.6 but then we would need to implement some parts of the dynamic linker into the D runtime. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On Monday, 7 January 2013 at 10:14:54 UTC, Robert Clipsham wrote: Though I believe it will probably fail with older OS X versions which don't have TLS support. Yes, it is not supported by linker and dyld versions shipping with OS X 10.7. This is also the reason why LDC 2 only supports OS X 10.7+, as LLVM does not implement a workaround for older versions (although implementing one up to the point where it is good enough for D should be doable without too much effort). David
Re: D 1.076 and 2.061 release
On 01/06/2013 10:18 PM, Pierre Rouleau wrote: On 13-01-06 9:45 PM, Jonathan M Davis wrote: On Sunday, January 06, 2013 21:22:18 Pierre Rouleau wrote: Is this something that the most influential people in the D project want to fix? What exactly do you want fixed? Really, I would like to be able to start using D at work. And be in a position to be able to convince people to use it. I found myself in the same position. My argument was: 1. There is a clear language reference 2. There are multiple implementations (DMD, GDC) 3. D has a lot of really nice features that make it better than C Now, you have to bear in mind, we don't do bytecode compiled languages that run on a VM - it's just not our thing, we use too much real hardware. Basically, D gives us all the fancy nice Java and C# features while letting us access real hardware without having to write a C shim to do it. We do not require a fancy cohesive roadmap, because we realize it's a FLOSS project and is therefore subject to the whims of its developers. If we want to influence said development, then we'll jump in or issue a bounty for things to be fixed. In the grand scheme of things, we've found this strategy to produce more time savings and value than it consumes. However, this does take a certain amount of buy in from your company management. Luckily, one of the company founders was an early embracer of Linux. -- Matthew Caron, Software Build Engineer Sixnet, a Red Lion business | www.sixnet.com +1 (518) 877-5173 x138 office
Re: D 1.076 and 2.061 release
On 01/05/2013 03:01 AM, Nick Sabalausky wrote: On Thu, 03 Jan 2013 08:20:19 -0500 Matthew Caron matt.ca...@redlion.net wrote: On 01/02/2013 04:18 PM, Walter Bright wrote: Why would you need to? If your mail store is IMAP, just let it rebuild. I don't store email on the server, I store it locally. I gave that up years ago when I ended up with more than one device. Too much did I get that email on my laptop or my desktop? And now with tablet, phone, laptop, desktop, and several kiosk machines around the house (because how else do you watch Firefly whilst loading custom hunting ammunition in the gun room?) and then the device proliferation continues... Turn off Delete email from server ten seconds after downloading it. Either increase it to a sane time period, or disable delete-from-server entirely. Problem solved. Worked fine for me. Isn't this just leave email on the server, which is what I suggested? Of course, what you're saying is use POP with leave on server enabled. A better solution is to just use IMAP. Accessing *sent* messages can be a different story though, but using your email client's setting for BCC outgoing messages to... to send to a special messages I sent address works well enough. Unless you need to use some shitty Fisher-Price email client like the one in iOS, because then you're just fucked. (But if you need to rely on iOS, you'll probably have bigger problems anyway.) Or, you just use IMAP. Windows is only suitable for playing video games, and I'm looking forward to Steam's release for Linux such that I can power on the Wintendo less and less. Steam on Linux? That's like installing hydraulics on a Formula 1 or a rusty nail in a jock strap. Nothing that involves Steam is suitable for playing videogames, whether Win/Lin or anything else. It's view it as an online shop which allows you to buy and install games for your platform. I have no issue with this. I don't use all the fancy extra social video game crap. I'd be willing to *release* a game, *non-exclusively*, on steam just for the visibility and for the subset of PC gamers that are unfortunately dumb enough to think steam isn't DRM, but that's all steam is good for. Gabe can suck the shit out of my ass for destroying the last non-orwellian gaming platform in existence and essentially turning it into a goddamn iPhone. You don't have to use it, you know. There are other games. GOG.com has a pile, and many of them run just fine under Wine and or DosBOX. I'd like to see them do more Linux, and I hope that the Steam port will be the beginning of more entries on to the platform. (Of course, I thought the same thing about Loki) -- Matthew Caron, Software Build Engineer Sixnet, a Red Lion business | www.sixnet.com +1 (518) 877-5173 x138 office
Re: D 1.076 and 2.061 release
On 13-01-07 7:49 AM, Matthew Caron wrote: On 01/06/2013 10:18 PM, Pierre Rouleau wrote: On 13-01-06 9:45 PM, Jonathan M Davis wrote: On Sunday, January 06, 2013 21:22:18 Pierre Rouleau wrote: Is this something that the most influential people in the D project want to fix? What exactly do you want fixed? Really, I would like to be able to start using D at work. And be in a position to be able to convince people to use it. However, this does take a certain amount of buy in from your company management. It does, and from other people too. Luckily, one of the company founders was an early embracer of Linux. It's not the case for my situation. The worst part I see is that bug fixes and new feature introductions are lumped together inside releases. Combined with the fact that the development is not predictable means that if you develop products with D you have to keep updating it. If you get stuck with a bug and wait for the release that fixes it, when that release comes out it could very well bring new language features that break the code that you have already written. It would be nice to have bug fixes separated from new feature introductions by having major and minor releases and branches for these releases. Contributors of a release could backport bug fix in the release they use if that was required by their project using the now old compiler version. Of course I realize that this means more overall work, more people, someone or a set of people in charge of release management, etc... -- /Pierre Rouleau
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-07 09:04, Walter Bright wrote: Please nail down what is necessary first. (BTW, I don't know how the compiler can tell what image an address comes from. Remember, shared libraries are loaded at runtime, not compile time.) I'll try and do that. -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On 01/07/2013 08:09 AM, Pierre Rouleau wrote: It would be nice to have bug fixes separated from new feature introductions by having major and minor releases and branches for these releases. Contributors of a release could backport bug fix in the release they use if that was required by their project using the now old compiler version. Of course I realize that this means more overall work, more people, someone or a set of people in charge of release management, etc... I also think that you'd be hard-pressed to find anyone who does development like that, proprietary or open source. It's not uncommon to have bugfix only releases, but having a new features release that doesn't fix any bugs is, in my experience, unheard of. Also, I'd be STRONGLY against it, because I have a fix bugs first mentality, and if you find a bug while implementing a new feature, it should be fixed. -- Matthew Caron, Software Build Engineer Sixnet, a Red Lion business | www.sixnet.com +1 (518) 877-5173 x138 office
Re: D 1.076 and 2.061 release
Brad Roberts, el 6 de January a las 17:28 me escribiste: On 1/6/2013 4:25 PM, Leandro Lucarella wrote: I really hope at some point this will be addressed, and I think other areas of the development process have been improved enough to think this is a good moment to do so, but first management (OK, I will say it: Walter) have to be convinced (or pushed) to do so. Maybe it will take 2 or 3 years. Believing that Walter is the problem is minimizing the problem. There's no way that a single developer can own and drive a roadmap, and that's essentially what Walter is. He's NOT a company of developers. He doesn't have a cadre of people that follow his instructions. If this community feels the need for a concerted _directed_ effort, the community needs to step up and volunteer to produce and progress upon that roadmap. The problem is that while D currently has maybe a dozen developers, each of them is essentially entirely self directed, following their own personal interests. There's nothing inherently wrong with that, and the results have been useful, but those results are also semi-chaotic and essentially impossible to predict. I can write a roadmap, but then, nobody will listen to me. The reality is, Walter is the leader and who decides what gets in and what not. It happened to me before to implement stuff that doesn't get in. And that's fine. But Walter, as a leader have to step up and tell where he wants to move so people focus on the stuff that have a chance to be merged. Otherwise the only road is forking, as it happened before. I don't think the Tango split and now Amber are coincidences. There is a lack of leadership in D, and talking with the community. Andrei tried to fill that leader position in the past, and even when I have lots of differences with Andrei, I think he successfully done that with Phobos. But he can't do that with DMD. I agree that Walter doesn't have to do all, but at least he must be convinced there is a value in it, and encourage it and help whoever wants to step up. Why would I bother to do anything if is very likely that Walter don't want to go that direction and all my work was done for nothing? Been there before. Now I'm more cautious when selecting my battles. Does anyone know of any mechanism for getting people to do what needs to be done vs what they want to do that doesn't involve paying them? The only long term successes I can point to all involve companies. I do think that D to take the next leap needs to have more (directly or indirectly) payed development. But still that doesn't stop you from having a plan, a tentative roadmap. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- ELLA FUE INFIEL, PERO EX POLOLO PAGÓ -- TV CHILE
Re: D 1.076 and 2.061 release
On 1/7/13 7:47 AM, Leandro Lucarella wrote: I can write a roadmap, but then, nobody will listen to me. Walter can write a roadmap, nobody will listen to him. One thing that few people know is that Walter and I have tried to kindly convince people to work on specific things we believed were important. Such attempts have been largely unsuccessful. The reality is, Walter is the leader and who decides what gets in and what not. It happened to me before to implement stuff that doesn't get in. And that's fine. But Walter, as a leader have to step up and tell where he wants to move so people focus on the stuff that have a chance to be merged. Otherwise the only road is forking, as it happened before. I don't think the Tango split and now Amber are coincidences. There is a lack of leadership in D, and talking with the community. Andrei tried to fill that leader position in the past, and even when I have lots of differences with Andrei, I think he successfully done that with Phobos. But he can't do that with DMD. I agree that Walter doesn't have to do all, but at least he must be convinced there is a value in it, and encourage it and help whoever wants to step up. I, too, think there is value in this approach. Why would I bother to do anything if is very likely that Walter don't want to go that direction and all my work was done for nothing? Been there before. Now I'm more cautious when selecting my battles. One thing I want to do is enshrine a vetting mechanism that would allow Walter and myself to pre-approve enhancement requests. Someone (including us) would submit an enhancement request to Bugzilla, and then Walter and I add the tag preapproved to it. That means an implementation of the request has our approval assuming it has the appropriate quality. That should reduce the cognitive load (am I working for nothing over here?) on the proponent of the feature and would also motivate the proponent to define the feature with reasonable completeness before implementing it. Does anyone know of any mechanism for getting people to do what needs to be done vs what they want to do that doesn't involve paying them? The only long term successes I can point to all involve companies. I do think that D to take the next leap needs to have more (directly or indirectly) payed development. But still that doesn't stop you from having a plan, a tentative roadmap. I agree, and I happen to disagree with Walter's Fog of War theory which I consider somewhat a rationalization of the simple fact he enjoys, like we all do, working under the haphazard of creative flow. Short- and medium-range plans do make sense for us, and we should put them together. Important stuff keeps on remaining not done because at the end of each release cycle we don't have a clear notion of what to work on next. Andrei
Re: D 1.076 and 2.061 release
On Monday, January 07, 2013 08:09:01 Pierre Rouleau wrote: The worst part I see is that bug fixes and new feature introductions are lumped together inside releases. Combined with the fact that the development is not predictable means that if you develop products with D you have to keep updating it. If you get stuck with a bug and wait for the release that fixes it, when that release comes out it could very well bring new language features that break the code that you have already written. It would be nice to have bug fixes separated from new feature introductions by having major and minor releases and branches for these releases. Contributors of a release could backport bug fix in the release they use if that was required by their project using the now old compiler version. Of course I realize that this means more overall work, more people, someone or a set of people in charge of release management, etc... The reality of the matter is that most code breakage comes from bug fixes. New features rarely break much of anything, especially if you're not using them. Having API changes mixed in with bug fixes _can_ pose a problem, but I think that if you really looked into it, you'd find that stuff like UFCS and UDAs and whatnot have resulted in very little (if any) broken code. They may not have worked as well as they should have and have plenty of bugs in their implementation, but code which isn't using them (as code wouldn't be prior to their release) didn't get broken by its introduction. So, while it may be valuable to move to a major/minor release situation, I think that the reality of the matter is that it will have little effect on stability simply because it's bug fixes which break things - either because they fix previously buggy behavior (breaking any code which relied on that behavior) or because regressions are introduced, and while we try hard to catch those, we don't always manage it. And the only thing that I can think of which would do a better job of catching those would be a bettere beta program where the beta is somehow better vetted so that regressions just don't manage to get through (though how we'd get more people to try the beta, I don't know). Major and minor releases will have little effect on stability from the standpoint of the compiler. They could have an effect from the standpoint of API changes, but since we're trying to stop making breaking API changes entirely (or at least make them very rare), a major/minor release model probably won't help much there either. - Jonathan M Davis
Re: D 1.076 and 2.061 release
On Mon, 07 Jan 2013 07:57:07 -0500 Matthew Caron matt.ca...@redlion.net wrote: On 01/05/2013 03:01 AM, Nick Sabalausky wrote: On Thu, 03 Jan 2013 08:20:19 -0500 Matthew Caron matt.ca...@redlion.net wrote: On 01/02/2013 04:18 PM, Walter Bright wrote: Why would you need to? If your mail store is IMAP, just let it rebuild. I don't store email on the server, I store it locally. I gave that up years ago when I ended up with more than one device. Too much did I get that email on my laptop or my desktop? And now with tablet, phone, laptop, desktop, and several kiosk machines around the house (because how else do you watch Firefly whilst loading custom hunting ammunition in the gun room?) and then the device proliferation continues... Turn off Delete email from server ten seconds after downloading it. Either increase it to a sane time period, or disable delete-from-server entirely. Problem solved. Worked fine for me. Isn't this just leave email on the server, which is what I suggested? Of course, what you're saying is use POP with leave on server enabled. A better solution is to just use IMAP. Accessing *sent* messages can be a different story though, but using your email client's setting for BCC outgoing messages to... to send to a special messages I sent address works well enough. Unless you need to use some shitty Fisher-Price email client like the one in iOS, because then you're just fucked. (But if you need to rely on iOS, you'll probably have bigger problems anyway.) Or, you just use IMAP. I don't think you get a local copy of everything with IMAP though, or do you? Windows is only suitable for playing video games, and I'm looking forward to Steam's release for Linux such that I can power on the Wintendo less and less. Steam on Linux? That's like installing hydraulics on a Formula 1 or a rusty nail in a jock strap. Nothing that involves Steam is suitable for playing videogames, whether Win/Lin or anything else. It's view it as an online shop which allows you to buy and install games for your platform. That view is the problem. Steam is *not* merely an online store, Steam (just like iOS) is DRM made cool. And that asshole Newell has managed to brainwash people into actually believing that Steam isn't DRM which is patently absurd. And as a bonus, the Steam client itself is a very poorly written piece of shitware. Slow, buggy, ugly, refuses to close when I click the close button (one of those asinine programs like Skype that has decided Close should mean Minimize to tray and shouldn't even be optionally fixable). Steam is NOT simply a store with community crap. And that fact that so many sheep think that it is, is a big part of what makes Steam and Newell so evil. I have no issue with this. I don't use all the fancy extra social video game crap. I'd be willing to *release* a game, *non-exclusively*, on steam just for the visibility and for the subset of PC gamers that are unfortunately dumb enough to think steam isn't DRM, but that's all steam is good for. Gabe can suck the shit out of my ass for destroying the last non-orwellian gaming platform in existence and essentially turning it into a goddamn iPhone. You don't have to use it, you know. There are other games. GOG.com has a pile, and many of them run just fine under Wine and or DosBOX. I'd like to see them do more Linux, and I hope that the Steam port will be the beginning of more entries on to the platform. GOG.com is mostly for older games (which is great, of course). But most PC games that are being developed and released now are exclusively Steam. Even a lot of retail ones (like Super Meat Boy, as I was irritated to discover after the fact) still require Steam and won't even run without also starting up Steam (which of course must be installed on my system).
Re: D 1.076 and 2.061 release
Andrei Alexandrescu, el 7 de January a las 08:31 me escribiste: Why would I bother to do anything if is very likely that Walter don't want to go that direction and all my work was done for nothing? Been there before. Now I'm more cautious when selecting my battles. One thing I want to do is enshrine a vetting mechanism that would allow Walter and myself to pre-approve enhancement requests. Someone (including us) would submit an enhancement request to Bugzilla, and then Walter and I add the tag preapproved to it. That means an implementation of the request has our approval assuming it has the appropriate quality. That should reduce the cognitive load (am I working for nothing over here?) on the proponent of the feature and would also motivate the proponent to define the feature with reasonable completeness before implementing it. I think that would help a *LOT*. So basically this tag would mean something like: If somebody implement this AND the implementation is complete AND it has good quality, it will be in the next release? If so, that's not too far from roadmap. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- 22% of the time a pizza will arrive faster than an ambulance in Great-Britain
Re: D 1.076 and 2.061 release
On 1/7/13 9:51 AM, Leandro Lucarella wrote: Andrei Alexandrescu, el 7 de January a las 08:31 me escribiste: Why would I bother to do anything if is very likely that Walter don't want to go that direction and all my work was done for nothing? Been there before. Now I'm more cautious when selecting my battles. One thing I want to do is enshrine a vetting mechanism that would allow Walter and myself to pre-approve enhancement requests. Someone (including us) would submit an enhancement request to Bugzilla, and then Walter and I add the tag preapproved to it. That means an implementation of the request has our approval assuming it has the appropriate quality. That should reduce the cognitive load (am I working for nothing over here?) on the proponent of the feature and would also motivate the proponent to define the feature with reasonable completeness before implementing it. I think that would help a *LOT*. So basically this tag would mean something like: If somebody implement this AND the implementation is complete AND it has good quality, it will be in the next release? Yah, that's the idea. If so, that's not too far from roadmap. It's less structured than a roadmap but maybe that's what would make it tenable! Andrei
Re: D 1.076 and 2.061 release
On 2013-01-07 19:29, Andrei Alexandrescu wrote: It's less structured than a roadmap but maybe that's what would make it tenable! It would be like a roadmap without the timeline. That's a lot better than nothing. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 1/7/2013 4:41 AM, David Nadlinger wrote: On Monday, 7 January 2013 at 10:14:54 UTC, Robert Clipsham wrote: Though I believe it will probably fail with older OS X versions which don't have TLS support. Yes, it is not supported by linker and dyld versions shipping with OS X 10.7. This is also the reason why LDC 2 only supports OS X 10.7+, as LLVM does not implement a workaround for older versions (although implementing one up to the point where it is good enough for D should be doable without too much effort). It's pretty clear where we'll be going with this. We'll be abandoning OS X versions older than 10.7. I don't know enough about the Mac ecosystem to know when we can pull the plug on that.
Re: D 1.076 and 2.061 release
Andrei Alexandrescu, el 7 de January a las 08:31 me escribiste: One thing I want to do is enshrine a vetting mechanism that would allow Walter and myself to pre-approve enhancement requests. Someone (including us) would submit an enhancement request to Bugzilla, and then Walter and I add the tag preapproved to it. That means an implementation of the request has our approval assuming it has the appropriate quality. BTW, I wouldn't mind if you like to try this out with issue 7044 (see the pull request for more comments), which is really annoying us at work but I never got to fix because the lack of feedback (a perfect example of somebody willing, almost craving, to fix something and not doing it because of the lack of feedback). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Soy como una mosca, parada en el agua. Y vos sos un transatlántico, querés nadar a mi lado. Y me estás ahogando.
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-07 20:54, Walter Bright wrote: It's pretty clear where we'll be going with this. We'll be abandoning OS X versions older than 10.7. Would it be a bad idea and do what the dynamic linker does in the druntime to support TLS? This would make it work on Mac OS X 10.6. I don't know enough about the Mac ecosystem to know when we can pull the plug on that. Me neither. Mac OS X 10.6 was released August 28, 2009. There have been two major releases since then. -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On 1/7/2013 8:31 AM, Andrei Alexandrescu wrote: Walter can write a roadmap, nobody will listen to him. One thing that few people know is that Walter and I have tried to kindly convince people to work on specific things we believed were important. Such attempts have been largely unsuccessful. True. Another thing that's been a bit frustrating to me is people regularly ask me (or the ng) what should I work on? I provide a list, and they go do something else. The reality is that, in a volunteer community, people work on what interests themselves. Finding ways to work successfully with that dynamic is the big challenge we face.
Re: D 1.076 and 2.061 release
Am Mon, 07 Jan 2013 19:39:52 +0100 schrieb Jacob Carlborg d...@me.com: On 2013-01-07 19:29, Andrei Alexandrescu wrote: It's less structured than a roadmap but maybe that's what would make it tenable! It would be like a roadmap without the timeline. That's a lot better than nothing. aka TO-DO list
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On Monday, 7 January 2013 at 19:54:54 UTC, Walter Bright wrote: On 1/7/2013 4:41 AM, David Nadlinger wrote: Yes, it is not supported by linker and dyld versions shipping with OS X 10.7. Sorry, I wrote my last post in a hurry – I suppose it's clear anyway, but that should have been »by the linker and dyld versions Apple shipped with OS X prior to 10.7«. This is also the reason why LDC 2 only supports OS X 10.7+, as LLVM does not implement a workaround for older versions (although implementing one up to the point where it is good enough for D should be doable without too much effort). It's pretty clear where we'll be going with this. We'll be abandoning OS X versions older than 10.7. I don't know enough about the Mac ecosystem to know when we can pull the plug on that. I don't know the current relative market share of the different OS X versions on top of my head either, but as we were getting a couple of bug reports from people who had tried to use LDC 2 on 10.6 (before we figured out that LLVM doesn't emulate TLS there), I guess it's too soon to drop support for it still. However, when finally somebody finds the time to implement shared library support in the runtime, the situation might have already changed anyway. David
Re: D 1.076 and 2.061 release
On 1/7/2013 11:40 AM, Leandro Lucarella wrote: Andrei Alexandrescu, el 7 de January a las 08:31 me escribiste: One thing I want to do is enshrine a vetting mechanism that would allow Walter and myself to pre-approve enhancement requests. Someone (including us) would submit an enhancement request to Bugzilla, and then Walter and I add the tag preapproved to it. That means an implementation of the request has our approval assuming it has the appropriate quality. BTW, I wouldn't mind if you like to try this out with issue 7044 (see the pull request for more comments), which is really annoying us at work but I never got to fix because the lack of feedback (a perfect example of somebody willing, almost craving, to fix something and not doing it because of the lack of feedback). At this point, reading the discussions in the links, I don't know just what the latest proposal is. https://github.com/D-Programming-Language/dmd/pull/497 http://d.puremagic.com/issues/show_bug.cgi?id=7044 http://forum.dlang.org/thread/mailman.1605.1334108859.4860.digitalmar...@puremagic.com
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 1/7/2013 12:12 PM, Jacob Carlborg wrote: On 2013-01-07 20:54, Walter Bright wrote: It's pretty clear where we'll be going with this. We'll be abandoning OS X versions older than 10.7. Would it be a bad idea and do what the dynamic linker does in the druntime to support TLS? This would make it work on Mac OS X 10.6. I don't think it's worth the effort. We don't have the resources to expend on platforms that are already obsolete. I don't know enough about the Mac ecosystem to know when we can pull the plug on that. Me neither. Mac OS X 10.6 was released August 28, 2009. There have been two major releases since then. Sounds like we can pull the plug.
Re: D 1.076 and 2.061 release
On Thu, 03 Jan 2013 17:08:58 +0100
deadalnix deadal...@gmail.com wrote:
However, it is just to discover that this do not work :
struct Bar {}
auto foo(ref Bar bar) {}
foo(Bar()); // Now this is an error !
I still have code broken all over the place.
IIRC, they tried to include this change in 2.060 (or was it 2.059?),
but due to the major problems it causes, and the fact that it *does*
make sense to use a temporary as an lvalue if you don't intend to use
it again afterwords, there was a big discussion about it on the beta
list and it was ultimately nixed. I'm disappointed to see that it snuck
back.
Re: D 1.076 and 2.061 release
On 1/7/2013 3:19 PM, Nick Sabalausky wrote:
On Thu, 03 Jan 2013 17:08:58 +0100
deadalnix deadal...@gmail.com wrote:
However, it is just to discover that this do not work :
struct Bar {}
auto foo(ref Bar bar) {}
foo(Bar()); // Now this is an error !
I still have code broken all over the place.
IIRC, they tried to include this change in 2.060 (or was it 2.059?),
but due to the major problems it causes, and the fact that it *does*
make sense to use a temporary as an lvalue if you don't intend to use
it again afterwords, there was a big discussion about it on the beta
list and it was ultimately nixed. I'm disappointed to see that it snuck
back.
Well, fixing the rvalue ref problem is still on the front burner.
Re: D 1.076 and 2.061 release
On 1/7/13 12:39 PM, Johannes Pfau wrote: Am Mon, 07 Jan 2013 19:39:52 +0100 schrieb Jacob Carlborgd...@me.com: On 2013-01-07 19:29, Andrei Alexandrescu wrote: It's less structured than a roadmap but maybe that's what would make it tenable! It would be like a roadmap without the timeline. That's a lot better than nothing. aka TO-DO list unprioritized
Re: D 1.076 and 2.061 release
On 13-01-07 9:12 AM, Matthew Caron wrote: On 01/07/2013 08:09 AM, Pierre Rouleau wrote: It would be nice to have bug fixes separated from new feature introductions by having major and minor releases and branches for these releases. Contributors of a release could backport bug fix in the release they use if that was required by their project using the now old compiler version. Of course I realize that this means more overall work, more people, someone or a set of people in charge of release management, etc... I also think that you'd be hard-pressed to find anyone who does development like that, proprietary or open source. It's not uncommon to have bugfix only releases, but having a new features release that doesn't fix any bugs is, in my experience, unheard of. I agree that feature releases mostly also contain bug fixes. I should have said, and I was thinking about proposing a process where minor releases that would only include bug fixes, and where major releases would mainly introduce new features but would also include some bug fixes. At work this is exactly what we do. And today, at work, I was just in a meeting evaluating bugs to identify bugs that will be fixed in a release of our product that will only contain bug fixes. The fixes that are selected where selected based on their severity, the impact they have on end-users and the time it takes to fix them. And maybe an alpha process suggested by Jonathan M. Davis is a better idea. Also, I'd be STRONGLY against it, because I have a fix bugs first mentality, and if you find a bug while implementing a new feature, it should be fixed. In my work I also have a bug-fix first mentality and I push for that everyday. I strongly agree with that. All I was suggesting (or checking if this is the way this group handles it) is whether bug fixes are isolated from feature implementations (and I assume they are since they are separate Bugzilla tickets). And at work, when a new feature is implemented and a bug is found during the process of developing that feature the first thing that is done is to create a _separate_ bug report ticket (separate from the ticket that request the introduction of the new feature or enhancement) to identify the presence of that bug if that bug affects release code. The releases the bug affects are identified and typically within a week, the bug is scrubbed in a meeting where people with different roles attend. The priority and severity of the bug is discussed, and the release version for the fix is identified in a forecast. Developer(s) have to estimate the time it will take to fix the bug (as is done for every ticket in our bug tracking system (bug fix, feature implementation, enhancement, etc...). A test case is also created for the bug since it was an escape from the test plan/integration test/unit test side of things. The bug is fixed, regression tested and the new feature is implemented on top of the bug fix. The sequence of events may differ depending on how we want to handle things with the VCS we use and the moment of the event respective to the product release plan. I am not suggesting to not fix a bug found when a new feature is introduced. I was trying to propose something that would help predictability and stability. Now I understand that I am comparing a commercial product development with an open source project here. But I am also comparing what a user *sees* from other projects that are used where I work; the PR part, the marketing material that help sells the product to people. When I look at Python and Erlang for instance, those two projects seem, I say seem (from the user's perspective) to provide more information to the user's base in terms of those two criteria of predictability and stability simply because of the various documents provided and release strategies one can see from the evolution of their projects. It possibly is only a matter of perception and Public Relations but D2 first release was done June 17, 2007 which is over 5 years and six months ago. I see nothing in the release version number that gives any outsider a vision of the stability of D2 or it's evolution milestone-wise. The first release number was D 2.000 and we are 66 months later at version 2.061. That's about a release a month. How can an outside user see the major milestones in those 5 years and a half? I imagine that some of you guys remember what were the significant releases, you have been living with it for those last 66 months. But how can you convince potential new users to use it in projects where manpower is also limited and continuous updates may not be possible? How can they see that its stabilizing? How many more releases may affect the development of products? In June 2007 I was using Python 2.5.1, Python 2.7.3 and 3.3.0 are the two official releases now. All of these versions have had bug fix (and security) releases independently of the
Re: D 1.076 and 2.061 release
On Monday, 7 January 2013 at 01:29:02 UTC, Brad Roberts wrote: Does anyone know of any mechanism for getting people to do what needs to be done vs what they want to do that doesn't involve paying them? The only long term successes I can point to all involve companies. You cannot achieve this without actually employing people. People on their free time ill work on whatever they want, and hopefully !
Re: D 1.076 and 2.061 release
On Mon, 07 Jan 2013 17:18:11 -0800
Walter Bright newshou...@digitalmars.com wrote:
On 1/7/2013 3:19 PM, Nick Sabalausky wrote:
On Thu, 03 Jan 2013 17:08:58 +0100
deadalnix deadal...@gmail.com wrote:
However, it is just to discover that this do not work :
struct Bar {}
auto foo(ref Bar bar) {}
foo(Bar()); // Now this is an error !
I still have code broken all over the place.
IIRC, they tried to include this change in 2.060 (or was it 2.059?),
but due to the major problems it causes, and the fact that it *does*
make sense to use a temporary as an lvalue if you don't intend to
use it again afterwords, there was a big discussion about it on the
beta list and it was ultimately nixed. I'm disappointed to see that
it snuck back.
Well, fixing the rvalue ref problem is still on the front burner.
Wait, so are you saying that the above code which stopped working in
2.061 will start working again in a later version?
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-07 21:30, David Nadlinger wrote: I don't know the current relative market share of the different OS X versions on top of my head either, but as we were getting a couple of bug reports from people who had tried to use LDC 2 on 10.6 (before we figured out that LLVM doesn't emulate TLS there), I guess it's too soon to drop support for it still. However, when finally somebody finds the time to implement shared library support in the runtime, the situation might have already changed anyway. In general Apple tries to push you to have always have the latest software. There are very few reasons to not have the latest OS, they are pretty darn cheap. -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On 2013-01-06 05:19, Pierre Rouleau wrote: I know. What I'm trying to see is what is the development *plan* for D2? Something that would identify the future features to be implemented and the planned targets/milestones for them. I would assume that I am not alone in watching the D language evolution, would like to get people to start using it at my work place, and would like to know what the plan is be so we can better convince other people to invest time into it. I've requested that for years, still nothing. Well that only thing I've seen is that the change log used to say Under Construction: Shared libraries for Linux. Still does for D1. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On Sun, 2013-01-06 at 12:08 +0100, Jacob Carlborg wrote: […] I've requested that for years, still nothing. Well that only thing I've seen is that the change log used to say Under Construction: Shared libraries for Linux. Still does for D1. I know that the Go folk are of the view that shared libraries are an abomination and all should be expunged from the universe; all Go executables are statically linked. Of course Linux, OS X, Solaris and AIX depend on shared libraries, but maybe Google think they can change the world? If D is to compete with C, C++ and JVM-based languages then it has to have a position on shared libraries other than we think it might be a good idea, but no-one has bothered to do anything about it to date. Either is is a good idea or it isn't. If it is a good idea then shared libraries should be in 2.062. If it isn't then a clear statement of won't fix and D is a static compile only language, like Go is needed. Of course then the issue is How to link to shared libraries?. Go has some difficulties here but the put a shim in place to deal with it. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Managing email [ was Re: D 1.076 and 2.061 release ]
On Sat, 2013-01-05 at 12:57 -0500, Nick Sabalausky wrote: […] That is a fair point. OTOH, Google (by their very nature) is dead-set on things like making sure the web gets treated as an application platform and getting people to store their personal data on Google's private cloud (a moronic and unnecessary renaming of the works hosted and internet, but that's a separate rant). Interesting that Google are changing their terms of service so that (indirectly) Windows 8 RT users have to pay to access GAE. […] Also I think another part of what makes Google (and Apple) so dangerous is that unlike MS, most people are still hailing them as wonderful and benevolent companies. The blinkered vision of Apple-heads is bizarre, but a great boon for Apple's bottom line. Unlike Amazon, Starbucks, Google, and Microsoft, Apple appear to be getting away with anti-competition practices with equanimity. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D 1.076 and 2.061 release
On Sunday, 6 January 2013 at 04:19:53 UTC, Pierre Rouleau wrote: I know. What I'm trying to see is what is the development *plan* for D2? Something that would identify the future features to be implemented and the planned targets/milestones for them. I would assume that I am not alone in watching the D language evolution, would like to get people to start using it at my work place, and would like to know what the plan is be so we can better convince other people to invest time into it. /Pierre IUP have a good road map: http://www.tecgraf.puc-rio.br/iup/. I really appreciate that because you can say OK, in April they're gonna have that feature, good! I agree that it is about time D left the dark corner of yeah I have heard of it, but don't know what it is. But it is hard to convince people of even looking at D, when other technologies are embraced and backed up by big companies with their huge PR networks.
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-06 12:27, Russel Winder wrote: I know that the Go folk are of the view that shared libraries are an abomination and all should be expunged from the universe; all Go executables are statically linked. Of course Linux, OS X, Solaris and AIX depend on shared libraries, but maybe Google think they can change the world? I'm pretty sure that they're linking with the dynamic libraries when linking with systems libraries. As you say, they don't have much of a choice. I guess they don't create new dynamic libraries with Go. If D is to compete with C, C++ and JVM-based languages then it has to have a position on shared libraries other than we think it might be a good idea, but no-one has bothered to do anything about it to date. Either is is a good idea or it isn't. If it is a good idea then shared libraries should be in 2.062. If it isn't then a clear statement of won't fix and D is a static compile only language, like Go is needed. I completely agree. We _need_ dynamic libraries. But the problem is that someone just have to do it and Walter doesn't seem to be in a rush to implement it. Of course then the issue is How to link to shared libraries?. Go has some difficulties here but the put a shim in place to deal with it. What would be the issue of linking with dynamic libraries? We can already link with C dynamic libraries without any problem. -- /Jacob Carlborg
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On Sun, 2013-01-06 at 12:56 +0100, Jacob Carlborg wrote: […] I completely agree. We _need_ dynamic libraries. But the problem is that someone just have to do it and Walter doesn't seem to be in a rush to implement it. Is Walter the only person who can implement this? I cannot commit to doing anything on this in the foreseeable short-, to medium-term future, but is there anyone who can? Of course then the issue is How to link to shared libraries?. Go has some difficulties here but the put a shim in place to deal with it. What would be the issue of linking with dynamic libraries? We can already link with C dynamic libraries without any problem. For the Go folks, it is all about issues with garbage collection and thread management, they need to perform contortions to deal with C and C ++ codes. I recollect it is to do with the way Go handles execution stacks. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-06 13:20, Russel Winder wrote: Is Walter the only person who can implement this? I cannot commit to doing anything on this in the foreseeable short-, to medium-term future, but is there anyone who can? No, absolutely not. But no one has been willing to do it yet. Martin Nowak seems to be closest to have something: https://github.com/dawgfoto/druntime/tree/SharedRuntime I have tried myself a couple of times but there has always been some issue with the compiler that needs to be fixed or implemented. I have never been able to figure out how to do that. For example, on Mac OS X where DMD implements its own TLS the compiler will most likely need to change somewhat. https://github.com/D-Programming-Language/druntime/blob/master/src/core/thread.d#L4549 In the above code we need to have access to which image that address (p) to the belongs to. For the Go folks, it is all about issues with garbage collection and thread management, they need to perform contortions to deal with C and C ++ codes. I recollect it is to do with the way Go handles execution stacks. I see. -- /Jacob Carlborg
Re: Managing email [ was Re: D 1.076 and 2.061 release ]
On Sun, 06 Jan 2013 11:32:28 + Russel Winder rus...@winder.org.uk wrote: On Sat, 2013-01-05 at 12:57 -0500, Nick Sabalausky wrote: […] Also I think another part of what makes Google (and Apple) so dangerous is that unlike MS, most people are still hailing them as wonderful and benevolent companies. The blinkered vision of Apple-heads is bizarre, but a great boon for Apple's bottom line. Unlike Amazon, Starbucks, Google, and Microsoft, Apple appear to be getting away with anti-competition practices with equanimity. Yea, I've noticed the same thing :( People are so enamored with their iDevices, that they think Apple can do no wrong. At least that's the only explanation I can think of. Like browsers, for instance. When Microsoft had their browser merely uninstallable and set as the *initial* default browser, the DOJ went apeshit, nevermind the fact that MS did *nothing* to prevent people from downloading and using competing browsers. Apple, OTOH, does the same, except they also PROHIBIT competing browsers (only the shell around the webview widget can be changed), and yet as long as Apple's the one doing it nobody seems to mind. Apple's has been known to do the same for other software besides browsers as well. And then Jobs's personal grudge against Android (still unfortunately being carried out in full by the new regime, puppeted by a ghost apparently), in particular the irrational lawsuit against Samsung where Apple is abusing software/design patents to go on the offensive (not just using them defensively). The judge, even as an Apple user, made it clear that Apple had basically no standing, and yet those goddamn jururs irrationally ruled in favor of Apple anyway.
Re: D 1.076 and 2.061 release
Pierre Rouleau, el 5 de January a las 23:19 me escribiste: On 13-01-05 4:01 PM, Walter Bright wrote: On 1/5/2013 10:06 AM, Pierre Rouleau wrote: On 13-01-05 5:39 AM, Walter Bright wrote: On 1/5/2013 1:30 AM, Pierre Rouleau wrote: I noticed that D 2.062 has no new features. What would it take to remove the link to New/Changed Features on that version since there are none? There will be. Do you have a plan of what they will be and a target date for the next release? We've never had a release that didn't have some new/changed features. I know. What I'm trying to see is what is the development *plan* for D2? Plan? hahaha, you must be new around here :P -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
Re: D 1.076 and 2.061 release
Walter Bright, el 4 de January a las 10:58 me escribiste: On 1/4/2013 6:02 AM, Leandro Lucarella wrote: Walter Bright, el 3 de January a las 23:03 me escribiste: On 1/3/2013 9:49 PM, Jonathan M Davis wrote: but other lines like $(LI std.string: $(RED The implementations of std.string.format and string.sformat have been replaced with improved implementations which conform to writef. In some, rare cases, this will break code. Please see the documentation for std.string.format and std.string.sformat for details.)) Yes, you can put this in as the bugzilla title, though I'd tighten it up a little. Are you being serious? Do you really think this would be useful for the user? That the user will be able to spot that particular comment among hundreds of bugs in a bugzilla search query result? It's not hundreds. It's the new/changed list, which is rather short. It was a little longer this time because it's been several months. Usually, it's just a handful. True, but sometimes bugfixes needs important news too, if some code use to compile when it shouldn't. What would you do with that? Add another bug and tag it as a enhancement? Makes no sense to me, is prostituting the tool and making the users go to a prostitute (no offense to prostitutes!). Why settle with an option that's clearly worse for the users? Is really that hard to acknowledge that release notes are better than doing that? I can understand if you see problems on keeping up to date the release notes, but I can't believe that anyone can think is plain better to user bugzilla instead (for the user POV at least). Can we at least agree on that and then see if is feasible to have good and up to date release notes? But we've done that before. It was not working. You are mixing everything together! What you did before is manually adding **all** the changes to the changelog. Again (and again, and again) I'm suggesting keep the automatic listings in bugzilla but adding release notes too, some more high level text explaining users the key changes in a new release. But I guess we are arguing for no reason now because you already said that was OK. So now, my only request is for the reviewers to try to pay more attention to pull request and stop merging them until they also update the documentation and add release notes when appropriate. That should improve the situation a lot and doesn't generate a lot of new work, just more attention when reviewing and telling the contributor what's missing for the pull request to be merged. Then the work of writing the release notes is distributed among all the users. I understand that, but I don't think that work should be optional and only done if somebody feels like. Every pull request should include proper documentation update. Can we try to focus on that for the next release? We are all volunteers. You are welcome to help out with this. I know that (and honestly, I think you know that I know). I already fix my incomplete pull request by updating the documentation and the release notes. I try to help with everything I can. And there's organization too. We are all volunteers but there some more experienced volunteers and some with extra responsibilities. I just can't reject pull requests because I can't merge them, and I'm not experienced enough to precisely tell people exactly what pull requests are missing. I'll try to pay more attention myself too and give feedback when I see a pull request that I think is incomplete. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- El techo de mi cuarto lleno de estrellas
Re: D 1.076 and 2.061 release
Pierre Rouleau, el 4 de January a las 11:59 me escribiste: On 13-01-04 3:45 AM, Walter Bright wrote: On 1/4/2013 12:16 AM, eles wrote: Two concrete examples: http://d.puremagic.com/issues/show_bug.cgi?id=5992 is described in the list as: Phobos Win64 - D2 ; At least, change its title to something more human, like Win64 alpha has been released with working Phobos. (yes, that's exactly Don's comment, but at the end of the discussion). http://d.puremagic.com/issues/show_bug.cgi?id=5269 is described as: version(assert). Only if you read the discussion you understand that version(unittest) that allows setup code for assertions to run when assertions are enabled and be compiled out when assertions are disabled was implemented. It is very different thing to see version(assert) and reading a meaningful description of it... I understand and agree. And, as I posted previously, anyone can fix the issue titles. I've already fixed a few. Don't you think a process that requires reviewing these titles *before* the actual software release announcement posting would help? Yeah, that's another issue too. Having mutating release notes is awful and a PR disaster. Users only see the changelog once, assuming is immutable, because one thinks that releases are immutable and complete (those are very fundamental properties of a release, otherwise is a preview or a snapshot). That's another thing that I think is important to address eventually. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- All evidence has been buried All tapes have been erased But your footsteps give you away So you're backtracking
Re: D 1.076 and 2.061 release
On 13-01-06 11:43 AM, Leandro Lucarella wrote: Pierre Rouleau, el 5 de January a las 23:19 me escribiste: On 13-01-05 4:01 PM, Walter Bright wrote: On 1/5/2013 10:06 AM, Pierre Rouleau wrote: On 13-01-05 5:39 AM, Walter Bright wrote: On 1/5/2013 1:30 AM, Pierre Rouleau wrote: I noticed that D 2.062 has no new features. What would it take to remove the link to New/Changed Features on that version since there are none? There will be. Do you have a plan of what they will be and a target date for the next release? We've never had a release that didn't have some new/changed features. I know. What I'm trying to see is what is the development *plan* for D2? Plan? hahaha, you must be new around here :P My wife keeps telling me to be more optimistic than pessimistic, although I think being pessimist for the short term for the goal of being optimistic for the longer term has always worked for me. That's why I was proposing a gentle first step of keeping a running list of future ideas inside a file that could be debated from a specific discussion in this mailing list or another. -- /Pierre Rouleau
Re: D 1.076 and 2.061 release
On 13-01-06 11:40 AM, Leandro Lucarella wrote: Pierre Rouleau, el 4 de January a las 11:59 me escribiste: On 13-01-04 3:45 AM, Walter Bright wrote: On 1/4/2013 12:16 AM, eles wrote: Two concrete examples: http://d.puremagic.com/issues/show_bug.cgi?id=5992 is described in the list as: Phobos Win64 - D2 ; At least, change its title to something more human, like Win64 alpha has been released with working Phobos. (yes, that's exactly Don's comment, but at the end of the discussion). http://d.puremagic.com/issues/show_bug.cgi?id=5269 is described as: version(assert). Only if you read the discussion you understand that version(unittest) that allows setup code for assertions to run when assertions are enabled and be compiled out when assertions are disabled was implemented. It is very different thing to see version(assert) and reading a meaningful description of it... I understand and agree. And, as I posted previously, anyone can fix the issue titles. I've already fixed a few. Don't you think a process that requires reviewing these titles *before* the actual software release announcement posting would help? Yeah, that's another issue too. Having mutating release notes is awful and a PR disaster. Users only see the changelog once, assuming is immutable, because one thinks that releases are immutable and complete (those are very fundamental properties of a release, otherwise is a preview or a snapshot). That's another thing that I think is important to address eventually. Currently, from the outside, I get the impression that the D language is a great language but a language for its developers only. Although it might be OK while the language is in its infancy, I would hope that D(2) would come out of that state now that several books exist, that the standard library seems in pretty good shape, that several other libraries, frameworks and tools exist. To me, what seems missing is some wrapper around all of this that would make D(2) much more attractive for organizations like the one I work for. I am personally very interested in D(2) and have already done discussions inside my work place, but without that sort of visible infrastructure I doubt I would be able to convince anyone to adopt D(2) for any product-based development (and even for some internal tools). So, again, this is why I was asking whether you guys thought it would be a good idea for me to start a discussion somewhere in one of the D mailing lists, to gather the list of new features planned for the future (unless something like that already exists, but I did not find it) and get something going to create a running list. -- /Pierre Rouleau
Re: Managing email [ was Re: D 1.076 and 2.061 release ]
On Sun, 2013-01-06 at 11:42 -0500, Nick Sabalausky wrote: […] Yea, I've noticed the same thing :( People are so enamored with their iDevices, that they think Apple can do no wrong. At least that's the only explanation I can think of. Perhaps Apple employees visit everyone who buys an Apple device and secretly implants the chip in the purchasers head? ;-) Personally I think Apple laptop hardware is great, the software however leaves a lot to be desired. Like browsers, for instance. When Microsoft had their browser merely uninstallable and set as the *initial* default browser, the DOJ went apeshit, nevermind the fact that MS did *nothing* to prevent people from downloading and using competing browsers. Apple, OTOH, does the same, except they also PROHIBIT competing browsers (only the shell around the webview widget can be changed), and yet as long as Apple's the one doing it nobody seems to mind. Apple's has been known to do the same for other software besides browsers as well. Perchance Apple have simply paid off the DOJ. Or mayhap the Apple employees and their chip implantation is more successful than we know? And then Jobs's personal grudge against Android (still unfortunately being carried out in full by the new regime, puppeted by a ghost apparently), in particular the irrational lawsuit against Samsung where Apple is abusing software/design patents to go on the offensive (not just using them defensively). The judge, even as an Apple user, made it clear that Apple had basically no standing, and yet those goddamn jururs irrationally ruled in favor of Apple anyway. The result in the case was basically a forgone conclusion: USA company domiciled within a couple of miles of all the jurors vs. a South Korean company. No contest, whatever the actual rights and wrongs. Should have been a bench trial from the outset. Hopefully everyone is responding to the USPTO regarding software patents. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D 1.076 and 2.061 release
On Sun, Jan 6, 2013 at 6:56 PM, Pierre Rouleau prouleau...@gmail.comwrote: So, again, this is why I was asking whether you guys thought it would be a good idea for me to start a discussion somewhere in one of the D mailing lists, to gather the list of new features planned for the future (unless something like that already exists, but I did not find it) and get something going to create a running list. You could start by a thread for 2.061: what's new, in a human-readable format. I'd say: - 64 bits for Windows - User-Defined Attributes (with a link to the incoming documentation). These two themes justify a new release by themselves. Window 64 was clearly an 'official' goal. UDA were just a momentary burst of coding from Walter :) As for the future, I fear you'll get 'generic' declarations concerning const/immutable/shared, but halas not from the guys who actually do the real work. Then everyone and their dog will flock to present their pet bug. The process is still a bit amateurish, but it's coming together. Now that 64 bits Windows is out, I guess the next release will focus on killing the related bugs. As a token of goodwill, I'm willing to write a short text describing the new release and plans for the next ones, except I don't even *know* what the new release brought or what the next one will be.
Re: D 1.076 and 2.061 release
On 13-01-03 1:37 PM, Johannes Pfau wrote: Am Thu, 03 Jan 2013 17:43:03 +0100 schrieb bearophile bearophileh...@lycos.com: I agree. But we should probably start shipping minor releases. +1 That would also enhance the visibility of the new language features in major releases for the end-users. -- /Pierre Rouleau
Re: D 1.076 and 2.061 release
On 13-01-06 2:52 PM, Philippe Sigaud wrote: On Sun, Jan 6, 2013 at 6:56 PM, Pierre Rouleau prouleau...@gmail.com mailto:prouleau...@gmail.com wrote: So, again, this is why I was asking whether you guys thought it would be a good idea for me to start a discussion somewhere in one of the D mailing lists, to gather the list of new features planned for the future (unless something like that already exists, but I did not find it) and get something going to create a running list. You could start by a thread for 2.061: what's new, in a human-readable format. Should I post it in D.announce or somewhere else? -- /Pierre Rouleau
Re: D 1.076 and 2.061 release
The main newsgroup. Normally, D.announce should not contain this kind of conversation. It's supposed to be a low-bandwidth list for announcing projects and releases.
Re: D 1.076 and 2.061 release
On 13-01-06 2:52 PM, Philippe Sigaud wrote: As a token of goodwill, I'm willing to write a short text describing the new release and plans for the next ones, except I don't even *know* what the new release brought or what the next one will be. I, for one, would be very interested. Even if the info gets updated later by people that notice errors or omissions in the information. If you did that, and either stored it inside a file stored in the repo or posted in the mailing list, it would be a starting point, No? Info on what is coming in the future as opposed to what has already been done would be a good point to start IMO, because the comments that might be drawn out of this activity may increase the overall awareness and push for an eventual procedure. -- /Pierre Rouleau
Re: D 1.076 and 2.061 release
On 2013-01-06 16:20, Pierre Rouleau wrote: Is there a file somewhere that lists all requested features, under development features? Or the various mailing lists the only source of information? There is some information at the wiki, the DIP's. -- /Jacob Carlborg
Re: Managing email [ was Re: D 1.076 and 2.061 release ]
On Sun, 06 Jan 2013 19:25:48 + Russel Winder rus...@winder.org.uk wrote: On Sun, 2013-01-06 at 11:42 -0500, Nick Sabalausky wrote: […] Yea, I've noticed the same thing :( People are so enamored with their iDevices, that they think Apple can do no wrong. At least that's the only explanation I can think of. Perhaps Apple employees visit everyone who buys an Apple device and secretly implants the chip in the purchasers head? ;-) Secretly? It's part of the eyePhone's basic user instructions! Matt Groening even showed Fry and Leela installing theirs. ;) Personally I think Apple laptop hardware is great, Is it? I wouldn't know. I know the earlier iPods had a lot of reliability problems. The one thing about modern Apple laptops that does get me though is that I just don't get the compulsive obsession with thinness. Yea, thin is fine (up to the point where I worry about accidentally snapping it), but I'd take a roomy HDD, optical drive, lots of connection ports, and good price over Gee whiz! Look how thin it is! anyway. I could ditch the traditional HDD/optical drives for the sake of battery life on a swivel-touchscreen netbook. But even then, I see very minimal benefit to extra thinness. the software however leaves a lot to be desired. I could go on and on about apple software, but I've done so enough already, and I'll refrain now ;) Like browsers, for instance. When Microsoft had their browser merely uninstallable and set as the *initial* default browser, the DOJ went apeshit, nevermind the fact that MS did *nothing* to prevent people from downloading and using competing browsers. Apple, OTOH, does the same, except they also PROHIBIT competing browsers (only the shell around the webview widget can be changed), and yet as long as Apple's the one doing it nobody seems to mind. Apple's has been known to do the same for other software besides browsers as well. Perchance Apple have simply paid off the DOJ. Or mayhap the Apple employees and their chip implantation is more successful than we know? Heh :) And then Jobs's personal grudge against Android (still unfortunately being carried out in full by the new regime, puppeted by a ghost apparently), in particular the irrational lawsuit against Samsung where Apple is abusing software/design patents to go on the offensive (not just using them defensively). The judge, even as an Apple user, made it clear that Apple had basically no standing, and yet those goddamn jururs irrationally ruled in favor of Apple anyway. The result in the case was basically a forgone conclusion: USA company domiciled within a couple of miles of all the jurors vs. a South Korean company. No contest, whatever the actual rights and wrongs. Should have been a bench trial from the outset. Good points. Hopefully everyone is responding to the USPTO regarding software patents. Does the USPTO even acknowledge the _existence_ of anyone who isn't a corporate bigwig? Let alone pay attention to anything they say? I think corruption, I think USPTO. Not joking about that, either.
