Re: DConf 2013 Day 3 Talk 1: Metaprogramming in the Real World by Don Clugston
On Tuesday, 11 June 2013 at 20:02:29 UTC, Walter Bright wrote: On 6/11/2013 12:21 PM, John Colvin wrote: On Tuesday, 11 June 2013 at 18:47:35 UTC, Walter Bright wrote: On 6/11/2013 8:28 AM, Adam D. Ruppe wrote: It is great stuff, solar power is almost free money if you can wait 20 years for it. Yeah, but you'll have to replace it before 20 years! Source? There's not much that wears out in a photovoltaic AFAIK. The associated electrical components may break however, especially on some of the more complex setups. Don't have a source, I read it long ago. Note that none of the advertisements, brochures, etc., mention expected life of the PVs. That's not correct. Almost all manufacturers provide a 20 or 30 year warranty. Warranty periods have been slowing increasing as the industry has gained field experience. I do know that the life of any semiconductor is measured as the integral of the heat it experiences. Heat causes the doping to migrate, and when it migrates far enough the part fails. That's true for certain kinds of dopants (it's particularly true if you have copper involved), but dopant migration is not an issue for any commercial solar modules that I know of. (The situation may be different for exotic technologies). This is because solar cells are very simple devices, they're just enormous diodes. Virtually all solar module failures in the field are caused by mechanical issues (bad solder joints, cracks, delamination), not by semiconductor degradation. PV panels can get pretty hot in direct sunlight. They do. Still not as hot as a CPU though! Heating/cooling cycling will also cause cracking. Most of these problems were solved in the 80's. We were continuously doing accelerated lifetime testing of our own modules and ones from various manufacturers. Temperature cycling, humidity freeze, hail impact testing (that's fun), wind load testing (that's really fun), etc. For some silicon modules you can get oxygen-boron complexes induced by UV, which causes a slow reduction in power, but our modules survived 200 years equivalent UVB exposure with no degradation whatsoever. Circuit boards, inverters, etc., also fail, and you'd need some assurance you can get replacement parts for 20 years. That one is definitely true. Even worse is batteries for off-grid systems, batteries have a very short lifetime.
DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
Reddit: http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/ Hackernews: https://news.ycombinator.com/item?id=5867764 Twitter: https://twitter.com/D_Programming/status/344798127775182849 Facebook: https://www.facebook.com/dlang.org/posts/655927124420972 Youtube: http://youtube.com/watch?v=ph_uU7_QGY0 Please drive discussions on the social channels, they help D a lot. Andrei
Re: DConf 2013 Day 3 Talk 1: Metaprogramming in the Real World by Don Clugston
On 6/11/13 11:40 PM, Walter Bright wrote: I just want to point out that owning a home is far from the sure path to wealth it is too often presented as. As always, caveat emptor. I'd say it's historically about as risky as owning stocks. The main difference is that the house has a utility value - you can't live in a stock. Andrei
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
Am 12.06.2013 14:50, schrieb Andrei Alexandrescu: Reddit: http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/ Hackernews: https://news.ycombinator.com/item?id=5867764 Twitter: https://twitter.com/D_Programming/status/344798127775182849 Facebook: https://www.facebook.com/dlang.org/posts/655927124420972 Youtube: http://youtube.com/watch?v=ph_uU7_QGY0 Please drive discussions on the social channels, they help D a lot. Andrei The reddit link seems to be deleted?
Re: DConf 2013 Day 3 Talk 1: Metaprogramming in the Real World by Don Clugston
On 06/11/2013 09:33 AM, Andrei Alexandrescu wrote: Reddit: http://www.reddit.com/r/programming/comments/1g47df/dconf_2013_metaprogramming_in_the_real_world_by/ Hackernews: https://news.ycombinator.com/item?id=5861237 Twitter: https://twitter.com/D_Programming/status/344431490257526785 Facebook: https://www.facebook.com/dlang.org/posts/655271701153181 Youtube: http://youtube.com/watch?v=pmwKRYrfEyY Please drive discussions on the social channels, they help D a lot. Andrei Great talk!!! Can't wait for faster CTFE, the new orange serialization library would benefit from it. --jm
Re: DConf 2013 Day 2 Talk 5: A Precise Garbage Collector for D by Rainer Schütze
On 06/05/2013 10:23 AM, Andrei Alexandrescu wrote: Reddit: http://www.reddit.com/r/programming/comments/1fpw2r/dconf_2013_day_2_talk_5_a_precise_garbage/ Hackernews: https://news.ycombinator.com/item?id=5825320 Twitter: https://twitter.com/D_Programming/status/342269600689430529 Facebook: https://www.facebook.com/dlang.org/posts/651801198166898 Youtube: http://youtube.com/watch?v=LQY1m_eT37c Please drive discussions on the social channels, they help D a lot. Andrei Loved this talk. Would struct have an extra field in memory pointing to the needed type info? If all of this is implemented, will this mean that an array of structs will not have their data contiguous in memory? Thanks for the talk! --jm
Re: DConf 2013 Day 2 Talk 5: A Precise Garbage Collector for D by Rainer Schütze
On 06/05/2013 10:23 AM, Andrei Alexandrescu wrote: Reddit: http://www.reddit.com/r/programming/comments/1fpw2r/dconf_2013_day_2_talk_5_a_precise_garbage/ Hackernews: https://news.ycombinator.com/item?id=5825320 Twitter: https://twitter.com/D_Programming/status/342269600689430529 Facebook: https://www.facebook.com/dlang.org/posts/651801198166898 Youtube: http://youtube.com/watch?v=LQY1m_eT37c Please drive discussions on the social channels, they help D a lot. Andrei Loved this talk. Would struct have an extra field in memory pointing to the needed type info? If all of this is implemented, will this mean that an array of structs will not have their data contiguous in memory? Thanks for the talk! --jm
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On 6/12/13 9:00 AM, David wrote: Am 12.06.2013 14:50, schrieb Andrei Alexandrescu: Reddit: http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/ Hackernews: https://news.ycombinator.com/item?id=5867764 Twitter: https://twitter.com/D_Programming/status/344798127775182849 Facebook: https://www.facebook.com/dlang.org/posts/655927124420972 Youtube: http://youtube.com/watch?v=ph_uU7_QGY0 Please drive discussions on the social channels, they help D a lot. Andrei The reddit link seems to be deleted? Sorry, wrong URL. It's here: http://www.reddit.com/r/programming/comments/1g6xbi/dconf_2013_code_analysis_for_d_with_analyzed_by/ Please vote, it only has 3 points! Andrei
Re: DConf 2013 Day 3 Talk 1: Metaprogramming in the Real World by Don Clugston
On 6/12/2013 1:04 AM, Don wrote: On Tuesday, 11 June 2013 at 20:02:29 UTC, Walter Bright wrote: Note that none of the advertisements, brochures, etc., mention expected life of the PVs. That's not correct. Almost all manufacturers provide a 20 or 30 year warranty. Warranty periods have been slowing increasing as the industry has gained field experience. Warranty is not the same as expected life, MTBF, etc. Anyhow, thanks for weighing in with a great post!
Re: DConf 2013 Day 3 Talk 1: Metaprogramming in the Real World by Don Clugston
On 06/11/2013 08:59 PM, Steven Schveighoffer wrote: On Tue, 11 Jun 2013 23:36:11 -0400, Jesse Phillips jesse.k.phillip...@gmail.com wrote: On Tuesday, 11 June 2013 at 21:55:48 UTC, Adam D. Ruppe wrote: ...and if you sell it, unless you own multiple houses, you're now homeless. And housing prices are up, so getting a new house will erase the gains you got from selling the old house! So I don't think raising property values makes me wealthier at all. But when housing cost goes up the government can take more from you on anything based on your wealth. Just because you can't pay because your wealth is all chewed up in material things like a house, who cares! In the US at least, only home sales (or transfers of ownership, like inheritance) are taxed. As long as you live there, they will not (and I believe they cannot) tax you based on the current value. Property taxes are different, and you will be paying those no matter how you live (rent or own). And you are allowed to transfer equity from your current home into a new home tax free, even if you gained, up to a certain amount. I think there are limitations on how many times you can do this... The tax system is definitely set up to favor the homeowner, not the renter. -Steve That's a state-by-state decision. As to whether it's fair...I could make a case against either side.
Re: DConf 2013 Day 3 Talk 1: Metaprogramming in the Real World by Don Clugston
On 6/12/2013 5:58 AM, Andrei Alexandrescu wrote: On 6/11/13 11:40 PM, Walter Bright wrote: I just want to point out that owning a home is far from the sure path to wealth it is too often presented as. As always, caveat emptor. I'd say it's historically about as risky as owning stocks. The main difference is that the house has a utility value - you can't live in a stock. When you're comparing ownership to renting, the utility issue is moot. Steven Schveighoffer wrote: But you can continue to live in an underwater-mortgage house if you can pay for it. Yes, but we are talking about the financial difference between owning vs renting. it was an educated choice. I'm not saying you're wrong, but the proof of that is if you can repeat the success consistently. For example, a lot of CEOs have made fortunes for their companies by backing the right horse. Sometimes, people dismiss them as just lucky, being in the right place at the right time and guessing the right direction. But some CEOs repeatedly make the right choices, and that cannot be dismissed as luck. Examples: Bill Gates and Steve Jobs. I also know a guy who sold everything at the 2000 peak and the 2007 peak. He tells me it was obvious, but I don't know anyone else who did both, although I know many who did one or the other.
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
Andrei Alexandrescu: Youtube: http://youtube.com/watch?v=ph_uU7_QGY0 It's an interesting talk. Maybe all talks of this conference were interesting. Some notes on the slides. - - - - - - - - - - - - Slide 12: A class is an item with a strict boundary. e.g.: Arrays will be dupped at these borders. I think this kind of privacy for reference data is a common need. I think enforcing this is not a job of static analysis tools, it looks like a job for the type system. An annotation should suffice (in theory this annotation should allow the access of the array from outside, so it should be forbidden by default for private fields. Now this can't be done, so an annotation needs to do the opposite). Maybe this needs some discussion in the main D newsgroup. - - - - - - - - - - - - Slide 12: We do not use Ddoc, because most important information about functions are not included. - In- / Out-Constrains - Exceptional Cases aka Throws How to annotate throws in ddoct? Do they need to be generated automatically? Regarding pre/post conditions, maybe a ddoc macro or switch can be used to make them appear in the ddoc output on request. - - - - - - - - - - - - Slide 12: Next to classes also model package dependency - no cyclic dependencies anymore Maybe it's possisible to add some way (like a standard annotation) to enforce the absence of cyclic dependencies in a section of a project (like inside a package). - - - - - - - - - - - - Slide 14: - Private static functions which could be tested inplace are tested using D-unittest-Blocks (Unit =:= Function) - Other tests require setups, teardowns, names (Testdox http://agiledox.sourceforge.net/). Need to be filtered, selected. For them using Dunit. (Unit =:= Class / Struct) I think the built-in unit test system should be improved, so in _most_ cases there's no need to use a second unittest system. Bye, bearophile
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On Wednesday, 12 June 2013 at 17:31:27 UTC, bearophile wrote: We do not use Ddoc, because most important information about functions are not included. - In- / Out-Constrains These are pretty easy to add to dmd. In doc.c's FuncDelaration::toDocBuffer you can throw in something like this: if(frequire) buf-writestring(frequire-toChars()); if(fensure) buf-writestring(fensure-toChars()); with a little cleanup and a wrapper macro and I think that would be good. - Exceptional Cases aka Throws No easy way to do this automatically though because the compiler doesn't even know what a function can throw. You'd just have to do it manually.
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On 6/12/13 8:50 AM, Andrei Alexandrescu wrote: Reddit: http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/ Hackernews: https://news.ycombinator.com/item?id=5867764 Twitter: https://twitter.com/D_Programming/status/344798127775182849 Facebook: https://www.facebook.com/dlang.org/posts/655927124420972 Youtube: http://youtube.com/watch?v=ph_uU7_QGY0 Please drive discussions on the social channels, they help D a lot. Andrei In HD: https://archive.org/details/dconf2013-day03-talk02 Andrei
Re: DConf 2013 Day 2 Talk 5: A Precise Garbage Collector for D by Rainer Schütze
On 12.06.2013 15:38, Juan Manuel Cabo wrote: On 06/05/2013 10:23 AM, Andrei Alexandrescu wrote: Reddit: http://www.reddit.com/r/programming/comments/1fpw2r/dconf_2013_day_2_talk_5_a_precise_garbage/ Hackernews: https://news.ycombinator.com/item?id=5825320 Twitter: https://twitter.com/D_Programming/status/342269600689430529 Facebook: https://www.facebook.com/dlang.org/posts/651801198166898 Youtube: http://youtube.com/watch?v=LQY1m_eT37c Please drive discussions on the social channels, they help D a lot. Andrei Loved this talk. Thanks. Would struct have an extra field in memory pointing to the needed type info? If all of this is implemented, will this mean that an array of structs will not have their data contiguous in memory? A struct allocated on the heap does not need the type info in memory, it is passed with the call invoked by new and it is used to supply the bitmap of pointers that is copied to the appropriate memory. Due to the implementation details of arrays, it is a bit different for them: The memory layout changes slightly depending on the size of the array, so it is not the allocation that creates the pointer bitmap, but the array functions call emplace to fill the bitmap from an array type info. The memory layout of the array itself is unchanged.
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On 6/12/13, Adam D. Ruppe destructiona...@gmail.com wrote: No easy way to do this automatically though because the compiler doesn't even know what a function can throw. You'd just have to do it manually. Are you sure? A compiler can tell whether a function /can/ throw (hence why nothrow works), so I assume it has information on where an exception is thrown. I think it'd be nice if we added this ability to ddoc, having to manually do it often means the documentation being out of date.
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On Wednesday, 12 June 2013 at 20:23:43 UTC, Andrej Mitrovic wrote:
Are you sure? A compiler can tell whether a function /can/ throw
(hence why nothrow works), so I assume it has information on
where an exception is thrown.
Consider this:
extern(D) void foo();
void bar() { foo(); }
That's legal D code, and foo could throw anything, and bar would
have no idea what it is.
Looking at dmd's source, looks like Walter actually wrote code to
parse a throws Exception, etc. to be part of the function
signature but stripped it out (surely because that's annoying).
Without a list like that, the compiler just can't be sure what
happens. It could maybe try to figure it out based on the source
it has available, and at least get an incomplete list, but
currently it doesn't attempt to do that.
That might not be too hard to do actually, when outputting the
ddoc, dive into the function body for throw statements and build
up a list. If the call tree goes down to anything it doesn't
recognize and is not marked nothrow, then it could say I'm not
sure if this is everything but this is what I found.
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On Wednesday, June 12, 2013 22:29:15 Adam D. Ruppe wrote:
On Wednesday, 12 June 2013 at 20:23:43 UTC, Andrej Mitrovic wrote:
Are you sure? A compiler can tell whether a function /can/ throw
(hence why nothrow works), so I assume it has information on
where an exception is thrown.
Consider this:
extern(D) void foo();
void bar() { foo(); }
That's legal D code, and foo could throw anything, and bar would
have no idea what it is.
nothrow is like @safe or pure. The compiler knows whether that attribute on
the function is valid by looking at the signatures of the functions called
within that function (as well as what the built-in operations used are). The
bodies of the functions being called never comes into play. At least some of
the time, it would be theoretically possible for the compiler to go look in
the bodies of the functions being called, but all of that stuff is based off of
the function signatures, not their bodies. A function's body is only looked at
when it's being compiled, not when other functions refer to it. And with the
C linking model, it really doesn't make sense for the compiler to look at the
bodies of other functions when compiling a function.
Tools could certainly look at source code and figure out stuff like what
exceptions could be thrown from a particular function, but that requires
having all of the source and examining it, and that's not how compilers
normally work.
- Jonathan M Davis
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On Wed, 12 Jun 2013 08:50:41 -0400 Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Reddit: http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/ Hackernews: https://news.ycombinator.com/item?id=5867764 Twitter: https://twitter.com/D_Programming/status/344798127775182849 Facebook: https://www.facebook.com/dlang.org/posts/655927124420972 Youtube: http://youtube.com/watch?v=ph_uU7_QGY0 Please drive discussions on the social channels, they help D a lot. Andrei Torrents and links: http://semitwist.com/download/misc/dconf2013/
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On 6/12/2013 1:29 PM, Adam D. Ruppe wrote: Looking at dmd's source, looks like Walter actually wrote code to parse a throws Exception, etc. to be part of the function signature but stripped it out (surely because that's annoying). That detritus should be removed. It was a bad idea, which is why I disabled it.
Re: DConf 2013 Day 3 Talk 1: Metaprogramming in the Real World by Don Clugston
On 06/11/2013 02:33 PM, Andrei Alexandrescu wrote:
Reddit:
http://www.reddit.com/r/programming/comments/1g47df/dconf_2013_metaprogramming_in_the_real_world_by/
Hackernews: https://news.ycombinator.com/item?id=5861237
Twitter: https://twitter.com/D_Programming/status/344431490257526785
Facebook: https://www.facebook.com/dlang.org/posts/655271701153181
Youtube: http://youtube.com/watch?v=pmwKRYrfEyY
Please drive discussions on the social channels, they help D a lot.
Andrei
Nice talk.
I'd like to relativize the statement about JITing CTFE though.
This is feasible, even given issues such as global local variables. [1]
I have a byte code interpreter for most of CTFE. I have been
unexpectedly busy lately, but hope to get my D frontend out the door in
a more or less respectable state soon.
[1] Given that I understand the term correctly. Is this what you meant?:
int foo(int x){
immutable globalLocal1 = 1;
int globalLocal2 = x;
int foo(bool first){return first?globalLocal1:globalLocal2;}
enum y = foo(true);
return foo(false)+y;
}
static assert(foo(2)==3);
Re: D at University of Minnesota
Sure, there's stuff that TDPL doesn't describe, but TDPL never described everything (for instance, it doesn't go into a detailed explanation of the various types of is expressions). But that's different from it being incorrect due to language changes, which seems to be what Carl is saying is happening. What happened is that I unclear what the state of play is; I am not asserting the wrongness of TDPL. Still, I am reassured by your responses.
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On Wednesday, June 12, 2013 13:46:20 Walter Bright wrote: On 6/12/2013 1:29 PM, Adam D. Ruppe wrote: Looking at dmd's source, looks like Walter actually wrote code to parse a throws Exception, etc. to be part of the function signature but stripped it out (surely because that's annoying). That detritus should be removed. It was a bad idea, which is why I disabled it. Well, I assume that it was the beginnings of a checked exceptions implementations, and checked exceptions do have their advantages, but the general verdict of the programming world as a whole does seem to be that they were ultimately a bad idea. Sometimes, it _does_ suck to not know exactly which exceptions a function can throw, but on the whole, I think that we hit a good balance with nothrow. What I find most interesting about checked exceptions is the fact that almost everyone thinks that they're a fantastic idea when they first encounter them and yet they're actually a bad idea. It's actually a good example of how a feature sometimes needs to be thoroughly field-tested before it becomes clear how good or bad it is. - Jonathan M Davis
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
Jonathan M Davis: What I find most interesting about checked exceptions is the fact that almost everyone thinks that they're a fantastic idea when they first encounter them and yet they're actually a bad idea. It's actually a good example of how a feature sometimes needs to be thoroughly field-tested before it becomes clear how good or bad it is. Maybe checked exceptions are bad only for the type system of Java. Maybe for a language that has global type inferencing on the exceptions such feature becomes better. Bye, bearophile
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
Walter Bright: Maybe checked exceptions are bad only for the type system of Java. Maybe for a language that has global type inferencing on the exceptions such feature becomes better. C++98 had checked exceptions (exception specifications), too. C++98 doesn't have a global type inferencer for exceptions. Bye, bearophile
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On 6/12/13, Adam D. Ruppe destructiona...@gmail.com wrote:
On Wednesday, 12 June 2013 at 20:23:43 UTC, Andrej Mitrovic wrote:
Are you sure? A compiler can tell whether a function /can/ throw
(hence why nothrow works), so I assume it has information on
where an exception is thrown.
Consider this:
extern(D) void foo();
void bar() { foo(); }
That's legal D code, and foo could throw anything, and bar would
have no idea what it is.
I thought doing this only for function definitions could make sense.
For declarations the user would have to do it manually.
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On 6/12/13 6:26 PM, Walter Bright wrote: On 6/12/2013 2:21 PM, bearophile wrote: Jonathan M Davis: What I find most interesting about checked exceptions is the fact that almost everyone thinks that they're a fantastic idea when they first encounter them and yet they're actually a bad idea. It's actually a good example of how a feature sometimes needs to be thoroughly field-tested before it becomes clear how good or bad it is. Maybe checked exceptions are bad only for the type system of Java. Maybe for a language that has global type inferencing on the exceptions such feature becomes better. It's not just Java specific. Bruce Eckel wrote a wonderful piece on why exception specifications *cause* bad code to be written. http://www.mindview.net/Etc/Discussions/CheckedExceptions Do you think the same will happen if the compiler tracks possible null references and whenever you might have a null pointer exception you are forced to handle it? (provided that the compiler is smart enough to know when a variable can't be null for sure, for transforming the code to SSA)
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On 6/12/13 6:21 PM, bearophile wrote: Jonathan M Davis: What I find most interesting about checked exceptions is the fact that almost everyone thinks that they're a fantastic idea when they first encounter them and yet they're actually a bad idea. It's actually a good example of how a feature sometimes needs to be thoroughly field-tested before it becomes clear how good or bad it is. Maybe checked exceptions are bad only for the type system of Java. Maybe for a language that has global type inferencing on the exceptions such feature becomes better. Why?
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On 06/12/2013 11:23 PM, Walter Bright wrote: On 6/12/2013 2:21 PM, bearophile wrote: Jonathan M Davis: What I find most interesting about checked exceptions is the fact that almost everyone thinks that they're a fantastic idea when they first encounter them and yet they're actually a bad idea. It's actually a good example of how a feature sometimes needs to be thoroughly field-tested before it becomes clear how good or bad it is. Maybe checked exceptions are bad only for the type system of Java. Maybe for a language that has global type inferencing on the exceptions such feature becomes better. C++98 had checked exceptions (exception specifications), too. Another failure of the idea, it failed so badly hardly anyone but language lawyers ever knew it had it. Weren't those checked at runtime?
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On Wednesday, 12 June 2013 at 21:34:31 UTC, Andrej Mitrovic wrote: I thought doing this only for function definitions could make sense. For declarations the user would have to do it manually. Yeah, it'd still be somewhat imprecise though because bar() would also 'throw' whatever foo() can throw too. (And if foo() is private there may be no documentation to check, either.) But it could still probably do a pretty good job, might be worth looking into.
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
Ary Borenszweig: Maybe checked exceptions are bad only for the type system of Java. Maybe for a language that has global type inferencing on the exceptions such feature becomes better. Why? I am not an expert of type systems, so this is this just an hypothesis. What are the disadvantages of checked exceptions? One problem is that those annotations are heavy, make the code rigid to change, and this doesn't go well with normal programmer laziness. A global type inferencer (that doesn't work well with the dynamic nature of Java) avoids the need for all exception annotations, but forces you to catch exceptions somewhere, assuring no holes remain if you don't want holes. Bye, bearophile
Re: D at University of Minnesota
On 6/12/13 5:07 PM, Carl Sturtivant wrote: Sure, there's stuff that TDPL doesn't describe, but TDPL never described everything (for instance, it doesn't go into a detailed explanation of the various types of is expressions). But that's different from it being incorrect due to language changes, which seems to be what Carl is saying is happening. What happened is that I unclear what the state of play is; I am not asserting the wrongness of TDPL. Still, I am reassured by your responses. Hi Carl -- TDPL is for the most part in good shape. There are a few inaccuracies, but I'd say most concern corner cases that are unlike to deter the learning process. You may want to encourage students to interact with us here, or write me email directly if they have any questions. I'd be very glad to help them. Andrei
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On 6/12/13 6:49 PM, bearophile wrote: Ary Borenszweig: Maybe checked exceptions are bad only for the type system of Java. Maybe for a language that has global type inferencing on the exceptions such feature becomes better. Why? I am not an expert of type systems, so this is this just an hypothesis. What are the disadvantages of checked exceptions? One problem is that those annotations are heavy, make the code rigid to change, and this doesn't go well with normal programmer laziness. A global type inferencer (that doesn't work well with the dynamic nature of Java) avoids the need for all exception annotations, but forces you to catch exceptions somewhere, assuring no holes remain if you don't want holes. Bye, bearophile But if a type checker deduces a function foo throws exception A, and in function bar you call foo: are you forced to handle the exception? If not, do you have to tell the compiler that you don't want to handle that exception? Isn't that the same as what Java does?
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
Ary Borenszweig: But if a type checker deduces a function foo throws exception A, and in function bar you call foo: are you forced to handle the exception? If not, do you have to tell the compiler that you don't want to handle that exception? Isn't that the same as what Java does? Let's keep playing :-) - I think if you don't want to handle the exception, you don't handle the exception, and the type system assumes you will handle the exception at a higher level. - In every point of the program you can also ask to the type system (like through the IDE) what are the current exceptions that can happen there. - If you don't handle exceptions in the main, your program will throw them. If you annotate a function with nothrow then the type system forces you to handle all the possible exceptions of that function inside the function. Bye, bearophile
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On Wednesday, June 12, 2013 23:33:31 Timon Gehr wrote: C++98 had checked exceptions (exception specifications), too. Another failure of the idea, it failed so badly hardly anyone but language lawyers ever knew it had it. Weren't those checked at runtime? Yes. If another exception type was thrown, it called something like unexpected_exception (I don't remember the exact function) which called abort by default and killed your program. So, while Java's checked are ultimately a bad idea, they at least have _some_ redeeming value, whereas C++ throw specifiers really don't. - Jonathan M Davis
xUnit Testing Framework for D
Here is the 'dunit' mentioned in the talk by Stefan Rohe: https://github.com/linkrope/dunit D-stroy ;-)
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On 6/12/2013 2:49 PM, bearophile wrote: What are the disadvantages of checked exceptions? See the link to Bruce Eckel's article I posted in this thread.
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
Walter Bright: See the link to Bruce Eckel's article I posted in this thread. Mine was a rhetorical question :-) Bye, bearophile
Re: xUnit Testing Framework for D
On 06/12/2013 07:15 PM, Mario Kroeplin wrote: Here is the 'dunit' mentioned in the talk by Stefan Rohe: https://github.com/linkrope/dunit D-stroy ;-) I'm glad that dunit was of use to you and that the fork went well. I'm sorry I couldn't follow up on it. --jm
Re: xUnit Testing Framework for D
Mario Kroeplin:
Here is the 'dunit' mentioned in the talk by Stefan Rohe:
https://github.com/linkrope/dunit
D-stroy ;-)
In that code have you felt the lack for some built-in feature for
D (Like some introspection, some hooks, some dynamic feature,
etc)?
Maybe you can replace code like this:
final switch (color)
{
case Color.red:
With code like:
final switch (color) with (Color)
{
case red:
Bye,
bearophile
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On Wednesday, 12 June 2013 at 12:50:39 UTC, Andrei Alexandrescu wrote: Reddit: http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/ Hackernews: https://news.ycombinator.com/item?id=5867764 Twitter: https://twitter.com/D_Programming/status/344798127775182849 Facebook: https://www.facebook.com/dlang.org/posts/655927124420972 Youtube: http://youtube.com/watch?v=ph_uU7_QGY0 Please drive discussions on the social channels, they help D a lot. Andrei He mentions a D plug-in for sonar. Is this available publicly?
