Re: Follow-up post explaining research rationale
On Monday, 9 May 2016 at 19:09:35 UTC, Joe Duarte wrote: One D-specific question I do have: Have any women ever posted here? I scoured a bunch of threads here recently and couldn't find a female poster. By this I mean a poster whose supplied name was female, where a proper name was supplied (some people just have usernames). Of course we don't really know who is posting, and there could be some George Eliot situations, but the presence/absence of self-identified women is useful enough. Women are underrepresented in programming, but the skew in online programming communities is even more extreme – we're seeing near-zero percent in lots of boards. This is not a D-specific problem. Does anyone know of occasions where women posted here? Links? One of the presenters at the recent DConfs is female: http://dconf.org/2013/talks/chevalier_boisvert.html She has posted in the forum occasionally. There seem to be others, though obviously a minority. Of course, given the prevalence of pseudonyms, it is impossible to tell much of the time, as you mentioned. Getting back to the research, recent studies have argued that one reason women are underrepresented in certain STEM fields is that smart women have more options than smart men. So think of the right tail of the bell curve, the men and women in that region on the relevant aptitudes for STEM fields. There's some evidence that smart women have a broader set of skills -- *on average* -- than equivalently smart men, perhaps including better social skills (or more interest in social interaction). This probably fits with stereotypes and intuitions a lot of people already held (lots of stereotypes are accurate, as probability distributions and so forth). Or women are underrepresented at the high end of the distribution for "reasoning" skills, from which STEM mostly hires, because their variance is lower, ie the Summers hypothesis that led to his resignation. This seems to be backed up by the fact that high SAT math scores are dominated by young men, just as the same is true for high SAT reading scores and young women. Of course, math is not "reasoning" and many programmers are bad at math, but they're at least adjacent skills. I also think a lot of the diversity efforts that are salient in tech right now are acting far too late in the cycle, sort of just waiting for women and minorities to show up. The skew starts long before people graduate with a CS degree, and I think Google, Microsoft, Apple, Facebook, et al. should think deeply about how programming language design might be contributing to these effects (especially before they roll out any more C-like programming languages). Most programmers don't have a CS degree. Programming language design may play a small role in the gender/race "monoculture," but other issues likely have much greater effect. Informally, I think what's happening in many cases is that when smart women are exposed to programming, it looks ridiculous and they think something like "Screw this – I'm going to med school", or any of a thousand permutations of that sentiment. Except that women only account for one-third of doctors and lawyers in the US, so even if they're going there instead, there's not enough of them to swing the numbers significantly in those fields either. Mainstream PL syntax is extremely unintuitive and poorly designed by known pedagogical, epistemological, and communicative science standards. The vast majority people who are introduced to programming do not pursue it (likely true of many fields, but programming may see a smaller grab than most – this point requires a lot more context). I'm open to the possibility that the need to master the bizarre syntax of incumbent programming languages might serve as a useful filter for qualities valuable in a programmer, but I'm not sure how good or precise the filter is. Syntax is a lesser concern when programming. PL syntax can be forboding to a newcomer, particularly something like Haskell, but getting your code to compile and run properly is the real difficulty. If you make the low bar of syntax even lower, that does nothing to change the even higher bar behind it, ie changing the syntax is unlikely to affect the bigger filter of dealing with the structured process of coding. 1. There's no clear distinction between types and names. It's just plain text run-on phrases like "char string". string is an unfortunate name here, and reminds us that this would be a type in many modern languages, but my point here is that there's nothing to visually distinguish types from names. I would make types parenthetical or use a hashtag, so: MyString (char) or MyString #char (and definitely with types at the end of the declaration, with names and values up front and uninterrupted by type names – I'll be testing my hunches here). Most programmers use some form of syntax highlighting in their editor, where char
Re: dmd not building with dmd
On 2016-05-08 12:33, Steven Schveighoffer wrote: Ok thanks. Will wait for next release. For some reason this doesn't affect command line compiles Since you're using DVM, :), you can easily roll back to 2.070.0 as a workaround. If I recall correctly, DMD is buildable with DMD 2.067.0 and later. -- /Jacob Carlborg
Re: dmd not building with dmd
On 2016-05-10 06:49, Lionello Lunesu wrote: Well, it's either wrong phobos or wrong dmd. I assumed phobos was mismatched, but perhaps DMD was mismatched? Installing with brew suggest it's installing 2.071.0, but DMD appears to be 2.070: The issue Steven is having is that the symbol doesn't exist in the default C++ runtime. This has been fixed in master. He installed DMD using DVM so it's not a Brew packaging problem. Rolling back to 2.70.0 can be used as a workaround. -- /Jacob Carlborg
Re: dmd not building with dmd
On 9/5/2016 20:19, John Colvin wrote: On Monday, 9 May 2016 at 07:57:33 UTC, Lionello Lunesu wrote: On 8/5/2016 14:43, Steven Schveighoffer wrote: [...] I ran into this as well. It's a bug in the package from brew: it shipped with the wrong phobos. You can build your own DMD: $ make -f posix.mak AUTO_BOOTSTRAP=1 In what way do you mean "shipped with the wrong phobos"? Well, it's either wrong phobos or wrong dmd. I assumed phobos was mismatched, but perhaps DMD was mismatched? Installing with brew suggest it's installing 2.071.0, but DMD appears to be 2.070: $ brew install dmd ==> Downloading https://homebrew.bintray.com/bottles/dmd-2.071.0.el_capitan.bottle.tar.gz Already downloaded: /Library/Caches/Homebrew/dmd-2.071.0.el_capitan.bottle.tar.gz ==> Pouring dmd-2.071.0.el_capitan.bottle.tar.gz 🍺 /usr/local/Cellar/dmd/2.071.0: 561 files, 65.0M $ /usr/local/bin/dmd --version DMD64 D Compiler v2.070 Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
Re: How are you enjoying DConf? And where to go next?
Dne 9.5.2016 v 19:45 jmh530 via Digitalmars-d napsal(a): On Monday, 9 May 2016 at 15:12:25 UTC, krzaq wrote: It's not just the distance, but also the overall personal cost of attending the conference. Berlin is, all things considered, a fairly cheap city. London is a big NO in this regard, can't speak about the other suggestions. I don't know what Berlin's like, but I just visited London for a long weekend and it wasn't so bad compared to where I live (NYC). I used AirBnB and my room was like $90 a night. But for people like me $90 per night is too much. I live in Czech Republic which is a really beautifull country in middle of europe (it is called heart of europe). And even in Prague which is capital city of Czech Republic I am able to get room per $10. And it is not only accomodation but other things are really cheap here. For example beer price is only about $1 (btw czech beer is the best beer on the word). Public transport in Prague for 3 days cost just only $15 and so on. Even dconf in Berlin (just 400km from me) is expensive for me (one month salary including transport and accommodation).
Re: Follow-up post explaining research rationale
On Monday, 9 May 2016 at 20:17:40 UTC, ag0aep6g wrote: Am 09.05.2016 um 21:09 schrieb Joe Duarte: 4. We switch the person or voice from an imperative "do this" as in printf, to some sort of narrator third-person voice with "gets". "gets" is still imperative. It's short for "get string". Not saying that this is obvious, or that it's a good name. Ah, I forgot about that! I think puts has the same abbreviation structure right? put string... I think knowing/remembering that it's an abbreviation would make it less distracting. My calling it a shift in voice is incorrect assuming people remember what it stands for. JD
Re: Always false float comparisons
On Monday, 9 May 2016 at 20:14:36 UTC, Walter Bright wrote: On 5/9/2016 11:37 AM, Xinok wrote: All of these scenarios are capable of producing "incorrect" results, are a source of discrete bugs (often corner cases that we failed to consider and test), and can be hard to detect. It's about time we stopped being stubborn and flagged these things as warnings. Even if they require a special compiler flag and are disabled by default, that's better than nothing. I've used a B+D language that does as you suggest (Wirth Pascal). It was highly unpleasant to use, as the code became littered with casts. Casts introduce their own set of bugs. Maybe it's a bad idea to enable these warnings by default but what's wrong with providing a compiler flag to perform these checks anyways? For example, GCC has a compiler flag to yield warnings for signed+unsigned comparisons but it's not even enabled with the -Wall flag, only by specifying -Wextra or -Wsign-compare.
Re: Follow-up post explaining research rationale
On Monday, 9 May 2016 at 19:09:35 UTC, Joe Duarte wrote: ... You're not addressing the root cause. America was founded on genocide, racism, sexism, and classism. That should be the starting point of such research, but nobody goes there because people, specially those who benefit from the current system, are not serious about changing anything. The idea that syntax has anything to do with women and minorities being underrepresented in the industry, or that it's some kind of deterrent, is the stupidest thing any one could come up with. It's like saying that the reason why more blacks do not have university degrees is because notebooks contain white sheets of paper instead of gray sheets of paper, or that #2 pencils lack blings. Idiot! Instead of saying shit like "PL syntax ... disproportionately deters qualified women", did you consider the possibility that maybe, just maybe, the current PL syntax disproportionately encourages white men to behave in sexist and racist manners? You see how retarded that sounds? So, you are completely ignoring the cultural, historical, and societal forces that have created the problems in the first place. Basically, not only is your hypotheses sexist in its own right, but you've completely shifted the blame of this injustice onto something completely artificial that has nothing to do with the problem.
Re: How are you enjoying DConf? And where to go next?
On Monday, 9 May 2016 at 17:45:24 UTC, jmh530 wrote: On Monday, 9 May 2016 at 15:12:25 UTC, krzaq wrote: It's not just the distance, but also the overall personal cost of attending the conference. Berlin is, all things considered, a fairly cheap city. London is a big NO in this regard, can't speak about the other suggestions. I don't know what Berlin's like, but I just visited London for a long weekend and it wasn't so bad compared to where I live (NYC). I used AirBnB and my room was like $90 a night. I came to London from the conference and have found it fairly reasonable. Back to Seoul and Real Life tomorrow, unfortunately. I'd happily fly back here for the next conf if need be. I'd really love to see it in Japan, though.
Re: Always false float comparisons
On Monday, 9 May 2016 at 09:10:19 UTC, Walter Bright wrote: Don Clugston pointed out in his DConf 2016 talk that: float f = 1.30; assert(f == 1.30); will always be false since 1.30 is not representable as a float. However, float f = 1.30; assert(f == cast(float)1.30); will be true. So, should the compiler emit a warning for the former case? I think it really depends on what the warning actually says. I think people have different expectations for what that warning would be. When you say 1.30 is not representable as a float, when is the "not representable" enforced? Because it looks like the programmer just represented it in the assignment of the literal – but that's not where the warning would be right? I mean I assume so because people need nonrational literals all the time, and this is the only way they can do it, which means it's a hole in the type system right? There should be a decimal type to cover all these cases, like some databases have. Would the warning say that you can't compare 1.30 to a float because 1.30 is not representable as a float? Or would it say that f was rounded upon assignment and is no longer 1.30? Short of a decimal type, I think it would be nice to have a "float equality" operator that covered this whole class of cases, where floats that started their lives as nonrational literals and floats that have been rounded with loss of precision can be treated as equal if they're within something like .001% of each other (well a percentage that can actually be represented as a float...) Basically equality that covers the known mutational properties of fp arithmetic. There's no way to do this right now without ranges right? I know that ~ is for concat. I saw ~= is an operator. What does that do? The Unicode ≈ would be nice for this. I assume IEEE 754 or ISO 10967 don't cover this? I was just reading the latter (zip here: http://standards.iso.org/ittf/PubliclyAvailableStandards/c051317_ISO_IEC_10967-1_2012.zip)
Re: powExpressions work at ctfe
On Monday, May 09, 2016 13:02:50 Stefan Koch via Digitalmars-d wrote: > that would also > prevent issues with cross-compiled binarys that have ctfe in them. That's going to be pretty critical in the long run, especially now that the compiler frontend is in D. - Jonathan M Davis
Re: Always false float comparisons
On Monday, 9 May 2016 at 20:16:59 UTC, Walter Bright wrote: (4) is already planned; it's just taking *a lot* longer than anticipated to actually implement it: https://issues.dlang.org/show_bug.cgi?id=259 https://github.com/dlang/dmd/pull/1913 https://github.com/dlang/dmd/pull/5229 I oppose this change. You'd be better off not having unsigned types at all than this mess, which was Java's choice. But then there are more problems created. One other thing - according to the bug report discussion, the proposed solution was pre-approved both by Andrei Alexandrescu and by *YOU*. Proposing a solution, letting various people work on implementing it for three years, and then suddenly announcing that you "oppose this change" and calling the solution a "mess" with no explanation is a fantastic way to destroy all motivation for outside contributors.
Re: Always false float comparisons
On Monday, 9 May 2016 at 20:20:00 UTC, Walter Bright wrote: On 5/9/2016 12:39 PM, tsbockman wrote: Educating programmers who've never studied how to write correct FP code is too complex of a task to implement via compiler warnings. The warnings should be limited to cases that are either obviously wrong, or where the warning is likely to be a net positive even for FP experts. I've seen a lot of proposals which try to hide the reality of how FP works. The cure is worse than the disease. The same goes for hiding signed/unsigned, and the autodecode mistake of pretending that code units aren't there. I completely agree that complexity that cannot be properly hidden should not be hidden. The underlying mechanisms of floating point is complexity that we shouldn't paper over. However, the peculiarities of language conventions w.r.t. floating point expressions doesn't quite fit that category.
Re: Always false float comparisons
On Monday, 9 May 2016 at 20:16:59 UTC, Walter Bright wrote: On 5/9/2016 11:51 AM, tsbockman wrote: (4) is already planned; it's just taking *a lot* longer than anticipated to actually implement it: https://issues.dlang.org/show_bug.cgi?id=259 https://github.com/dlang/dmd/pull/1913 https://github.com/dlang/dmd/pull/5229 I oppose this change. You'd be better off not having unsigned types at all than this mess, which was Java's choice. But then there are more problems created. What mess? The actual fix for issue 259 is simple, elegant, and shouldn't require much code in the wild to be changed. The difficulties and delays have all been associated with the necessary improvements to VRP and constant folding, which are worthwhile in their own right, since they help the compiler generate faster code.
Re: Always false float comparisons
On 5/9/16 4:22 PM, Walter Bright wrote: On 5/9/2016 6:46 AM, Steven Schveighoffer wrote: I know this is a bit band-aid-ish, but if one is comparing literals to a float, why not treat the literal as the type being compared against? In other words, imply the 1.3f. This isn't integer-land where promotions do not change the outcome. Because it's yet another special case, and we know where those lead. For example, what if the 1.30 was the result of CTFE? This is true, it's a contrived example. -Steve
Re: Always false float comparisons
Am Mon, 09 May 2016 15:56:21 + schrieb Nordlöw : > On Monday, 9 May 2016 at 12:28:04 UTC, Walter Bright wrote: > > On 5/9/2016 4:38 AM, Nordlöw wrote: > >> Would that include comparison of variables only aswell? > > No. > > Why? Because the float would be converted to double without loss of precision just like uint == ulong is a valid comparison which can yield 'true' in 2^32 cases. float == 1.30 on the other hand is false in any case. You'd have to warn on _every_ comparison with a widening conversion to be consistent! -- Marco
Re: Follow-up post explaining research rationale
On Monday, 9 May 2016 at 20:29:12 UTC, Joe Duarte wrote: On Monday, 9 May 2016 at 20:09:35 UTC, Adam D. Ruppe wrote: I'd also be surprised if you find an empirical gender gap after controlling for programming language syntax, too. Even if we grant that PL syntax is suboptimal, why would that result in a gender bias? But, hey, you never really know until you actually collect the data... I forgot to mention the math. You can run the model in your head. If group W has more career options than group M, W will be underrepresented in career domain A. The effect will be larger if A is less appealing than W's other options, ceteris paribus and with some starting assumptions. (But it doesn't need to be, if W has more options than M.) If aspects of career domain A are *equally frustrating* for members of groups W and M, W will still be underrepresented (and M overrepresented) if people in W have more options. So we don't even need it to be the case that bizarre programming language design disproportionately annoys women for bizarre programming language design to result in the underrepresentation of women. JD (Assuming A is included in the set of options for both groups, and is equally available to them.)
Re: Always false float comparisons
Am Mon, 9 May 2016 02:10:19 -0700
schrieb Walter Bright :
> Don Clugston pointed out in his DConf 2016 talk that:
>
> float f = 1.30;
> assert(f == 1.30);
>
> will always be false since 1.30 is not representable as a float. However,
>
> float f = 1.30;
> assert(f == cast(float)1.30);
>
> will be true.
>
> So, should the compiler emit a warning for the former case?
I'd say yes, but exclude the case where it can be statically
verified, that the comparison can yield true, because the
constant can be losslessly converted to the type of 'f'.
By example, don't warn for these:
f == 1.0, f == -0.5, f == 3.625, f == 2UL^^60
But do warn for:
f == 1.30, f == 2UL^^60+1
As an extension of the existing "comparison is always
false/true" check it could read "Comparison is always false:
literal 1.30 is not representable as 'float'".
There is a whole bunch in this warning category:
byte b;
if (b == 1000) {}
"Comparison is always false: literal 1000 is not representable
as 'byte'"
--
Marco
Re: Follow-up post explaining research rationale
On Monday, 9 May 2016 at 20:09:35 UTC, Adam D. Ruppe wrote: I'd also be surprised if you find an empirical gender gap after controlling for programming language syntax, too. Even if we grant that PL syntax is suboptimal, why would that result in a gender bias? But, hey, you never really know until you actually collect the data... I forgot to mention the math. You can run the model in your head. If group W has more career options than group M, W will be underrepresented in career domain A. The effect will be larger if A is less appealing than W's other options, ceteris paribus and with some starting assumptions. (But it doesn't need to be, if W has more options than M.) If aspects of career domain A are *equally frustrating* for members of groups W and M, W will still be underrepresented (and M overrepresented) if people in W have more options. So we don't even need it to be the case that bizarre programming language design disproportionately annoys women for bizarre programming language design to result in the underrepresentation of women. JD
Re: Always false float comparisons
On 5/9/2016 6:46 AM, Steven Schveighoffer wrote: I know this is a bit band-aid-ish, but if one is comparing literals to a float, why not treat the literal as the type being compared against? In other words, imply the 1.3f. This isn't integer-land where promotions do not change the outcome. Because it's yet another special case, and we know where those lead. For example, what if the 1.30 was the result of CTFE?
Re: Always false float comparisons
On 5/9/2016 12:39 PM, tsbockman wrote: Educating programmers who've never studied how to write correct FP code is too complex of a task to implement via compiler warnings. The warnings should be limited to cases that are either obviously wrong, or where the warning is likely to be a net positive even for FP experts. I've seen a lot of proposals which try to hide the reality of how FP works. The cure is worse than the disease. The same goes for hiding signed/unsigned, and the autodecode mistake of pretending that code units aren't there.
Re: Follow-up post explaining research rationale
Am 09.05.2016 um 21:09 schrieb Joe Duarte: 4. We switch the person or voice from an imperative "do this" as in printf, to some sort of narrator third-person voice with "gets". "gets" is still imperative. It's short for "get string". Not saying that this is obvious, or that it's a good name.
Re: Always false float comparisons
On 5/9/2016 11:51 AM, tsbockman wrote: On Monday, 9 May 2016 at 18:37:10 UTC, Xinok wrote: (4) While we're at it, let's also emit a warning when comparing signed and unsigned types. (4) is already planned; it's just taking *a lot* longer than anticipated to actually implement it: https://issues.dlang.org/show_bug.cgi?id=259 https://github.com/dlang/dmd/pull/1913 https://github.com/dlang/dmd/pull/5229 I oppose this change. You'd be better off not having unsigned types at all than this mess, which was Java's choice. But then there are more problems created.
Re: Always false float comparisons
On 5/9/2016 11:37 AM, Xinok wrote: All of these scenarios are capable of producing "incorrect" results, are a source of discrete bugs (often corner cases that we failed to consider and test), and can be hard to detect. It's about time we stopped being stubborn and flagged these things as warnings. Even if they require a special compiler flag and are disabled by default, that's better than nothing. I've used a B+D language that does as you suggest (Wirth Pascal). It was highly unpleasant to use, as the code became littered with casts. Casts introduce their own set of bugs.
Re: File size of exe: DMD vs LDC
On 5/9/2016 11:48 AM, David Nadlinger wrote: AFAIR, because of how ModuleInfo/TypeInfo is emitted which makes linker never collect sections because they are referenced at least from there. LDC was intentionally modified to change code gen in that regard to make --gc-sections work - David will surely tell more :) It's something along those lines. What is certainly true is that I spent quite some time trying to work around "interesting" linker behaviour to make this work. You can find more details on my solution at https://issues.dlang.org/show_bug.cgi?id=879. I haven't looked at DMD's related codegen in a while, so I don't know what exactly remains to be done there. — David Thanks. At least the deh sections are a non-issue now that DMD generates Dwarf exception handling tables.
Re: Follow-up post explaining research rationale
On Monday, 9 May 2016 at 19:09:35 UTC, Joe Duarte wrote: One D-specific question I do have: Have any women ever posted here? Yes, I can think of three off the top of my head, and there's probably more that I just don't remember. Of course, I can name twenty male regular posters here without even thinking about it, so a skew is evident. I don't want to name any names though. The vast majority people who are introduced to programming do not pursue it (likely true of many fields, but programming may see a smaller grab than most – this point requires a lot more context). I'd be surprised if that point survives scrutiny, though I guess you need to define "introduced" and "pursue" to say more. I'd also be surprised if you find an empirical gender gap after controlling for programming language syntax, too. Even if we grant that PL syntax is suboptimal, why would that result in a gender bias? But, hey, you never really know until you actually collect the data...
Re: How are you enjoying DConf? And where to go next?
On 9 May 2016 at 17:32, wobbles via Digitalmars-d wrote: > On Monday, 9 May 2016 at 15:12:25 UTC, krzaq wrote: >> >> On Monday, 9 May 2016 at 09:58:32 UTC, Mark Isaacson wrote: >>> >>> Full recognition that there was way less demand for another US DConf... >>> so perhaps somewhere easier to fly to? >>> >>> Reykjavik? >>> Dublin? >>> Oslo? >>> Stockholm? >>> Barcelona? >>> London? >>> >>> Those are pretty good hubs and have solid airfare from the US... and all >>> over. London and Barcelona in particular have a truly impressive number of >>> flights in and out. They're all also really wonderful places to go >>> exploring. Not a huge fan of Berlin as a city... that said the venue was >>> pretty nice (a larger screen would've been better) and the food was >>> definitely a step up from Utah. >> >> >> It's not just the distance, but also the overall personal cost of >> attending the conference. Berlin is, all things considered, a fairly cheap >> city. London is a big NO in this regard, can't speak about the other >> suggestions. > > > I also think it should not only be in a decently cheap location, but also in > a location where there is, by default, a high concentration of D users. > > Berlin fits that. > Facebook fits that. > Where's the other high concentration of D users? Europe is fairly accessible for many people, if this year is anything to go by. I wouldn't mind going to another capital. Paris? Bucharest? If it must be the US, then I'd pick Boston. :-)
Re: Always false float comparisons
On Monday, 9 May 2016 at 19:15:20 UTC, Xinok wrote:
It's a complex issue because there isn't necessarily right or
wrong behavior, only things that *might* be wrong. But if we
want to truly detect all possible cases of incorrect behavior,
then we have to be exhaustive in our checks.
We absolutely, emphatically, DO NOT want to "detect all possible
cases of incorrect behavior". Given the limited information
available to the compiler and the intractability of the Halting
Problem, the correct algorithm for doing so is this:
foreach(line; sourceCode)
warning("This line could not be proven correct.");
Only warnings with a reasonably high signal-to-noise ratio should
be implemented.
Not necessarily. Reusing 1.3 from the original case, the
following assertion passes:
float f = 1.3;
assert(f < 1.3);
And considering we also have <= and >=, we may as well check
all of the comparison operators.
Because of the inevitability of rounding errors, FP code
generally cannot be allowed to depend upon precise equality
comparisons to any value other than zero (even implicit ones as
in your example).
Warning about this makes sense:
float f = 1.3;
assert(f == 1.3);
Because the `==` makes it clear that the programmer's intent was
to test for equality, and that will fail unexpectedly.
On the other hand, with `<`, `>`, `<=`, and `>=`, the compiler
should generally assume that they are being used correctly, in a
way that is tolerant of small rounding errors. Doing otherwise
would cause tons of false positives in competently written FP
code.
Educating programmers who've never studied how to write correct
FP code is too complex of a task to implement via compiler
warnings. The warnings should be limited to cases that are either
obviously wrong, or where the warning is likely to be a net
positive even for FP experts.
Re: Always false float comparisons
On Monday, 9 May 2016 at 18:51:58 UTC, tsbockman wrote: On Monday, 9 May 2016 at 18:37:10 UTC, Xinok wrote: ... (3) Generalize it to all comparisons as well, including < and ... (3) Makes no sense though; inequalities with mixed floating-point types are perfectly safe. (Well, as safe as any floating-point code can be, anyway.) ... Not necessarily. Reusing 1.3 from the original case, the following assertion passes: float f = 1.3; assert(f < 1.3); And considering we also have <= and >=, we may as well check all of the comparison operators. It's a complex issue because there isn't necessarily right or wrong behavior, only things that *might* be wrong. But if we want to truly detect all possible cases of incorrect behavior, then we have to be exhaustive in our checks.
Follow-up post explaining research rationale
Hi all, As I mentioned on the other thread where I asked about D syntax, I'm a social scientist about to launch some studies of the effects of PL syntax on learnability, motivation to pursue programming, and differential gender effects on these factors. This is a long post – some of you wanted to know more about my research goals and rationale, and I also said I would post separately on the gender issue, so here we go... As you know, women are starkly underrepresented in software engineering roles. I'm interested in zooming back to the decisions people are making when they're 16 or 19 re: programming as a career. I'm interested in people's *first encounters* with programming, in high school or college, how men and women might differentially assess programming as a career option, and why. Let me note a few things: Someone on the other thread thought that my hypothesis was that women don't become programmers because of the semicolons and curly braces in PL syntax. That's not one of my hypotheses. I do think PL syntax is a large problem, and I have some hypotheses about how it disproportionately deters qualified women, but the issues I see go much deeper than what I've called the "punctuation noise" of semicolons and curly braces. (I definitely don't have any hypotheses about female perceptions of the aesthetics of curly braces, which some posters had inferred – none of this is about female aesthetic preferences.) Also, I don't think D is particularly problematic – it has cleaner and clearer syntax than its contemporaries (well, we'll need careful research to know if it truly is clearer to a targeted population). I plan to use D as a presumptive *clearer syntax* condition in some studies – we'll see how it goes. Lastly, I'm not approaching the gender issue from an ideological or PC Principal perspective. My work will focus mostly on cognitive science and pedagogical factors – as you'll see below, I'm interested in diversity issues from lots of angles, but I don't subscribe to the diversity ideology that is fashionable in American academia. One D-specific question I do have: Have any women ever posted here? I scoured a bunch of threads here recently and couldn't find a female poster. By this I mean a poster whose supplied name was female, where a proper name was supplied (some people just have usernames). Of course we don't really know who is posting, and there could be some George Eliot situations, but the presence/absence of self-identified women is useful enough. Women are underrepresented in programming, but the skew in online programming communities is even more extreme – we're seeing near-zero percent in lots of boards. This is not a D-specific problem. Does anyone know of occasions where women posted here? Links? Getting back to the research, recent studies have argued that one reason women are underrepresented in certain STEM fields is that smart women have more options than smart men. So think of the right tail of the bell curve, the men and women in that region on the relevant aptitudes for STEM fields. There's some evidence that smart women have a broader set of skills -- *on average* -- than equivalently smart men, perhaps including better social skills (or more interest in social interaction). This probably fits with stereotypes and intuitions a lot of people already held (lots of stereotypes are accurate, as probability distributions and so forth). I'm interested in monocultures and diversity issues in a number of domains. I've done some recent work on the lack of philosophical and political diversity in social science, particularly in social psychology, and how this has undermined the quality and validity of our research (here's a recent paper by me and my colleagues in Behavioral and Brain Sciences: http://dx.doi.org/10.1017/S0140525X14000430). My interest in the lack of gender diversity in programming is an entirely different research area, but there isn't much rigorous social science and cognitive psychology research on this topic, which surprised me. I think it's an important and interesting issue. I also think a lot of the diversity efforts that are salient in tech right now are acting far too late in the cycle, sort of just waiting for women and minorities to show up. The skew starts long before people graduate with a CS degree, and I think Google, Microsoft, Apple, Facebook, et al. should think deeply about how programming language design might be contributing to these effects (especially before they roll out any more C-like programming languages). Informally, I think what's happening in many cases is that when smart women are exposed to programming, it looks ridiculous and they think something like "Screw this – I'm going to med school", or any of a thousand permutations of that sentiment. Mainstream PL syntax is extremely unintuitive and poorly designed by known pedagogical, epistemological, and
Re: Always false float comparisons
On Monday, 9 May 2016 at 18:37:10 UTC, Xinok wrote: (1) Yes, emit a warning for this case. (2) Generalize it to all variables, like Nordlöw suggested. (3) Generalize it to all comparisons as well, including < and > . (4) While we're at it, let's also emit a warning when comparing signed and unsigned types. (5) Dare I say it... warn against implicit conversions of double to float. (6) The same applies to "real" as well. All of these scenarios are capable of producing "incorrect" results, are a source of discrete bugs (often corner cases that we failed to consider and test), and can be hard to detect. It's about time we stopped being stubborn and flagged these things as warnings. Even if they require a special compiler flag and are disabled by default, that's better than nothing. (1) is good, because the code in question is always wrong. (2) is a logical extension, in those cases where constant folding and VRP can prove that the code is always wrong. (3) Makes no sense though; inequalities with mixed floating-point types are perfectly safe. (Well, as safe as any floating-point code can be, anyway.) (4) is already planned; it's just taking *a lot* longer than anticipated to actually implement it: https://issues.dlang.org/show_bug.cgi?id=259 https://github.com/dlang/dmd/pull/1913 https://github.com/dlang/dmd/pull/5229
Re: File size of exe: DMD vs LDC
On Monday, 9 May 2016 at 13:53:45 UTC, Dicebot wrote: On Monday, 9 May 2016 at 13:48:50 UTC, Walter Bright wrote: On 5/9/2016 5:24 AM, Jacob Carlborg wrote: LDC can strip sections which DMD cannot. Why not? AFAIR, because of how ModuleInfo/TypeInfo is emitted which makes linker never collect sections because they are referenced at least from there. LDC was intentionally modified to change code gen in that regard to make --gc-sections work - David will surely tell more :) It's something along those lines. What is certainly true is that I spent quite some time trying to work around "interesting" linker behaviour to make this work. You can find more details on my solution at https://issues.dlang.org/show_bug.cgi?id=879. I haven't looked at DMD's related codegen in a while, so I don't know what exactly remains to be done there. — David
Re: Always false float comparisons
On Monday, May 09, 2016 02:10:19 Walter Bright via Digitalmars-d wrote: > Don Clugston pointed out in his DConf 2016 talk that: > > float f = 1.30; > assert(f == 1.30); > > will always be false since 1.30 is not representable as a float. However, > > float f = 1.30; > assert(f == cast(float)1.30); > > will be true. > > So, should the compiler emit a warning for the former case? It does seem like having implicit conversions with floating point numbers is problematic in general, though warning about it or making it illegal could very well be too annoying to be worth it. But at bare minimum, warning about literals not matching the type that they're being compared against when there _is_ a literal that would be of the same type is probably worth warning about - and that could apply to more than just floating point values. But figuring out when implicit conversions are genuinely useful and should be allowed and when they're more trouble than they're worth is surprisingly hard to get right. :( - Jonathan M Davis
Re: Walter's Famous German Language Essentials Guide
On Friday, May 06, 2016 13:34:08 Andrei Alexandrescu via Digitalmars-d wrote: > On 5/6/16 1:04 PM, Chris wrote: > > Ok, guilty as charged > > No need to feel singled out, most of us do this once in a while. We're > exploring either the creation of an "internal" forum (more focused) or > an "offtopic" forum where such discussions can go. -- Andrei The main problem with the "offtopic" forum idea is that most of the time when we end up with an off-topic discussion, it's because a perfectly on-topic discussion devolves into an off-topic one. It may very well be a good idea to create an off-topic forum, but I doubt that it'll get a lot of traffic or that it will really fix the OT problems here aside from making it possible to tell folks to take it to the OT forum if they want to continue to discuss whatever OT thing they started discussing. It's actually one area where more traditional forum software might do better, because then threads (or portions of them) could be moved to different forums so that OT discussions could theoretically be moved out of on-topic threads. But that would also required increased moderation, which isn't something that we're really looking for either. As for a more focused forum, that probably depends at least somewhat on what it's focused on (though any forum will likely risk some topics devolving into OT discussions) - and we already created dlang-study for at least some of the more directed discussions, and that hasn't really gone much of anywhere. I think that part of the problem is that we seem to have had fewer useful discussions of late (for whatever reason), so the OT discussions have stood out more, and we've gotten at least a couple that have gotten pretty far out of hand with discussions on gender and whatnot. So, it seems like the recent situation is worse than it's been historically. Historically, I don't think that OT discussions have been that big of a problem, whereas recently, it's been pretty bad. - Jonathan M Davis
Re: Always false float comparisons
On Monday, 9 May 2016 at 09:10:19 UTC, Walter Bright wrote: Don Clugston pointed out in his DConf 2016 talk that: float f = 1.30; assert(f == 1.30); will always be false since 1.30 is not representable as a float. However, float f = 1.30; assert(f == cast(float)1.30); will be true. So, should the compiler emit a warning for the former case? (1) Yes, emit a warning for this case. (2) Generalize it to all variables, like Nordlöw suggested. (3) Generalize it to all comparisons as well, including < and > . (4) While we're at it, let's also emit a warning when comparing signed and unsigned types. (5) Dare I say it... warn against implicit conversions of double to float. (6) The same applies to "real" as well. All of these scenarios are capable of producing "incorrect" results, are a source of discrete bugs (often corner cases that we failed to consider and test), and can be hard to detect. It's about time we stopped being stubborn and flagged these things as warnings. Even if they require a special compiler flag and are disabled by default, that's better than nothing.
Re: How are you enjoying DConf? And where to go next?
On Monday, 9 May 2016 at 15:12:25 UTC, krzaq wrote: It's not just the distance, but also the overall personal cost of attending the conference. Berlin is, all things considered, a fairly cheap city. London is a big NO in this regard, can't speak about the other suggestions. I don't know what Berlin's like, but I just visited London for a long weekend and it wasn't so bad compared to where I live (NYC). I used AirBnB and my room was like $90 a night.
Re: How are you enjoying DConf? And where to go next?
On Monday, 9 May 2016 at 15:32:05 UTC, wobbles wrote: I also think it should not only be in a decently cheap location, but also in a location where there is, by default, a high concentration of D users. Berlin fits that. Facebook fits that. Where's the other high concentration of D users? Lots of D user in Japan and Australia. Many scattered around the US.
Re: Always false float comparisons
On Monday, 9 May 2016 at 12:28:04 UTC, Walter Bright wrote: On 5/9/2016 4:38 AM, Nordlöw wrote: Would that include comparison of variables only aswell? No. Why?
Re: How are you enjoying DConf? And where to go next?
On Monday, 9 May 2016 at 15:12:25 UTC, krzaq wrote: On Monday, 9 May 2016 at 09:58:32 UTC, Mark Isaacson wrote: Full recognition that there was way less demand for another US DConf... so perhaps somewhere easier to fly to? Reykjavik? Dublin? Oslo? Stockholm? Barcelona? London? Those are pretty good hubs and have solid airfare from the US... and all over. London and Barcelona in particular have a truly impressive number of flights in and out. They're all also really wonderful places to go exploring. Not a huge fan of Berlin as a city... that said the venue was pretty nice (a larger screen would've been better) and the food was definitely a step up from Utah. It's not just the distance, but also the overall personal cost of attending the conference. Berlin is, all things considered, a fairly cheap city. London is a big NO in this regard, can't speak about the other suggestions. I also think it should not only be in a decently cheap location, but also in a location where there is, by default, a high concentration of D users. Berlin fits that. Facebook fits that. Where's the other high concentration of D users?
Re: How are you enjoying DConf? And where to go next?
On Monday, 9 May 2016 at 09:58:32 UTC, Mark Isaacson wrote: Full recognition that there was way less demand for another US DConf... so perhaps somewhere easier to fly to? Reykjavik? Dublin? Oslo? Stockholm? Barcelona? London? Those are pretty good hubs and have solid airfare from the US... and all over. London and Barcelona in particular have a truly impressive number of flights in and out. They're all also really wonderful places to go exploring. Not a huge fan of Berlin as a city... that said the venue was pretty nice (a larger screen would've been better) and the food was definitely a step up from Utah. It's not just the distance, but also the overall personal cost of attending the conference. Berlin is, all things considered, a fairly cheap city. London is a big NO in this regard, can't speak about the other suggestions.
Re: Always false float comparisons
On Monday, 9 May 2016 at 12:24:05 UTC, John Colvin wrote: On Monday, 9 May 2016 at 11:26:55 UTC, Walter Bright wrote: On 5/9/2016 3:16 AM, Jens Mueller via Digitalmars-d wrote: Warning for those comparisons should be fine. Shouldn't mix them anyway. Too onerous. Surely not too onerous if we're only talking about == ? Mixing floating point types on either side of == seems like a pretty solidly bad idea. Why only == ? The example also applies to opCmp. float f = 1.30; assert(f >= 1.30); assert(f <= 1.30);
Re: std.experimental.allocator and @nogc
On 10/05/2016 1:05 AM, ZombineDev wrote:
On Monday, 9 May 2016 at 12:37:24 UTC, rikki cattermole wrote:
On 10/05/2016 12:33 AM, ZombineDev wrote:
On Monday, 9 May 2016 at 12:02:19 UTC, rikki cattermole wrote:
On 09/05/2016 11:56 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 11:20:00 UTC, rikki cattermole wrote:
On 09/05/2016 11:12 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 10:33:27 UTC, rikki cattermole wrote:
I've done windowing and image libraries before.
You are correct, you do not need OOP.
But if you want to keep implementation nicely separated out from
usage, you really do. Which is a major part of my requirements.
Well, in my example above, everything is nicely separated, easy to
use,
yet quite flexible. And still there is no Java-style OOP. Do you
have
any examples, where the use of classic OOP would provide a strictly
superior design?
You're using templates. While this might be ok for image library.
I cannot use this for the windowing library. The implementation may
not be known and must be plugable at runtime.
The reality is, just because you say you know about something at
compile time doesn't mean the system that runs a program does.
I'm still not convinced. You have a fixed at CT number of
implementations. Even if you don't know at CT the actual platform that
will be used, you can still choose at RT the correct template.
Example:
You do not.
Shared libraries remember them?
You will statically link the windowing library and it will dynamically
load the necessary shared/dynamic libaries of the platform at runtime.
What's the problem? E.g. Derelict* does the same.
// platform name can be "X11", "mir", "Wayland", etc.
auto getPlatformWindow(CTArgs...)(string platformNameRTArg)
{
switch (platformNameRTArg.toLower)
{
default:
enforce(false, "Unknown platform: " ~ platformNameRTArg);
foreach (platform; EnumMembers!Platform)
case name.stringof:
// Use std.experiment.typecons.Wrap if you need a
common type.
return getWindow!(name, CTArgs);
}
assert (0);
}
Platform is undefined, did you mean IPlatform?
Platform obviously an enum. The return type can be a plain struct, a
Variant, or a std.experimental.typecons.wrap, depending on your needs.
But that's besides the point. Even with OOP, your return type can
be an
interface that has template parameters like allocators, policies, etc.
You're providing some the arguments at CT and the rest of the return
type is dynamically polymorphic. E.g.:
interface Window(Allocator, Policy);
Window!(Allocator, Policy) getWindow(alias allocator,
Policy)(RunTimeArgs);
Sure you can, but now you have added another layer of indirection
between implementation and usage because you can't use templated types
in between.
There's no indirection (besides the interface, which would also be the
case with your approach) and you **should** use templated types :)
My point is that there's no need for IAllocator, even if you want
to use
OOP so badly.
But in most cases you will either write different code for different
platforms, making interfaces unnecessary, or you would be able to hide
the differences behind a struct.
And when the allocator and the other policies are template parameters
you will know at CT that your code is @nogc.
Again, no templates. You cannot initialize them at runtime, and since
you won't know all implementations until it executes, well, you've got
a problem.
Its a many to many problem. I faced this with Cmsed as well.
As I demonstrated, it's not a problem. You just need to choose the
template at runtime. You have a fixed number of implementations which
are all statically linked. Only the one chosen at runtime will be
initialized and at the moment of initialization it can do the necessary
dynamic loading.
In the example above:
interface Window(Allocator, Policy);
Window!(Allocator, Policy) getWindow(alias allocator,
Policy)(RunTimeArgs);
Since you don't need to switch Allocator implementations at run-time
(and if you switch them you will most certainly get silent memory
corruption), you can leverage the fact that some stuff are known at CT
and leave the rest to RT.
At this point, all I'm going to say is, prove me wrong.
Give me all the power I have now and do it the way you want to.
Challange accepted ;)
PR's welcome.
Well, I'll maybe write my own implementation just cuz it's fun. May be
we can contribute in the future :)
https://github.com/rikkimax/alphaPhobos/
From a cursory look, I would have written
std.experimental.ui.rendering.IDisplay like this:
struct Display
{
// I prefer Nullable because not all information
// could be available on all platforms.
// May be some things are common everywhere,
// but I don't have time to check, right now.
Nullable!string name;
Nullable!vec2!ushort size;
Nullable!uint refreshRate;
Nullable!uint luminosity;
Nullable!
Re: File size of exe: DMD vs LDC
On Monday, 9 May 2016 at 13:48:50 UTC, Walter Bright wrote: On 5/9/2016 5:24 AM, Jacob Carlborg wrote: LDC can strip sections which DMD cannot. Why not? AFAIR, because of how ModuleInfo/TypeInfo is emitted which makes linker never collect sections because they are referenced at least from there. LDC was intentionally modified to change code gen in that regard to make --gc-sections work - David will surely tell more :)
Re: File size of exe: DMD vs LDC
On 5/9/2016 5:24 AM, Jacob Carlborg wrote: LDC can strip sections which DMD cannot. Why not?
Re: Always false float comparisons
On 5/9/16 7:26 AM, Walter Bright wrote: I wonder what's the difference between 1.30f and cast(float)1.30. There isn't one. I know this is a bit band-aid-ish, but if one is comparing literals to a float, why not treat the literal as the type being compared against? In other words, imply the 1.3f. This isn't integer-land where promotions do not change the outcome. What I see here is that double(1.3) cannot be represented as a float. So right there, the compiler can tell you, no, this is never going to be true. Something stinks when you can write an always-false expression as an if conditional by accident. -Steve
Re: std.experimental.allocator and @nogc
On Monday, 9 May 2016 at 12:37:24 UTC, rikki cattermole wrote:
On 10/05/2016 12:33 AM, ZombineDev wrote:
On Monday, 9 May 2016 at 12:02:19 UTC, rikki cattermole wrote:
On 09/05/2016 11:56 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 11:20:00 UTC, rikki cattermole
wrote:
On 09/05/2016 11:12 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 10:33:27 UTC, rikki cattermole
wrote:
I've done windowing and image libraries before.
You are correct, you do not need OOP.
But if you want to keep implementation nicely separated
out from
usage, you really do. Which is a major part of my
requirements.
Well, in my example above, everything is nicely separated,
easy to
use,
yet quite flexible. And still there is no Java-style OOP.
Do you have
any examples, where the use of classic OOP would provide a
strictly
superior design?
You're using templates. While this might be ok for image
library.
I cannot use this for the windowing library. The
implementation may
not be known and must be plugable at runtime.
The reality is, just because you say you know about
something at
compile time doesn't mean the system that runs a program
does.
I'm still not convinced. You have a fixed at CT number of
implementations. Even if you don't know at CT the actual
platform that
will be used, you can still choose at RT the correct
template. Example:
You do not.
Shared libraries remember them?
You will statically link the windowing library and it will
dynamically
load the necessary shared/dynamic libaries of the platform at
runtime.
What's the problem? E.g. Derelict* does the same.
// platform name can be "X11", "mir", "Wayland", etc.
auto getPlatformWindow(CTArgs...)(string platformNameRTArg)
{
switch (platformNameRTArg.toLower)
{
default:
enforce(false, "Unknown platform: " ~
platformNameRTArg);
foreach (platform; EnumMembers!Platform)
case name.stringof:
// Use std.experiment.typecons.Wrap if you
need a
common type.
return getWindow!(name, CTArgs);
}
assert (0);
}
Platform is undefined, did you mean IPlatform?
Platform obviously an enum. The return type can be a plain
struct, a
Variant, or a std.experimental.typecons.wrap, depending on
your needs.
But that's besides the point. Even with OOP, your return
type can be an
interface that has template parameters like allocators,
policies, etc.
You're providing some the arguments at CT and the rest of
the return
type is dynamically polymorphic. E.g.:
interface Window(Allocator, Policy);
Window!(Allocator, Policy) getWindow(alias allocator,
Policy)(RunTimeArgs);
Sure you can, but now you have added another layer of
indirection
between implementation and usage because you can't use
templated types
in between.
There's no indirection (besides the interface, which would
also be the
case with your approach) and you **should** use templated
types :)
My point is that there's no need for IAllocator, even if you
want to use
OOP so badly.
But in most cases you will either write different code for
different
platforms, making interfaces unnecessary, or you would be
able to hide
the differences behind a struct.
And when the allocator and the other policies are template
parameters
you will know at CT that your code is @nogc.
Again, no templates. You cannot initialize them at runtime,
and since
you won't know all implementations until it executes, well,
you've got
a problem.
Its a many to many problem. I faced this with Cmsed as well.
As I demonstrated, it's not a problem. You just need to choose
the
template at runtime. You have a fixed number of
implementations which
are all statically linked. Only the one chosen at runtime will
be
initialized and at the moment of initialization it can do the
necessary
dynamic loading.
In the example above:
interface Window(Allocator, Policy);
Window!(Allocator, Policy) getWindow(alias allocator,
Policy)(RunTimeArgs);
Since you don't need to switch Allocator implementations at
run-time
(and if you switch them you will most certainly get silent
memory
corruption), you can leverage the fact that some stuff are
known at CT
and leave the rest to RT.
At this point, all I'm going to say is, prove me wrong.
Give me all the power I have now and do it the way you want to.
Challange accepted ;)
PR's welcome.
Well, I'll maybe write my own implementation just cuz it's fun.
May be we can contribute in the future :)
https://github.com/rikkimax/alphaPhobos/
From a cursory look, I would have written
std.experimental.ui.rendering.IDisplay like this:
struct Display
{
// I prefer Nullable because not all information
// could be available on all platforms.
// May be some things are common everywhere,
// but I don't have time to check, right now.
Nullable!string name;
Nullable!vec2!ushort size;
Nullable!uint refreshRate;
Nullable!uint luminosity;
Re: powExpressions work at ctfe
On Monday, 9 May 2016 at 12:49:16 UTC, Stefan Koch wrote: On Monday, 9 May 2016 at 12:33:33 UTC, Stefan Koch wrote: On Monday, 9 May 2016 at 12:24:18 UTC, Timon Gehr wrote: [...] I see. I did not test a floating point value at the left-hand site. working on a fix. okay the workaround would be just to avoid pointer casts. And use bitwise operations to convert the values. Another option is not to jit std.math routines at ctfe. I would prefer the second option, any opinions ? Yet another option is using soft-float for ctfe, that would also prevent issues with cross-compiled binarys that have ctfe in them.
Re: powExpressions work at ctfe
On Monday, 9 May 2016 at 12:33:33 UTC, Stefan Koch wrote: On Monday, 9 May 2016 at 12:24:18 UTC, Timon Gehr wrote: On 09.05.2016 11:24, Stefan Koch wrote: At Dconf Manu asked to use pow expressions at CTFE. Luckily he can. powExpressions work at ctfe. enum x=2.4^^4.5; DMD master: ./../../phobos/std/math.d(4857): Error: cannot convert &real to ushort* at compile time ./../../phobos/std/math.d(6113):called from here: isNaN(y) ./../../phobos/std/math.d(6303):called from here: impl(cast(real)x, cast(real)y) ctfepow.d(1):called from here: pow(2.4, 4.5) I see. I did not test a floating point value at the left-hand site. working on a fix. okay the workaround would be just to avoid pointer casts. And use bitwise operations to convert the values. Another option is not to jit std.math routines at ctfe. I would prefer the second option, any opinions ?
Re: Always false float comparisons
On Monday, 9 May 2016 at 12:30:13 UTC, Walter Bright wrote: Promoting to double does not lose precision. Yes, badly worded on my part, I was getting at the original assignment from double to float.
Re: std.experimental.allocator and @nogc
On 10/05/2016 12:33 AM, ZombineDev wrote:
On Monday, 9 May 2016 at 12:02:19 UTC, rikki cattermole wrote:
On 09/05/2016 11:56 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 11:20:00 UTC, rikki cattermole wrote:
On 09/05/2016 11:12 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 10:33:27 UTC, rikki cattermole wrote:
I've done windowing and image libraries before.
You are correct, you do not need OOP.
But if you want to keep implementation nicely separated out from
usage, you really do. Which is a major part of my requirements.
Well, in my example above, everything is nicely separated, easy to
use,
yet quite flexible. And still there is no Java-style OOP. Do you have
any examples, where the use of classic OOP would provide a strictly
superior design?
You're using templates. While this might be ok for image library.
I cannot use this for the windowing library. The implementation may
not be known and must be plugable at runtime.
The reality is, just because you say you know about something at
compile time doesn't mean the system that runs a program does.
I'm still not convinced. You have a fixed at CT number of
implementations. Even if you don't know at CT the actual platform that
will be used, you can still choose at RT the correct template. Example:
You do not.
Shared libraries remember them?
You will statically link the windowing library and it will dynamically
load the necessary shared/dynamic libaries of the platform at runtime.
What's the problem? E.g. Derelict* does the same.
// platform name can be "X11", "mir", "Wayland", etc.
auto getPlatformWindow(CTArgs...)(string platformNameRTArg)
{
switch (platformNameRTArg.toLower)
{
default:
enforce(false, "Unknown platform: " ~ platformNameRTArg);
foreach (platform; EnumMembers!Platform)
case name.stringof:
// Use std.experiment.typecons.Wrap if you need a
common type.
return getWindow!(name, CTArgs);
}
assert (0);
}
Platform is undefined, did you mean IPlatform?
Platform obviously an enum. The return type can be a plain struct, a
Variant, or a std.experimental.typecons.wrap, depending on your needs.
But that's besides the point. Even with OOP, your return type can be an
interface that has template parameters like allocators, policies, etc.
You're providing some the arguments at CT and the rest of the return
type is dynamically polymorphic. E.g.:
interface Window(Allocator, Policy);
Window!(Allocator, Policy) getWindow(alias allocator,
Policy)(RunTimeArgs);
Sure you can, but now you have added another layer of indirection
between implementation and usage because you can't use templated types
in between.
There's no indirection (besides the interface, which would also be the
case with your approach) and you **should** use templated types :)
My point is that there's no need for IAllocator, even if you want to use
OOP so badly.
But in most cases you will either write different code for different
platforms, making interfaces unnecessary, or you would be able to hide
the differences behind a struct.
And when the allocator and the other policies are template parameters
you will know at CT that your code is @nogc.
Again, no templates. You cannot initialize them at runtime, and since
you won't know all implementations until it executes, well, you've got
a problem.
Its a many to many problem. I faced this with Cmsed as well.
As I demonstrated, it's not a problem. You just need to choose the
template at runtime. You have a fixed number of implementations which
are all statically linked. Only the one chosen at runtime will be
initialized and at the moment of initialization it can do the necessary
dynamic loading.
In the example above:
interface Window(Allocator, Policy);
Window!(Allocator, Policy) getWindow(alias allocator,
Policy)(RunTimeArgs);
Since you don't need to switch Allocator implementations at run-time
(and if you switch them you will most certainly get silent memory
corruption), you can leverage the fact that some stuff are known at CT
and leave the rest to RT.
At this point, all I'm going to say is, prove me wrong.
Give me all the power I have now and do it the way you want to.
PR's welcome. https://github.com/rikkimax/alphaPhobos/
FYI, I'll be streaming in a minute https://www.livecoding.tv/alphaglosined/
Re: std.experimental.allocator and @nogc
On Monday, 9 May 2016 at 12:02:19 UTC, rikki cattermole wrote:
On 09/05/2016 11:56 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 11:20:00 UTC, rikki cattermole wrote:
On 09/05/2016 11:12 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 10:33:27 UTC, rikki cattermole
wrote:
I've done windowing and image libraries before.
You are correct, you do not need OOP.
But if you want to keep implementation nicely separated out
from
usage, you really do. Which is a major part of my
requirements.
Well, in my example above, everything is nicely separated,
easy to use,
yet quite flexible. And still there is no Java-style OOP. Do
you have
any examples, where the use of classic OOP would provide a
strictly
superior design?
You're using templates. While this might be ok for image
library.
I cannot use this for the windowing library. The
implementation may
not be known and must be plugable at runtime.
The reality is, just because you say you know about something
at
compile time doesn't mean the system that runs a program does.
I'm still not convinced. You have a fixed at CT number of
implementations. Even if you don't know at CT the actual
platform that
will be used, you can still choose at RT the correct template.
Example:
You do not.
Shared libraries remember them?
You will statically link the windowing library and it will
dynamically load the necessary shared/dynamic libaries of the
platform at runtime. What's the problem? E.g. Derelict* does the
same.
// platform name can be "X11", "mir", "Wayland", etc.
auto getPlatformWindow(CTArgs...)(string platformNameRTArg)
{
switch (platformNameRTArg.toLower)
{
default:
enforce(false, "Unknown platform: " ~
platformNameRTArg);
foreach (platform; EnumMembers!Platform)
case name.stringof:
// Use std.experiment.typecons.Wrap if you
need a
common type.
return getWindow!(name, CTArgs);
}
assert (0);
}
Platform is undefined, did you mean IPlatform?
Platform obviously an enum. The return type can be a plain
struct, a Variant, or a std.experimental.typecons.wrap, depending
on your needs.
But that's besides the point. Even with OOP, your return type
can be an
interface that has template parameters like allocators,
policies, etc.
You're providing some the arguments at CT and the rest of the
return
type is dynamically polymorphic. E.g.:
interface Window(Allocator, Policy);
Window!(Allocator, Policy) getWindow(alias allocator,
Policy)(RunTimeArgs);
Sure you can, but now you have added another layer of
indirection between implementation and usage because you can't
use templated types in between.
There's no indirection (besides the interface, which would also
be the case with your approach) and you **should** use templated
types :)
My point is that there's no need for IAllocator, even if you
want to use
OOP so badly.
But in most cases you will either write different code for
different
platforms, making interfaces unnecessary, or you would be able
to hide
the differences behind a struct.
And when the allocator and the other policies are template
parameters
you will know at CT that your code is @nogc.
Again, no templates. You cannot initialize them at runtime, and
since you won't know all implementations until it executes,
well, you've got a problem.
Its a many to many problem. I faced this with Cmsed as well.
As I demonstrated, it's not a problem. You just need to choose
the template at runtime. You have a fixed number of
implementations which are all statically linked. Only the one
chosen at runtime will be initialized and at the moment of
initialization it can do the necessary dynamic loading.
In the example above:
interface Window(Allocator, Policy);
Window!(Allocator, Policy) getWindow(alias allocator,
Policy)(RunTimeArgs);
Since you don't need to switch Allocator implementations at
run-time (and if you switch them you will most certainly get
silent memory corruption), you can leverage the fact that some
stuff are known at CT and leave the rest to RT.
Re: powExpressions work at ctfe
On Monday, 9 May 2016 at 12:24:18 UTC, Timon Gehr wrote: On 09.05.2016 11:24, Stefan Koch wrote: At Dconf Manu asked to use pow expressions at CTFE. Luckily he can. powExpressions work at ctfe. enum x=2.4^^4.5; DMD master: ./../../phobos/std/math.d(4857): Error: cannot convert &real to ushort* at compile time ./../../phobos/std/math.d(6113):called from here: isNaN(y) ./../../phobos/std/math.d(6303):called from here: impl(cast(real)x, cast(real)y) ctfepow.d(1):called from here: pow(2.4, 4.5) I see. I did not test a floating point value at the left-hand site. working on a fix.
Re: So, About That Official Blog...
On Sunday, 8 May 2016 at 20:31:26 UTC, Nick Sabalausky wrote: I would also recommend a static site generator, I currently use Hugo https://gohugo.io/ though it is written it Go haha. Jekyll got really slow after 30 blog entries, especially if you want to do the syntax highlighting offline. In short: Hybrid site generating :) Only generate on-the-fly what NEEDS to be on-the-fly. Only regenerate things when they change, not every time they're viewed (unless they change more than they're viewed, like maybe an admin-only site webstats page, but such cases are rare). Guys - KISS! During the time we already spent in this thread, we could have written least five great blog entries! Therefore +1 for static site generators - they keep stuff simple. The advantage of Jekyll is that it works so nice with Github pages and everyone can thus preview the changes on their local gh-pages branch. Getting the Dlang theme is not difficult, see e.g. my proposal for to put the DIPs into a github repo: https://github.com/wilzbach/d-dip http://wilzbach.github.io/d-dip/DIP86 The DIP Jekyll site builds in ~five seconds (90 pages). That being said, I like Hugo too. Btw if we just keep using DDOC (a static site generator), all the custom macros will continue to work ;-)
Re: Always false float comparisons
On 5/9/2016 5:21 AM, Ethan Watson wrote: I'd assume in the first case that the float is being promoted to double for the comparison. Is there already a warning for loss of precision? Promoting to double does not lose precision. We treat warnings as errors in our C++ code, so C4244 triggers all the time in MSVC with integer operations. I just tested that float initialisation in MSVC, initialising a float with a double triggers C4305. That's going quite a bit further.
Re: Always false float comparisons
On Monday, 9 May 2016 at 12:28:04 UTC, Walter Bright wrote: On 5/9/2016 4:38 AM, Nordlöw wrote: Would that include comparison of variables only aswell? float f = 1.3; double d = 1.3; assert(f == d); // compiler warning No. Just get rid of the problem : remove == and != from floats.
Re: Always false float comparisons
On 5/9/2016 4:38 AM, Nordlöw wrote: Would that include comparison of variables only aswell? float f = 1.3; double d = 1.3; assert(f == d); // compiler warning No.
Re: Always false float comparisons
On 5/9/2016 4:16 AM, ZombineDev wrote: just like emitting a warning for mismatched signed/unsigned comparison. Not at all the same, such are not always false.
Re: File size of exe: DMD vs LDC
On 2016-05-09 12:58, Chris wrote: I have a program whose size is 3.2 MB when compiled with LDC, and 6.3 MB when compiled with DMD. Both are release builds. That's almost twice as big. LDC can strip sections which DMD cannot. -- /Jacob Carlborg
Re: powExpressions work at ctfe
On 09.05.2016 11:24, Stefan Koch wrote: At Dconf Manu asked to use pow expressions at CTFE. Luckily he can. powExpressions work at ctfe. enum x=2.4^^4.5; DMD master: ./../../phobos/std/math.d(4857): Error: cannot convert &real to ushort* at compile time ./../../phobos/std/math.d(6113):called from here: isNaN(y) ./../../phobos/std/math.d(6303):called from here: impl(cast(real)x, cast(real)y) ctfepow.d(1):called from here: pow(2.4, 4.5)
Re: Always false float comparisons
On Monday, 9 May 2016 at 11:26:55 UTC, Walter Bright wrote: On 5/9/2016 3:16 AM, Jens Mueller via Digitalmars-d wrote: Warning for those comparisons should be fine. Shouldn't mix them anyway. Too onerous. Surely not too onerous if we're only talking about == ? Mixing floating point types on either side of == seems like a pretty solidly bad idea.
Re: Always false float comparisons
On Monday, 9 May 2016 at 09:10:19 UTC, Walter Bright wrote: Don Clugston pointed out in his DConf 2016 talk that: float f = 1.30; assert(f == 1.30); will always be false since 1.30 is not representable as a float. However, float f = 1.30; assert(f == cast(float)1.30); will be true. So, should the compiler emit a warning for the former case? I'd assume in the first case that the float is being promoted to double for the comparison. Is there already a warning for loss of precision? We treat warnings as errors in our C++ code, so C4244 triggers all the time in MSVC with integer operations. I just tested that float initialisation in MSVC, initialising a float with a double triggers C4305. So my preference is "Yes please". https://msdn.microsoft.com/en-us/library/th7a07tz.aspx https://msdn.microsoft.com/en-us/library/0as1ke3f.aspx
Re: dmd not building with dmd
On Monday, 9 May 2016 at 07:57:33 UTC, Lionello Lunesu wrote: On 8/5/2016 14:43, Steven Schveighoffer wrote: [...] I ran into this as well. It's a bug in the package from brew: it shipped with the wrong phobos. You can build your own DMD: $ make -f posix.mak AUTO_BOOTSTRAP=1 In what way do you mean "shipped with the wrong phobos"?
Re: So, About That Official Blog...
On 2016-05-08 22:31, Nick Sabalausky wrote: I've been moving the direction of hybrid approaches. Kinda like static site generating, but the regenerating is done automatically as-needed, can receive updates via HTTP GET/POST and do other real-time processing during certain requests, etc. I don't know much about off-the-shelf website tools out there (or whether there are any that work this way), but it's what I did for the travis d compiler list ( https://semitwist.com/travis-d-compilers ): It's fully dynamic templated, driven by Vibe.d and a database, new entires are added automatically via HTTP POST, etc, it has REAL server-side logic running. But instead of regenerating the HTML page on every request (or dynamically regenerating a JSON/XML description of the data on every request for client-side JS to then render - an approach I never really understood), the Vibe.d-based site simply regenerates a static HTML page when the *data* changes, which on most web pages is much less frequent than actual page requests. Something like sever side caching? There are other ways to adjust static/dynamic balances too. There's usually a LOT of components on even a fully-dynamic page that ARE pre-cachable, even if the page as a whole isn't: For example, a classic case where a static site generator wouldn't work: An online shopping search results page. You can't predict ahead of time what queries will be run and pregenerate entire results pages, but you CAN pregenerate divs for how each individual item will be displayed when it does appear in someone's results page. Then when someone runs a search you just write the appropriate pre-built divs to the output stream, one after the other. Sounds like Russian doll caching [1]. In short: Hybrid site generating :) Only generate on-the-fly what NEEDS to be on-the-fly. Only regenerate things when they change, not every time they're viewed (unless they change more than they're viewed, like maybe an admin-only site webstats page, but such cases are rare). [1] http://blog.remarkablelabs.com/2012/12/russian-doll-caching-cache-digests-rails-4-countdown-to-2013 -- /Jacob Carlborg
Re: std.experimental.allocator and @nogc
On 09/05/2016 11:56 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 11:20:00 UTC, rikki cattermole wrote:
On 09/05/2016 11:12 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 10:33:27 UTC, rikki cattermole wrote:
I've done windowing and image libraries before.
You are correct, you do not need OOP.
But if you want to keep implementation nicely separated out from
usage, you really do. Which is a major part of my requirements.
Well, in my example above, everything is nicely separated, easy to use,
yet quite flexible. And still there is no Java-style OOP. Do you have
any examples, where the use of classic OOP would provide a strictly
superior design?
You're using templates. While this might be ok for image library.
I cannot use this for the windowing library. The implementation may
not be known and must be plugable at runtime.
The reality is, just because you say you know about something at
compile time doesn't mean the system that runs a program does.
I'm still not convinced. You have a fixed at CT number of
implementations. Even if you don't know at CT the actual platform that
will be used, you can still choose at RT the correct template. Example:
You do not.
Shared libraries remember them?
// platform name can be "X11", "mir", "Wayland", etc.
auto getPlatformWindow(CTArgs...)(string platformNameRTArg)
{
switch (platformNameRTArg.toLower)
{
default:
enforce(false, "Unknown platform: " ~ platformNameRTArg);
foreach (platform; EnumMembers!Platform)
case name.stringof:
// Use std.experiment.typecons.Wrap if you need a
common type.
return getWindow!(name, CTArgs);
}
assert (0);
}
Platform is undefined, did you mean IPlatform?
But that's besides the point. Even with OOP, your return type can be an
interface that has template parameters like allocators, policies, etc.
You're providing some the arguments at CT and the rest of the return
type is dynamically polymorphic. E.g.:
interface Window(Allocator, Policy);
Window!(Allocator, Policy) getWindow(alias allocator, Policy)(RunTimeArgs);
Sure you can, but now you have added another layer of indirection
between implementation and usage because you can't use templated types
in between.
My point is that there's no need for IAllocator, even if you want to use
OOP so badly.
But in most cases you will either write different code for different
platforms, making interfaces unnecessary, or you would be able to hide
the differences behind a struct.
And when the allocator and the other policies are template parameters
you will know at CT that your code is @nogc.
Again, no templates. You cannot initialize them at runtime, and since
you won't know all implementations until it executes, well, you've got a
problem.
Its a many to many problem. I faced this with Cmsed as well.
Re: std.experimental.allocator and @nogc
On Monday, 9 May 2016 at 11:20:00 UTC, rikki cattermole wrote:
On 09/05/2016 11:12 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 10:33:27 UTC, rikki cattermole wrote:
I've done windowing and image libraries before.
You are correct, you do not need OOP.
But if you want to keep implementation nicely separated out
from
usage, you really do. Which is a major part of my
requirements.
Well, in my example above, everything is nicely separated,
easy to use,
yet quite flexible. And still there is no Java-style OOP. Do
you have
any examples, where the use of classic OOP would provide a
strictly
superior design?
You're using templates. While this might be ok for image
library.
I cannot use this for the windowing library. The implementation
may not be known and must be plugable at runtime.
The reality is, just because you say you know about something
at compile time doesn't mean the system that runs a program
does.
I'm still not convinced. You have a fixed at CT number of
implementations. Even if you don't know at CT the actual platform
that will be used, you can still choose at RT the correct
template. Example:
// platform name can be "X11", "mir", "Wayland", etc.
auto getPlatformWindow(CTArgs...)(string platformNameRTArg)
{
switch (platformNameRTArg.toLower)
{
default:
enforce(false, "Unknown platform: " ~
platformNameRTArg);
foreach (platform; EnumMembers!Platform)
case name.stringof:
// Use std.experiment.typecons.Wrap if you need
a common type.
return getWindow!(name, CTArgs);
}
assert (0);
}
But that's besides the point. Even with OOP, your return type can
be an interface that has template parameters like allocators,
policies, etc. You're providing some the arguments at CT and the
rest of the return type is dynamically polymorphic. E.g.:
interface Window(Allocator, Policy);
Window!(Allocator, Policy) getWindow(alias allocator,
Policy)(RunTimeArgs);
My point is that there's no need for IAllocator, even if you want
to use OOP so badly.
But in most cases you will either write different code for
different platforms, making interfaces unnecessary, or you would
be able to hide the differences behind a struct.
And when the allocator and the other policies are template
parameters you will know at CT that your code is @nogc.
Re: Always false float comparisons
On Monday, 9 May 2016 at 09:10:19 UTC, Walter Bright wrote: So, should the compiler emit a warning for the former case? Would that include comparison of variables only aswell? float f = 1.3; double d = 1.3; assert(f == d); // compiler warning
Re: Always false float comparisons
On Monday, 9 May 2016 at 09:10:19 UTC, Walter Bright wrote: So, should the compiler emit a warning for the former case? Yes, please. I would prefer, at least, a warning flag for that.
Re: Always false float comparisons
On 5/9/2016 3:16 AM, Jens Mueller via Digitalmars-d wrote: passes I find the root cause lies in the implicit type conversion from float to double. That isn't going to change. Warning for those comparisons should be fine. Shouldn't mix them anyway. Too onerous. I wonder what's the difference between 1.30f and cast(float)1.30. There isn't one.
Re: Always false float comparisons
On 5/9/2016 2:25 AM, qznc wrote: What is the actual reason for the mismatch? floats cannot represent 1.30 exactly, and promoting it to a double gives a different result than 1.30 as a double.
Re: std.experimental.allocator and @nogc
On 09/05/2016 11:12 PM, ZombineDev wrote: On Monday, 9 May 2016 at 10:33:27 UTC, rikki cattermole wrote: I've done windowing and image libraries before. You are correct, you do not need OOP. But if you want to keep implementation nicely separated out from usage, you really do. Which is a major part of my requirements. Well, in my example above, everything is nicely separated, easy to use, yet quite flexible. And still there is no Java-style OOP. Do you have any examples, where the use of classic OOP would provide a strictly superior design? You're using templates. While this might be ok for image library. I cannot use this for the windowing library. The implementation may not be known and must be plugable at runtime. The reality is, just because you say you know about something at compile time doesn't mean the system that runs a program does.
Re: Always false float comparisons
On Monday, 9 May 2016 at 09:10:19 UTC, Walter Bright wrote: Don Clugston pointed out in his DConf 2016 talk that: float f = 1.30; assert(f == 1.30); will always be false since 1.30 is not representable as a float. However, float f = 1.30; assert(f == cast(float)1.30); will be true. So, should the compiler emit a warning for the former case? Yes, I think it is a good idea, just like emitting a warning for mismatched signed/unsigned comparison.
Re: std.experimental.allocator and @nogc
On Monday, 9 May 2016 at 10:33:27 UTC, rikki cattermole wrote: I've done windowing and image libraries before. You are correct, you do not need OOP. But if you want to keep implementation nicely separated out from usage, you really do. Which is a major part of my requirements. Well, in my example above, everything is nicely separated, easy to use, yet quite flexible. And still there is no Java-style OOP. Do you have any examples, where the use of classic OOP would provide a strictly superior design?
Re: File size of exe: DMD vs LDC
On Monday, 9 May 2016 at 10:58:12 UTC, Chris wrote: I have a program whose size is 3.2 MB when compiled with LDC, and 6.3 MB when compiled with DMD. Both are release builds. That's almost twice as big. You can upload the .map files to http://thecybershadow.net/d/mapview/ to get a visualization of what's taking how much space.
File size of exe: DMD vs LDC
I have a program whose size is 3.2 MB when compiled with LDC, and 6.3 MB when compiled with DMD. Both are release builds. That's almost twice as big.
Re: The end of curl (in phobos)
On Monday, 9 May 2016 at 09:35:18 UTC, sigod wrote: On Monday, 9 May 2016 at 08:55:36 UTC, Jonathan M Davis wrote: But given that std.net.curl handles stuff like SSL/TLS, we _can't_ actually replace all of its functionality - at least not without adding a dependency on a different C library, since there's no way that it's sane to do the crypto stuff ourselves without a crypto expert, and even then, we should think twice about it. I could see implementing the SSL/TLS protocols themselves but not the crypto they use. If we replace std.net.curl, we likely should just provide the basic HTTP functionality, and leave the rest to a dub package that we move std.net.curl to. Any chances that we can produce good crypto code over time? And verify it with experts, of course. https://github.com/etcimon/botan AFAIK, it is already used in production by its author, in combination with libasync + vibe.d + http2 for a full stack D solution. ...
Re: std.experimental.allocator and @nogc
I've done windowing and image libraries before. You are correct, you do not need OOP. But if you want to keep implementation nicely separated out from usage, you really do. Which is a major part of my requirements.
Re: Always false float comparisons
On Monday, 9 May 2016 at 10:16:54 UTC, Jens Mueller wrote: Walter Bright via Digitalmars-d wrote: Don Clugston pointed out in his DConf 2016 talk that: float f = 1.30; assert(f == 1.30); will always be false since 1.30 is not representable as a float. However, float f = 1.30; assert(f == cast(float)1.30); will be true. So, should the compiler emit a warning for the former case? Since assert(f == 1.30f); passes I find the root cause lies in the implicit type conversion from float to double. Warning for those comparisons should be fine. Shouldn't mix them anyway. I wonder what's the difference between 1.30f and cast(float)1.30. Jens +1
Re: std.experimental.allocator and @nogc
On Monday, 9 May 2016 at 06:35:36 UTC, rikki cattermole wrote:
On 09/05/2016 6:22 PM, Hildigard Sandyman wrote:
It's true but... why do you bother with IAllocator ?
Everything can be
set a compile time with a template parameter. As long as the
param is a
struct with allocate/deallocate/reallocate it's OK. you can
use already
a good part of the package content in a @nogc fashion.
Do you have an example where IAllocator must be used and
where, for
example, Mallocator can't be passed ?!
The moment where you need to use OOP, you most definitely need
IAllocator.
I cannot make a windowing library without the use of IAllocator.
You can't always template functions with the type that is the
allocator.
Its just not possible or reasonable.
You don't need OOP for neither windowing, nor image abstraction.
None of the OS APIs require it. I haven't considered using
classes for my projects for more than a year, because D offers
much better ways to solve most problems and cuz programming in a
Java-like way just sucks.
Functions that require memory allocation should take alias
allocator template parameters. And everything should be templated
for maximum flexibility!
For example, instead writing Image interfaces/classes or even
structs, just offer a couple of free functions that convert from
.bmp/.png/.jpg/ etc. to ndslice and back.
For example:
/**
* Automatically determines the image format and reads the
* image in memory by converting each pixel to `ColorType`.
* Internally calls readImage!(ImageFormat.png) /
* readImage!(ImageFormat.bmp / etc. depending on
* the deduced image format.
*
* If the underlying `allocator` is `MmapAllocator`, it maps
* the file into memory, instead of copying it.
*
* Parameters:
* file_path = string input range specifying location
* of the image to be read
*
* Returns:
*`Slice!(N, RandAccessR!ColorType)` where `N` is >= 2.
*(All images are conceptually two dimensional, but may
*be internally divided into blocks).
*/
auto readImage(ColorType, alias allocator = GCAllocator.instance,
R)(R file_path)
if (isStringRange!R && isColor!ColorType &&
is(typeof(allocatorInstance!allocator)));
// example 1 - image manipulation
unittest
{
auto tinyAlloc = StackAllocator!256();
auto imgAlloc = ScopedAllocator!MmapAllocator;
alias C = Color!(ColorFormat.RGBA8);
auto images =
["./img1.jpg", "../images/img2.png", "./mask.bmp"]
.map!(path => path.readImage!(C, imgAlloc))
.array!tinyAlloc; // force eager evaluation
auto result = makeSlice!C(imgAlloc, image[0].shape);
auto xyzo_slice = lockstep(aliasSeqOf!images, result);
xyzo_slice.each!((in ref x, in ref y, in ref y, ref o) =>
o = (x + y) * z)();
result.writeImage!(ImageFormat.png)("./output.png");
// All allocated memory is freed at the end of the scope.
}
// example 2 - image viewer
void main(string[] args)
{
enforce(args.length == 2, "Usage: imgshow ");
enforce(exists(args[1], "%s doesn't exist".format(args[1]));
auto imgAllocator = ScopedAllocator!MmapAllocator;
auto uiAllocator = ScopedAllocator!Mallocator;
alias C = Color!(ColorFormat.RGBA8);
auto img = readImage!(C, imgAllocator)(args[1]);
// I don't think you need heap allocations for basic stuff
// with Win32 but still I'm not familiar with every API out
there.
// `window` is RAII struct that should manage GUI resources
// as needed.
auto window = createWindowWithImage!uiAllocator(img);
bool running = true;
window.show.enterEventLoop!(
(QuitEvent q) { running = false; },
(ResizeEvent r) => false /* do not allow resizing */
(MouseClick m) /* color picker */
{ writefln("pixel at [%s, %s] is %s",
m.coords.expand, img[m.coords]); }
/* ignore other events */
)(&running);
}
See, no classes or interfaces were harmed during the making of
those examples :D
Re: Always false float comparisons
Walter Bright via Digitalmars-d wrote: > Don Clugston pointed out in his DConf 2016 talk that: > > float f = 1.30; > assert(f == 1.30); > > will always be false since 1.30 is not representable as a float. However, > > float f = 1.30; > assert(f == cast(float)1.30); > > will be true. > > So, should the compiler emit a warning for the former case? Since assert(f == 1.30f); passes I find the root cause lies in the implicit type conversion from float to double. Warning for those comparisons should be fine. Shouldn't mix them anyway. I wonder what's the difference between 1.30f and cast(float)1.30. Jens
Re: The end of curl (in phobos)
On Monday, May 09, 2016 09:35:18 sigod via Digitalmars-d wrote: > On Monday, 9 May 2016 at 08:55:36 UTC, Jonathan M Davis wrote: > > But given that std.net.curl handles stuff like SSL/TLS, we > > _can't_ actually replace all of its functionality - at least > > not without adding a dependency on a different C library, since > > there's no way that it's sane to do the crypto stuff ourselves > > without a crypto expert, and even then, we should think twice > > about it. I could see implementing the SSL/TLS protocols > > themselves but not the crypto they use. If we replace > > std.net.curl, we likely should just provide the basic HTTP > > functionality, and leave the rest to a dub package that we move > > std.net.curl to. > > Any chances that we can produce good crypto code over time? And > verify it with experts, of course. I'm sure that it's possible, but it's also very dangerous territory to deal with. Even if you get the crypto itself right, there are all kinds of other nasty problems you have to worry about that most people won't - like ensuring that certain operations take the same amount of time regardless of whether they succeed or not so that folks snooping can't figure out what is and isn't succeeding. There's also the issue of keeping up-to-date with which protocols should be used and which shouldn't (e.g. if I understand correctly, pretty much nothing should be using SSL now; it should all be TLS). So, while there is no technical barrier to us implementing all of this in D (the crypto itself included), it's a very tall order to get it right. Having the code vetted by experts would _definitely_ help, but it's going to go a lot better if we have a security expert writing and maintaining the code, and I'm not sure that we have anyone like that among our active contributors right now (though someone like that is definitely welcome to start contributing code). I actually considered implementing SSL in D at one point (with the idea that I'd use a C or C++ library for the crypto itself), but the more that I learn about this stuff, the more leery I am of implementing anything that's in the security domain. And the only way that I would ever consider doing the crypto itself would be by porting C code that did it, and even that seems pretty hairy - especially since I wouldn't have the knowledge necessary to maintain it. So, we may very well end up with full-on crypto stuff written in D at some point - maybe even in the standard library - but it's something that we need to be very careful with. - Jonathan M Davis
Re: The end of curl (in phobos)
On Monday, 9 May 2016 at 08:55:36 UTC, Jonathan M Davis wrote: Walter's main complaint seemed to be that he didn't like the idea of depending on C libraries other than the C runtime in our standard library, since it meant that there was code in our standard library that we did not have control of, and it arguably looks bad to have to use C libraries in our own standard library. But the big problem that I'm aware of has had to do with the fact that we then have an external dependency that not everyone has on their system. Even on Linux, on distros that separate out "dev" packages so that you have to install one package to use a library and another to build code using it, libcurl is not necessarily going to be there to be built against (and it's definitely not on Windows normally). And that's definitely caused problems - though including libcurl with the dmd installer (which we didn't do initially) has reduced those problems. Martin has also made curl lazy-loaded, so you should not have any problems unless you both try to use curl and don't have the curl DLL in your PATH.
Re: Always false float comparisons
On Monday, 9 May 2016 at 09:10:19 UTC, Walter Bright wrote: So, should the compiler emit a warning for the former case? I'm not for a compiler change. IMO a library called std.sanity_float with a equal and a notequal function would be better.
Re: How are you enjoying DConf? And where to go next?
Full recognition that there was way less demand for another US DConf... so perhaps somewhere easier to fly to? Reykjavik? Dublin? Oslo? Stockholm? Barcelona? London? Those are pretty good hubs and have solid airfare from the US... and all over. London and Barcelona in particular have a truly impressive number of flights in and out. They're all also really wonderful places to go exploring. Not a huge fan of Berlin as a city... that said the venue was pretty nice (a larger screen would've been better) and the food was definitely a step up from Utah.
Re: The end of curl (in phobos)
On Monday, 9 May 2016 at 08:55:36 UTC, Jonathan M Davis wrote: But given that std.net.curl handles stuff like SSL/TLS, we _can't_ actually replace all of its functionality - at least not without adding a dependency on a different C library, since there's no way that it's sane to do the crypto stuff ourselves without a crypto expert, and even then, we should think twice about it. I could see implementing the SSL/TLS protocols themselves but not the crypto they use. If we replace std.net.curl, we likely should just provide the basic HTTP functionality, and leave the rest to a dub package that we move std.net.curl to. Any chances that we can produce good crypto code over time? And verify it with experts, of course. In addition, Phobos is not tied to curl's release cycle, and if curl gets a version bump on someone's system, and Phobos hasn't been updated to match, they're going to have a problem. And if we updated to match the version bump, and their distro hadn't, then we'd also have a problem. Oh, that explains why I constantly ran into [this issue][0]. While it was fixed in curl itself. [0]: https://github.com/curl/curl/issues/447
Re: Always false float comparisons
On Monday, 9 May 2016 at 09:10:19 UTC, Walter Bright wrote: Don Clugston pointed out in his DConf 2016 talk that: float f = 1.30; assert(f == 1.30); will always be false since 1.30 is not representable as a float. However, float f = 1.30; assert(f == cast(float)1.30); will be true. So, should the compiler emit a warning for the former case? What is the actual reason for the mismatch? Does f lose precision as a float, while the 1.30 literal is a more precise double/real? Comparing float and double might be worth a warning. Does it encode the two literals differently? If so, why?
powExpressions work at ctfe
At Dconf Manu asked to use pow expressions at CTFE. Luckily he can. powExpressions work at ctfe.
Re: Compiler benchmarks for an alternative to std.uni.asLowerCase.
On Sunday, 8 May 2016 at 23:38:31 UTC, Jon D wrote: * Performance varied widely between compilers, and for DMD, whether the -inline flag was included. The performance delta between asLowerCase and the mapAsLowerCase replacement was very dependent on these choices. Similarly, the delta between inclusion and exclusion of auto-decoding was highly dependent on these selections. This makes me suspicious, since you did not measure standard deviation or variance. A quick local test with your code looks ok, though. One of my students recently made a benchmarking tool. If you really want to do this properly, you could try that: https://github.com/parttimenerd/temci I would not require better statistics here, since the speedups seem to be stable. :)
Re: How are you enjoying DConf? And where to go next?
On Sunday, 8 May 2016 at 12:50:01 UTC, wobbles wrote: Another +1 for Dublin here too. PyConIE is in the Radisson, which is very central and handy for everyone. Theres many many other venues around the city too - including the RDS which has oceans of event space. Also, tis a lovely city! I can do some research about the conference centers. RDS is big, as wobbles said, then you have loads of other places that host conferences (including the three big universities DCU, TCD, UCD). https://dublin.ie/working/conferences/ Maybe the Convention Centre is a bit OTT, but who knows. Anyway, Dublin has Google, Facebook and others. It wouldn't be too hard to get an IT crowd. In the city center everything is within walking distance (no need to take buses or cabs if you go on sight seeing - cabs are quite cheap in Dublin). Hotels and B&Bs are not the cheapest but not ridiculously expensive either, and if you book early enough you should get a decent price. I know of a B&B close to the Convention Centre that charges €45 a night (including breakfast) which is perfectly acceptable given the location. Since Ireland is small, you can go on day tours to other parts, like the west (e.g. Cliffs of Moher). By train, bus or car you're in Galway within 2-3 hours, which is the loveliest city in Ireland. So if you spend a few more days, you can see a good bit of the rest of the country too. Céad míle fáilte! Jaysus, I sound like Fáilte Ireland :-)) http://www.discoverireland.ie/
Always false float comparisons
Don Clugston pointed out in his DConf 2016 talk that: float f = 1.30; assert(f == 1.30); will always be false since 1.30 is not representable as a float. However, float f = 1.30; assert(f == cast(float)1.30); will be true. So, should the compiler emit a warning for the former case?
Re: The end of curl (in phobos)
On Sunday, May 08, 2016 11:33:07 Andrei Alexandrescu via Digitalmars-d wrote: > On 5/8/16 11:05 AM, Jonathan M Davis via Digitalmars-d wrote: > > On Sunday, May 08, 2016 02:44:48 Adam D. Ruppe via Digitalmars-d wrote: > >> On Saturday, 7 May 2016 at 20:50:53 UTC, Jonas Drewsen wrote: > >>> But std.net.curl supports not just HTTP but also FTP etc. so i > >>> guess that won't suffice. > >> > >> We can always implement ftp too, it isn't that complicated of a > >> protocol. > >> > >> Though, I suspect its users are a tiny minority and they might > >> not mind depending on a separate curl package. > > > > An alternative would be to move std.net.curl into a dub package. > > That would still be a breaking change, is that correct? Any replacement would be a breaking change, unless the intention is to keep to std.net.curl's API while ripping out the actual curl usage, and that seems unnecessarily restrictive to me and likely to end up with something inferior to what we would otherwise get. IIRC, we've already had issues with std.net.curl not quite doing what we want (though at least some of those could likely be fixed if we have full control over what the underlying code is doing). But given that std.net.curl handles stuff like SSL/TLS, we _can't_ actually replace all of its functionality - at least not without adding a dependency on a different C library, since there's no way that it's sane to do the crypto stuff ourselves without a crypto expert, and even then, we should think twice about it. I could see implementing the SSL/TLS protocols themselves but not the crypto they use. If we replace std.net.curl, we likely should just provide the basic HTTP functionality, and leave the rest to a dub package that we move std.net.curl to. But even if we did manage to replace all of std.net.curl's functionality in Phobos, I definitely think that we should put in dub. Whatever problems we've had with it, they're definitely not bad enough for us to want to eradicate it as D code, just remove it from Phobos. And if it were a dub package, updating your code to use it should be pretty trivial. Once std.net.curl was deprecated in Phobos, and it was put in dub as a separate package, anyone who wanted to update would just change their import statements to use the module name from the dub package and add it as a dependency to their dub.json/dub.sdl file. So, as far as breaking changes go, moving std.net.curl from Phobos to code.dlang.org would be very easy to deal with. > I'm unclear on what the reasons are for removing libcurl so I'd love to > see them stated clearly. Walter's argumentation was vague - code that we > don't control etc. There have been past reports of issues with libcurl > on windows, have those not been permanently solved? > > I even see a plus: dealing with libcurl is a good exercise in eating our > dogfood regarding "interfacing with C libraries is trivial" stance. > Having to deal with it is a reflection of what other projects have to do > on an ongoing basis. Walter's main complaint seemed to be that he didn't like the idea of depending on C libraries other than the C runtime in our standard library, since it meant that there was code in our standard library that we did not have control of, and it arguably looks bad to have to use C libraries in our own standard library. But the big problem that I'm aware of has had to do with the fact that we then have an external dependency that not everyone has on their system. Even on Linux, on distros that separate out "dev" packages so that you have to install one package to use a library and another to build code using it, libcurl is not necessarily going to be there to be built against (and it's definitely not on Windows normally). And that's definitely caused problems - though including libcurl with the dmd installer (which we didn't do initially) has reduced those problems. Personally, I've run into issues with the tools repo due to its dependence on std.net.curl, and while that may be related to issues on my system rather than anything that's been done with Phobos itself, that doesn't exactly give me warm, fuzzy feelings for std.net.curl. In addition, Phobos is not tied to curl's release cycle, and if curl gets a version bump on someone's system, and Phobos hasn't been updated to match, they're going to have a problem. And if we updated to match the version bump, and their distro hadn't, then we'd also have a problem. AFAIK, curl's API has been fairly stable such that this hasn't been a problem, but it's definitely a concern with C libraries in general, and it was pointed out at dconf that it _is_ a problem with the sqlite bindings. So, even if we decide to keep std.net.curl, I think that versioning issues alone should make us very leery of including C libraries in Phobos - be they via bindings or wrappers. I don't think that we want to be in a situation where someone has to use a specific version of dmd and Phobos, because it's the one that matches a C librar
Re: Pointer top 16 bits use
On Saturday, 7 May 2016 at 06:08:01 UTC, Nicholas Wilson wrote: In Dicebot's DConf talk he mentioned that it is possible to use the top 16 bits for tagging pointers and the associated risks. Regarding the GC not seeing a pointer if the top 16 bits are used, whats to stop us from changing the GC to (or adding an option to) ignore those bits when checking? I imagine that it would cause a lot more false pointers, but when we get precise GC that problem would go away. I would not rely on it *at all* actually, even now. I do not think it would make D portable to every system (let's not only consider x86 architecture). We don't know how a system would choose to map physical memory and hardware devices to virtual memory.
Re: Compiler benchmarks for an alternative to std.uni.asLowerCase.
On 09-May-2016 02:38, Jon D wrote: I did a performance study on speeding up case conversion in std.uni.asLowerCase. Specifics for asLowerCase have been added to issue https://issues.dlang.org/show_bug.cgi?id=11229. Publishing here as some of the more general observations may be of wider interest. Background - Case conversion can generally be sped up by checking if a character is ascii before invoking a full unicode case conversion. The single character std.uni.toLower does this optimization, but std.uni.asLowerCase does not. asLowerCase does a lazy conversion of a range. For the test, I created a replacement for asLowerCase which uses map and toLower. In essence, `map!(x => x.toLower)` or `map!(x => x.byDchar.toLower)`. The only problem is that it should consider multi-codepoint replacements aka full-case folding in Unicode. Otherwise - go ahead and issue a pull request to add special case for < 0x80. -- Dmitry Olshansky
Re: Compiler benchmarks for an alternative to std.uni.asLowerCase.
On 9/5/2016 12:01, Jon D wrote: On Monday, 9 May 2016 at 00:15:03 UTC, Peter Häggman wrote: On Sunday, 8 May 2016 at 23:38:31 UTC, Jon D wrote: I did a performance study on speeding up case conversion in std.uni.asLowerCase. Specifics for asLowerCase have been added to issue https://issues.dlang.org/show_bug.cgi?id=11229. Publishing here as some of the more general observations may be of wider interest. [...] Nice, it seems that you would have enough material to advocate a pull request in phobos then ;) Thanks! I haven't yet taken the time to go through the 'becoming a contributor' steps, when I have the time I'll do that. In this case, I'd want to start by validating with the library designers that the approach makes sense. It by-passes what appears to a basic primitive, std.uni.toCaser. There may be reasons this is not desirable. Less code, and faster, and using existing building blocks. Win, win, win, if you ask me! +1
Re: dmd not building with dmd
On 8/5/2016 14:43, Steven Schveighoffer wrote: I went to create a PR, and did a git pull on all my repositories. After make clean on OSX, dmd would not build: /Applications/Xcode.app/Contents/Developer/usr/bin/make -C src -f posix.mak no cpu specified, assuming X86 CC=c++ dmd idgen.d Undefined symbols for architecture x86_64: "__Unwind_GetIPInfo", referenced from: ___dmd_personality_v0 in libphobos2.a(dwarfeh_5c8_811.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) I had to revert to dmd 2.070 as the build tool to get it to build. My question is: is this expected behavior, or should I file a bug? -Steve I ran into this as well. It's a bug in the package from brew: it shipped with the wrong phobos. You can build your own DMD: $ make -f posix.mak AUTO_BOOTSTRAP=1
For the Weka guys: this fixes your casts
I just saw Shachar's lightning talk and wanted to point them to this
feature that I had done for enhancing Value Range Propagation.
By adding "const" to the index variable, the compiler will actually
enforce the value-range for a foreach iterator. But, this still requires
the range to known, so only works for static arrays:
void main() {
immutable ubyte PARITIES_START = 10;
ubyte[4] parities = [1, 2, 4, 5];
foreach(const ubyte i, ref parity; parities) {
ubyte diskId = PARITIES_START + i; // look ma, no cast
}
}
This has been in D for over year now. Try it.
L.
Re: std.experimental.allocator and @nogc
On Monday, 9 May 2016 at 06:35:36 UTC, rikki cattermole wrote: On 09/05/2016 6:22 PM, Hildigard Sandyman wrote: It's true but... why do you bother with IAllocator ? Everything can be set a compile time with a template parameter. As long as the param is a struct with allocate/deallocate/reallocate it's OK. you can use already a good part of the package content in a @nogc fashion. Do you have an example where IAllocator must be used and where, for example, Mallocator can't be passed ?! The moment where you need to use OOP, you most definitely need IAllocator. I cannot make a windowing library without the use of IAllocator. You can't always template functions with the type that is the allocator. Its just not possible or reasonable. Yes there's a problem with this but that doesn't mean that whole package is concerned. The first message clearly orientates the answer: It seems to me, that std.experimental.allocator should work with @nogc It should == It doesn't yet Are there plans for this ? Question is based on the previous wrong assumption, but since the most important part of the message is the Q itself, it makes people swallow the craps. So basically anyone not well informed who reads this can deduce that it doesn't work at all.
Re: std.experimental.allocator and @nogc
> It's true but... why do you bother with IAllocator ? Everything can be set a > compile time with a template parameter. As long as the param is a struct > with allocate/deallocate/reallocate it's OK. you can use already a good part > of the package content in a @nogc fashion. > > Do you have an example where IAllocator must be used and where, for example, > Mallocator can't be passed ?! How is that going to work in a situation where the code is in a library that you are linking to rather than compiling?
Re: std.experimental.allocator and @nogc
On Mon, May 9, 2016 at 3:10 PM, Hildigard Sandyman via Digitalmars-d wrote: > On Monday, 9 May 2016 at 04:50:59 UTC, Danni Coy wrote: > It already mostly works in @nogc block: > - Mallocator and AlignedMallocator are @nogc. I was trying to use BitmappedBlock, AllocatorList and MmapAllocator with @nogc without much luck. BitmappedBlock and AllocatorList, both take allocators as arguments so they may or may not use GC depending on which allocators they are using. I was wondering how D would handle this.
