Re: property-like data members
On Sun, 02 Jan 2011 05:29:48 -0500, spir wrote: Hello, Using properties allows travesting a method call into direct data access. What if the underlying member actually is plain data? Would it be possible to provide a real data member where the language expects a property (for instance as range empty & front properties)? Yes, see the Uniform access principle (http://en.wikipedia.org/wiki/Uniform_access_principle). (Though UAP hasn't been discussed much on the newsgroup)
Re: Who here actually uses D?
"Patrick Kreft" wrote in message news:op.vopbqgqzq2m...@zeus-pc.belkin... > On Sun, 02 Jan 2011 19:28:07 +0100, Nick Sabalausky wrote: > >> Yea, my three primary critera for a GUI lib are: >> >> - Multiplatform >> - Native controls >> - Works on D2 > > > Qt has self-drawn control, which could hold an native handler, if needed. > But they are different from native control. Qt has a compile-time setting to disable that and just use native controls like it always used to do. And since Qt added the self-drawing primarily just to decrease some redraw flicker, I suspect its self-drawing might not be too bad.
Re: const - Best practices
On 2/01/11 10:43 PM, Jonathan M Davis wrote: http://d.puremagic.com/issues/show_bug.cgi?id=1824 For the const/immutable situation to be totally useable, several dmd bugs must be fixed. Some of the major ones are 1824 (Object is not const-correct), 3659 (opEquals() and const needs to be sorted out), 4867 (postblit doesn't work with const objects), and 3748 (inout is broken). The auto ref issue which came up recently when discussing the fact that const ref doesn't work with temporories needs to be resolved as well. There are a number of critical issues with const and immutable as things stand. The result is that that they can quickly become rather problematic to use correctly, if not outright impossible. There are definitely cases where const and immutable can and should be used, but you really have to want to use them at this point to be able to manage it, because they have a lot of problems. And until those problems are fixed, there's no way that we can know what the "best practices" of const in D will really be. To really understand that, we need to write code which uses const and immutable heavily and really see how it all works out. We can speculate on what we think will work well and point out areas where it's clear that there will be problems or which will pretty much need to use const in some manner (like opEquals()), but not enough people have been using const for there to be much experience with it, and those who have tried have consistently run into serious bugs which prevented them from using it like they'd like to. Another big thing is that Phobos as a whole is not const-correct. I don't believe that much attempt has been made to ensure that many of Phobos' functions work properly when const and immutable are used. The lack of tail-const for arbitrary ranges is one of the big open issues which has yet to be resolved. As I understdand it, there are some things work for arrays which will never work for other ranges. And some things have worked in the past because of compiler bugs. Such bugs have hidden issues (including issues relating to const) and made it look like const worked where it doesn't. Until Phobos is properly const- correct, there are a lot of cases where you're not going to be able to use const (this is also true for purity, though I believe that the situation is quite a bit worse for purity). I expect that there is going to have to be a definite focus on fixing bugs related to const and immutable in both the compiler and in Phobos before const and immutable will really be generally useable. It's on the TODO list, though it's not clear whether that or dynamic libraries is next after the 64-bit port (regardless, the 64-bit port is taking longer than expected so, it's going to be longer before the rest of the stuff in line gets focused on and fixed). Personally, I think that const should be used as much as it can be reasonably used. But it does generally preclude any kind of caching of values and the like that you could do with logical const (though you could do things like have a mutable version of a getter on top of a non-mutable one and have _it_ cache the value, so that if either it or the const version is called later and the value doesn't need to be recalculated, the const one can use the cached value and still gain some efficiency from caching). So, if you're expecting to have to cache values and the like, then don't use const. But honestly, in my experience in C++, I have almost never used mutable. And when I have, it's generally been for mutexes and the like (which won't be necessary in the same way in D). Doing things like caching calculations is extremely rare. So, the lack of logical const really wouldn't affect much from what I've seen. The transivity of const is what really affects things IMHO (things like returning a list of mutable objects from a const getter where that list is a member variable of the object aren't going to work in D, but they work just fine in C++ since the container itself isn't copied). I'm sure that there is code out there which does high-cost calculations on a regular basis and pretty much needs to be able to cache the results to be properly efficient, but that is not the norm. So, while some people are going to acutely feel the lack of logical const, a _lot_ of people are going to be able to use const in D very much like they do in C++ without having any issues with the lack of logical const. _Transivity_ may very well make it impossible to use const like they would have in C++, but the lack of logical const really isn't that big a deal in _most_ cases. - Jonathan M Davis Huge thanks Jonathan for writing that. Cheers. So basically, const-correctness in DMD is completely broken :-( I had no idea the situation was so dire, which in itself is a major problem. I don't envy people outside this NG that have no idea what's going on at all. I found this in one of those bugs. It's a post from Andrei, and I think it basically sums up
Re: Thread fails to start
Okay. Here's a working version. Does all the hand-coded queues in old-style
threads and the message passing via spawn.
Code attached.
FWIW, message passing is (in terms of avg and max latency) on par with the
locking
linked-list queues but the lockfree linked list queues are much faster (6x to
7x)
in all the scenarios I tried. I'm running on a 2 x 2.8 GHz Quad-Core Intel Xeon
running Mac OS X.
Am I doing the message passing wrong somehow or is it expected to underperform
lockfree queueing if transaction speed is all that matters?
D really is great. I haven't had this much fun programming in a while. Thanks!
Adam
begin 644 Queue.d
M:6UP;W)T('-T9"YC+G-T9&EO.PT*:6UP;W)T(&-O3L-"@t*...@9ferWT-"B`@("!T:&es...@=f%l*2`-"B`@("![
M#0H@("`@("!V86QU92`]('9A;#L-"B`@("`@(&YE>'0@/2!N=6QL.PT*("`@
M('T-"B`@("!4('9A;'5E.PT*("`@($YO9&4@;F5X=#L-"b...@?0t*("`-"B`@
M#0H@(&EN=&5R9F%C92!1=65U92`-"B`@>PT*("`@('9O:60@PT*("!PR!R97-E="@I.R!]
M#0H@("`...@#0h@("`@6YC:')O;FEZ
m...@*'1H:7,I('L-"@ET;7`N;F5X="`](&QA'0@/2!T;7`["0T*("`@("`...@?2`-"B`@("!]#0H@("`...@#0h@("`...@8f]o;"!C
M;VYS=6UE*&]U="!4(')EPT*("`@("`...@3f]d92!t;7`[
M#0H@("`@("!S>6YC:')O;fez...@*'1H:7,I('L-"@ET;7`@/2!F:7)S="YN
M97AT.PT*"6EF("AT;7`@:7,@;G5L;"D-"@D@(')E='5R;B!F86QS93L-"@EF
M:7)S="YN97AT(#...@=&UP+FYE>'0[#0H@("`@("!]#0H@("`@("!R97-U;'0@
M/2!T;7`N=F%L=64[#0H@("`@("!R971UR!R971UR!R971UF5D("AT:&ES*2![#0H)
M=&UP+FYE>'0@/2!L87-T+FYE>'0[#0H);&%S="YN97AT(#...@=&UP.PD-"B`@
M("`@('t...@#0h@("`...@?0t*("`@(`T*("`@(&)O;v...@8v]nF5D("AT:&ES*2![#0H)=&UP(#T@;&%S="YN97AT.PT*"6EF("AT;7`@
M:7,@;G5L;"D-"@D@(')E='5R;B!F86QS93L-"@EL87-T+FYE>'0@/2!T;7`N
M;F5X=#L-"B`@("`@('T-"B`@("`@(')ER!F:7)S="`](&QA
MPT*("`@("`@PT*"71M<"`](&9I'0[#0H)
M:6...@*'1M<"!IPT*("`@("`@PT*"71M
M<"`](&QA'0L=&UP+'1M
M<"YN97AT*2D[#0H@("`@("`-"B`@("`@(')ER!R971U6YC:')O;fez...@*'1H
M:7,I('L-"@DJ*&-UPT*"2`@:6YT(&P@/2!B
M=69F97)?+FQE;F=T:#L-"@D@(&)U9F9ER`@("`...@#0h):6...@*&-U
MR!R971UR!R971UR!R971U3L*
M:6UP;W)T('-T9"YT7!EPH@('-T3L*("!]"@H@(&%L
M:6%S(%%U975E7U1Y<&5S(2A$871A7U!A8VME="d...@450["@H@('1E;7!L871E
M(%%U975E7U5S92`H42D@"B`@>PH@("`...@=f]i9"!S96YD7W1O*%$@<2P@:6X@
M1&%t85]086-k...@9"D@>R!Q+G!R;V1U8V4H9"D[('T*("`@(&)O;VP@R!R971U
MPH@("`...@=&AIPH@("`@("!17R`]('$["B`@("`@(')?(#T@PH@("`@("!D96)u...@q*2![('!R:6y...@b:6X@<')O9'5...@i7&XB
m...@?0h@("`@("!I;g...@8v]u;G1E5\LWT["B`@"b...@=f]i9"!PPH)1&%t85]086-k...@9&%T83L*"61A=&$N<%1I;64@/2!S>7-T:6UE*"D[
M"@ED96)U9R`H-2D@>R!P2QP
M86-K971?=F%R:6%B:6QI='DLPH@
M("`...@450n365sPH@("`@("!D96)u...@q*2![('!R:6y...@b:6...@8v]n2AD871A*3L*"7T*("`@("`...@?0h@("`@("!D96)u...@q*2![('!R:6y...@b
M96YD(&-O;G-U;64H*5QN(BD[('T*("`@('T*"B`@<'5B;&e...@h@("`@;&]N
M9UM=(&1E;&%YR!PPH@("`...@9&5B=6R!PR!PPH@("`@:6UM=71A8FQE('-T%QT/&UI;CY<=#q...@^(c...@?0h@("`@"B`@<')I=F%T93H*
M("`@(`H@("`...@+r\@9F]R('1E5\["B`@("`*("`@("\O(&9O
MR`*("`@("`...@875t;R!WPH@("`@("!Q7VYA;65?(#T@<2YN86UE.PH@("`@("!Q+G)E
M7,["B`@("`@(%1I9"!C5&ED.PH@("`@("!S9&5L87ES
M+FQE;F=T:"`](&YU;6)E7,I.PH);7!Q+G-E=%]C;VYS=6UEPH)9&5B=6R!PPH)9F]R("AI;G0@:STP
M.R!K/&YU;5]PR!PWTI.PH)?0H)
M9&5B=6R!PPH)5&AR96%D1W)O=7`@<')O9'5C
M97)4:')E861S(#T@;F5W(%1HPH)("!A=71O('!R;V1U8V5R(#T@
M;F5W(%!R;V1U8V5R*'$L9V5N+'!A8VME='-?<&5R7W!R;V1U8V5R7RQP<',L
M;6ECR!PR!PR!P7,["B`@("`@(&5L7-;9&5L87ES+FQE;F=T:"TQ73L*("`@
M("`@;6EN:6UU;5\@/2!D96QA>7-;,%T["B`@("`@(`H@("`@("!A=71O('-U
M;2`](')E9'5C92$H(F$K8B(I*&-A7,N
M;&5N9W1H+S$P,"PQ*3L*("`@("`@;&]N9UM=('-M86QL97-T(#...@9&5L87ES
m...@+bx@<&-T73L*("`@("`@;&]N9UM=(&QA7-;*&1E
M;&%Y7,N;&5N9W1H73L*("`@("`...@879g
M7VUI;E\@/2!R961U8V4A*")A*V(b...@p+c`l%\@/2!R961U8V4A*")A*V(b...@p+c`l;&%R9V5S="DO<&-T
M.PH@("`@("`*("`@('T*("!]"GT*"F%L:6%S(%%U975E7U1E#...@87)E(&%V97)A9V5S(&]V97(@9F%S=&5S="!A;F0@
MPH@("`@("!T+G)U;BA1*3L*("`@("`@
M<')I;G1F*"(E+BIS7&XB+'0N4G5N7TEN9F\I.PH@("`...@?0h@("`@<')I;G1F
2*")<;B(I.PH@('T*"GT*"@H*
`
end
std.unittests for (final?) review
Okay. As some of you are aware, I created a module with unit testing functions when I wrote std.datetime, and it really helped with writing the unit tests for std.datetime. It has been at least somewhat reviewed here previously, and that has definitely improved it. However, it has not yet been decided whether it's going to go into Phobos along with std.datetime. I'd like it to, but it hasn't been voted on, and I'm not sure that it's been reviewed as heavily as it should be. So, I'm posting the most up-to-date version in the hopes of getting any necessary changes found and made so that it can be voted on. Andrei has yet to weigh in on std.unittests at all, so I don't know if we're actually going to get a vote on it, but I'm presenting it for (final?) review so that it can be voted in if that's what he wants to do. The code: http://is.gd/jZEVl Both the source file and the ddoc hmtl file are included. And unlike std.datetime, it's actually straightforward enough that it makes sense for your average program to actually look at it. To be clear, this module has 2 purposes: 1. Improve error messages on test failure. A good example of this is assertEqual, which prints out both of the values being compared so that you don't have to add a print statement (or run a debugger) and rerun the test to see what the actual values were. 2. Reduce boiler-plate code in unit tests. A good example of this is assertExThrown. Testing whether a function call actually throws an exception like it's supposed to becomes a single line of code instead of being around 10 lines. This module does _not_ attempt to change how unit testing in D fundamentally works. It does not print out on success. It doesn't make it so that a unittest block continues after a failure occurs in that block. All of the assertXXX functions throw an AssertError upon failure - just like assert does, but the message in the AssertError is far more informative. While improvements can be made to how unit tests work in D, I believe that that should be addressed by actually making those improvements to the core language as opposed to using a module in Phobos to change things. You shouldn't _need_ std.unittests to write unit testing code. std.unittests is intended to help you write more informative unit test code and save you from writing some of the boilerplate code in unit tests, but it is _not_ intended to fundamentally alter how unit tests in D function. So, please have a look at the code. I've made changes according to previous suggestions, and I think that the result is quite a bit better than my original proposal. If all goes well, perhaps Andrei will put it up for vote soon, and we can actually have it in Phobos. - Jonathan M Davis
Re: Who here actually uses D?
Eric Poggel wrote: On 1/1/2011 11:56 PM, Walter Bright wrote: dmd does not use the xmm registers for floating point, so its performance tends to be worse on that for later CPUs. Granted, this should be lower priority than bug fixes, but out of curiosity, is this something that's hard to fix? I see it come up frequently in the benchmark-related posts here. It requires a bunch of new code to be written.
Hooking the GC?
Hi, Is there any way to add a hook to the garbage collector in D, so that I can be immediately notified (for example) when an object is created? (I'm aware that this could cause infinite recursion/deadlock if I try to allocate memory, but that's all right, I'm fine with that.) Thank you!
Re: Thread fails to start
Thanks! It's OSX, by the way. So it's clear, I understand that message passing is preferred and I can see how to do that (kind of!) but I want to compare the performance to other queue implementations so I can see that message passing is faster or comparable. Originally, I was just trying to compare (avg and worst case latency) Locking and LockFree queues (and learn the basics of using CAS) but then I wanted to add message passing to the list to compare. Combining them all in one test harness is proving challenging. That the main thread has a default mailbox makes sense and explains a lot. Though I doubt I know enough to comment usefully, creating a mailbox if "thisTid" is called makes sense to me. Thanks again. Adam
Re: Who here actually uses D?
On 1/1/2011 11:56 PM, Walter Bright wrote: dmd does not use the xmm registers for floating point, so its performance tends to be worse on that for later CPUs. Granted, this should be lower priority than bug fixes, but out of curiosity, is this something that's hard to fix? I see it come up frequently in the benchmark-related posts here.
Re: const - Best practices
"Peter Alexander" wrote in message news:ifqg7o$1hn...@digitalmars.com... > Sorry for the bump, but there's at least three people here that would > like an answer to this. Surely someone knows how to use const in D? :-) > http://www.digitalmars.com/d/2.0/const-faq.html
Re: What's the problem in opensourcing htod?
On 21/12/2010 22:08, Jonathan M Davis wrote: Just so you know, htod works on wine. But how many people are willing to install Wine just to run this program? I'd still like to know what on earth the barrier is to building htod to run on platforms other than Windows. Stewart.
Re: Thread fails to start
Adam Conner-Sax Wrote: > Thanks for trying it! > > I've seen that outcome once also but usually I don't get the "in produce(...)" > when it hangs. And I don't get the bus errors (I've gotten them other ways). > > I get that I should use spawn (and I am writing a new version to use spawn > everywhere), though I did make it all work without ever using spawn so the > mailbox > setup seems to work anyway though I do not understand how. Are both (from > spawner > to spawnee and vice versa) mailboxes set up by spawn? How does the unit test > in > std.concurrency work? It spawns but then sends messages in both directions. spawn creates the mailbox in the new thread. I'm going to change thisTid to create a mailbox for the current thread if none exists though. That should resolve the issue I mentioned earlier. The main thread gets a mailbox by default, if I remember correctly. I just didn't want to give other threads one by default because the ref is immediately overwritten by spawn. > If I get the error on a smaller subset I will post. It was all working then > at > some point as I was moving toward the std.concurrency way, it all broke in > the way > I described so I don't know how to make a smaller version that also has the > error. I'll try to find some time to give your code a closer look. It seems like it could be used as a more thorough test suite for the thread and messaging code.
Re: Thread fails to start
Thanks for trying it! I've seen that outcome once also but usually I don't get the "in produce(...)" when it hangs. And I don't get the bus errors (I've gotten them other ways). I get that I should use spawn (and I am writing a new version to use spawn everywhere), though I did make it all work without ever using spawn so the mailbox setup seems to work anyway though I do not understand how. Are both (from spawner to spawnee and vice versa) mailboxes set up by spawn? How does the unit test in std.concurrency work? It spawns but then sends messages in both directions. If I get the error on a smaller subset I will post. It was all working then at some point as I was moving toward the std.concurrency way, it all broke in the way I described so I don't know how to make a smaller version that also has the error. Adam
Re: Who here actually uses D?
Robert Clipsham wrote:
Having seen a post by Peter Alexander (in Re: D for game development),
mentioning some of the issues he's hit I thought I'd post this. I've
been in his shoes (every other time I use D it seems), and feel I should
ask - who here uses D, and to what extent?
I'm mostly interested in those of you with 1000 Line plus projects in D,
as that's when I've found I start hitting issues.
Just to clarify, for those D purists among you... I'm not trolling, just
curious (I wouldn't normally have asked, but now I know I'm not paranoid
and the only one having problems, I thought I'd ask).
I don't use D (anymore), but took some time during the holidays
to make sure that GDC and wxD works with 64-bit on all platforms.
The previous packages, from 2007 and 2008, were all 32-bit only:
http://gdcgnu.sourceforge.net/ ("FSF" GCC)
http://gdcmac.sourceforge.net/ (Apple GCC)
http://gdcwin.sourceforge.net/ (MinGW GCC)
This incidentally involved upgrading Mac from gcc-4.0 to gcc-4.2
and upgrading Win from Win32 to Win64, but now both of those work:
i686-apple-darwin10-gdc-4.2.1 (GCC) 4.2.1 20070719
x86_64-w64-mingw32-gdc (GCC) 4.5.1 20100731
For Mac OS X it also involved upgrading GUI from Carbon to Cocoa,
which included upgrading from wxWidgets 2.8 to wxWidgets 2.9...
hhttp://wxd.sourceforge.net/ (GUI)
And after the release of Fedora 14, LDC support was also added to
Code::Blocks in addition to the previously existing GDC and DMD.
http://www.codeblocks.org/(IDE)
This also marks the fourth anniversary, from the first release:
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=46121
I was also mainly interested in using D to make games with (SDL/GL),
and as a programming language offering an upgrade from C and Java.
--anders
Re: Less commas
On 1/2/11 4:30 PM, spir wrote: On Sun, 02 Jan 2011 20:56:48 + Peter Alexander wrote: This is great stuff, bearophile. Thanks for finding that. Please add this as an enhancement request to bugzilla (disallowing (!x&y) expressions). That really surprises me that it's a common bug. Isn't it obvious that ! has higher precedence than&? Or have I totally misunderstood the cause of the bug? That's not such surprising: a study on the topic (operator priority) has shown a very high frequency of such errors (in C). The public were all highly educated, tranined, experienced, programmers. On the other hand, the same study showed how ridiculous the proportion of lines of code holding poly-operator expressions is (which comparatively still highers the relative frequency of errors). A logical conclusions is , I guess: is it worth complexifying a language (by a sub-language just for expressions, which is often the bigger and most complicated part of a parser)& causing loads of bugs for a need that arises even 1000th lines of code? I'd say that a class of bugs that occurs every 1000 lines, is traceable to a unique cause, is mechanically detectable with ease, and is easy to avoid by the programmer, is a MUST to eliminate through language design. Phobos has 90K lines. If I could eliminate 90 bugs in it by a recompile, that would be awesome. By the way - if (a & b == 0) is another one (Don worked on that). Andrei
Re: const - Best practices
On Sunday 02 January 2011 10:41:16 Peter Alexander wrote: > On 31/12/10 6:33 PM, Peter Alexander wrote: > > Ok, so while I'm still not 100% satisfied with the lack of logical const > > in D, I'm willing to see how far I can get without bitwise const without > > going crazy, and I just want to clarify some things. > > > > Andrei has commented a couple of times on the fact that D's const has > > more guarantees than C++'s const, and as a result you should use it a > > lot less often than you do in C++. > > > > Questions: > > > > 1. What exactly does this mean? What are the situations where you should > > use const in C++, but not in D? > > > > 2. When designing base classes and interfaces, when should you mark a > > member function as const? In C++ you would do so for any accessor, as > > they would be logically const. In D, you can't assume that an accessor > > is bitwise const (due to lazy initialisation and caching), so when do > > you make it const in the base class, and when do you leave it mutable? > > > > 3. When should you take const references in template functions > > (essentially same subquestions as above). > > > > Final note: my intention here is not to start another logical const vs. > > bitwise const war. I just want to know how the differences in const from > > C++ affect library design, and what the best practices for > > const-correctness are in D. > > > > Thanks in advance. > > Sorry for the bump, but there's at least three people here that would > like an answer to this. Surely someone knows how to use const in D? :-) > > Additional question: why are none of Object's methods const, e.g. > toString and toHash? http://d.puremagic.com/issues/show_bug.cgi?id=1824 For the const/immutable situation to be totally useable, several dmd bugs must be fixed. Some of the major ones are 1824 (Object is not const-correct), 3659 (opEquals() and const needs to be sorted out), 4867 (postblit doesn't work with const objects), and 3748 (inout is broken). The auto ref issue which came up recently when discussing the fact that const ref doesn't work with temporories needs to be resolved as well. There are a number of critical issues with const and immutable as things stand. The result is that that they can quickly become rather problematic to use correctly, if not outright impossible. There are definitely cases where const and immutable can and should be used, but you really have to want to use them at this point to be able to manage it, because they have a lot of problems. And until those problems are fixed, there's no way that we can know what the "best practices" of const in D will really be. To really understand that, we need to write code which uses const and immutable heavily and really see how it all works out. We can speculate on what we think will work well and point out areas where it's clear that there will be problems or which will pretty much need to use const in some manner (like opEquals()), but not enough people have been using const for there to be much experience with it, and those who have tried have consistently run into serious bugs which prevented them from using it like they'd like to. Another big thing is that Phobos as a whole is not const-correct. I don't believe that much attempt has been made to ensure that many of Phobos' functions work properly when const and immutable are used. The lack of tail-const for arbitrary ranges is one of the big open issues which has yet to be resolved. As I understdand it, there are some things work for arrays which will never work for other ranges. And some things have worked in the past because of compiler bugs. Such bugs have hidden issues (including issues relating to const) and made it look like const worked where it doesn't. Until Phobos is properly const- correct, there are a lot of cases where you're not going to be able to use const (this is also true for purity, though I believe that the situation is quite a bit worse for purity). I expect that there is going to have to be a definite focus on fixing bugs related to const and immutable in both the compiler and in Phobos before const and immutable will really be generally useable. It's on the TODO list, though it's not clear whether that or dynamic libraries is next after the 64-bit port (regardless, the 64-bit port is taking longer than expected so, it's going to be longer before the rest of the stuff in line gets focused on and fixed). Personally, I think that const should be used as much as it can be reasonably used. But it does generally preclude any kind of caching of values and the like that you could do with logical const (though you could do things like have a mutable version of a getter on top of a non-mutable one and have _it_ cache the value, so that if either it or the const version is called later and the value doesn't need to be recalculated, the const one can use the cached value and still gain some efficiency from cachin
Re: Less commas
On Sun, 02 Jan 2011 13:21:33 -0800 Walter Bright wrote: > That's the interesting part, and why I suggested that studying recurring > patterns of real life bugs is productive. What we think might be a problem vs > what actually is a problem can be very different. Thank you for pointing (& re-pointing) at that, Walter. Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: Less commas
On Sun, 02 Jan 2011 20:56:48 + Peter Alexander wrote: > > This is great stuff, bearophile. Thanks for finding that. Please add > > this as an enhancement request to bugzilla (disallowing (!x&y) > > expressions). > > That really surprises me that it's a common bug. Isn't it obvious that ! > has higher precedence than &? Or have I totally misunderstood the cause > of the bug? That's not such surprising: a study on the topic (operator priority) has shown a very high frequency of such errors (in C). The public were all highly educated, tranined, experienced, programmers. On the other hand, the same study showed how ridiculous the proportion of lines of code holding poly-operator expressions is (which comparatively still highers the relative frequency of errors). A logical conclusions is , I guess: is it worth complexifying a language (by a sub-language just for expressions, which is often the bigger and most complicated part of a parser) & causing loads of bugs for a need that arises even 1000th lines of code? Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: Who here actually uses D?
On Sun, 02 Jan 2011 19:28:07 +0100, Nick Sabalausky wrote: Yea, my three primary critera for a GUI lib are: - Multiplatform - Native controls - Works on D2 Qt has self-drawn control, which could hold an native handler, if needed. But they are different from native control.
Re: Who here actually uses D?
On 2/01/11 9:13 PM, Don wrote: And BTW, that list used to be about ten times as long. There are not many nightmare bugs left. I'm personally not comfortable with heavily promoting the language until that list is reduced to practically zero. At the current rare, we're probably a couple of months away. I agree, but that's good that we're only a couple of months off :-)
Re: property-like data members
spir wrote:
> Using properties allows travesting a method call into direct data
access. What if the underlying member actually is plain data? Would it
be possible to provide a real data member where the language expects a
property (for instance as range empty & front properties)?
There has been a lot of discussions on properties and their syntax.
There is a complexity in your proposal: should we allow write access to
@property members? We would need to come up with a way to limit write
access.
> Is there any difficulty for the compiler to check whether a data
member of the same name and correct type exists? To help it, we could
mark said data member with an @property hint. For instance:
>
> struct String {
> char[] cs;
> private uint index = 0; // for traversal
> @property char front;
> @property bool empty;
> this (string characters) {
> this.cs = characters.dup;
> this.empty = (this.cs.length == 0);
> if (this.cs.length > 0)
> this.front = this.cs[0];
> }
> @property void popFront () {
> ++ this.index;
> this.empty = (this.index >= this.cs.length);
> if (this.index < this.cs.length)
> this.front = this.cs[this.index];
> }
> }
> unittest {
> auto s = String("abc");
> // works fine
> while (! s.empty) {
> auto c = s.front;
> write(c,' ');
> s.popFront;
> }
> writeln();
> // works not
> //~ foreach (char c ; s) write(c,' ');
> writeln();
> }
>
> Here, popFront does not only advance, it correctly sets empty and
front, so that a single method is needed. But the language expects a
method-property (actually, it complains for missing opApply *).
Phobos is happy with 'empty' being a static member. The following member
would make an infinite range:
static enum bool empty = false;
But I know that you don't want that. :)
The actual problem in your example is the missing front() function.
> I'm a bit troubled to implement methods where plain data does the job
and conceptually better matches my model (maybe it's only me: I wish the
code to mirror my views).
Having never used a language that had properties, I am very happy how D
handles them. Having to write a one-liner doesn't bother me.
Ali
Re: Less commas
Walter Bright wrote: That's the interesting part, and why I suggested that studying recurring patterns of real life bugs is productive. What we think might be a problem vs what actually is a problem can be very different. This also reminds me of how the reliability of aircraft engines was improved during WW2. The engines were mounted on a test stand and simply run at full power until they broke. The broken part was analyzed, redesigned, installed, and the engine run again until it broke. Rinse, repeat.
Re: Please comment on http://d-programming-language.org/
Matthias Pleh wrote: >>> ... there is already a SVG logo for the D-man since 5 years, but >>> obviousily it get not adopted :/ >>> http://w148.de/~mmartin/d/logo.html >> >> Looks good. May I use it on d-programming-language.org? > > This should be answered by Marcel Martin. (I will send a copy of this > email to the email-address on the website) Hi, great to hear someone is looking at that page :-) Yes, I agree to that use (and actually all other uses). I have clarified that on on the web page. Marcel
Re: Less commas
Peter Alexander wrote: That really surprises me that it's a common bug. Isn't it obvious that ! has higher precedence than &? Or have I totally misunderstood the cause of the bug? That's the interesting part, and why I suggested that studying recurring patterns of real life bugs is productive. What we think might be a problem vs what actually is a problem can be very different.
Re: Less commas
Walter Bright wrote: > disallowing (!x&y) expressions While `!x&y' may be replaced by `y&!x', for `!x&&y' an isomorphic change is not possible. -manfred
Re: Who here actually uses D?
Sönke Ludwig wrote: Am 01.01.2011 23:22, schrieb Robert Clipsham: Having seen a post by Peter Alexander (in Re: D for game development), mentioning some of the issues he's hit I thought I'd post this. I've been in his shoes (every other time I use D it seems), and feel I should ask - who here uses D, and to what extent? I'm mostly interested in those of you with 1000 Line plus projects in D, as that's when I've found I start hitting issues. Just to clarify, for those D purists among you... I'm not trolling, just curious (I wouldn't normally have asked, but now I know I'm not paranoid and the only one having problems, I thought I'd ask). My main project is abount 100.000 lines of code. Most of the time now, I stay away from new features - including pure and the new concurrency model. However, I use the const/immutable system since the beginning. Also quite some string-mixin stuff, templates and CTFE. (*) At times I'm hitting multiple bugs a day, but by far the most devastating bugs are those freakin' unexpected OPTLINK terminations (e.g. http://d.puremagic.com/issues/show_bug.cgi?id=4808). With that code base it is practically impossible to make repro cases or workarounds for those bugs and they slip up every now and then (right now I have one of them). Unfortunately those are often bugs that lie there for years. I remember someone said there should be no known new regressions in the compiler - the reality seems to be quite different here and I quit D programming for multiple periods of months because of such beasts. (Fortunately most of the time there is one method of compilation or operating system that successfully builds). The other kind of bug that I find really frustrating because it is hard to discover and takes a lot of time to track down and work around is that kind with corruped data/wrong code. Todays examples are http://d.puremagic.com/issues/show_bug.cgi?id=3863 and some postblit stuff that I have not yet been able to track down. At least in times when it is possible to program without hitting those issues, D somehow is able to close the gap again with its nice and efficient language constructs. But I think the priority for fixing bugs really has to be changed because that is what is driving people away (for good reason): Blockers, Regressions and maybe criticals should be taken more serious, as well as the top votes in bugzilla should be handled somehow. Here is the priority list: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#DMDCompilerStability And here's my personal list of top-priority bugs: -- Showstoppers -- 4854 Regression(2.047, Mac 10.5 only) writefln Segmentation fault if no globals 3516 Destructor not called on temporaries 4437 copy construction bug with "return this;" 314 Static, renamed, and selective imports are always public -- Critical wrong code -- 4714 Cannot return ref this when struct has invariant (= 3273, 1251, 3973) 4269 Regression(2.031) invalid type accepted if evaluated while errors are gagged 1350 delegate literal inside tuple; wrong values 1513 try/catch/finally misbehavior on windows 1759 Closures and With Statements 1841 Closure detection doesn't work when variable is used in a nested function 1899 AA of fixed-length arrays fails to initialize 2962 ICE(glue.c) or bad codegen passing variable as template value parameter 3824 An AA with an AA as key doesn't seem to work 3863 Various errors and ICE(todt.c) for struct constructors with ellipses And BTW, that list used to be about ten times as long. There are not many nightmare bugs left. I'm personally not comfortable with heavily promoting the language until that list is reduced to practically zero. At the current rare, we're probably a couple of months away.
Re: Less commas
Peter Alexander wrote: That really surprises me that it's a common bug. Isn't it obvious that ! has higher precedence than &? Or have I totally misunderstood the cause of the bug? No, you got the cause right. However, how often are you actually interested in doing (!foo)&bar? The language can very well disallow such syntax, because most of the time, it's not what you want it to do. -- Simen
Re: Less commas
On 1/2/2011 12:56 PM, Peter Alexander wrote:
> On 2/01/11 8:04 PM, Walter Bright wrote:
>> bearophile wrote:
>>> A common bug in Linux kernel:
>>>
>>> if(!state->card->
>>> ac97_status&CENTER_LFE_ON)
>>> val&=~DSP_BIND_CENTER_LFE;
>>>
>>> The fix is to replace (!E & C) with (!(E & C)).
>>>
>>> Currently D acts like C:
>>>
>>> void main() {
>>> uint x, y;
>>> if (!x & y) {}
>>> }
>>>
>>> - 96 instances of this bug in Linux from 2.6.13 (August 2005) to
>>> v2.6.28 (December 2008).
>>> - 58 instances of this bug in 2.6.20 (February 2007)
>>> - 2 in Linux-next (October 10, 2009)
>>>
>>> They have faced and reduced the number of such bugs using Coccinelle,
>>> see pages 8-9 here:
>>> http://coccinelle.lip6.fr/papers/fosdem10.pdf
>>
>> This is great stuff, bearophile. Thanks for finding that. Please add
>> this as an enhancement request to bugzilla (disallowing (!x&y)
>> expressions).
>
> That really surprises me that it's a common bug. Isn't it obvious that ! has
> higher precedence than &? Or have I totally misunderstood the cause of the
> bug?
I haven't read the paper, probably should, but is it counting found, fixed,
introduced? Each of those are different data points. Also of interest would be
any indicator of total bug counts during that same period. We're talking about
a LONG period of time here (5-6 years) and a rather large code base that does a
lot of low level bit manipulations.
Later,
Brad
Re: Less commas
On 2/01/11 8:04 PM, Walter Bright wrote:
bearophile wrote:
A common bug in Linux kernel:
if(!state->card->
ac97_status&CENTER_LFE_ON)
val&=~DSP_BIND_CENTER_LFE;
The fix is to replace (!E & C) with (!(E & C)).
Currently D acts like C:
void main() {
uint x, y;
if (!x & y) {}
}
- 96 instances of this bug in Linux from 2.6.13 (August 2005) to
v2.6.28 (December 2008).
- 58 instances of this bug in 2.6.20 (February 2007)
- 2 in Linux-next (October 10, 2009)
They have faced and reduced the number of such bugs using Coccinelle,
see pages 8-9 here:
http://coccinelle.lip6.fr/papers/fosdem10.pdf
This is great stuff, bearophile. Thanks for finding that. Please add
this as an enhancement request to bugzilla (disallowing (!x&y)
expressions).
That really surprises me that it's a common bug. Isn't it obvious that !
has higher precedence than &? Or have I totally misunderstood the cause
of the bug?
Re: Less commas
bearophile wrote:
A common bug in Linux kernel:
if(!state->card->
ac97_status&CENTER_LFE_ON)
val&=~DSP_BIND_CENTER_LFE;
The fix is to replace (!E & C) with (!(E & C)).
Currently D acts like C:
void main() {
uint x, y;
if (!x & y) {}
}
- 96 instances of this bug in Linux from 2.6.13 (August 2005) to v2.6.28
(December 2008).
- 58 instances of this bug in 2.6.20 (February 2007)
- 2 in Linux-next (October 10, 2009)
They have faced and reduced the number of such bugs using Coccinelle, see pages
8-9 here:
http://coccinelle.lip6.fr/papers/fosdem10.pdf
This is great stuff, bearophile. Thanks for finding that. Please add this as an
enhancement request to bugzilla (disallowing (!x&y) expressions).
Re: Advocacy (Was: Who here actually uses D?)
bearophile wrote: Walter: Based on what? It's just a lump of opinions of mine, I have not written a microkernel yet :-) But I am reading a lot, I am learning and I will be able to write this kind of code too. Some people have tried to write a kernel with Python. D2 is a nice language to use, it allows some low level control, inline asm, and it compilation model comes from C with things added. So I am sure it's possible to write a good enough kernel with D2. So it's a matter of how much the language is fit for this purpose, it's not a binary thing. Is D2 the best conceivable language to write a kernel? I don't think so (but I am often wrong). It's not perfect, but it is better than any other existing language. For a kernel writer D2 doesn't offer a lot of control on low level matters, like how the compiler compiles and optimizes code (see the thread about "guaranteed optimizations". I'm afraid that's baloney, as I pointed out in the other thread. This is a case where you don't want to "Let the compiler implementors do their job" because you lose low-level control on the code produced and this introduces bugs). This was one of the main complaints of Linus against C++ for Linux kernel development. I think that is a serious misinterpretation of the complaint. The complaint was actually that the high level abstractions that one can choose to use in C++ can be impenetrable in what they do. In D, if you want low level control, write low level code. It's that simple. D2 type system is refined and much more powerful than the C one. And people have written many kernels with C (C plus with few nonstandard extensions). But if you want to write a modern kernel you may want a type system more powerful than the C and D ones, that give stronger static guarantees. Linus has written a tool to strengthen the C type system: http://en.wikipedia.org/wiki/Sparse Yes, I know about Sparse. You can do the same thing in D without needing annotations. In another thread I have written something about typed assembly, useful to make less wild parts written in assembly: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=125815 In some situations linear types too help: http://en.wikipedia.org/wiki/Linear_types Typed assembler is a waste of effort in a language like D, as you only need a few drops of assembler here and there. The Spec# language and the experimental Verve kernel we have discussed a bit in past show possible directions for future kernels, they require a pretty strong static analysis. Those languages are failures at what they propose to do; they need years and perhaps decades to fulfill that. The Sparse tool shows that some of those type system feature may be added later to D with an external tool. Like I said, you can already do that with D. But Verve shows that sometimes you need something more built-in. I don't buy that.
Re: Advocacy (Was: Who here actually uses D?)
Ulrik Mikaelsson wrote: "Systems programming" in my vocabulary is not limited to JUST kernel programming. To be honest, I think D has a pretty long way to go to be good for kernel development (irregardless of Linus/Linux). For kernel development I suspect stop-the-world GC, or any non-deterministic GC for that matter is a big no-no. Sure, but D has *optional* gc. If you want to, you can use D as simply a "better C" and it will compile to the same code as C does.
Re: Advocacy (Was: Who here actually uses D?)
"spir" wrote in message news:mailman.359.1293969777.4748.digitalmar...@puremagic.com... On Sun, 2 Jan 2011 10:19:48 +0100 Gour wrote: > Caligo> So why is D being advertised as a systems programming > Caligo> language? By saying Linus would not find D appealing you are > Caligo> basically saying kernel developers would not find it appealing. > > Do Linus & co. have to put label on something to qualify as > system-programming language? > > Here is something interesting: > > http://tommd.wordpress.com/2009/09/13/kernel-modules-in-haskell/ Oberon is both a system programming lang very different from C and a system written in it that is/was rather innovating. > For me, D looks as the most-promising general programming language > having good-enough performance and being safe-enough - iow. sweet > spot: C(++) <--- D ---> Haskell. Yes. I find simply wrong presentations starting with "D is a system programming language..." D is more than that. (And is/will certainly be more used in other domains that in system programming) Borland did the same miss-selling - they marketed Delphi as a database language... :-) -=mike=-
Re: TDPL ebook
On Fri, Dec 31, 2010 at 11:34 AM, Thomas Mader wrote: > Am 2010-08-27 22:04, schrieb Daniel Gibson: >> >> == Quote from sergk (kovrov+purema...@gmail.com)'s article >>> >>> Despite word "download" being mentioned. What safari really provide, >>> is an "online version" of the book, not "electronic version". >>> When I've bought paperback TDPL, I was kinda hoping to read "bonus >>> book" on my kindle dx, leaving paperback book on my office desk as >>> promo for my colleagues and guests. Well, too good to be truth. >>> FWIW, I would still like to have a kindle version. Pdf is fine too. >> >> Has this changed? I bought TDPL in early July, registered at >> informit/Safari Books >> Online and could download a PDF version, which was even updated about two >> weeks >> later. Those versions were labeled "Rough Cuts" but whatever.. >> So I got a nice searchable (and even updated) PDF version of the book that >> I can >> use forever, even when the free 45day subscription expires (and I >> certainly >> wouldn't pay for a Safari Online subscription just to use a digital >> version of a >> book I already bought). >> It has my name and E-Mail Address on every page, but this is okay, it's >> probably >> meant to be some kind of copy protection. >> >> Andrei: Please make this version available again for anyone who bought >> your book, >> because many people like having a searchable PDF in addition to the real >> dead-tree >> book. I think the way it was handled in early July (get a free 45day >> subscription >> and the possibility to download the book as PDF within that time) was >> really fair >> - although I certainly wouldn't mind getting updated versions of the book >> even >> after that 45day period - and useful. >> >> Cheers, >> - Daniel > > I also found the book on > http://www.informit.com/store/product.aspx?isbn=0321635361 and it seems to > be the most viable ebook solution. > I would like to know where the name and email address watermarks are > printed. Do they distract the reading? > > Thomas > Sorry for replying so late, I must have missed your post. See http://bildupload.sro.at/p/368007.html for an example (I hope Andrei doesn't mind, this page has no interesting content.) The big grey watermark in the background is on some pages (maybe on every 10th page?), the footer with my name and E-Mail address is on every page. The big gray watermark consists of my name and a 7 digit number (which I've mostly pixelated). I don't know if the watermarks are the same in the current E-Book versions. Cheers, - Daniel
Re: David Simcha's std.parallelism [questions for Walter]
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article > On 1/2/11 10:39 AM, dsimcha wrote: > > On 1/1/2011 6:07 PM, Andrei Alexandrescu wrote: > >> * parallel is templated on range, but not on operation. Does this affect > >> speed for brief operations (such as the one given in the example, > >> squares[i] = i * i)? I wonder if using an alias wouldn't be more > >> appropriate. Some performance numbers would be very useful in any case. > > > > Will benchmark, though the issue here is that I like the foreach syntax > > and this can't be done with templates as you describe. Also, IIRC (I'll > > do the benchmark at some point to be sure) for such examples memory > > bandwidth is limiting, so the delegate call doesn't matter anyhow. > I think anyone who wants to run something in parallel is motivated > primarily by increasing efficiency, so focusing on aesthetics would be > secondary and unsatisfactory for your target audience. Ok, next questions, and things I've wanted clarified for a while: 1. How are template alias parameters that reference variables in local scope going to work once fully debugged? There's a laundry list of Bugzilla issues related to such aliases and the spec isn't very clear. 2. As I'd strongly prefer to keep the foreach syntax, will opApply ever be allowed to work with an alias instead of a delegate? I ask because I was reading the DMD source code a while back and saw this feature half implemented. If so, I'll just leave it alone for now and switch to an alias when this is implemented.
Re: Moving to D
they are a D2 port for tango. It is not done. take source here: git clone git://supraverse.net/tango.git The job is almost done. everyone can do this job. Take a D2 compiler build and fix error
Re: const - Best practices
On 31/12/10 6:33 PM, Peter Alexander wrote: Ok, so while I'm still not 100% satisfied with the lack of logical const in D, I'm willing to see how far I can get without bitwise const without going crazy, and I just want to clarify some things. Andrei has commented a couple of times on the fact that D's const has more guarantees than C++'s const, and as a result you should use it a lot less often than you do in C++. Questions: 1. What exactly does this mean? What are the situations where you should use const in C++, but not in D? 2. When designing base classes and interfaces, when should you mark a member function as const? In C++ you would do so for any accessor, as they would be logically const. In D, you can't assume that an accessor is bitwise const (due to lazy initialisation and caching), so when do you make it const in the base class, and when do you leave it mutable? 3. When should you take const references in template functions (essentially same subquestions as above). Final note: my intention here is not to start another logical const vs. bitwise const war. I just want to know how the differences in const from C++ affect library design, and what the best practices for const-correctness are in D. Thanks in advance. Sorry for the bump, but there's at least three people here that would like an answer to this. Surely someone knows how to use const in D? :-) Additional question: why are none of Object's methods const, e.g. toString and toHash?
Re: Who here actually uses D?
"Andrej Mitrovic" wrote in message news:mailman.361.1293976216.4748.digitalmar...@puremagic.com... > On 1/2/11, Nick Sabalausky wrote: >> I have been avoiding doing GUI work because I'm not quite sure how far >> along >> QtD is, and the other D GUI libs aren't really suitable for me various >> reasons. >> > > FWIW gtkD seems to work fine on D2 (but I've only tried a few small > samples). It seems to be one of the few multiplatform GUI libs that > works with D2. DFL works, and it has a GUI designer which is pretty > cool. But it's Windows only. > Yea, my three primary critera for a GUI lib are: - Multiplatform - Native controls - Works on D2 To my knowledge, QtD is the only one that fits the bill. GTK fails horribly at #2. > But yeah, ultimately I'd want to use Qt as well. I used Qt for a while > with Python, it was so damn easy to build some GUI apps that look & > behave nice.
Re: Moving to D
"Adrian Mercieca" wrote in message news:ifpj8l$ln...@digitalmars.com... > Hi everyone, > > I am currently mulling if I should be adopting D as my (and subsequently > my company's) language of choice. > > We have great experience/investment in C++, so D seems - from what I've > seen so far - as the logical step; D seems to me to be as C++ done right. > I'm also looking at Go in the process, but Go seems to be more of a 'from > C' progression, whilst D seems to be the 'from C++' progression. > Personally, I love D and can't stand Go (the lack of exceptions, generics, metaprogramming and decent memory-access are deal-breakers for me, and overall it seems like a one-trick pony - it has the interesting goroutines and that's about it). But since this is the D newsgroup you can probably expect we'll be bigger D fans here ;) > I am only worried about 2 things though - which I've read on the net: > > 1. No 64 bit compiler 64-bit code generation is on the way and is Walter's top priority. In the meantime, I would recommend taking a good look at whether it really is necessary for your company's software. Certainly there are many things that benefit greatly from 64-bit, but even as "in-vogue" as 64-bit is, most things don't actually *need* it. And there are still plenty of times when 64-bit won't even make any real difference anyway. But regardless, 64-bit is absolutely on the way and is very high priority. In fact, AIUI, the basic "Hello World" has been working for quite some time now. > 2. The Phobos vs Tango issue: is this resolved now? This issue represents > a major stumbling block for me. > If you use D2, there is no Tango. Just Phobos. And there are no plans for Tango to move to D2. If you use D1, Tango is really the "de facto" std lib because D1's Phobos is extremely minimal. (D1's Phobos was created way back before there was a real Phobos development team and Walter had to divide his time between language and library, and language was of course the higher priority.) So no, it's really not the issue it's been made out to be.
Re: Thread fails to start
Adam Conner-Sax Wrote: > == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article > > On 01/01/2011 06:02 PM, Adam Conner-Sax wrote: > > > As a way to learn D, I am writing a quick test setup for examining > > > different > > > ways of passing data from one set of threads to another. I am trying a > > > few > > > kinds of queues (resizeable array with locking, linked list with locking > > > and > > > lockfree with cas) and trying to also add message passing and then compare > > > performance. > > > > > > Anyway, I'm running into an odd case where a thread fails to start. The > > > code > > > simply hangs in the Threadgroup.create(...) call. I am printing (with > > > unbuffered i/o) right before the call to "create" and then as soon as the > > > threadfunction starts so as far as I can tell, the "create" call is made > > > but > > > the threadfunc never starts and "create" never returns. What OS are you using? ThreadGroup.create is extremely simple, the problem is almost definitely in either the thread startup code itself or in the preamble of your supplied thread routine. What would be great is if you could produce a minimal repro. The full source you included is a bit much to easily figure out where the problem may be. > > > It's repeatable but doesn't happen every time the queue is used. It > > > happens > > > sometimes when the queue is locking and sometimes when it is lockfree. > > > I'd be > > > happy to post code but for now I thought I'd just see if anyone can think > > > of > > > why that might happen or can provide some ideas for how to debug it. > > > > > > The code always starts the one consumer thread (via spawn. I'm learning!), > > > then loops over the producers and creates them in a threadgroup just so I > > > can > > > do a "joinAll" to wait for them to finish. Also, when the problem occurs, > > > it's always the first producer thread that fails. I never get 2 out of 4 > > > started, e.g. If you're using std.concurrency then don't start threads manually using core.thread. The mailbox for a thread is created by spawn, and you'll get a segfault trying to send a message to a thread started using core.thread. I could change this to throw an exception instead though. > So, in the normal case, I get matched "creating & starting..." and "started" > and > "in produce()" > > In the case where it hangs, all I get is "Creating and starting..." and then > it > stays forever (or as long as I have patience to leave it). I tried this twice. The first time I got partway into the third test and got a bus error. The second time (run via GDB) I have this on my screen and it's been this way for a while now: F,LL,Lk 8.87 64.41 970.64 0 505661.91 4512.36 starting consumer started. creating & starting producer in consume(...) in produce(...) Seems different from what you've experienced.
Re: GC conservatism -- again
> Sorry for not replying, I've had some personal issues recently that have > taken up all of my time. Your suggestion seemed workable for solving the > dereferencing issue, but leaving the destroyed objects in an invalid state > seems likely to cause weird bugs. And the objects can't safely be reset to > their initial state (ala. clear) after destruction for concurrency reasons. > So I'm not sure it will really help all that much in practice. It wouldn't > be a tremendous amount of work to try this out though. On the druntime-list, it was also pointed out that the assumption that related objects are collected either in the same run or in reference-order are not true for all GC-types, I.E. not for incremental GC:s. Therefore it seems like a bad semantic to impose on the GC, in case someone wants other GC:s some day. >> The problem I've encountered in D, is that support for complementary >> predictable allocation schemes which could alleviate some of the >> problems (i.e. reference-counting and tree-allocation), is quite weak. >> By weak, I mean undocumented and no supporting framework from the >> stdlib. In a perfect world, this could even work hand-in-hand with the >> GC, such that references to refcounted-object could be voided from the >> destruction of the reference-counted object. > There's been some talk of doing this, but other things have had priority. > >> Is this a discussion that should be held in Phobos/Tango, druntime, or >> on this list? > The druntime list would be most appropriate, but it has very few members > (partially because so few people are interested in this level of code, I > suspect). The most expedient solution would be to just write the code and > submit a patch for evaluation. > FYI: I don't have access to build-env for D2/druntime, but I've created an implementation for RefCounting for Tango, in http://www.dsource.org/projects/tango/ticket/2024. It might be of interest to port to druntime, with the mentioned D2-improvements to SmartRef.
Re: David Simcha's std.parallelism
dsimcha: > Andrei: > > * I think it does make sense to evaluate a parallel map lazily by using > > a finite buffer. Generally map looks the most promising so it may be > > worth investing some more work in it to make it "smart lazy". > > Can you elaborate on this? I'm not sure what you're suggesting. I think Andrei is talking about vectorized lazyness, I have explained the idea here two times in past. This isn't a replacement for the fully eager parallel map. Instead of computing the whole resulting array in parallel, you compute only a chunk of the result, in parallel, and you store it. When the code that uses the data lazily has exhausted that chunk, the lazy parallel map computes the next chunk and stores it inside, and so on. Each chunk is large enough that performing it in parallel is advantageous, but not large enough to require a lot of memory. An option is even self-tuning, let the library find the chunk size by itself, according to how much time each item computation (mapping function call) requires (this is an optional behaviour). If you have a read-only memory mapped file that is readable from several threads in parallel, the map may perform some operation on the lines/records of the file. If the file is very large or huge, and you want to collect/summarize (reduce) the results of the mapping functions in some way, then a lazy parallel map is useful :-) This looks like a special case, but lot of heavy file processing (1 - 5000 gigabytes of data) can be done with this schema (map-reduce). Bye, bearophile
Re: Who here actually uses D?
Sönke Ludwig: > Hmm by the way: the good news when talking abount LOC is, the number of > lines went down by half during the C++ -> D conversion, which is really > nice :) When I convert a good amount of C code to D I've seen that another thing you can do is to profile your D code and de-optimize parts of it that don't require performance, rewriting them in a higher-level style. So you are able to shrink the D code some more compared to the C or C++ starting code. In this shrinking refactoring work it is useful to know some higher level language too, because they train you a lot to write shorter code. Bye, bearophile
Re: David Simcha's std.parallelism
Andrei Alexandrescu Wrote: > I think David Simcha's library is close to reviewable form. Code: > > http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d > > Documentation: > > * why runCallable()? There's no runUncallable(). Does this even need to be public? It looks like an implementation detail. > * Should there be a makeAngel to undo makeDaemon? Or an isDaemon property ala. Thread. Though the chances of someone wanting to undo the isDaemon property once set are practically nil.
Re: David Simcha's std.parallelism
On 1/2/11 10:39 AM, dsimcha wrote: On 1/1/2011 6:07 PM, Andrei Alexandrescu wrote: I think David Simcha's library is close to reviewable form. Code: http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d Documentation: http://cis.jhu.edu/~dsimcha/d/phobos/std_parallelism.html Here are a few comments: * parallel is templated on range, but not on operation. Does this affect speed for brief operations (such as the one given in the example, squares[i] = i * i)? I wonder if using an alias wouldn't be more appropriate. Some performance numbers would be very useful in any case. Will benchmark, though the issue here is that I like the foreach syntax and this can't be done with templates as you describe. Also, IIRC (I'll do the benchmark at some point to be sure) for such examples memory bandwidth is limiting, so the delegate call doesn't matter anyhow. I think anyone who wants to run something in parallel is motivated primarily by increasing efficiency, so focusing on aesthetics would be secondary and unsatisfactory for your target audience. * Why is ThreadPool a class and what are the prospects of overriding its members? It's a class b/c I wanted to have reference semantics and a monitor. I could make it a final class, as I didn't design for overriding anything. Final should be it then. * Can't we define the behavior of break inside a parallel loop? I left the behavior of this undefined because I didn't have any good ideas about what it should do. If you can suggest something that would be useful, I'll define it. I'd rather not define it to do something completely arbitrary and not obviously useful b/c if we eventually come up w/ a useful semantic our hands will be tied. As Sean said - abort current computation I guess. * I think it does make sense to evaluate a parallel map lazily by using a finite buffer. Generally map looks the most promising so it may be worth investing some more work in it to make it "smart lazy". Can you elaborate on this? I'm not sure what you're suggesting. * waitStop() -> join()? I like waitStop() better, though join() is more standard and I've received this comment from some friends, too. If there's a strong preference for join(), then I'll change it rather than wasting time on bikeshed issues. If they called it "fork-waitStop parallelism" I'd like waitStop better, too. But they call it "fork-join parallelism". * why runCallable()? There's no runUncallable(). runCallable() is in the weird position of being exposed for the purpose of clarifying how running delegates and function pointers works, but not being a part of the public interface that is supposed to be used directly. I gave it a verbose name for clarity. Are you suggesting I just call it run? I'd think so, unless there are reasons not to. Thanks for working on this! Andrei
Re: Who here actually uses D?
Am 02.01.2011 14:51, schrieb Andrej Mitrovic: On 1/2/11, Sönke Ludwig wrote: My main project is abount 100.000 lines of code. Wow, that's pretty big. Building an operating system? :-) Is a simulation/game engine plus some more that I ported some years ago from C++ along with an editor application for the engine. The project started in 2001, that's why it has grown considerably by now - but well I hope to have a public version this year... Hmm by the way: the good news when talking abount LOC is, the number of lines went down by half during the C++ -> D conversion, which is really nice :)
Re: David Simcha's std.parallelism
On 1/1/2011 6:07 PM, Andrei Alexandrescu wrote: I think David Simcha's library is close to reviewable form. Code: http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d Documentation: http://cis.jhu.edu/~dsimcha/d/phobos/std_parallelism.html Here are a few comments: * parallel is templated on range, but not on operation. Does this affect speed for brief operations (such as the one given in the example, squares[i] = i * i)? I wonder if using an alias wouldn't be more appropriate. Some performance numbers would be very useful in any case. Will benchmark, though the issue here is that I like the foreach syntax and this can't be done with templates as you describe. Also, IIRC (I'll do the benchmark at some point to be sure) for such examples memory bandwidth is limiting, so the delegate call doesn't matter anyhow. * Why is ThreadPool a class and what are the prospects of overriding its members? It's a class b/c I wanted to have reference semantics and a monitor. I could make it a final class, as I didn't design for overriding anything. * Can't we define the behavior of break inside a parallel loop? I left the behavior of this undefined because I didn't have any good ideas about what it should do. If you can suggest something that would be useful, I'll define it. I'd rather not define it to do something completely arbitrary and not obviously useful b/c if we eventually come up w/ a useful semantic our hands will be tied. * I think it does make sense to evaluate a parallel map lazily by using a finite buffer. Generally map looks the most promising so it may be worth investing some more work in it to make it "smart lazy". Can you elaborate on this? I'm not sure what you're suggesting. * waitStop() -> join()? I like waitStop() better, though join() is more standard and I've received this comment from some friends, too. If there's a strong preference for join(), then I'll change it rather than wasting time on bikeshed issues. * The documentation should use more examples. Currently it uses entities without defining them (Task, TaskPool etc.) Will do when I get a chance. * why runCallable()? There's no runUncallable(). runCallable() is in the weird position of being exposed for the purpose of clarifying how running delegates and function pointers works, but not being a part of the public interface that is supposed to be used directly. I gave it a verbose name for clarity. Are you suggesting I just call it run? * Should there be a makeAngel to undo makeDaemon? Will fold into the next revision. I've never had a use for it, but it's trivial to implement, orthogonal with the rest of the design, and symmetry is generally a good thing. Overall, to prepare this for the review process, the documentation should be grown considerably with motivating examples and relevant benchmarks. We are modeling our review process after http://www.boost.org/community/reviews.html. The first realization of the process has been for std.datetime, and it seems to have been a success. Andrei
Re: Thread fails to start
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> On 01/01/2011 06:02 PM, Adam Conner-Sax wrote:
> > As a way to learn D, I am writing a quick test setup for examining different
> > ways of passing data from one set of threads to another. I am trying a few
> > kinds of queues (resizeable array with locking, linked list with locking and
> > lockfree with cas) and trying to also add message passing and then compare
> > performance.
> >
> > Anyway, I'm running into an odd case where a thread fails to start. The
> > code
> > simply hangs in the Threadgroup.create(...) call. I am printing (with
> > unbuffered i/o) right before the call to "create" and then as soon as the
> > threadfunction starts so as far as I can tell, the "create" call is made but
> > the threadfunc never starts and "create" never returns.
> >
> > It's repeatable but doesn't happen every time the queue is used. It happens
> > sometimes when the queue is locking and sometimes when it is lockfree. I'd
> > be
> > happy to post code but for now I thought I'd just see if anyone can think of
> > why that might happen or can provide some ideas for how to debug it.
> >
> > The code always starts the one consumer thread (via spawn. I'm learning!),
> > then loops over the producers and creates them in a threadgroup just so I
> > can
> > do a "joinAll" to wait for them to finish. Also, when the problem occurs,
> > it's always the first producer thread that fails. I never get 2 out of 4
> > started, e.g.
> >
> > I am truly enjoying learning D. Coming from a C++ and C# background, it's a
> > pleasure.
> >
> > Any ideas would be appreciated.
> >
> > Thanks!
> >
> > Adam
> Welcome. I suggest you post some code to serve as a basis for suggestions.
> Andrei
Okay, thanks. Was trying to avoid subjecting you all to my naive first try
code...
alias void delegate(in Data_Packet d) sender;
void produce(sender send, Random r, int packets, int packets_per_s, int
us_variability)
{
debug { printf("in produce(...)\n"); }
int packet_spacing = 1000/packets_per_s; //units are 100ns
// make sure we can't have -tve sleep
int packet_variability = min(10*us_variability,packet_spacing+1);
packets--; // one extra produced after loop with signal to end
int counter = 0;
while (counter++ < packets) {
Data_Packet data;
data.pTime = systime();
debug (5) { printf("Sending t=%i\n",data.pTime.value); }
debug (3) { printf("S"); }
send(data);
Thread.sleep(packet_spacing +
uniform(-packet_variability,packet_variability,r));
}
Data_Packet data;
data.last = true;
data.pTime = systime();
send(data);
}
for (int k=0; k3L-"@t*...@9ferWT-"B`@("!T:&es...@=f%l*2`-"B`@("![
M#0H@("`@("!V86QU92`]('9A;#L-"B`@("`@(&YE>'0@/2!N=6QL.PT*("`@
M('T-"B`@("!4('9A;'5E.PT*("`@($YO9&4@;F5X=#L-"b...@?0t*("`-"B`@
M#0H@(&EN=&5R9F%C92!1=65U92`-"B`@>PT*("`@('9O:60@R!F:7)S="`](&QAPT*("`@("`...@3f]d92!t;7`@/2!N97<@3F]D92AT
M*3L-"B`@("`@('-Y;F-HPT*"71M<"YN97AT(#T@
M;&%S="YN97AT.PT*"6QAPT*"71M<"`](&9I'0[#0H):6...@*'1M<"!I'0@/2!T;7`N;F5X=#L-"B`@
M("`@('T-"B`@("`@(')EPT*("!PR!L87-T(#T@;F5W($YO9&4[('T-"B`@("!T:&ES*"D@>R!R97-E
M="@I.R!]#0H@("`...@#0h@("`@6YC
M:')O;fez...@*'1H:7,I('L-"@ET;7`N;F5X="`](&QA'0@/2!T;7`["0T*("`@("`...@?2`-"B`@("!]#0H@("`...@#0h@("`@
M8F]O;"!C;VYS=6UE*&]U="!4(')EPT*("`@("`...@3f]d
M92!T;7`[#0H@("`@("!S>6YC:')O;fez...@*'1H:7,I('L-"@ET;7`@/2!L
M87-T+FYE>'0[#0H):6...@*'1M<"!IR!R97-E="@I.R!]#0H@("`@("`@(`T*("`@('-TR!R971UR!R971UPT*"71M<"YN97AT(#T@;&%S="YN97AT.PT*("`@("`@
M?2!W:&EL92`H(6-APT*("!PR!R97-E="@I.R!]#0H@
M("`@("`@(`T*("`@('-TR!R971UR!R971UPT*"71M<"YN97AT(#T@
M;&%S="YN97AT.PT*("`@("`...@?2!w:&EL92`H(6-AR!R971U
MPT*("`@
M("`...@8g5f9f5r7r`](&YE=R!46W-T87)T:6YG7V)U9F9EPT*"61E;&5T92!B=69F97)?.PT*("`@("`@
M?0T*#0H@("`-"B`@("!V;VED('!R;V1U8V4H:6...@5"!T*0T*("`@('L-"B`@
M("`@('-Y;F-HPT*"2HH8W5RPT*("`@("`@F5D("AT
M:&ES*2![("`@("`-"@EI9B`H8W5RPT*("!PPT*("`@("`@3L*
M:6UP;W)T('-T9"YT'1R82!P2QP86-K971?=F%R:6%B:6QI='DL7,I(`H@('L*("`@(&1E
M8G5G('L@<')I;G1F*")I;B!C;VYS=6UE*"XN+BE<;B(I.R!]"B`@("!$871A
M7U!A8VME="!D871A.PH@("`@:6YT('!A8VME=%]N=6UB97(["B`@("!D96QA
M>7,N;&5N9W1H(#T@;G5M8F5R7W!A8VME=',["B`@("!W:&EL92AP86-K971?
M;G5M8F5R(#P@;G5M8F5R7W!A8VME=',I('L*("`@("`@:6...@*')E8V5I=F5?
M9BAD871A*2D*"61E;&%YR!D96QA>7-;<&%C:V5T7VYU
M;6)E7-T:6UE*"D[(`H@("`...@9&5B=6<@*#4I
M('!R:6y...@b4f5c)v...@870@=#TE:5QN(BQC5&EM92YV86QU92D["B`@("!4
M:6-K%QT/&UI;CY<="`\;6%X/EQN7U]?
M7U]?7'1?7U]?7U]<=%]?7U]?7'1?7U]?7UQT7U]?7'1?7U]?7UQT7U]?7U]<
M=%]?7U]?7U\B.PH*("!PPH@("`@("!N=6U?<')O9'5C97)S7R`](&YU;5]P&EM=6U?
M*3L*("`@("`...@9f]r;6%T=&5D5W)I=&4H=W)I=&5R+")<="4U+C)F(BQA=F=?
M;6EN7RD["B`@("`@(&9O%\I.PH@("`@("!R971UPH@("`@("!Q7VYA;65?(#T@
M<2YN86UE.PH@("`@("!Q+G)E7,["B`@("`@(&)O;v...@8v]n7,["B`@("`@(%1HPH)8V]NR!C;VYS=6UE*&1E;&5G871E(&)O;VPH;W5T($1A
M=&%?4&%C:V5T(&0I('L@R!PPH)("!D96)U9R![('!R:6y...@b8w)E871I;F<@)B!S=&%R=&EN
M9R!PW!R;V1U8V4H9&5L96=A=&4@
M=F]I9"AI;B!$871A7U!A8VME="!D*2![('$N<')O9'
Re: Advocacy (Was: Who here actually uses D?)
> So why is D being advertised as a systems programming language? By saying > Linus would not find D appealing you are basically saying kernel developers > would not find it appealing. "Systems programming" in my vocabulary is not limited to JUST kernel programming. To be honest, I think D has a pretty long way to go to be good for kernel development (irregardless of Linus/Linux). For kernel development I suspect stop-the-world GC, or any non-deterministic GC for that matter is a big no-no. Also, imagine the current frustration over compiler/stdlib-bugs if you're operating in kernel-space, with no GDB to help you track it down. That's not to say I don't think D COULD be used for kernel development, but at the current state of things, I don't think it's really a promising cost/benefit. But systems development in my world doesn't end with the kernel, system-development is everything up to the applications the users really want, all libraries, codecs, file-format implementations etc. I.E. i would be really interested to see what kind of systems-API could be developed directly against the kernel ABI of *BSD or Linux, if you ignore the libc-layer. I.E. what would a completely event-driven (twisted) close-to-os stdlib look like, and how would that improve the simplicity of writing performant I/O-driven applications? Currently, however, I think the D community (which I'm increasingly being pulled into by common interests) should really focus on low-hanging fruit, and proving to the larger developer-community why D is worthwhile. In this area, I think the timing of D is perfect, given the current trend of cheaper hardware, rather than more powerful hardware. For instance are there currently any good database-implementations in D, suitable for beating the Tracker/Beagle/Strigi Desktop-search mess of the open source desktops? Integrating such database with the upcoming Linux fanotify API and libextractor should be an achievable goal, and could perhaps even be a compatible drop-in replacement for I.E. Tracker, but with lower footprint? I also have a stripped binding for FUSE as part of BitHorde, so implementing a fuse-based metadata-browser should be doable for integrating metadata directly into the Linux VFS. Definitely good for showing off.
Re: Advocacy (Was: Who here actually uses D?)
On Sun, 02 Jan 2011 17:17:55 +0200, Ulrik Mikaelsson wrote: "Messier" is a matter of perspective. C is a beautifully clear and mature language, but some of the missing features (delegates for one) often leads to unnecessarily convoluted code. Exactly, and there are too many of these simple but necessary tools, which eventually makes the language "complex". People has strange beliefs, rediscovering a feature in every five lines of code and believing the said language is simple, elegant, modern... is one of them. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Advocacy (Was: Who here actually uses D?)
"Messier" is a matter of perspective. C is a beautifully clear and mature language, but some of the missing features (delegates for one) often leads to unnecessarily convoluted code. Hejlsberg describes it quite well as "Simplexity", roughly speaking, when the tools are too crude, the produced result might not look as refined as with better tools. http://www.artima.com/intv/simplexity.html 2011/1/2 Jimmy Cao : > On Sun, Jan 2, 2011 at 12:38 AM, Caligo wrote: >> >> I agree with you on this. For example, Linus Torvald hates C++ and >> probably for good reasons. > > I think he hates C++ because it's messier than C. Many things are messier > than C, including D. > > > > >
Re: Advocacy (Was: Who here actually uses D?)
While we're on topic of advocacy, I've just noticed these two topics on reddit: http://www.reddit.com/r/programming/comments/eup9a/creating_database_schemas_with_go/ http://www.reddit.com/r/programming/comments/euuuw/creating_database_schemas_with_c/ Someone came up with a hackish way to do database schemas in Go, but it left Reddit unimpressed (ha!). Another guy created the same thing in C. Now would be a perfect time to show how it's done in D and gain a little rep. I'm sure this would be piece of cake to do in D since there's not a lot of code, any volunteers? (me, I wouldn't know the first thing about databases so I'd likely screw something up :p). On 1/2/11, Andrei Alexandrescu wrote: > On 1/2/11 4:35 AM, Walter Bright wrote: >> Caligo wrote: >>> Yeah, I don't think Linus would find D appealing. >> >>> So why is D being advertised as a systems programming language? By >>> saying Linus would not find D appealing you are basically saying >>> kernel developers would not find it appealing. >> >> Not at all. He's hardly the only systems programmer. I'd expect the >> number of different opinions about what makes a good systems language to >> be about equal to the number of systems developers. > > If not greater than :o). > > Andrei >
Re: Who here actually uses D?
On 01/01/2011 11:22 PM, Robert Clipsham wrote: Having seen a post by Peter Alexander (in Re: D for game development), mentioning some of the issues he's hit I thought I'd post this. I've been in his shoes (every other time I use D it seems), and feel I should ask - who here uses D, and to what extent? I'm mostly interested in those of you with 1000 Line plus projects in D, as that's when I've found I start hitting issues. Just to clarify, for those D purists among you... I'm not trolling, just curious (I wouldn't normally have asked, but now I know I'm not paranoid and the only one having problems, I thought I'd ask). I used D for one year now, converting my years-long C++ home project (50K lines). I recently quit my job and i am starting a new small venture (real-time graphics) in which i will use D for some of the components. I am happy with it, and i will slowly move to the new features. I am specially interested in multithreading. When it is worth (as in useful for somebody) i will open source some of the D components. j.
Re: Moving to D
On 1/2/11 6:44 AM, Adrian Mercieca wrote: On Sun, 02 Jan 2011 11:21:38 +, bioinfornatics wrote: LDC exist for D2: https://bitbucket.org/prokhin_alexey/ldc2 Same for tango a port to D2 exist, the job is not done: git clone git://supraverse.net/tango.git any help are welcome Geez! that was quick! I see that the community is very, very alive. Ok - that clears the issues re 64bit and Phobos vs Tango; Guess Phobos is the way to go with D2. Thanks a lot for your responses - very much appreciated. - Adrian. I also recommend reading Adam Ruppe's recent posts. His tips on getting great work done in D in spite of its implementation's current imperfections are very valuable. Andrei
Re: Advocacy (Was: Who here actually uses D?)
On 1/2/11 4:35 AM, Walter Bright wrote: Caligo wrote: Yeah, I don't think Linus would find D appealing. So why is D being advertised as a systems programming language? By saying Linus would not find D appealing you are basically saying kernel developers would not find it appealing. Not at all. He's hardly the only systems programmer. I'd expect the number of different opinions about what makes a good systems language to be about equal to the number of systems developers. If not greater than :o). Andrei
Re: Who here actually uses D?
== Quote from Andrej Mitrovic (andrej.mitrov...@gmail.com)'s article > On 1/2/11, Nick Sabalausky wrote: > > I have been avoiding doing GUI work because I'm not quite sure how far along > > QtD is, and the other D GUI libs aren't really suitable for me various > > reasons. > > > FWIW gtkD seems to work fine on D2 (but I've only tried a few small > samples). It seems to be one of the few multiplatform GUI libs that > works with D2. DFL works, and it has a GUI designer which is pretty > cool. But it's Windows only. > But yeah, ultimately I'd want to use Qt as well. I used Qt for a while > with Python, it was so damn easy to build some GUI apps that look & > behave nice. As far as I'm aware, gtkD is not 64bit-ready. A lot of the code (or so I've come to assume from some comments made in IRC yesterday) assumes that sizeof .length is 4 (as is on 32bits). I've also ran into one or two bugs using gtkD applications with more recent gtk releases. Some deadlocks when performing one or two actions.
Re: Who here actually uses D?
On 1/2/11, Sönke Ludwig wrote: > My main project is abount 100.000 lines of code. Wow, that's pretty big. Building an operating system? :-)
Re: Who here actually uses D?
On 1/2/11, Nick Sabalausky wrote: > I have been avoiding doing GUI work because I'm not quite sure how far along > QtD is, and the other D GUI libs aren't really suitable for me various > reasons. > FWIW gtkD seems to work fine on D2 (but I've only tried a few small samples). It seems to be one of the few multiplatform GUI libs that works with D2. DFL works, and it has a GUI designer which is pretty cool. But it's Windows only. But yeah, ultimately I'd want to use Qt as well. I used Qt for a while with Python, it was so damn easy to build some GUI apps that look & behave nice.
Re: Advocacy (Was: Who here actually uses D?)
> Linus has written a tool to strengthen the C type system: > http://en.wikipedia.org/wiki/Sparse Studying Sparse a bit more I've seen it's not that complex system. It does simple things. Bye, bearophile
Re: Deprecate ReturnStatements?
Manfred Nowak: > Walters remark suggests that the dysmorphism between returnStatement and > expressionStatement is based on arbitrariness: > ... > To make this homomorphic it might be adequate to view returning as an > attribute of an expressionStatement: To better contextualize Manfred notes I suggest this post of mine: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=23652 Bye, bearophile
Re: Nimrod language
Iain Buclaw: > Less is not more in this case. I agree with elsif (Perl does it right too :) I was talking about vertical alignments (4 with 4), not about saving one or two chars :-) Bye, bearophile
Deprecate ReturnStatements?
Walter Bright wrote:
> writing generic code so that the same code can be generated for void
> and non-void return values.
http://d.puremagic.com/issues/show_bug.cgi?id=5399 (cited 01/02/11)
The docs include:
| Expressions that have no effect, like (x + x), are illegal in
| expression statements. If such an expression is needed, casting it to
| void will make it legal.
http://www.digitalmars.com/d/2.0/statement.html#ExpressionStatement
| If the Expression has no side effects, and the return type is void,
| then it is illegal.
http://www.digitalmars.com/d/2.0/statement.html#ReturnStatement
( both cited 01/02/11)
Walters remark suggests that the dysmorphism between returnStatement and
expressionStatement is based on arbitrariness: generating an expression
by generic code must still take into account, whether the genrated
expression will be used for an expressionStatement or a returnStatement.
This is because casting to void will not legalize an expression without
side effects for a returnStatement, but for an expressionStatement only.
To make this homomorphic it might be adequate to view returning as an
attribute of an expressionStatement:
`(void).return;' instead of `return;' whithin `void f(){}'
`(1).return;'instead of `return 1;' whithin `int f(){}'
and `(cast(void) 1).return;' whitin `void f(){}' to make returning a
constant to void as legal as using a constant as an expression:
`cast(void) 1;'.
-manfred
Re: Nimrod language
== Quote from bearophile (bearophileh...@lycos.com)'s article > spir: > > "elif" is nearly unguessable: should be "elseif" or "elsif" (--> Lua does it right). > "elif" is 4 chars long, as "else", this is not a random choice. Less is not more in this case. I agree with elsif (Perl does it right too :)
Re: Moving to D
On Sun, 02 Jan 2011 11:21:38 +, bioinfornatics wrote: > LDC exist for D2: https://bitbucket.org/prokhin_alexey/ldc2 Same for > tango a port to D2 exist, the job is not done: git clone > git://supraverse.net/tango.git any help are welcome Geez! that was quick! I see that the community is very, very alive. Ok - that clears the issues re 64bit and Phobos vs Tango; Guess Phobos is the way to go with D2. Thanks a lot for your responses - very much appreciated. - Adrian.
Re: Less commas
Walter:
> If you really want to be productive with this, rather than sitting back and
> thinking up imaginary problems, do things like peruse the bug database of a
> large open source project. Look for patterns of problems that might be headed
> off with language solutions.
A common bug in Linux kernel:
if(!state->card->
ac97_status&CENTER_LFE_ON)
val&=~DSP_BIND_CENTER_LFE;
The fix is to replace (!E & C) with (!(E & C)).
Currently D acts like C:
void main() {
uint x, y;
if (!x & y) {}
}
- 96 instances of this bug in Linux from 2.6.13 (August 2005) to v2.6.28
(December 2008).
- 58 instances of this bug in 2.6.20 (February 2007)
- 2 in Linux-next (October 10, 2009)
They have faced and reduced the number of such bugs using Coccinelle, see pages
8-9 here:
http://coccinelle.lip6.fr/papers/fosdem10.pdf
See you later,
bearophile
Re: Advocacy (Was: Who here actually uses D?)
On Sun, 02 Jan 2011 13:08:08 +0200, spir wrote: I thank Walter / Digital Mars heartfully for such a present to the programming community. Still, I would advocate for an independant reference site dedicated to the language properly speaking, without a Digital Mars logo on top of the front page (why is it currently there?); but instead as many references and pointers to Walter and the Digital Mars site as you like. This could have an adverse effect. Commercial users of D will most likely find it more satisfying to know that there is a company backing D, from which they could get commercial support if required. Similarly, if the main reference website of a language is not affiliated with the company behind the language, it puts into serious doubt the competence of said company. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Advocacy (Was: Who here actually uses D?)
On Sun, 2 Jan 2011 10:19:48 +0100 Gour wrote: > Caligo> So why is D being advertised as a systems programming > Caligo> language? By saying Linus would not find D appealing you are > Caligo> basically saying kernel developers would not find it appealing. > > Do Linus & co. have to put label on something to qualify as > system-programming language? > > Here is something interesting: > > http://tommd.wordpress.com/2009/09/13/kernel-modules-in-haskell/ Oberon is both a system programming lang very different from C and a system written in it that is/was rather innovating. > For me, D looks as the most-promising general programming language > having good-enough performance and being safe-enough - iow. sweet > spot: C(++) <--- D ---> Haskell. Yes. I find simply wrong presentations starting with "D is a system programming language..." D is more than that. (And is/will certainly be more used in other domains that in system programming) Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: Advocacy (Was: Who here actually uses D?)
Frankly, I'd love to sit down and talk about it with Linus over beers. Now i have read the entire thread. He and that community made me sick, they just lynched the OP. Your posts also didn't get the most objective responses either. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Nimrod language
On Sun, 02 Jan 2011 04:58:28 -0500 bearophile wrote: > - I like the idea of AST macros, they are powerful, but they add a > significant amount of complexity to the language. So I am not pushing a lot > for them, despite I almost hate string mixings and creating code with string > snippets. I feel exactly the same. Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: Nimrod language
spir: > "elif" is nearly unguessable: should be "elseif" or "elsif" (--> Lua does it > right). "elif" is 4 chars long, as "else", this is not a random choice. > IIRC, said usability studies were about indented code structure (as opposed > to token-delimited structure). I have never read anything in studies about > ':'. This is from Guido's blog: http://python-history.blogspot.com/2009/02/early-language-design-and-development.html >However, ABCs authors did invent the use of the colon that separates the >lead-in clause from the indented block. After early user testing without the >colon, it was discovered that the meaning of the indentation was unclear to >beginners being taught the first steps of programming. The addition of the >colon clarified it significantly: the colon somehow draws attention to what >follows and ties the phrases before and after it together in just the right >way.< Bye, bearophile
Re: Advocacy (Was: Who here actually uses D?)
Walter: > Based on what? It's just a lump of opinions of mine, I have not written a microkernel yet :-) But I am reading a lot, I am learning and I will be able to write this kind of code too. Some people have tried to write a kernel with Python. D2 is a nice language to use, it allows some low level control, inline asm, and it compilation model comes from C with things added. So I am sure it's possible to write a good enough kernel with D2. So it's a matter of how much the language is fit for this purpose, it's not a binary thing. Is D2 the best conceivable language to write a kernel? I don't think so (but I am often wrong). For a kernel writer D2 doesn't offer a lot of control on low level matters, like how the compiler compiles and optimizes code (see the thread about "guaranteed optimizations". This is a case where you don't want to "Let the compiler implementors do their job" because you lose low-level control on the code produced and this introduces bugs). This was one of the main complaints of Linus against C++ for Linux kernel development. D2 type system is refined and much more powerful than the C one. And people have written many kernels with C (C plus with few nonstandard extensions). But if you want to write a modern kernel you may want a type system more powerful than the C and D ones, that give stronger static guarantees. Linus has written a tool to strengthen the C type system: http://en.wikipedia.org/wiki/Sparse In another thread I have written something about typed assembly, useful to make less wild parts written in assembly: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=125815 In some situations linear types too help: http://en.wikipedia.org/wiki/Linear_types The Spec# language and the experimental Verve kernel we have discussed a bit in past show possible directions for future kernels, they require a pretty strong static analysis. The Sparse tool shows that some of those type system feature may be added later to D with an external tool. But Verve shows that sometimes you need something more built-in. Bye, bearophile
Re: Nimrod language
On Sun, 02 Jan 2011 01:46:46 -0500 bearophile wrote: > > My fantasy: bearophile goes to the Nimrod forum and says "Hey, how about > > this D language, seems interesting..." :o) > > That fantasy of yours means that I am interested in using my time to explain > to Nimrod developers what's good in D, what may be modified or improved, to > steal some of the good ideas of the D language for the development and > spreading of Nimrod :-) That's a Very Good Thing: imo, the programming community desperately needs Bearophile's (instead of each designer not even beeing aware of alternatives and/or believing in one only way and/or wearing blinders). Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: Who here actually uses D?
Am 01.01.2011 23:22, schrieb Robert Clipsham: Having seen a post by Peter Alexander (in Re: D for game development), mentioning some of the issues he's hit I thought I'd post this. I've been in his shoes (every other time I use D it seems), and feel I should ask - who here uses D, and to what extent? I'm mostly interested in those of you with 1000 Line plus projects in D, as that's when I've found I start hitting issues. Just to clarify, for those D purists among you... I'm not trolling, just curious (I wouldn't normally have asked, but now I know I'm not paranoid and the only one having problems, I thought I'd ask). My main project is abount 100.000 lines of code. Most of the time now, I stay away from new features - including pure and the new concurrency model. However, I use the const/immutable system since the beginning. Also quite some string-mixin stuff, templates and CTFE. (*) At times I'm hitting multiple bugs a day, but by far the most devastating bugs are those freakin' unexpected OPTLINK terminations (e.g. http://d.puremagic.com/issues/show_bug.cgi?id=4808). With that code base it is practically impossible to make repro cases or workarounds for those bugs and they slip up every now and then (right now I have one of them). Unfortunately those are often bugs that lie there for years. I remember someone said there should be no known new regressions in the compiler - the reality seems to be quite different here and I quit D programming for multiple periods of months because of such beasts. (Fortunately most of the time there is one method of compilation or operating system that successfully builds). The other kind of bug that I find really frustrating because it is hard to discover and takes a lot of time to track down and work around is that kind with corruped data/wrong code. Todays examples are http://d.puremagic.com/issues/show_bug.cgi?id=3863 and some postblit stuff that I have not yet been able to track down. At least in times when it is possible to program without hitting those issues, D somehow is able to close the gap again with its nice and efficient language constructs. But I think the priority for fixing bugs really has to be changed because that is what is driving people away (for good reason): Blockers, Regressions and maybe criticals should be taken more serious, as well as the top votes in bugzilla should be handled somehow. Sönke (*) I think the fact that only very few people use new features and the rest is mostly just doing smaller tests with them is a real problem in the language/compiler development. All of those people think "I will use it when it's ready", but it will never or really slowly reach that stage beause of missing input. This also means first use feedback for new features should be taken more serious - I've often seen important observations vanish in time and meanwhile the underlying problem was consolidated in the language.
Re: Nimrod language
On Sat, 01 Jan 2011 18:36:17 -0500 bearophile wrote: > spir: > > > (Even reproduced "elif" > > Python doesn't have the switch statement, so to write a switch you sometimes > use a sequence of if statements, in this case "elif" helps keep the code more > tidy: > > x = 3 > if x == 0: > pass > elif x = 1: > pass > else: > pass Sorry, my words were too imprecise; and too strong for such a little issues. I aggre with you, but it's not my point (I wrote "elif" in quote: it's about the term). "elif" is nearly unguessable: should be "elseif" or "elsif" (--> Lua does it right). > > and kept the stupid ':' of Python ;-). Sorry again, for "stupid". > It comes from usability studies on the ABC language. If you are going to use > a Python-like syntax, then removing those ":" is stupid. IIRC, said usability studies were about indented code structure (as opposed to token-delimited structure). I have never read anything in studies about ':'. This non-token, that does not mean anything, should at best be optional, just like the ';' statement terminator (which is allowed in python, but no one uses it outside multi-statement lines, probably because, precisely, it does not mean anything). When I used python everyday, I constantly repeted 2 syntax errors: * forgetting ':' (just like forgetting ';' in D) * using '=' instead of '==' (obvious reason, same in D) These are for me 2 grammatical design errors. > > "Parameters are constant in the procedure body. Their value cannot be > > changed because this allows the compiler to implement parameter passing in > > the most efficient way. > > I have missed that part of the docs. What kind of "most efficient way"? nsure. I guess the author refers to the possibility to pass _any_ non-var parameter by ref under the hood if more efficient, since it won't be changed. (arrays, which have copy semantics in Nimrod , its tuples ~ structs, and object types also are value types apparently) I plan to do the same for my toy project one day. Pleased to see I'm not the only fool ;-) Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: Moving to D
LDC exist for D2: https://bitbucket.org/prokhin_alexey/ldc2 Same for tango a port to D2 exist, the job is not done: git clone git://supraverse.net/tango.git any help are welcome
Re: Advocacy (Was: Who here actually uses D?)
On Sun, 2 Jan 2011 06:27:41 +0100 Ulrik Mikaelsson wrote: > Just discovering > http://d-programming-language.org/ with much nicer presentation of the > docs I've already seen, raised my motivation for D just as much as any > random dozen solved bugs from bugzilla. I am very much for helping and develop an independant, community-driven, site dedicated to D. At my first contact with the language, just discovering it _apparently_ was a (private, for profit) company's product was enough to let me turn back, and ciao! Whatever the language's qualities. (That it was free as in free beer did not make any difference.) I thank Walter / Digital Mars heartfully for such a present to the programming community. Still, I would advocate for an independant reference site dedicated to the language properly speaking, without a Digital Mars logo on top of the front page (why is it currently there?); but instead as many references and pointers to Walter and the Digital Mars site as you like. The first contact is very important. If we take this as an opportunity to improve presentation and above all documentation: superb! (*) If we honestly present the language including its present drawbacks, defaults, and issues in general: bravo! (*) 2011: the year of D? Denis (*) Possibly an even greater entry barrier than the present unfinished state of D2. (EDIT: Also target non-C++ programmers. And do this _seriously_. The statemtent in TDPL that programmers knowing a C++-like language will enjoy a _slight_ advantage is quite an understatement, imo: the whole book silently refers to loads of notions perticular to this language family.) (**) The page at http://d-programming-language.org/comparison.html should also list all D2 issues, imo. Let us take example on Nimrod's doc that fears not telling about (present and lasting, accidental and designed) shortcomings of the language. This adult attitude would be far more appealing than possibly deceiving statements, imo, and even more than non-told facts. -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: Who here actually uses D?
On 2/01/11 3:59 AM, Walter Bright wrote: Peter Alexander wrote: I don't use Windows personally, but OPTLINK seems to still be quite a major cause of pain, with the crashes (http://h3.gd/devlog/?p=31) and OMF format that no one uses. As the link says, that problem was fixed. Well, the link says that it was fixed, but then Tomasz got the crash again (according to his blog post). Now he has completely given up on D and he was one of the most active D developers out there.
Re: Moving to D
Adrian Mercieca wrote: > Hi everyone, > > I am currently mulling if I should be adopting D as my (and subsequently > my company's) language of choice. > > We have great experience/investment in C++, so D seems - from what I've > seen so far - as the logical step; D seems to me to be as C++ done right. > I'm also looking at Go in the process, but Go seems to be more of a 'from > C' progression, whilst D seems to be the 'from C++' progression. > > I am only worried about 2 things though - which I've read on the net: > > 1. No 64 bit compiler > 2. The Phobos vs Tango issue: is this resolved now? This issue represents > a major stumbling block for me. > > Any comments would be greatly appreciated. > > Thanks. 64 bit support is the main focus of dmd development at the moment. I take it that you would first evaluate D for a while, possibly 64-bit support will arrive when you are ready and need it. gdc development is also going strong. As for tango vs phobos the situation is now that most of development in the previous version of D (released circa 2007 iirc) is done with Tango. There is also a fine 64-bit compiler for D1, LDC. The feature set of D1 is frozen and significant (some backwards incompatible) changes have been made since. There isn't any sign that Tango will be ported to D2 and phobos is shaping up to be a fine library for D2. Some parts of phobos are still in flux, though other parts are more stable. Perhaps you'll find this thread about experiences with D worth a read: http://thread.gmane.org/gmane.comp.lang.d.general/45993
Re: Moving to D
Adrian Mercieca wrote: 1. No 64 bit compiler The 64 bit dmd compiler (for Linux) is nearing alpha stage. 2. The Phobos vs Tango issue: is this resolved now? This issue represents a major stumbling block for me. Tango does not exist for D2.
Re: Advocacy (Was: Who here actually uses D?)
bearophile wrote: I think Linux devices are used through some kind of virtual table. But he needs control on how things are implemented (I think C++ Standard doesn't specify how virtual calls are implemented). This is a red herring. In practice, not only does every C++ compiler I've ever heard of do it the same way, but Linus certainly has enough pull to get g++ to do it his way. (10 years ago g++ did do it differently than other C++ compilers, but they since changed it to match.)
Re: Advocacy (Was: Who here actually uses D?)
bearophile wrote: But D is not currently the best fit to write a kernel Based on what?
Re: Advocacy (Was: Who here actually uses D?)
Nick Sabalausky wrote: Yea, it's not as if Linus is all there is to kernel development. Frankly, I'd love to sit down and talk about it with Linus over beers.
Re: Advocacy (Was: Who here actually uses D?)
Caligo wrote: Yeah, I don't think Linus would find D appealing. So why is D being advertised as a systems programming language? By saying Linus would not find D appealing you are basically saying kernel developers would not find it appealing. Not at all. He's hardly the only systems programmer. I'd expect the number of different opinions about what makes a good systems language to be about equal to the number of systems developers.
property-like data members
Hello,
Using properties allows travesting a method call into direct data access. What
if the underlying member actually is plain data? Would it be possible to
provide a real data member where the language expects a property (for instance
as range empty & front properties)?
Is there any difficulty for the compiler to check whether a data member of the
same name and correct type exists? To help it, we could mark said data member
with an @property hint. For instance:
struct String {
char[] cs;
private uint index = 0; // for traversal
@property char front;
@property bool empty;
this (string characters) {
this.cs = characters.dup;
this.empty = (this.cs.length == 0);
if (this.cs.length > 0)
this.front = this.cs[0];
}
@property void popFront () {
++ this.index;
this.empty = (this.index >= this.cs.length);
if (this.index < this.cs.length)
this.front = this.cs[this.index];
}
}
unittest {
auto s = String("abc");
// works fine
while (! s.empty) {
auto c = s.front;
write(c,' ');
s.popFront;
}
writeln();
// works not
//~ foreach (char c ; s) write(c,' ');
writeln();
}
Here, popFront does not only advance, it correctly sets empty and front, so
that a single method is needed. But the language expects a method-property
(actually, it complains for missing opApply *).
I'm a bit troubled to implement methods where plain data does the job and
conceptually better matches my model (maybe it's only me: I wish the code to
mirror my views).
[Note: I do not mean at all the current imput-range model is overkill or
anything similar. It is certainly more general as is, and I do not have enough
various use cases to give any opinion on that! The given example is just that:
an example.]
Denis
(*) Would be good to update the error message:
Error: no property 'opApply' for type 'String'
Error: opApply() function for String must return an int
-->
Error: type String does not provide any iteration method.
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: Advocacy (Was: Who here actually uses D?)
Nick Sabalausky: > Although, if he suddenly decided he wanted to change something about the > implementation of virtual tables, with C he'd probably have to rewrite a lot > of code. Not so with a "depends on the implementation" form of virtual > tables. The Coccinelle tool helps a lot, it allows to perform Semantic Patching, http://coccinelle.lip6.fr/ See slides: http://coccinelle.lip6.fr/workshop/slides.pdf (I think coccinelle is usable with D too, maybe with small changes. It may be good for the development of the D compiler too). Bye, bearophile
Re: Moving to D
Adrian Mercieca: Welcome here. > We have great experience/investment in C++, so D seems - from what I've > seen so far - as the logical step; Maybe. > D seems to me to be as C++ done right. "C++ done right" was one of the main purposes for D design :-) > I'm also looking at Go in the process, but Go seems to be more of a 'from > C' progression, whilst D seems to be the 'from C++' progression. Go and D are quite different. You will probably need a short time to find what do you need more among the two. There is also C# Mono. > I am only worried about 2 things though - which I've read on the net: There are other things to be worried about :-) > 1. No 64 bit compiler It's in development for Linux. It will come, it already compiles some code. > 2. The Phobos vs Tango issue: is this resolved now? This issue represents > a major stumbling block for me. The Phobos vs Tango issue is essentially a D1 issue. If you are interested in D2 then Phobos is going to be good enough. Bye, bearophile
Re: Advocacy (Was: Who here actually uses D?)
"bearophile" wrote in message news:ifpj7e$mg...@digitalmars.com... > Nick Sabalausky: > >> Right. And I have no doubt about that. It just sounded like he was >> insisting >> that such measures were every bit as necessary and appropriate for >> application software, too. > > What he said years ago about C++ is relative to Linux Kernel development > of several years ago :-) It's not relative to application software > development today, it's not relative to not-Linux-like kernels, and it's > not relative to new kernels written 5-15 years from now. > Well, he was talking about git, too.
Re: Advocacy (Was: Who here actually uses D?)
When you insult people like that, what does that make you? Objective, since i bring evidence or ask for evidence. It was you that linked his nerd rage in the other thread, if mine is insult what about his? Please go read it. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Advocacy (Was: Who here actually uses D?)
"bearophile" wrote in message news:ifpiv8$lt...@digitalmars.com... > so: > >> There are tons of open source C code, which re-invents "C++ virtual", i >> wouldn't be surprised if he did this too. > > I think Linux devices are used through some kind of virtual table. But he > needs control on how things are implemented (I think C++ Standard doesn't > specify how virtual calls are implemented). > That does bring up one thing I think he might like about D versus C++: C++ tends to leave a *lot* as undefined, whereas D tries to avoid doing that. I have no idea if that applies to virual table implementations, though. Although, if he suddenly decided he wanted to change something about the implementation of virtual tables, with C he'd probably have to rewrite a lot of code. Not so with a "depends on the implementation" form of virtual tables. But maybe he does have it abstracted away with macros of something, I dunno. Heck, I might not even be making any sense anyway, it's bedtime and I'm about half asleep already...
Moving to D
Hi everyone, I am currently mulling if I should be adopting D as my (and subsequently my company's) language of choice. We have great experience/investment in C++, so D seems - from what I've seen so far - as the logical step; D seems to me to be as C++ done right. I'm also looking at Go in the process, but Go seems to be more of a 'from C' progression, whilst D seems to be the 'from C++' progression. I am only worried about 2 things though - which I've read on the net: 1. No 64 bit compiler 2. The Phobos vs Tango issue: is this resolved now? This issue represents a major stumbling block for me. Any comments would be greatly appreciated. Thanks.
Re: Advocacy (Was: Who here actually uses D?)
Nick Sabalausky: > Right. And I have no doubt about that. It just sounded like he was insisting > that such measures were every bit as necessary and appropriate for > application software, too. What he said years ago about C++ is relative to Linux Kernel development of several years ago :-) It's not relative to application software development today, it's not relative to not-Linux-like kernels, and it's not relative to new kernels written 5-15 years from now. Bye, bearophile
Re: Advocacy (Was: Who here actually uses D?)
2011/1/2 so > I agree with you on this. For example, Linus Torvald hates C++ and >> probably >> for good reasons. >> > > If someone using the word "love" for C and at the same time "hate" C++... > He might be a god to some people but at the same time this makes him a > dumbass language lawyer. > When you insult people like that, what does that make you?
Re: Advocacy (Was: Who here actually uses D?)
so: > There are tons of open source C code, which re-invents "C++ virtual", i > wouldn't be surprised if he did this too. I think Linux devices are used through some kind of virtual table. But he needs control on how things are implemented (I think C++ Standard doesn't specify how virtual calls are implemented). Bye, bearophile
Re: Advocacy (Was: Who here actually uses D?)
"bearophile" wrote in message news:ifpdbd$dr...@digitalmars.com... > Nick Sabalausky: > >> Hmm, from that I get the impression that Linus is basically just like the >> old Java-evangelists except instead of OO being his silver bullet, it's >> zero-abstraction. I'm almost suprised he allows things like functions, or >> anything other than Asm for that matter, or cares about portability. I >> really doubt he'd like D. Maybe he'd dislike parts of it less than C++, >> but >> that's probably about it. > > Why do you think he doesn't care about Linux portability? > I didn't say that I don't think he cares about portability, I just meant that from that one post it seemed like he was opposed to abstractions. With "portability", I was just pointing out the silliness and self-contradiction of that stance. > I've seen Linux broken by compiler optimizations present in new GCC > versions. If you write very important C code that breaks if you optimize > it in new ways (see pointer aliasing troubles), you grow dislike for > compilers. He needs a dumb C compiler that doesn't do what it likes. If > you write the code he writes, then probably you learn to appreciate the > same things he likes. He's not the only person that's writing Linux, the > other people after so many years keep doing the same things he is doing, > so probably his choices are not so dumb for their job. > Right. And I have no doubt about that. It just sounded like he was insisting that such measures were every bit as necessary and appropriate for application software, too. Of course, I'm usually one of the first people to get annoyed by slow code and techniques being considered "good enough" in application development, but he seems to be taking it a bit far.
Re: Advocacy (Was: Who here actually uses D?)
I have seen this before. **YOU** are full of bullshit. C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do **nothing** but keep the C++ programmers out, that in itself would be a huge reason to use C. In other words: the choice of C is the only sane choice. I know Miles Bader jokingly said "to piss you off", but it's actually true. I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really **would** prefer to piss off, so that he doesn't come and screw up any project I'm involved with. C++ leads to really really bad design choices. You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap, that may "help" you program, but causes: - infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny) - inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app. This whole thing contains not a single evidence but hate. In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic "object model" crap. Object model is crap to an extent. Mostly it is the implementations that are crap. --- struct context; context* new(...); void this(context*); void that(context*); void delete(context*); context2* c2 = (context2*)c; Isn't this an example to object model crap? It is everywhere, so he codes without this? There are tons of open source C code, which re-invents "C++ virtual", i wouldn't be surprised if he did this too. Even the official C++ book itself says "Don't abuse class". C has this macro model, we know how safe how useful it is. Do you have to use it? Sometimes yes, here you don't even have to use "object model" crap. I am not saying C++ is awesome and all, but it is a big step after C. If you don't like it, don't use it. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Nimrod language
> And generally Walter and you are (rightly) adding major new features to D2 > right now. Sorry, I meant: > And generally Walter and you are (rightly) against adding major new features > to D2 right now. Bye, bearophile
Re: Nimrod language
>From that Reddit thread on Nimrod: Andrei: >Our initial plan with D2 was to include AST macros, but we decided to see how >string mixins swim and defer macros to D3. The D forums are virtually silent >on the topic of macros now, and it's definitely not because the community is >being coy :o).< You are right that lately no serious discussions have happened here about AST macros. But the causes are not coyness or because string mixins are good enough. I think the causes are: - AST Macros a not a minor feature, they require some time and thinking to design them well, some syntax support, some code in the front-end, some documentation for users, and some time to learn to use them. - D2 has many bugs and some unfinished parts. Most people here know that adding more features now is not right. And generally Walter and you are (rightly) adding major new features to D2 right now. Once D2 is more finished and debugged some discussions about AST macros may start again. - Lot of people here probably are not experienced with AST macros. - I like the idea of AST macros, they are powerful, but they add a significant amount of complexity to the language. So I am not pushing a lot for them, despite I almost hate string mixings and creating code with string snippets. kapilash : >The forum I was referring to had too many useless discussions about the length >of the word "immutable", unnecessary arguments about D vs other languages and >far too much emphasis on reddit.< I don't mark threads as this "Nimrod language" as OT because a new language like D2 must keep eyes open on other new languages and some computer science. Bye, bearophile
Re: Advocacy (Was: Who here actually uses D?)
"so" wrote in message news:op.voocpmy97dt...@so-pc... >> By saying >> Linus would not find D appealing you are basically saying kernel >> developers >> would not find it appealing. > > Nope by saying Linus would not find D appealing he basically said Linus > would not find D appealing. > Yea, it's not as if Linus is all there is to kernel development.
Re: Nimrod language
bearophile wrote: IMO the concept is interesting (especially the Python-like syntax for a compiled language), There several other examples of the same thing (like the Python compiler I'm helping the development, ShedSkin), Boo, etc. but there are a lot of rough edges and development is very slow. Nimrod seems to contain no new ideas, and probably some large ideas of D2 are missing, but the syntax and some smaller details are nice. There's also http://delight.sourceforge.net/ It's based on GDC, with a Python-like syntax. --anders
Re: Advocacy (Was: Who here actually uses D?)
By saying Linus would not find D appealing you are basically saying kernel developers would not find it appealing. Nope by saying Linus would not find D appealing he basically said Linus would not find D appealing. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
