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-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-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 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! :-)
Re: D 1.076 and 2.061 release
On Thursday, January 10, 2013 23:37:29 Pierre Rouleau wrote: > 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. People who don't want javascript, disable it, and it's my understanding that you can set up a page to provide alternate content if javascript is disabled, so if we want to use javascript but are worried about people like Nick freaking out about it, that's how I'd expect that we'd deal with it. - Jonathan M Davis
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 Thursday, 10 January 2013 at 18:30:10 UTC, 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? 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 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.
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: 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/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: 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 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 Wed, 9 Jan 2013 12:54:54 -0500 Nick Sabalausky 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 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: 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 : push rbp
0x0025 : movrbp,rsp
0x0028 : movrdi,QWORD
PTR [rip+0x0]# 0x30
0x0030 : call 0x35
0x0035 : moveax,DWORD
PTR [rax]
0x0037 :poprbp
0x0038 :ret
Re: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-09 17:16, David Nadlinger wrote: 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 I've already found that code. That's where I got my information from in my previous post. -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On Wed, 09 Jan 2013 01:09:21 -0800 Jonathan M Davis 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:
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: 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: D 1.076 and 2.061 release
On Wed, Jan 9, 2013 at 9:52 AM, Andrei Alexandrescu 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 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: 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 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 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: 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: 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
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 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 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: 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: 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: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-07 23:04, Walter Bright wrote: 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. I've been trying to see if it's possible to get the market share for Mac OS X 10.6. This site claims it has just below 30% : http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomb=*2 -- /Jacob Carlborg
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: D 1.076 and 2.061 release
On Tue, 08 Jan 2013 07:11:30 +0100
"deadalnix" 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 wrote:
> >
> >> On 1/7/2013 3:19 PM, Nick Sabalausky wrote:
> >> > On Thu, 03 Jan 2013 17:08:58 +0100
> >> > "deadalnix" 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 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 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 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: 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 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: 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: 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: 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
On 13-01-08 3:57 AM, Walter Bright wrote: 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 Good point. Probably the most important. -- /Pierre Rouleau
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: 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: 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: 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: 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: Shared Libraries [was Re: D 1.076 and 2.061 release]
On 2013-01-07 21:17, Russel Winder wrote: As far as I am aware white MacBooks cannot run 10.7 and 10.8, but are stuck at 10.6 I'm running 10.7 on my white MacBook from 2006. -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On Tuesday, 8 January 2013 at 05:29:15 UTC, Nick Sabalausky wrote:
On Mon, 07 Jan 2013 17:18:11 -0800
Walter Bright wrote:
On 1/7/2013 3:19 PM, Nick Sabalausky wrote:
> On Thu, 03 Jan 2013 17:08:58 +0100
> "deadalnix" 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).
Re: D 1.076 and 2.061 release
On Mon, 07 Jan 2013 17:18:11 -0800
Walter Bright wrote:
> On 1/7/2013 3:19 PM, Nick Sabalausky wrote:
> > On Thu, 03 Jan 2013 17:08:58 +0100
> > "deadalnix" 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: 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 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 1/7/13 12:39 PM, Johannes Pfau wrote: Am Mon, 07 Jan 2013 19:39:52 +0100 schrieb Jacob Carlborg: 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 1/7/2013 3:19 PM, Nick Sabalausky wrote:
On Thu, 03 Jan 2013 17:08:58 +0100
"deadalnix" 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 Thu, 03 Jan 2013 17:08:58 +0100
"deadalnix" 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: 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 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 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
Am Mon, 07 Jan 2013 19:39:52 +0100 schrieb Jacob Carlborg : > 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: 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: Shared Libraries [was Re: D 1.076 and 2.061 release]
On Mon, 2013-01-07 at 21:12 +0100, 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 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. As far as I am aware white MacBooks cannot run 10.7 and 10.8, but are stuck at 10.6 -- 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-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
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 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
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: 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
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 Mon, 07 Jan 2013 07:57:07 -0500 Matthew Caron wrote: > On 01/05/2013 03:01 AM, Nick Sabalausky wrote: > > On Thu, 03 Jan 2013 08:20:19 -0500 > > Matthew Caron 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
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 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
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 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: 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 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: 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 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 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: 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: 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 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
__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: 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 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: 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 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. -- /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 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 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. 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. Yeah, I know. I'm not complaining. 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 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. 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. -- /Jacob Carlborg
Re: D 1.076 and 2.061 release
On 1/6/2013 7:30 PM, Pierre Rouleau wrote: Understood, that's pretty much always the case for any programming language. Now, for someone from the outside, how would someone know what are the latest features? In the changelog, click on New/Changed Features. Would it be possible to identify the version number where a particular feature has been introduced in the Language Reference? If not, since this is DDoc based, is it possible for someone to go back in the github repo file history to identify what was added in the Language Reference files between release to releases and document this somehow? If you can't find it in the changelog under New/Changed Features, you can look in github for it which has a complete history.
Re: D 1.076 and 2.061 release
On 13-01-06 9:41 PM, Walter Bright wrote: On 1/6/2013 6:15 PM, Pierre Rouleau wrote: So, given that enhancements are identified in Bugzilla, is there a review process? Are ticket priorities and vote used? Who decides what is the priority of an enhancement? Who assigns them? Pretty much anyone who wants to take one of them on does so and when done, issues a pull request for it. At that point, there's a general discussion of it and a decision is reached, usually by consensus. Also, given that view on the development of D, what is the position on the evolution of the language in context with backward compatibility and stability? How can an organization of D users that are not also D developers can plan a project and use D for it? Do you consider D stable enough for outside users/organizations to start using it in their own projects? Yes, and it is used heavily for commercial purposes by at least a couple companies. Like any other language, if you insist on using the latest feature and pushing it to the limit, you are more likely to run into problems than if you are a bit more modest in your use of it. Understood, that's pretty much always the case for any programming language. Now, for someone from the outside, how would someone know what are the latest features? Would it be possible to identify the version number where a particular feature has been introduced in the Language Reference? If not, since this is DDoc based, is it possible for someone to go back in the github repo file history to identify what was added in the Language Reference files between release to releases and document this somehow? That said, we make a large effort to fix all regressions upon each release, and I push hard to avoid making breaking changes to the language unless it is really unavoidable. And I can imagine it's a lot of work... -- /Pierre Rouleau
Re: D 1.076 and 2.061 release
On 13-01-06 9:35 PM, Jonathan M Davis wrote: On Sunday, January 06, 2013 21:15:43 Pierre Rouleau wrote: So, given that enhancements are identified in Bugzilla, is there a review process? Are ticket priorities and vote used? Who decides what is the priority of an enhancement? Who assigns them? There's pretty much never any assigning of issues in D's developement. Developers work on whatever they feel like working on. An enhancement request gets implemented, because someone decided to put the time in to implement it. If it's controversial, then it'll generally get discussed in the newsgroup, though some of that is likely to take place in the bug report itself or in a pull request if the developer implements it without discussing it first. Large language changes always get major discussions, but we also don't get a lot of those at this point. It's mostly little stuff. Also, given that view on the development of D, what is the position on the evolution of the language in context with backward compatibility and stability? We're trying to reach the point where you can count on your code compiling for years without changing it. We're getting there, but it doens't always happen. Even fixing bugs breaks code when code relies on buggy behavior. There's also still some API changes in Phobos which breaks stuff, but we've been cutting back on those and trying to avoid them, so they happen much less now then they used to. The recent change to make deprecated warn instead of giving an error should help with that. How can an organization of D users that are not also D developers can plan a project and use D for it? Do you consider D stable enough for outside users/organizations to start using it in their own projects? It's stable enough as long as you're continually working on your code. If you let it sit for a long period of time, you're likely to need the same compiler and library version that you used when you last worked on it. Breakages are _far_ fewer than they used to be, but they still happen. I'd expect that anyone using D seriously for professional development would stick to one version of the compiler for a while and then upgrade it when they have time to update their code (which they may not need to do, but it's still not quite to the point that there isn't at least a decent chance that a few lines of code will have to be changed). API breakage does occur sometimes, but we're making an effort to keep that to a minumum, and we'd like to get rid of it completely. But regardless, I believe that most breakages at this point are due to bug fixes, so when we'll reach the point that you can really expect your code to continue to compile for years on newer compilers without trouble, I don't know. That may depend primarily on the bugs that we have left and how well regressions get caught. The work that's currently being done on formalizing and ironing out the release process should help with that though. - Jonathan M Davis Thank you for the info! -- /Pierre Rouleau
Re: D 1.076 and 2.061 release
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. Sure, it would be great if we could know when certain things are going to be implemented or fixed, but without people to work on them, we can't know when that's going to happen. A lack of time and of manpower are frequently the problem here. And if you want a particular problem fixed, someone else wants another one fixed. Frequently, both could be considered high priority, and the developers only have so much time. Also, it's frequently the case that specific people are needed to fix specific issues - especially if we don't have new people stepping up to the plate and learning how to do stuff - creating an even greater bottleneck. Maybe we could get some sort of consensus on what the biggest issues are and try and get people to focus on those, but frequently, what we really need is for someone to step up and spend the time necessary to fix the issue. When that happens, stuff gets done. When it doesn't, it doesn't really matter what the biggest issues are, because there's a lack of manpower to fix them. And frequently, each major issue requires a different set of expertise, making it hard to for someone or even a small group of someones to work on all of the major issues. And we only have a small group of someones. So, if you have any suggestions on how to improve the process or otherwise help us get stuff done, great. If you think that there's something that we can do to better encourage participation, we're all ears. For instance, the release process is currently being adjusted precisely because people thought that it was a major issue and have spent the time to work out what should be done about it. But to a great extent, I don't think we necessarily know what needs to be changed or how it should be changed. Good ideas are required, and we're tight enough on time and manpower as it is just trying to get done everything that we know needs to get done. Almost always, the key is for someone who's passionate about something to get involved and make sure that it gets done. And I understand and agree on all of the above points. I am trying to see what I could do. Yes, I can start going through the list of tickets, try to compile some info, and eventually even become one more developer. At the moment I was trying to learn more on the development process to get ideas on how (or whether it is possible) to improve the predictability aspect I would need to convince people at work on the usefulness of D. For the moment, I will continue to read the lists, the Bugzilla tickets (and propose better titles via comments if I see opportunities to do so), learn how you use DDoc for the documentation, find out what is supported by the community and its leader (which I assume is Walter) and hopefully I can help a little somehow. - Jonathan M Davis -- /Pierre Rouleau
Re: D 1.076 and 2.061 release
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? Sure, it would be great if we could know when certain things are going to be implemented or fixed, but without people to work on them, we can't know when that's going to happen. A lack of time and of manpower are frequently the problem here. And if you want a particular problem fixed, someone else wants another one fixed. Frequently, both could be considered high priority, and the developers only have so much time. Also, it's frequently the case that specific people are needed to fix specific issues - especially if we don't have new people stepping up to the plate and learning how to do stuff - creating an even greater bottleneck. Maybe we could get some sort of consensus on what the biggest issues are and try and get people to focus on those, but frequently, what we really need is for someone to step up and spend the time necessary to fix the issue. When that happens, stuff gets done. When it doesn't, it doesn't really matter what the biggest issues are, because there's a lack of manpower to fix them. And frequently, each major issue requires a different set of expertise, making it hard to for someone or even a small group of someones to work on all of the major issues. And we only have a small group of someones. So, if you have any suggestions on how to improve the process or otherwise help us get stuff done, great. If you think that there's something that we can do to better encourage participation, we're all ears. For instance, the release process is currently being adjusted precisely because people thought that it was a major issue and have spent the time to work out what should be done about it. But to a great extent, I don't think we necessarily know what needs to be changed or how it should be changed. Good ideas are required, and we're tight enough on time and manpower as it is just trying to get done everything that we know needs to get done. Almost always, the key is for someone who's passionate about something to get involved and make sure that it gets done. - Jonathan M Davis
Re: D 1.076 and 2.061 release
On 1/6/2013 6:15 PM, Pierre Rouleau wrote: So, given that enhancements are identified in Bugzilla, is there a review process? Are ticket priorities and vote used? Who decides what is the priority of an enhancement? Who assigns them? Pretty much anyone who wants to take one of them on does so and when done, issues a pull request for it. At that point, there's a general discussion of it and a decision is reached, usually by consensus. Also, given that view on the development of D, what is the position on the evolution of the language in context with backward compatibility and stability? How can an organization of D users that are not also D developers can plan a project and use D for it? Do you consider D stable enough for outside users/organizations to start using it in their own projects? Yes, and it is used heavily for commercial purposes by at least a couple companies. Like any other language, if you insist on using the latest feature and pushing it to the limit, you are more likely to run into problems than if you are a bit more modest in your use of it. That said, we make a large effort to fix all regressions upon each release, and I push hard to avoid making breaking changes to the language unless it is really unavoidable.
Re: D 1.076 and 2.061 release
On Sunday, January 06, 2013 21:15:43 Pierre Rouleau wrote: > So, given that enhancements are identified in Bugzilla, is there a > review process? Are ticket priorities and vote used? Who decides what > is the priority of an enhancement? Who assigns them? There's pretty much never any assigning of issues in D's developement. Developers work on whatever they feel like working on. An enhancement request gets implemented, because someone decided to put the time in to implement it. If it's controversial, then it'll generally get discussed in the newsgroup, though some of that is likely to take place in the bug report itself or in a pull request if the developer implements it without discussing it first. Large language changes always get major discussions, but we also don't get a lot of those at this point. It's mostly little stuff. > Also, given that view on the development of D, what is the position on > the evolution of the language in context with backward compatibility and > stability? We're trying to reach the point where you can count on your code compiling for years without changing it. We're getting there, but it doens't always happen. Even fixing bugs breaks code when code relies on buggy behavior. There's also still some API changes in Phobos which breaks stuff, but we've been cutting back on those and trying to avoid them, so they happen much less now then they used to. The recent change to make deprecated warn instead of giving an error should help with that. > How can an organization of D users that are not also D > developers can plan a project and use D for it? > > Do you consider D stable enough for outside users/organizations to start > using it in their own projects? It's stable enough as long as you're continually working on your code. If you let it sit for a long period of time, you're likely to need the same compiler and library version that you used when you last worked on it. Breakages are _far_ fewer than they used to be, but they still happen. I'd expect that anyone using D seriously for professional development would stick to one version of the compiler for a while and then upgrade it when they have time to update their code (which they may not need to do, but it's still not quite to the point that there isn't at least a decent chance that a few lines of code will have to be changed). API breakage does occur sometimes, but we're making an effort to keep that to a minumum, and we'd like to get rid of it completely. But regardless, I believe that most breakages at this point are due to bug fixes, so when we'll reach the point that you can really expect your code to continue to compile for years on newer compilers without trouble, I don't know. That may depend primarily on the bugs that we have left and how well regressions get caught. The work that's currently being done on formalizing and ironing out the release process should help with that though. - Jonathan M Davis
Re: D 1.076 and 2.061 release
On 13-01-06 8:41 PM, Jonathan M Davis wrote: On Sunday, January 06, 2013 17:28:57 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'd have to look at major open source projects. They do sometimes come to together and agree on the direction that they should take (KDE and gnome would probably be good examples of that), and a lot of their efforts get focused on what gets decided, but I believe that it's still primarily a case of people working on what they want to work on. But I haven't examined the development processes of other open source projects in depth. If you have enough people, then the holes tend to get filled, but plenty of stuff still falls through the cracks, and unlike projects like KDE or gnome, I don't think that we have a need to create a direction for our project(s) and decide where they're going to be going. That might happen if we were talking about D3, but we're not (and I think that even the KDE and gnome guys only tend to do that when they're talking about where to go with their next major version). It's more of an issue of making sure that all of the little stuff that needs doing gets done. And if there's something that no one wants to work on or if everyone with the time and skill are working on other stuff that needs to be worked on, then some stuff just doesn't get done. And like you, I have no idea how to fix that. - Jonathan M Davis Is this something that the most influential people in the D project want to fix? -- /Pierre Rouleau
Re: D 1.076 and 2.061 release
On 13-01-06 7:36 PM, Walter Bright wrote: On 1/6/2013 3:49 PM, Pierre Rouleau wrote: If this list already contains all (does it?) of what is currently identified then is there some criteria one can use to try to infer what will be implemented in the next release? Or is it just "first come first served" where the solved enhancements automatically get pulled inside the release? 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: 1. some crisis may occur 2. some opportunity may present itself 3. the language market may change its perception of what is important 4. a member of the community may promote themselves to be a champion of some particular issue, and work to get it implemented 5. our understanding of what is important and what isn't constantly evolves 6. there's constant evolution of what exactly is best practice and the best way to realize that Probably pretty high on the list would be solving the rvalue reference problem. OK, I can understand that point of view and I recognize that it's been the view the project has taken which allowed D to evolved nicely. So, given that enhancements are identified in Bugzilla, is there a review process? Are ticket priorities and vote used? Who decides what is the priority of an enhancement? Who assigns them? Also, given that view on the development of D, what is the position on the evolution of the language in context with backward compatibility and stability? How can an organization of D users that are not also D developers can plan a project and use D for it? Do you consider D stable enough for outside users/organizations to start using it in their own projects? -- /Pierre Rouleau
Re: D 1.076 and 2.061 release
Walter Bright, el 6 de January a las 16:36 me escribiste: > On 1/6/2013 3:49 PM, Pierre Rouleau wrote: > >If this list already contains all (does it?) of what is currently identified > >then is there some criteria one can use to try to infer what will be > >implemented > >in the next release? Or is it just "first come first served" where the solved > >enhancements automatically get pulled inside the release? > > 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: > > 1. some crisis may occur > > 2. some opportunity may present itself > > 3. the language market may change its perception of what is important > > 4. a member of the community may promote themselves to be a champion > of some particular issue, and work to get it implemented > > 5. our understanding of what is important and what isn't constantly evolves > > 6. there's constant evolution of what exactly is best practice and > the best way to realize that This is all true for planning 5 years ahead, not 1~3 months. You don't even have to get a very precise plan, you can just focus on some aspect and try to advance in that direction. And having a plan doesn't mean you can't change it if something comes up. > Probably pretty high on the list would be solving the rvalue reference > problem. This is a good example of something that can go into a roadmap for the next 1~3 months (AKA next release). See? You can do it. :P -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Hello? Is there anybody in there? Just nod if you can hear me. Is there anyone at home?
