Re: Promoting D
hasen wrote: Jesse Phillips wrote: On Mon, 11 May 2009 04:48:16 +0200, Saaa wrote: So, what language do you use? D Ok.. why? Just keep your answers simple... "It compiles to machine code." "Why not C++" "It is safer, less complex" Let the person interested probe for answers they want answers to. I know a language K that compiles to native code, why don't you use it for this really important project? It's safer than C++, and less complex, really! (by definition, nothing can be more complicated than C++) I hope you're now convinced to try out my K language, read all the documentation, oh and btw, it's not well organized, good luck! Where can I find this K language? I think it's not http://en.wikipedia.org/wiki/K_(programming_language)
Re: Promoting D
Jesse Phillips wrote: On Mon, 11 May 2009 04:48:16 +0200, Saaa wrote: So, what language do you use? D Ok.. why? Just keep your answers simple... "It compiles to machine code." "Why not C++" "It is safer, less complex" Let the person interested probe for answers they want answers to. I know a language K that compiles to native code, why don't you use it for this really important project? It's safer than C++, and less complex, really! (by definition, nothing can be more complicated than C++) I hope you're now convinced to try out my K language, read all the documentation, oh and btw, it's not well organized, good luck!
Re: Promoting D
Nick Sabalausky wrote: "Andrei Alexandrescu" wrote in message news:gu89ev$jq...@digitalmars.com... hasen wrote: Walter Bright wrote: Jesse Phillips wrote: It looks to me that Walter's points aren't about convincing people to use it, but to show that you are using it, that there are customers. That's right. It's called "social proof". http://en.wikipedia.org/wiki/Social_Proof Apple, for example, uses social proof as the central theme in its marketing campaigns. Back in the 1970's, Dr. Pepper hilariously used social proof in their oxymoronic campaign "join the non-conformists!" Social proof eh? hmm interesting. That's why I decided to learn vim, not because I felt or thought I needed to, but because it *seemed* that /real/ programmers use vim. You know what I mean? Absolutely. Some of the best dating advice I've ever got: just be yourself. No, I was kidding :o). It was: be seen with women. It's social proof. I think "The 'if-others-are-doing-it-then-it-*must*-be-right' Fallacy" is probably a much more accurate term for "social proof". I realize "social proof" is the typical term for it, but calling it that just seems like trying to call the ad hominem fallacy "associative proof". More like "then for all I know it's *probably* right" Like: if everyone here uses buzz words and jargon like ad hominem then I better learn this jargon to be considered smart.
Re: Plotting Using PLPlot
On 2009-05-11 02:05:51 +0200, Robert Fraser said: dsimcha wrote: == Quote from Fawzi Mohamed (fmoha...@mac.com)'s article On 2009-05-10 21:23:48 +0200, dsimcha said: It seems like there's substantial interest in this. Please give me some use cases, i.e. what would you personally use this for, and what do you foresee others using it for, so I can start thinking about what the API should be. I need a wide variety of use cases because, if I design the API based only on my personal use cases, it will end up being geared entirely toward histograms, scatter plots, and line graphs because that's what I use regularly. yep me too, well 3d surface plots would also be nice to have, but I can live without. Besides use cases, here are some specific questions: 1. Is there any need for an OO-based API, or should I just use free functions? I would use an OO API where one window/image/output graph is represented by an object, and then you have functions to 2. Does anyone have any use cases where plotting is performance critical, or should I just keep things simple/stupid in terms of the performance/simplicity tradeoff? keep it simple I would just send dense arrays to it (which are close to the C api), and then have utility functions that convert ranges,... to dense arrays, but maybe I am biased because I have a good library to handle dense arrays. I would say that a reasonable goal is that the library could cope directly to plot of 1'000s of points at least for the simple 1D plot types. Ok, this is way less than I had in mind. When I said high performance, I was thinking like, either plotting stuff under realtime constraints like if you're some Wall Street bigwig plotting zillions of charts to figure out what stocks to buy or, when doing summary stuff like histograms, handling billions of points read as a range from a file, i.e. more data than you have address space. I personally would not consider anything that couldn't gracefully handle at least a few million data points for histograms and a few 10s of thousands for scatter plots to be good enough. Having plots that update in realtime would be kind of awesome for monitoring, but the ones I was thinking of wouldn't be more than a few thousand data points in each sliding window, if that. my answer was along the keep it simple lines, you cannot really expect to represent more than some 1000s of points, if you have more you should do some transformation to represent them. Histogram for example reduce them, some cluster or spread analysis and represent fewer discrete objects,... All those things can be built later, the only thing needed is a basic lib that supports few 1000s of simple objects well, and less of complex objects. even realtime update an animations can be done if the library is fast for its basic use. Keep it simple, the fancy stuff can be built on the top of it later.
Re: Promoting D
Hello Nick, I think "The 'if-others-are-doing-it-then-it-*must*-be-right' Fallacy" is probably a much more accurate term for "social proof". I realize "social proof" is the typical term for it, but calling it that just seems like trying to call the ad hominem fallacy "associative proof". It marketing. Why do you expect them to lable it correctly? (Rule of Acquisition 239)
Re: Promoting D
"Andrei Alexandrescu" wrote in message news:gu89ev$jq...@digitalmars.com... > hasen wrote: >> Walter Bright wrote: >>> Jesse Phillips wrote: It looks to me that Walter's points aren't about convincing people to use it, but to show that you are using it, that there are customers. >>> >>> That's right. It's called "social proof". >>> http://en.wikipedia.org/wiki/Social_Proof >>> >>> Apple, for example, uses social proof as the central theme in its >>> marketing campaigns. >>> >>> Back in the 1970's, Dr. Pepper hilariously used social proof in their >>> oxymoronic campaign "join the non-conformists!" >> >> Social proof eh? hmm interesting. That's why I decided to learn vim, not >> because I felt or thought I needed to, but because it *seemed* that >> /real/ programmers use vim. You know what I mean? > > Absolutely. Some of the best dating advice I've ever got: just be > yourself. > > No, I was kidding :o). It was: be seen with women. It's social proof. > I think "The 'if-others-are-doing-it-then-it-*must*-be-right' Fallacy" is probably a much more accurate term for "social proof". I realize "social proof" is the typical term for it, but calling it that just seems like trying to call the ad hominem fallacy "associative proof".
Re: Promoting D
On Mon, 11 May 2009 04:48:16 +0200, Saaa wrote: > So, what language do you use? >> D > Ok.. why? Just keep your answers simple... "It compiles to machine code." "Why not C++" "It is safer, less complex" Let the person interested probe for answers they want answers to.
Re: Promoting D
hasen wrote: Walter Bright wrote: Jesse Phillips wrote: It looks to me that Walter's points aren't about convincing people to use it, but to show that you are using it, that there are customers. That's right. It's called "social proof". http://en.wikipedia.org/wiki/Social_Proof Apple, for example, uses social proof as the central theme in its marketing campaigns. Back in the 1970's, Dr. Pepper hilariously used social proof in their oxymoronic campaign "join the non-conformists!" Social proof eh? hmm interesting. That's why I decided to learn vim, not because I felt or thought I needed to, but because it *seemed* that /real/ programmers use vim. You know what I mean? Absolutely. Some of the best dating advice I've ever got: just be yourself. No, I was kidding :o). It was: be seen with women. It's social proof. Andrei
Re: D users in Munich, Rome, Venice, or Frankfurt?
Hello Robert, BCS wrote: Noch ein Bier bitte! No Beer! Why would you ever need to say that? 1) "No Beer, " ~ ru ? "Vadka!" : snob ? "Wine!" : cowboy ? "Wisky" : "oh never mind"; 2) No Beer, I'm driving. 3) No Beer, I have to work tomorrow. (OTOH, http://xkcd.com/323/) 4) No Beer, I'm giving a presentation tomorrow. (OTOH... *Lots More Beer!*)
Re: What's the current state of D?
Leandro Lucarella wrote: In case you missed my other mail, I opened a bug report in GDB bugzilla to keep track of the patch: http://sourceware.org/bugzilla/show_bug.cgi?id=10142 This is great. I'm glad you're pushing this.
Re: Promoting D
Walter Bright wrote: Jesse Phillips wrote: It looks to me that Walter's points aren't about convincing people to use it, but to show that you are using it, that there are customers. That's right. It's called "social proof". http://en.wikipedia.org/wiki/Social_Proof Apple, for example, uses social proof as the central theme in its marketing campaigns. Back in the 1970's, Dr. Pepper hilariously used social proof in their oxymoronic campaign "join the non-conformists!" Social proof eh? hmm interesting. That's why I decided to learn vim, not because I felt or thought I needed to, but because it *seemed* that /real/ programmers use vim. You know what I mean?
Re: What's the current state of D?
Walter Bright, el 10 de mayo a las 15:42 me escribiste: > Leandro Lucarella wrote: > >Walter Bright, el 10 de mayo a las 11:21 me escribiste: > >I posted it in this very same thread, just before the link to the GDB > >patches link. Here it is again: > >http://www.digitalmars.com/d/archives/digitalmars/D/Getting_D_language_patch_into_GDB_82597.html > > Thank you. You are welcome. I'm very glad this is taking some attention =) In case you missed my other mail, I opened a bug report in GDB bugzilla to keep track of the patch: http://sourceware.org/bugzilla/show_bug.cgi?id=10142 > >>Given all the beating of breasts and rending of robes about D1 not being > >>stable and breaking code even when a bug is fixed in it, I just can't > >>see coming out with a new D1 that substantially breaks every existing D1 > >>code base. > >It would break all existing D1 code base? > > I suspect it would break pretty much all the non-trivial code. What are exactly the user-visible changes? > >If the compiler were really open source, and the frontend were in a public > >repository, and fixes would be well separated patches, you wouldn't have > >to maintain 3 D version. > > It's not just me, it's the poor sap who has to maintain 3 different > versions of his library. This is not fixable by adding a aliases for old names and leave them as deprecated? > >>D2 has already taken the steps necessary to support both Phobos and Tango. > >But D2 is not nearly ready for production use. D1 is almost there... Is > >missing so little that it's frustrating. > > I don't believe that contract inheritance is the key to production use. > There shouldn't be anything standing in the way of using D1 for > production use, and in fact it is being used that way. Honestly I'm not confident enough in D1 for production use if it's incomplete and if the Tango/Druntime runtime is not merged because 2 codebases should be maintained and you can't use the few libraries available for one runtime with the other (without using some hackish wrappers). Lack of support in mainstream tools is the other thing preventing me to use D at work. I *can't* use D for something serious (sadly, because I'd love to). > >In case you are not following the thread about interior pointers, here is > >another drawback for the Tango vs. Phobos problem, here is copy&pasted > >fragment: > > I think it would be great to have a centralized place where to put this > > improvements. This is another situation where I think Tango vs. Phobos > > issue is killing D. When I started my work in the thesis I had to decide > > whether to work with Phobos or Tango. I finally decided for Tango, because > > is the only option for LDC and because is way better organized (and more > > receptive to patches). But I hate knowing that my work will be available > > (in the best case) only for people using Tango. > > I don't believe that splitting D into yet another separate version can > fix this, as then the user has to decide which D to use. Use the latest stable version, as you do with any serious language =) You shouldn't introduce breaking changes too often. I think a language version bump every (half) year is very acceptable. I mean, just see how Python/Ruby/PHP/Java/Haskel/ development model works, all very evolving languages that don't break backwards compatibility very often and with a lot of well maintained programs and libraries. But this is getting repetitive, so I guess it has no point to keep discussing it. Once in a while I have the crazy idea that you can be convinced otherwise (hey! You finally got convinced to fork D2 from D1! =)... Maybe I'll try again in a few months... -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) Si ella es el sol, yo soy la luna Si ella es el mar, soy el desierto Y estamos en eclipse total Y estamos en eclipse total
Re: Promoting D
So, what language do you use? > D Ok.. why? > (Runs away) >> It looks to me that Walter's points aren't about convincing people to use >> it, but to show that you are using it, that there are customers. > > That's right. It's called "social proof". > http://en.wikipedia.org/wiki/Social_Proof > > Apple, for example, uses social proof as the central theme in its > marketing campaigns. > > Back in the 1970's, Dr. Pepper hilariously used social proof in their > oxymoronic campaign "join the non-conformists!"
Re: D users in Munich, Rome, Venice, or Frankfurt?
Robert Fraser wrote: BCS wrote: Noch ein Bier bitte! No Beer! Why would you ever need to say that? You wouldn't. "Noch ein" means "Another one!" I don't think "No Beer!" has a German translation. I tried it with Google's translator and got a server error.
Re: What's the current state of D?
Brad Roberts, el 10 de mayo a las 16:08 me escribiste: > Leandro Lucarella wrote: > > > I reported the bug because I think that could be the case. If is not, it's > > a Gold bug and it should be reported. If it is, it should be fixed in DMD. > > I don't have the knowlegde to check that myself, and that's why I reported > > the bug to both tools. > > > >> In other words, it's not at all surprising to me that the bug report > >> hasn't received a lot of attention yet. > > > > So you are saying you have to be a compiler hacker to report a bug? Great, > > that make sense! > > You seem to have missed my point. The point was, the more detailed the > report, > the clearer the steps to reproduce, the more obvious it is that the compiler > is > what's broken.. all of these things increase the likelihood of a bug report > having a higher priority. > > The incoming rate is higher than the fix rate (as evidenced by the number of > open bugs) and so something has to give. All I was doing was illustrating > some > reasons that might have contributed to that specific report not having been > fixed yet. > > Do I encourage filing bugs without the level of detail I suggest help get bugs > fixed fast? Absolutely. An un-filed bug is an un-fixed bug. > > Take these points as ways to help make sure your important issues can be > addressed quickly and easily. I totally agree, but you put my bug report as an example of a bad bug report. I don't think it is a bad bug report, so please let me know if you think I can improve it without being a compiler hacker. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) He used to do surgery On girls in the eighties But gravity always wins
Re: D users in Munich, Rome, Venice, or Frankfurt?
BCS wrote: Noch ein Bier bitte! No Beer! Why would you ever need to say that?
Re: D users in Munich, Rome, Venice, or Frankfurt?
BCS wrote: No problem. In Germany, at least, the only German necessary in order to get along famously is: let me guess: Ein Bier bitte! Beer! Noch ein Bier bitte! No Beer! More Beer! Wo ist der WC? To much Beer! Beer is the same in all languages!
Re: D users in Munich, Rome, Venice, or Frankfurt?
Hello Walter, Robert Fraser wrote: I'm going to be in Munich from June 24-27, Venice June 28-July 1, Rome July 2-3, and Frankfurt on July 4, if there are any D users in the area who want to meet up. Like your typical American, I can only speak English, though ;-P (I might be able to manage some Japanese...). No problem. In Germany, at least, the only German necessary in order to get along famously is: let me guess: Ein Bier bitte! Beer! Noch ein Bier bitte! No Beer! Wo ist der WC? To much Beer!
Re: Plotting Using PLPlot
dsimcha Wrote: > It seems like there's substantial interest in this. Please give me some use > cases, i.e. what would you personally use this for, and what do you foresee > others > using it for, so I can start thinking about what the API should be. I need a > wide > variety of use cases because, if I design the API based only on my personal > use > cases, it will end up being geared entirely toward histograms, scatter plots, > and > line graphs because that's what I use regularly. > > Besides use cases, here are some specific questions: > 1. Is there any need for an OO-based API, or should I just use free > functions? > 2. Does anyone have any use cases where plotting is performance critical, or > should I just keep things simple/stupid in terms of the performance/simplicity > tradeoff? All my plotting would be real time monitoring of program operation. While I'm performance-sensitive, I would not expect a plotting library to be terribly efficient. A seamless way to allow plotting data over a socket would be awesome. My current uses would involve two kinds of plots: line graphs that where I append data for the most recent timestamp. bar graphs or maybe points with error bars (x axis is has labels, not numbers)
Re: D users in Munich, Rome, Venice, or Frankfurt?
Robert Fraser wrote: I'm going to be in Munich from June 24-27, Venice June 28-July 1, Rome July 2-3, and Frankfurt on July 4, if there are any D users in the area who want to meet up. Like your typical American, I can only speak English, though ;-P (I might be able to manage some Japanese...). No problem. In Germany, at least, the only German necessary in order to get along famously is: Ein Bier bitte! Noch ein Bier bitte! Wo ist der WC?
Re: Getting D language patch into GDB
Walter Bright Wrote: > Jason House wrote: > > Is there any legal/copyright issues that prevent the gdb patch from > > making it into gdb? Maybe demangling uses digital mars code? I'd > > really love to see complete support for D in gdb. It's really > > frustrating to not have it :( > > I'd be happy to address any licensing issues for a patch to gdb. Just > let me know. I don't know what the past hang-ups were, but I guess that hardly matters. I'll ping the author of the existing gdb patches and try to reinitiate the submission process. Additionally, we still need to figure out what is wrong with -gc and fix it. In the past, I've spent some quality time on #gdb discussing how to fix that. I'm just not knowlegable on the topic. Having the compiler source could help... Do you have any pointers for where to look for writing of debug info?
D users in Munich, Rome, Venice, or Frankfurt?
I'm going to be in Munich from June 24-27, Venice June 28-July 1, Rome July 2-3, and Frankfurt on July 4, if there are any D users in the area who want to meet up. Like your typical American, I can only speak English, though ;-P (I might be able to manage some Japanese...).
Re: Plotting Using PLPlot
dsimcha wrote: == Quote from Fawzi Mohamed (fmoha...@mac.com)'s article On 2009-05-10 21:23:48 +0200, dsimcha said: It seems like there's substantial interest in this. Please give me some use cases, i.e. what would you personally use this for, and what do you foresee others using it for, so I can start thinking about what the API should be. I need a wide variety of use cases because, if I design the API based only on my personal use cases, it will end up being geared entirely toward histograms, scatter plots, and line graphs because that's what I use regularly. yep me too, well 3d surface plots would also be nice to have, but I can live without. Besides use cases, here are some specific questions: 1. Is there any need for an OO-based API, or should I just use free functions? I would use an OO API where one window/image/output graph is represented by an object, and then you have functions to 2. Does anyone have any use cases where plotting is performance critical, or should I just keep things simple/stupid in terms of the performance/simplicity tradeoff? keep it simple I would just send dense arrays to it (which are close to the C api), and then have utility functions that convert ranges,... to dense arrays, but maybe I am biased because I have a good library to handle dense arrays. I would say that a reasonable goal is that the library could cope directly to plot of 1'000s of points at least for the simple 1D plot types. Ok, this is way less than I had in mind. When I said high performance, I was thinking like, either plotting stuff under realtime constraints like if you're some Wall Street bigwig plotting zillions of charts to figure out what stocks to buy or, when doing summary stuff like histograms, handling billions of points read as a range from a file, i.e. more data than you have address space. I personally would not consider anything that couldn't gracefully handle at least a few million data points for histograms and a few 10s of thousands for scatter plots to be good enough. Having plots that update in realtime would be kind of awesome for monitoring, but the ones I was thinking of wouldn't be more than a few thousand data points in each sliding window, if that.
Re: What's the current state of D?
Leandro Lucarella wrote: > Brad Roberts, el 10 de mayo a las 10:12 me escribiste: >> Leandro Lucarella wrote: >> >>> How many people is using that? How bad would it be to call the next >>> version of DMD that include the Tango/Druntime runtime D 1.100 or >>> something (is really hard to pick right version numbers under the version >>> scheme you use[*]) to make clear there is compatibility break in that >>> version? >>> >>> [*] I really wonder how would you call D2 when it's stable. You will just >>> say D 2.134 is D2 final/stable? I think this is another problem with >>> D, version naming is really confusing and lame. You can't know >>> anything from a D version number. And DMD compiler and D specs are too >>> much coupled. It would be nice to have separate version numbers if you >>> really want to encourage some kind of D standard and compiler vendors >>> to start making D compilers. >> For what it's worth, there's at least one other major product that follows a >> similar versioning scheme.. mysql. > > At least MySQL uses major, minor, and patchlevel version numbering scheme > ;) > Mysql uses an x.y.z numbering scheme. DMD uses a y.z numbering scheme. With mysql's x.y being equavilent to dmd's y. The use of z in both is the same. Given that mysql's increase of its x.y component being somewhat arbitrary, it might as well just be one number. Either way, the transition of the z component through various stages from alpha to release being at arbitrary points along the number line, my point still stands. :) Later, Brad
Re: What's the current state of D?
Leandro Lucarella wrote: > I reported the bug because I think that could be the case. If is not, it's > a Gold bug and it should be reported. If it is, it should be fixed in DMD. > I don't have the knowlegde to check that myself, and that's why I reported > the bug to both tools. > >> In other words, it's not at all surprising to me that the bug report >> hasn't received a lot of attention yet. > > So you are saying you have to be a compiler hacker to report a bug? Great, > that make sense! You seem to have missed my point. The point was, the more detailed the report, the clearer the steps to reproduce, the more obvious it is that the compiler is what's broken.. all of these things increase the likelihood of a bug report having a higher priority. The incoming rate is higher than the fix rate (as evidenced by the number of open bugs) and so something has to give. All I was doing was illustrating some reasons that might have contributed to that specific report not having been fixed yet. Do I encourage filing bugs without the level of detail I suggest help get bugs fixed fast? Absolutely. An un-filed bug is an un-fixed bug. Take these points as ways to help make sure your important issues can be addressed quickly and easily. Later, Brad
Re: Getting D language patch into GDB
Jason House wrote: Is there any legal/copyright issues that prevent the gdb patch from making it into gdb? Maybe demangling uses digital mars code? I'd really love to see complete support for D in gdb. It's really frustrating to not have it :( I'd be happy to address any licensing issues for a patch to gdb. Just let me know.
Re: What's the current state of D?
Leandro Lucarella wrote: There was a thread in the NG asking for possible copyright issues to include the GDB patch upstream, and it had no answer for example. I don't think you *have* to answer that mail, but I think helping this kind of things happening instead of ignoring them is good for D promotion too =) Can you point me to that thread? There are an awful lot of posts, and I miss things. I posted it in this very same thread, just before the link to the GDB patches link. Here it is again: http://www.digitalmars.com/d/archives/digitalmars/D/Getting_D_language_patch_into_GDB_82597.html If someone has a patch ready to submit to GDB, and needs some licensing change for it, I'm happy to provide that.
Re: What's the current state of D?
Leandro Lucarella wrote: Walter Bright, el 10 de mayo a las 11:21 me escribiste: I posted it in this very same thread, just before the link to the GDB patches link. Here it is again: http://www.digitalmars.com/d/archives/digitalmars/D/Getting_D_language_patch_into_GDB_82597.html Thank you. Given all the beating of breasts and rending of robes about D1 not being stable and breaking code even when a bug is fixed in it, I just can't see coming out with a new D1 that substantially breaks every existing D1 code base. It would break all existing D1 code base? I suspect it would break pretty much all the non-trivial code. If the compiler were really open source, and the frontend were in a public repository, and fixes would be well separated patches, you wouldn't have to maintain 3 D version. It's not just me, it's the poor sap who has to maintain 3 different versions of his library. D2 has already taken the steps necessary to support both Phobos and Tango. But D2 is not nearly ready for production use. D1 is almost there... Is missing so little that it's frustrating. I don't believe that contract inheritance is the key to production use. There shouldn't be anything standing in the way of using D1 for production use, and in fact it is being used that way. In case you are not following the thread about interior pointers, here is another drawback for the Tango vs. Phobos problem, here is copy&pasted fragment: I think it would be great to have a centralized place where to put this improvements. This is another situation where I think Tango vs. Phobos issue is killing D. When I started my work in the thesis I had to decide whether to work with Phobos or Tango. I finally decided for Tango, because is the only option for LDC and because is way better organized (and more receptive to patches). But I hate knowing that my work will be available (in the best case) only for people using Tango. I don't believe that splitting D into yet another separate version can fix this, as then the user has to decide which D to use.
Re: Promoting D
Jesse Phillips wrote: It looks to me that Walter's points aren't about convincing people to use it, but to show that you are using it, that there are customers. That's right. It's called "social proof". http://en.wikipedia.org/wiki/Social_Proof Apple, for example, uses social proof as the central theme in its marketing campaigns. Back in the 1970's, Dr. Pepper hilariously used social proof in their oxymoronic campaign "join the non-conformists!"
Re: Associative Arrays and Interior Pointers
== Quote from Leandro Lucarella (llu...@gmail.com)'s article > I really like the idea of NO_INTERIOR too. I don't think it's possible to > be the default because if that is the case you can't have array slices > and/or pointers to a member of a struct/class. But I think it's great for > very special cases (specially to implement high performance data > structures) to be able to instruct the GC to discard interior pointers. Of course, I don't think any reasonable person thinks it should be the default. The idea is that it would be an unsafe optimization for people who really know what they're doing or are really having serious trouble with false pointers. It should be thought of kind of like using manual memory management in D. > > A few questions: > > 1. (For Leonardo, especially): Is the GC likely to get precise enough in > > the > > near future that something like this would end up being considered a piece > > of cruft? > I'm sorry, but I finally decided to add concurrency to the current GC. The > main idea is to reduce (almost vanish) pauses. If is not too hard, and > time help, I'll try to add some preciseness if it only involves changes in > the internal runtime, but I honestly don't think I'll have the time. > I'm talking about finishing my thesis here. When it's finished I think and > hope to keep working on the D GC... Ok, cool. I just wanted to make sure that, if we took the time to put this in, you weren't likely to come back in 6 months and say "I've made the GC almost completely precise. All false pointer stuff is now irrelevant and just a bunch of cruft." On the other hand, I certainly wouldn't mind if the GC became more precise instead. > > 2. Other than that, is there any reason this should not go in? > I don't see any reason, is a backward compatible change. > > 3. Sean, if you're seriously thinking of putting this in in the near > > future, let > > me know so I can fix that patch, too. I did it the same way as my other GC > > patch, > > with no whitespace, so the line numbers might be screwy here, too. > I think it would be great to have a centralized place where to put this > improvements. This is another situation where I think Tango vs. Phobos > issue is killing D. When I started my work in the thesis I had to decide > whether to work with Phobos or Tango. I finally decided for Tango, because > is the only option for LDC and because is way better organized (and more > receptive to patches). But I hate knowing that my work will be available > (in the best case) only for people using Tango. > I hate to see the D "community" fragmented. You're right, this is unfortunate. Basically every contribution I've made to D is D2-oriented and completely irrelevant to D1.
Re: Promoting D
On Sun, 10 May 2009 09:27:49 +0200, Saaa wrote: > The problem I have explaining why somebody should take up D is that I > know not enough about the languages they use to actually show them the > things they are missing. Sometimes it is the, for me, obvious feature > like functions within functions that tilts their heads a bit. It looks to me that Walter's points aren't about convincing people to use it, but to show that you are using it, that there are customers. Convincing people to use your language rarely works. If they needed a different language they would have found one. Funny thing is I like looking at different languages and so does my friend, but neither of us actually tried the other's language.
Re: What's the current state of D?
Walter Bright, el 10 de mayo a las 11:21 me escribiste: > Leandro Lucarella wrote: > >Walter Bright, el 9 de mayo a las 22:05 me escribiste: > >>Leandro Lucarella wrote: > >>>Official? I don't see any official support for D in GDB. I can only find > >>>this patches: > >>>http://www.dsource.org/projects/gdb-patches/ > >>Dwarf has an official value for the language, DW_LANG_D = 0x13. > >I'm talking about GDB. GDB has no official D support. > > GDB officially supports Dwarf, and Dwarf officially has a D identifier. While > gdb may not go any further than that, it's a start. > > >There was a thread > >in the NG asking for possible copyright issues to include the GDB patch > >upstream, and it had no answer for example. I don't think you *have* to > >answer that mail, but I think helping this kind of things happening > >instead of ignoring them is good for D promotion too =) > > Can you point me to that thread? There are an awful lot of posts, and I miss > things. I posted it in this very same thread, just before the link to the GDB patches link. Here it is again: http://www.digitalmars.com/d/archives/digitalmars/D/Getting_D_language_patch_into_GDB_82597.html > >>>How is that? Most runtime code is not used by the user directly. And for > >>>this item I think not merging it does more damage than introducing > >>>a breaking change (is much better to introduce a breaking change to solve > >>>this problem than to add a predefined Posix version ;). > >>Tango chose to use a number of incompatible names and a fundamentally > >>different class hierarchy for the same thing(s). > >How many people is using that? How bad would it be to call the next > >version of DMD that include the Tango/Druntime runtime D 1.100 or > >something (is really hard to pick right version numbers under the version > >scheme you use[*]) to make clear there is compatibility break in that > >version? > > Given all the beating of breasts and rending of robes about D1 not being > stable and breaking code even when a bug is fixed in it, I just can't > see coming out with a new D1 that substantially breaks every existing D1 > code base. It would break all existing D1 code base? > >Seriously, there were several (silly) compatibility breaks since 1.0 was > >out, I think is a huge issue that deserves it... > > This is what I mean when I say that it's simply impossible to ask for > breaking changes for D1 while pillorying D1 for breaking changes. I also > believe it is impractical to divide D1 into two incompatible versions > - then there'd be 3 D versions to simultaneously support. If the compiler were really open source, and the frontend were in a public repository, and fixes would be well separated patches, you wouldn't have to maintain 3 D version. You probably even have to maintain 2 D versions. Other people could take over and apply fixes to the stable D branches while you with D2. The problem is doing that right now is really hard, because to see what changed in the DMDFE from one version to another you have to download 2 complete compiler version, make a diff yourself and you end up with a big diff that you can't possible break in small chunks with individual bugfixes. > D2 has already taken the steps necessary to support both Phobos and Tango. But D2 is not nearly ready for production use. D1 is almost there... Is missing so little that it's frustrating. In case you are not following the thread about interior pointers, here is another drawback for the Tango vs. Phobos problem, here is copy&pasted fragment: I think it would be great to have a centralized place where to put this improvements. This is another situation where I think Tango vs. Phobos issue is killing D. When I started my work in the thesis I had to decide whether to work with Phobos or Tango. I finally decided for Tango, because is the only option for LDC and because is way better organized (and more receptive to patches). But I hate knowing that my work will be available (in the best case) only for people using Tango. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) De tan fina la condesa, por no cagarse, reza. -- Ricardo Vaporeso
Re: Plotting Using PLPlot
dsimcha wrote: It seems like there's substantial interest in this. Please give me some use cases, i.e. what would you personally use this for, and what do you foresee others using it for, so I can start thinking about what the API should be. I need a wide variety of use cases because, if I design the API based only on my personal use cases, it will end up being geared entirely toward histograms, scatter plots, and line graphs because that's what I use regularly. Besides use cases, here are some specific questions: 1. Is there any need for an OO-based API, or should I just use free functions? 2. Does anyone have any use cases where plotting is performance critical, or should I just keep things simple/stupid in terms of the performance/simplicity tradeoff? I would be *very* interested in a plotting library for D. (Currently I output my data to text files, which I then process in Gnuplot.) You've already mentioned line graphs. The other thing I use most are 3D plots, i.e. z as a function of x and y -- preferably with color/gradient mapping. In such plots one should be able to specify the viewpoint from which the graph is seen. A special case should be the top-down view, which is essentially a 2d plot where the z axis value is represented solely by color/brightness. I think the functions should be able to work with both data sets and functions, i.e. both plot (real[] x, real[] y) and plot (real function(real) f, real xLeft, real xRight) should be available. Regarding the API, I say keep it as simple as possible -- at least to begin with. I would love it if plotting my results could be done almost as simply as writefln'ing them. :) -Lars
Re: What's the current state of D?
Brad Roberts, el 10 de mayo a las 10:12 me escribiste: > Leandro Lucarella wrote: > > > How many people is using that? How bad would it be to call the next > > version of DMD that include the Tango/Druntime runtime D 1.100 or > > something (is really hard to pick right version numbers under the version > > scheme you use[*]) to make clear there is compatibility break in that > > version? > > > > [*] I really wonder how would you call D2 when it's stable. You will just > > say D 2.134 is D2 final/stable? I think this is another problem with > > D, version naming is really confusing and lame. You can't know > > anything from a D version number. And DMD compiler and D specs are too > > much coupled. It would be nice to have separate version numbers if you > > really want to encourage some kind of D standard and compiler vendors > > to start making D compilers. > > For what it's worth, there's at least one other major product that follows a > similar versioning scheme.. mysql. At least MySQL uses major, minor, and patchlevel version numbering scheme ;) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) The biggest lie you can tell yourself is When I get what I want I will be happy
Re: Associative Arrays and Interior Pointers
dsimcha, el 10 de mayo a las 18:04 me escribiste: > == Quote from Sean Kelly (s...@invisibleduck.org)'s article > > dsimcha wrote: > > > > > > 2. Other than its abysmal interaction with the current GC and the lack of > > > ability to iterate using ranges, the current AA implementation actually > > > seems > > > pretty good. One way to remedy a large portion of the GC issues without a > > > massive overhaul of the GC would be to introduce a feature into the GC > > > where a > > > block of memory can be flagged as NO_INTERIOR. > > Neat idea. Some GCs (like the Boehm GC) can be set NO_INTERIOR > > globally, but it never crossed my mind to do this per block. For > > certain data structures, this might be pretty useful. > > I get the impression that D's GC will always have a significant degree of > conservatism. Of course, there's always unions, but unioning a pointer type > w/ a > non-pointer type is such an edge case that, if this is the only thing that's > conservative, then the GC can be considered precise for all practical > purposes. > For now, I'd love to see this added, because it would be an extremely "cheap" > way > to solve a lot of annoying problems. I really like the idea of NO_INTERIOR too. I don't think it's possible to be the default because if that is the case you can't have array slices and/or pointers to a member of a struct/class. But I think it's great for very special cases (specially to implement high performance data structures) to be able to instruct the GC to discard interior pointers. > A few questions: > 1. (For Leonardo, especially): Is the GC likely to get precise enough in the > near future that something like this would end up being considered a piece of > cruft? I'm sorry, but I finally decided to add concurrency to the current GC. The main idea is to reduce (almost vanish) pauses. If is not too hard, and time help, I'll try to add some preciseness if it only involves changes in the internal runtime, but I honestly don't think I'll have the time. I'm talking about finishing my thesis here. When it's finished I think and hope to keep working on the D GC... > 2. Other than that, is there any reason this should not go in? I don't see any reason, is a backward compatible change. > 3. Sean, if you're seriously thinking of putting this in in the near future, > let > me know so I can fix that patch, too. I did it the same way as my other GC > patch, > with no whitespace, so the line numbers might be screwy here, too. I think it would be great to have a centralized place where to put this improvements. This is another situation where I think Tango vs. Phobos issue is killing D. When I started my work in the thesis I had to decide whether to work with Phobos or Tango. I finally decided for Tango, because is the only option for LDC and because is way better organized (and more receptive to patches). But I hate knowing that my work will be available (in the best case) only for people using Tango. I hate to see the D "community" fragmented. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) Estamos cantando a la sombra de nuestra parra una canción que dice que uno sólo conserva lo que no amarra
Re: Plotting Using PLPlot
== Quote from Fawzi Mohamed (fmoha...@mac.com)'s article > On 2009-05-10 21:23:48 +0200, dsimcha said: > > It seems like there's substantial interest in this. Please give me some use > > cases, i.e. what would you personally use this for, and what do you > > foresee others > > using it for, so I can start thinking about what the API should be. I > > need a wide > > variety of use cases because, if I design the API based only on my personal > > use > > cases, it will end up being geared entirely toward histograms, scatter > > plots, and > > line graphs because that's what I use regularly. > yep me too, well 3d surface plots would also be nice to have, but I can > live without. > > Besides use cases, here are some specific questions: > > 1. Is there any need for an OO-based API, or should I just use free > > functions? > I would use an OO API where one window/image/output graph is > represented by an object, and then you have functions to > > 2. Does anyone have any use cases where plotting is performance critical, > > or > > should I just keep things simple/stupid in terms of the > > performance/simplicity > > tradeoff? > keep it simple I would just send dense arrays to it (which are close to > the C api), and then have utility functions that convert ranges,... to > dense arrays, but maybe I am biased because I have a good library to > handle dense arrays. > I would say that a reasonable goal is that the library could cope > directly to plot of 1'000s of points at least for the simple 1D plot > types. Ok, this is way less than I had in mind. When I said high performance, I was thinking like, either plotting stuff under realtime constraints like if you're some Wall Street bigwig plotting zillions of charts to figure out what stocks to buy or, when doing summary stuff like histograms, handling billions of points read as a range from a file, i.e. more data than you have address space. I personally would not consider anything that couldn't gracefully handle at least a few million data points for histograms and a few 10s of thousands for scatter plots to be good enough.
Re: Plotting Using PLPlot
On 2009-05-10 21:23:48 +0200, dsimcha said: It seems like there's substantial interest in this. Please give me some use cases, i.e. what would you personally use this for, and what do you foresee others using it for, so I can start thinking about what the API should be. I need a wide variety of use cases because, if I design the API based only on my personal use cases, it will end up being geared entirely toward histograms, scatter plots, and line graphs because that's what I use regularly. yep me too, well 3d surface plots would also be nice to have, but I can live without. Besides use cases, here are some specific questions: 1. Is there any need for an OO-based API, or should I just use free functions? I would use an OO API where one window/image/output graph is represented by an object, and then you have functions to 2. Does anyone have any use cases where plotting is performance critical, or should I just keep things simple/stupid in terms of the performance/simplicity tradeoff? keep it simple I would just send dense arrays to it (which are close to the C api), and then have utility functions that convert ranges,... to dense arrays, but maybe I am biased because I have a good library to handle dense arrays. I would say that a reasonable goal is that the library could cope directly to plot of 1'000s of points at least for the simple 1D plot types. Fawzi
Re: Associative Arrays and Interior Pointers
On 2009-05-10 20:04:40 +0200, dsimcha said: == Quote from Sean Kelly (s...@invisibleduck.org)'s article dsimcha wrote: 2. Other than its abysmal interaction with the current GC and the lack of ability to iterate using ranges, the current AA implementation actually seems pretty good. One way to remedy a large portion of the GC issues without a massive overhaul of the GC would be to introduce a feature into the GC where a block of memory can be flagged as NO_INTERIOR. Neat idea. Some GCs (like the Boehm GC) can be set NO_INTERIOR globally, but it never crossed my mind to do this per block. For certain data structures, this might be pretty useful. I get the impression that D's GC will always have a significant degree of conservatism. Of course, there's always unions, but unioning a pointer type w/ a non-pointer type is such an edge case that, if this is the only thing that's conservative, then the GC can be considered precise for all practical purposes. For now, I'd love to see this added, because it would be an extremely "cheap" way to solve a lot of annoying problems. A few questions: 1. (For Leonardo, especially): Is the GC likely to get precise enough in the near future that something like this would end up being considered a piece of cruft? 2. Other than that, is there any reason this should not go in? 3. Sean, if you're seriously thinking of putting this in in the near future, let me know so I can fix that patch, too. I did it the same way as my other GC patch, with no whitespace, so the line numbers might be screwy here, too. Yes the idea of NO_INTERIOR was floated before, and it is a good idea and works for 99% of the usages of AA and similar objects. Normally it is not very different from having a GC managed wrapper object that alloc non GC managed memory, which for example is what I do with multidimensional arrays. For these there isn't a big advantage in NO_INTERIOR,because basically always you have a wrapper object, and for these wrapper objects one can explicitly say that internal pointers are valid only if a pointer to the AA is kept For the AA usage these is still the 0.1% usage in which one might lose the pointer to the AA, but still have a pointer to some of its contents. At the moment this is legal (I think) your change would disallow it. This might still be ok, but one should be aware of it Fawzi
Re: Plotting Using PLPlot
dsimcha wrote: Besides use cases, here are some specific questions: 1. Is there any need for an OO-based API, or should I just use free functions? 2. Does anyone have any use cases where plotting is performance critical, or should I just keep things simple/stupid in terms of the performance/simplicity tradeoff? I'd stick with (2) for now.
Re: Plotting Using PLPlot
It seems like there's substantial interest in this. Please give me some use cases, i.e. what would you personally use this for, and what do you foresee others using it for, so I can start thinking about what the API should be. I need a wide variety of use cases because, if I design the API based only on my personal use cases, it will end up being geared entirely toward histograms, scatter plots, and line graphs because that's what I use regularly. Besides use cases, here are some specific questions: 1. Is there any need for an OO-based API, or should I just use free functions? 2. Does anyone have any use cases where plotting is performance critical, or should I just keep things simple/stupid in terms of the performance/simplicity tradeoff?
Re: What's the current state of D?
Tomas Lindquist Olsen wrote: > On Sun, May 10, 2009 at 12:05 AM, mpt wrote: >> I keep making 2 mistakes in my D programs, and fixing them feels >> troublesome. >> >> 1. Null references. I get a segfault and gdb is useless (ldc thing maybe). > > Useless how? Generally LDC debug info should be decent. If not, we'd > be glad to look into why that is! I had a problem in the past where gdb would only output a bunch of ???'s like it does for stripped or optimized executables. This seems no longer to be the case. I stand corrected.
Re: What's the current state of D?
Leandro Lucarella wrote: Walter Bright, el 9 de mayo a las 22:05 me escribiste: Leandro Lucarella wrote: Official? I don't see any official support for D in GDB. I can only find this patches: http://www.dsource.org/projects/gdb-patches/ Dwarf has an official value for the language, DW_LANG_D = 0x13. I'm talking about GDB. GDB has no official D support. GDB officially supports Dwarf, and Dwarf officially has a D identifier. While gdb may not go any further than that, it's a start. There was a thread in the NG asking for possible copyright issues to include the GDB patch upstream, and it had no answer for example. I don't think you *have* to answer that mail, but I think helping this kind of things happening instead of ignoring them is good for D promotion too =) Can you point me to that thread? There are an awful lot of posts, and I miss things. How is that? Most runtime code is not used by the user directly. And for this item I think not merging it does more damage than introducing a breaking change (is much better to introduce a breaking change to solve this problem than to add a predefined Posix version ;). Tango chose to use a number of incompatible names and a fundamentally different class hierarchy for the same thing(s). How many people is using that? How bad would it be to call the next version of DMD that include the Tango/Druntime runtime D 1.100 or something (is really hard to pick right version numbers under the version scheme you use[*]) to make clear there is compatibility break in that version? Given all the beating of breasts and rending of robes about D1 not being stable and breaking code even when a bug is fixed in it, I just can't see coming out with a new D1 that substantially breaks every existing D1 code base. Seriously, there were several (silly) compatibility breaks since 1.0 was out, I think is a huge issue that deserves it... This is what I mean when I say that it's simply impossible to ask for breaking changes for D1 while pillorying D1 for breaking changes. I also believe it is impractical to divide D1 into two incompatible versions - then there'd be 3 D versions to simultaneously support. D2 has already taken the steps necessary to support both Phobos and Tango.
Re: Associative Arrays and Interior Pointers
== Quote from Sean Kelly (s...@invisibleduck.org)'s article > dsimcha wrote: > > > > 2. Other than its abysmal interaction with the current GC and the lack of > > ability to iterate using ranges, the current AA implementation actually > > seems > > pretty good. One way to remedy a large portion of the GC issues without a > > massive overhaul of the GC would be to introduce a feature into the GC > > where a > > block of memory can be flagged as NO_INTERIOR. > Neat idea. Some GCs (like the Boehm GC) can be set NO_INTERIOR > globally, but it never crossed my mind to do this per block. For > certain data structures, this might be pretty useful. I get the impression that D's GC will always have a significant degree of conservatism. Of course, there's always unions, but unioning a pointer type w/ a non-pointer type is such an edge case that, if this is the only thing that's conservative, then the GC can be considered precise for all practical purposes. For now, I'd love to see this added, because it would be an extremely "cheap" way to solve a lot of annoying problems. A few questions: 1. (For Leonardo, especially): Is the GC likely to get precise enough in the near future that something like this would end up being considered a piece of cruft? 2. Other than that, is there any reason this should not go in? 3. Sean, if you're seriously thinking of putting this in in the near future, let me know so I can fix that patch, too. I did it the same way as my other GC patch, with no whitespace, so the line numbers might be screwy here, too.
Re: How to use C++ static library in d
Hima wrote: Hello everyone. I'm wondering is there a way to use a C++ static library in D? I only have the .h and .lib files of the library, but not .dll or .cpp D 2.0 can interface directly with C++ free functions and single inheritance hierarchies. If you need to go further than that, the way is to create a C wrapper for the C++ code, then D can call the C wrapper.
Re: What's the current state of D?
Brad Roberts, el 9 de mayo a las 21:42 me escribiste: > Leandro Lucarella wrote: > > Brad Roberts, el 9 de mayo a las 12:31 me escribiste: > >> If there's things that need to change in what the compiler emits, Walter > >> has > >> shown himself to be willing to rapidly change them where the required > >> changes > >> are clearly described in terms of both 'what' and 'why'. In other words, > >> "it's > >> broken" isn't sufficient but "if the frobble was changed to frobnosticator > >> for > >> each wobble, it would work" results in the next release having that change > >> made. > > > > BTW, here is something that should be fixed in the compiler to improve GNU > > binutils support =) > > http://d.puremagic.com/issues/show_bug.cgi?id=2932 > > > > A great illustration of a less than ideal bug report. "A tool breaks in some > way, fix the compiler." It's entirely possible that dmd is producing the > wrong > thing, but there's an definite lack of specificity about what's wrong on the > compiler side. Those errors are coming out of the linker. It's not even > particularly clear that the bug is with dmd and not the new linker (one that's > not shipped as the default linker on any distribution yet, unless I've lost > track again). No, it's not (it's shipped but not as the default linker), because they are making sure that it works well with other tools. Usually when you use a tool that is a de facto standard and have some bug, people start relying in that bug as a feature. I know I had some linking bugs because of this, and I spotted them thanks to Gold. I'm not saying that Gold is perfect, but since it's a complete rewrite there are some bugs fixed (or things where is more strict than the old GNU ld) that should be adjusted to work well with the new linker. I reported the bug because I think that could be the case. If is not, it's a Gold bug and it should be reported. If it is, it should be fixed in DMD. I don't have the knowlegde to check that myself, and that's why I reported the bug to both tools. > In other words, it's not at all surprising to me that the bug report > hasn't received a lot of attention yet. So you are saying you have to be a compiler hacker to report a bug? Great, that make sense! I think the error message is pretty clear (the ELF header size is supposed to be wrong). I think somebody that know the compiler can check if this bug report is right or if it's a bug in GNU Gold in a couple of minutes (maybe seconds). And BTW GDC and LDC works just fine. I guess you can argue that GDC uses the GCC backend which can be tightly coupled with GNU binutils being both a GNU product, but LDC is not. So the bug report has a high probability to be right, I wasn't saw the error message and run to the D bugzilla to report the bug, I tested other tools first, and from my own experience with Gold, when it said there was an error and I thought the error was in Gold, I was wrong and Gold was right (because what I said before, I was relying on some bugs in the old GNU ld), so I have some degree of confidence in that Gold is not a piece of crap full of bugs. And you may take a look to the GNU Gold linker bug report: http://sourceware.org/bugzilla/show_bug.cgi?id=10126 It is having attention. That's why GNU tools are widely used and D isn't. This kind of things make very sad... -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) VECINOS RESCATARON A CABALLITO ATROPELLADO -- Crónica TV
Re: What's the current state of D?
Leandro Lucarella wrote: > How many people is using that? How bad would it be to call the next > version of DMD that include the Tango/Druntime runtime D 1.100 or > something (is really hard to pick right version numbers under the version > scheme you use[*]) to make clear there is compatibility break in that > version? > > [*] I really wonder how would you call D2 when it's stable. You will just > say D 2.134 is D2 final/stable? I think this is another problem with > D, version naming is really confusing and lame. You can't know > anything from a D version number. And DMD compiler and D specs are too > much coupled. It would be nice to have separate version numbers if you > really want to encourage some kind of D standard and compiler vendors > to start making D compilers. For what it's worth, there's at least one other major product that follows a similar versioning scheme.. mysql. Later, Brad
Re: What's the current state of D?
It seems I didn't explain myself very clearly. Daniel Keep wrote: >> The point of non-nullables would be to detect improper usage at >> compile-time, right? Then I don't believe this problem has an elegant >> solution until compilers can do a rigorous control-flow analysis. >> Specifying default pointer values other than null doesn't seem very nice. > > You don't need control-flow analysis. You just need a type system which > supports nullables like D2's supports const. You need control-flow analysis to know at compile-time if: * an uninitialized value is read, or * a null pointer is dereferenced. >> Nonetheless, a good step forward would be to recognize the distinction >> between `null' and `uninitialized'. Reading a variable that's >> uninitialized is an error. Reading a null pointer is fine, but >> dereferencing it is an error. > > Uninitialised variables is only a symptom. The larger issue is that it > doesn't make sense for most functions to accept null object arguments. > It's quite rare, at least in my code, to have a function that can do > anything sensible with "nothing" other than HCF [1]. I understand the issue. In my idea, there are non-nullable pointers. In fact, they would probably be the default kind of pointer. But Christopher explained those kinds of pointers have their own problems. How to initialize an array of non-nullables? Or a struct? So formally introduce the notion of `uninitialized' variables, or in particular, pointers. No need to initialize (even non-nullables) right away. Just initialize anytime. I believe in D you specify this with =void. But don't you see, you've replaced your null-dereference problem with a uninitialized-reading problem. That's basically the same deal. > We already have a runtime check, and > it's not good enough. The major issue is that it notifies us of a > problem at a time when we generally do not have any useful information > on how to solve it. Exactly. This brings me back to the need for rigorous control-flow analysis. Without it, you can't get your info at compile-time in the general case. -- Michiel Helvensteijn
Re: when will D2 be stable?
On Fri, May 8, 2009 at 11:00 AM, Andrei Alexandrescu wrote: > zsxxsz wrote: >> >> I found D is a wonderful programming language and start to use it in my >> projects. I use D2 now, but which is still unstable although it's version >> is >> D2.029. Can anyone tell me when D2 will be stable? Although D's using rate >> suffers sharp fall(shown in tiobe), I'll still believe that D will be >> better >> in future. But why does D fall down so much? > > The fall of D in Tiobe has to do with an issue in Yahoo's search engine. I > have talked to a friend of mine who is a research scientist at Yahoo and he > is looking into fixing the issue and also the fact that the top 3 results > for "D programming" search are irrelevant. I love it! Straight to the root of the problem. --bb
Re: What's the current state of D?
Walter Bright, el 9 de mayo a las 22:05 me escribiste: > Leandro Lucarella wrote: > >Official? I don't see any official support for D in GDB. I can only find > >this patches: > >http://www.dsource.org/projects/gdb-patches/ > > Dwarf has an official value for the language, DW_LANG_D = 0x13. I'm talking about GDB. GDB has no official D support. There was a thread in the NG asking for possible copyright issues to include the GDB patch upstream, and it had no answer for example. I don't think you *have* to answer that mail, but I think helping this kind of things happening instead of ignoring them is good for D promotion too =) > >How is that? Most runtime code is not used by the user directly. And for > >this item I think not merging it does more damage than introducing > >a breaking change (is much better to introduce a breaking change to solve > >this problem than to add a predefined Posix version ;). > > Tango chose to use a number of incompatible names and a fundamentally > different class hierarchy for the same thing(s). How many people is using that? How bad would it be to call the next version of DMD that include the Tango/Druntime runtime D 1.100 or something (is really hard to pick right version numbers under the version scheme you use[*]) to make clear there is compatibility break in that version? Seriously, there were several (silly) compatibility breaks since 1.0 was out, I think is a huge issue that deserves it... [*] I really wonder how would you call D2 when it's stable. You will just say D 2.134 is D2 final/stable? I think this is another problem with D, version naming is really confusing and lame. You can't know anything from a D version number. And DMD compiler and D specs are too much coupled. It would be nice to have separate version numbers if you really want to encourage some kind of D standard and compiler vendors to start making D compilers. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) MATAN AL PERRO: DICEN QUE ESTABA POSEIDO POR EL DEMONIO... -- Crónica TV
Re: Plotting Using PLPlot
A D-ish wrapper around PLPlot's low-level D-to-C bindings sounds great to me too. I frequently use the D -> data file -> Python matplotlib route myself. Something more direct would be great. --bb On Sun, May 10, 2009 at 5:51 AM, Fawzi Mohamed wrote: > On 2009-05-10 05:19:53 +0200, dsimcha said: > >> As the scientific computing libraries for D improve, I find myself wanting >> more and more to be able to plot stuff straight from D without having to >> rely >> on kludges like writing data out to a file and then calling Python or >> Matlab >> or something. I've noticed that PLPlot has D bindings. Its license is >> also >> reasonably permissive (LGPL). This is certainly an improvement over >> nothing, >> but the API kind of sucks because it was written in C. For example, >> instead >> of ranges or D arrays of arbitrary type, you pass data in as a double* and >> a >> number of data points. >> >> On the other hand, all the nitty-gritty, low-level, probably >> platform-specific, stuff needed for a plotting library is (I guess) pretty >> good. This led me to the following idea for how to get a good D plotting >> lib >> for relatively few man-hours: Take the low-level stuff from PLPlot, and >> reimplement the higher level stuff on top of it in pure D, using the full >> power of templates, ranges, builtin arrays, etc. I'm considering making >> this >> my next hobby project, and I'm interested in some suggestions on how it >> should >> be done (what a good API would be, etc.), as well as getting an idea of >> how >> many people are interested in something like this. > > This is definitely very interesting, having an integrated plot would be very > nice > > Fawzi > >
Re: What's the current state of D?
Michiel Helvensteijn wrote: > ... > > The point of non-nullables would be to detect improper usage at > compile-time, right? Then I don't believe this problem has an elegant > solution until compilers can do a rigorous control-flow analysis. > Specifying default pointer values other than null doesn't seem very nice. You don't need control-flow analysis. You just need a type system which supports nullables like D2's supports const. > Nonetheless, a good step forward would be to recognize the distinction > between `null' and `uninitialized'. Reading a variable that's uninitialized > is an error. Reading a null pointer is fine, but dereferencing it is an > error. Uninitialised variables is only a symptom. The larger issue is that it doesn't make sense for most functions to accept null object arguments. It's quite rare, at least in my code, to have a function that can do anything sensible with "nothing" other than HCF [1]. > This effectively solves your non-nullable problems, but you'd basically be > replacing them with another problem. No, it doesn't. > ... > > So effectively, what's the difference between that and the original null > reference problem? You'd basically get the runtime error when you read the > pointer, but before you dereference it. > > Until compilers are smart enough. The whole point of having non-nullable types is so that you can't even STORE a null in the first place. We already have a runtime check, and it's not good enough. The major issue is that it notifies us of a problem at a time when we generally do not have any useful information on how to solve it. The problem isn't dereferencing nulls. It's when they get STORED that's the problem. -- Daniel [1] HCF - Halt and Catch Fire; old instruction on the PDP machines. :P
Re: Associative Arrays and Interior Pointers
dsimcha wrote: 2. Other than its abysmal interaction with the current GC and the lack of ability to iterate using ranges, the current AA implementation actually seems pretty good. One way to remedy a large portion of the GC issues without a massive overhaul of the GC would be to introduce a feature into the GC where a block of memory can be flagged as NO_INTERIOR. Neat idea. Some GCs (like the Boehm GC) can be set NO_INTERIOR globally, but it never crossed my mind to do this per block. For certain data structures, this might be pretty useful.
Re: What's the current state of D?
Christopher Wright wrote: >> About the null references, most people seem to agree that the right way >> to fix that is with some sort of "non-nullable". But there's a lot of >> disagreement on exactly how non-nullables should work. > > And whether they *can* work. D2 has struct constructors, so structs can > have non-nullable fields, but you can't have an array of non-nullable > elements (you can set the length, and suddenly your non-nullable-element > array has a bunch of nulls in it). Similarly, no arrays of structs > containing non-nullable types, etc. The point of non-nullables would be to detect improper usage at compile-time, right? Then I don't believe this problem has an elegant solution until compilers can do a rigorous control-flow analysis. Specifying default pointer values other than null doesn't seem very nice. Nonetheless, a good step forward would be to recognize the distinction between `null' and `uninitialized'. Reading a variable that's uninitialized is an error. Reading a null pointer is fine, but dereferencing it is an error. This effectively solves your non-nullable problems, but you'd basically be replacing them with another problem. In general, you can only know if a variable is initialized at run-time. And then only if you reserve memory for the `uninitialized' state. So effectively, what's the difference between that and the original null reference problem? You'd basically get the runtime error when you read the pointer, but before you dereference it. Until compilers are smart enough. -- Michiel Helvensteijn
Re: DMD's Released Source, Great Stuff!
Nick Sabalausky wrote: I just wanted to say how nice it is having and working with the DMD source, and how nice the whole submission process (ie bugzilla) is. Yes, and now with the new look of bugzilla, you'd feel you're browsing Enterprise's bugzilla :o). Thanks Brad. I'm glad to finally see a good word out here. It's been a few good days since there's been much more than incessant and unjustified (IMHO) whining. Andrei
Re: DMD's Released Source, Great Stuff!
Nick Sabalausky wrote: I just wanted to say how nice it is having and working with the DMD source, and how nice the whole submission process (ie bugzilla) is. Yes, and now with the new look of bugzilla, you'd feel you're browsing Enterprise's bugzilla :o). Thanks Brad. I'm glad to finally see a good word out here. It's been a few good days since there's been little more than incessant and unjustified (IMHO) whining. Andrei
Re: SCHEDULED for deprecation
Tomasz Sowiński wrote: This phrase gave me an idea for a small feat: deprecated(2009-4-19) void foo(); Compiling references to the deprecated declaration *before* the deprecation date would result in a *warning*. Compiling the deprecated declaration OR any reference to it *after* the date would result in an *error*. Advantages for maintanance are obvious, plus, the feature seems easy to implement. What do you think? Tomek Put this in the control of the library creator. Have scheduled_for_deprecation and deprecated.
Re: What's the current state of D?
Nick Sabalausky wrote: About the null references, most people seem to agree that the right way to fix that is with some sort of "non-nullable". But there's a lot of disagreement on exactly how non-nullables should work. And whether they *can* work. D2 has struct constructors, so structs can have non-nullable fields, but you can't have an array of non-nullable elements (you can set the length, and suddenly your non-nullable-element array has a bunch of nulls in it). Similarly, no arrays of structs containing non-nullable types, etc. There are a lot of things to look into with non-nullables, and Walter doesn't have the time.
Re: What's the current state of D?
torhu wrote: On 10.05.2009 00:05, mpt wrote: I keep making 2 mistakes in my D programs, and fixing them feels troublesome. 1. Null references. I get a segfault and gdb is useless (ldc thing maybe). 2. Exceptions. It prints the msg nicely, but it's unhelpful in tracing the real cause of error. Shouldn't there be an automatic null check for references and stack traces? Sometimes I think I'm using the wrong tool as others have solutions for these. Tango trunk has stacktrace functionality for both Windows and linux I think. There's also a Phobos backtrace patch. Though the Linux one just prints out the addresses and not the line numbers. Licensing issues with linking to libbfd to extract that information.
Re: Plotting Using PLPlot
On 2009-05-10 05:19:53 +0200, dsimcha said: As the scientific computing libraries for D improve, I find myself wanting more and more to be able to plot stuff straight from D without having to rely on kludges like writing data out to a file and then calling Python or Matlab or something. I've noticed that PLPlot has D bindings. Its license is also reasonably permissive (LGPL). This is certainly an improvement over nothing, but the API kind of sucks because it was written in C. For example, instead of ranges or D arrays of arbitrary type, you pass data in as a double* and a number of data points. On the other hand, all the nitty-gritty, low-level, probably platform-specific, stuff needed for a plotting library is (I guess) pretty good. This led me to the following idea for how to get a good D plotting lib for relatively few man-hours: Take the low-level stuff from PLPlot, and reimplement the higher level stuff on top of it in pure D, using the full power of templates, ranges, builtin arrays, etc. I'm considering making this my next hobby project, and I'm interested in some suggestions on how it should be done (what a good API would be, etc.), as well as getting an idea of how many people are interested in something like this. This is definitely very interesting, having an integrated plot would be very nice Fawzi
DMD's Released Source, Great Stuff!
I just wanted to say how nice it is having and working with the DMD source,
and how nice the whole submission process (ie bugzilla) is.
A couple years ago, there were some things I wanted to try to do with GCC,
but it was a nightmare. Took forever to figure out how to get things set up
to properly compile the GCC sources (this was under windows). Then the
actual build took hours per-attempt, and I had to do it a few times, because
it kept running into problems mid-way through. Then when I was ready to try
to make my changes, finding my way through the source was a like navigating
the world's most devious maze while blindfolded and walking backwards. And
the one thing I never did figure out was just how the heck the submission
process worked. Best I could figure, part of it seemed to even involve "wait
for the right month". I messed with it on and off for weeks before finally
giving up.
So I was a bit put-off from attempting to build and contribute to compilers,
and hadn't attempted to do anything with or even look at the DMD source
since the before the backend's source was released, until now.
I finally got motivated to try to do a patch ('zilla #2567, FWIW), and, wow,
it went smooth:
I downloaded DMC, made some very minor changes to the makefile (only because
I seem to have another conflicting tool named "sc" in my path), successfully
recompiled it, found the locations in the source I needed, changed a few
lines, recompiled again, tested, it worked, attached a patch to bugzilla,
and was done in no more than about a couple of hours. Wow!
How to use C++ static library in d
Hello everyone. I'm wondering is there a way to use a C++ static library in D? I only have the .h and .lib files of the library, but not .dll or .cpp Thank you in advance :)
Re: Promoting D
The problem I have explaining why somebody should take up D is that I know not enough about the languages they use to actually show them the things they are missing. Sometimes it is the, for me, obvious feature like functions within functions that tilts their heads a bit.
