Re: [OT] Was: totally satisfied :D
On Sun, 23 Sep 2012 22:47:58 -0700 "H. S. Teoh" wrote: [...] > > As soon as you start having a whole bunch of code at different levels > of abstraction mixed together, you know it's time to split them up > into separate functions, 'cos chances are you'll need to use each > piece independently one day. > Yea, I feel the same way: Code should operate at one level of abstraction. At least ideally. I don't always adhere hard-and-fast to it either because sometimes "getting it done" is more important than "getting it perfect" (not to say that excuses *really* bad enterprisey code). And sometimes you *can't* stick to one level due to performance or language limitations (depending on the language). But whenever reasonably possible, the rule of thumb: One level of abstraction per function. Along similar lines, there's another rule-of-thumb that I actually did pick up in college (and oddly enough, from the "Let's teach first-time beginners OOP, ie code architecture, before flow-of-execution" instructor): If a function is more than one screenful, it's probably too long. Now obviously that can't and shouldn't be used as a hard-and-fast rule, but I've found it a sensible rough guideline. Although I'm much more relaxed about it now than I used to be...and even *moreso* now that I'm on one of these annoying half-height short-screens, erm, I mean "widescreen" ;) > > [...] > > > > What really gets me is that these are the sorts of things that are > > harped on in chapter 1 of just about any decent "intro to > > programming" book. So where did these people even learn to code in > > the first place? > > Probably from a youtube video on how to write your own lame Flash > game. :-P OK, I'm being a bit harsh. But it's hard not to be cynical > when you've seen the kind of code that passes for "enterprise > software" these days. > Maybe it's just because I'm just beyond the snapping point, too, but I don't think it's possible to be too harsh on such code, or anything involving Flash ;) > > (Well, except for the handful of students, and I could always tell > > which ones they were, who were from the class of Mrs. "Let's Teach > > OOP *Before* Basic Flow Of Execution". Those poor students couldn't > > write *any* code, let alone good or bad code. I felt bad for them.) > > Speaking of students who couldn't code... I used to give out > "sympathy marks" for struggling students. Y'know, their code was so > bad, like code that obviously didn't compile or work, or code with > comments written in a way that suggested the student thought that if > they pleaded hard enough verbally the computer might *just* do what > they wanted it to do -- they had to get a failing mark, but I tried > to find excuses to not give them an outright zero. But one time, > after marking a bunch of 15-20 page assignments (complete with intro, > description, code, test results, etc.), I came across a submission > consisting of a single sheet of paper *hand-written* on a single > side. I was boggled for a good moment. It was like... I was trying > not to give anyone an outright zero but she gave me no choice, > y'know? What was the point of handing that piece of paper if she > wasn't even going to make the effort of using the lab *printer*, for > crying out loud. > Ouch. Yea. I think I actually got a sympathy "pass" in German 101. I barely scraped by with a "D-" overall, but if you went strictly by the numbers and class rules it really should have been an F. I think she knew I was at least trying and struggling though. Ironically, the only reason I even took it was because I was having trouble getting through the school's "4 semesters of the same foreign language" requirement when I went with Japanese. Little did I know German would be *far* harder. "Oh, yea, go with German - it's the closest language to English!" Yea, I think that's actually what made it so hard ;) That, and gendered words.
Re: Extending unittests [proposal] [Proof Of Concept]
On 2012-09-23 16:57, Jens Mueller wrote: How is the stack trace provided? Do you get a stack trace for each failure/error? Because that may clutter up the output. Maybe they stop at a predefined stack trace length. Rspec with an exception thrown: http://pastebin.com/wVeQEBUh With full backtrace: http://pastebin.com/Qb7XrXM2 The same for test-unit: http://pastebin.com/5wAG7mHS -- /Jacob Carlborg
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 23/09/12 22:40, Andrei Alexandrescu wrote:
I discussed this with Walter, and we concluded that we could deprecate
the comma operator if it helps tuples. So I started with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Unfortunately, I started much cockier than I ended. The analysis in
there fails to construct a case even half strong that deprecating the
comma operator could significantly help tuples. Well it essentially
concludes that tuples are mostly fine as they are, and attempts to
embellish them syntactically are marred with unexpected problems.
Nevertheless, I sure have missed aspects all over, so contributions are
appreciated.
Thanks,
Andrei
Regarding the comma operator: I'd love to deprecate it, but even if we
don't, could we at least ensure that this kind of rubbish doesn't compile:
void main()
{
int x;
x > 0, x += 5;
}
At present, because comma expressions are expressions, not statements,
the "x > 0" doesn't generate a "statement has no effect" error, despite
the fact that it is meaningless and gets completely discarded.
Re: Infer function template parameters
On Saturday, 22 September 2012 at 07:48:14 UTC, Simen Kjaeraas wrote: On 2012-09-21, 21:29, Jonas Drewsen wrote: A mentioned in the proposal (albeit not very clear) it requires non-templated function definitions to include both type and param names. If only one name is provided in a definition is always a param name. Unfortunately this is a breaking change for some code and that does speak against the proposal. Not only is it a breaking change, it breaks one of the basic design desiderata of D - if it's valid C it either fails to compile or compiles with the same behavior as in C. I guess it is not that basic of a desiderata after all :) http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19 -Jonas
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sunday, 23 September 2012 at 21:51:35 UTC, Nick Sabalausky
wrote:
Ok, here's a crazy idea:
Do the reasons for explicit tuple-expansion necessarily apply to
zero- and one-element tuples? I'm not so sure. Suppose we
allowed
implicit expansion on those...
Now I know what you're thinking: That would be an ugly
inconsistency
between tuples of sizes >1 vs <=1. Well, *mechanically* yes, but
consider this:
*Logically* speaking, is there really any difference between a
one-element tuple and an ordinary single value? I don't think
so, and
here's why: What is a tuple, logically speaking? Multiple
values being
handled as if they were a single value. So what's a one-element
tuple?
*One* value being handled as if it were one value - which is
*is*.
Similarly, a zero-element tuple is logically equivalent to void
(or the
one value a void can have: the value void, a concept which has
been
argued in the past that might be useful for D, particularly in
metaprogramming). (I admit this is a little weaker than my
argument
for one-element tuples.)
So perhaps zero- and one-element tuples should be implicitly
convertible back and forth with void and ordinary non-tuple
values,
respectively (polysemous values?), because that's what they
essentially
are.
That means (at least I think it means) that things like () or
(1) or
((1)) require no way to disambiguate between tuple and
expression,
because either way they're the same thing (or at least freely
convertible).
Nope.
One of the ways in math to "build" the positive numbers based on
set theory is via singletons:
n := |tuple of empty tuples|
so "1" is defined as { {} } whereas "0" is simply {}. That does
not work with the above suggestion. Now, I realize this is an
arguably convoluted math example but it does show that the
treating { {} } as {} is limiting the expressive power of tuples.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-24 07:01, Nick Sabalausky wrote: I think one of us is missing something, and I'm not entirely sure who. As I explained (perhaps poorly), the zero- and one-element tuples *would still be* tuples. They would just be implicitly convertible to non-tuple form *if* needed, and vice versa. Do you see a reason why that would *necessarily* not be the case? Would that mean you could start doing things like: int a = 3; int b = a[0]; That feels very weird. -- /Jacob Carlborg
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-23 22:40, Andrei Alexandrescu wrote: I discussed this with Walter, and we concluded that we could deprecate the comma operator if it helps tuples. So I started with this: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19 +1 -- /Jacob Carlborg
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-24 00:11, bearophile wrote: This is a complex topic, and in this post I am not able to discuss everything that needs to be discussed. So I will discuss only part of the story. First: tuples are important enough. I think they should be built-in in a modern language, but maybe having them as half-built-in will be enough in D. Currently in D we have (deprecated) built-in complex numbers that I use only once in a while, and half-usable library defined tuples that I use all the time. Second: removing comma operator from D has some advantages unrelated to tuple syntax. Even disallowing bad looking C-like code that uses commas is an improvement by itself (but maybe it's not a big enough improvement...). Third: replacing the packing syntax tuple(x,y) with (x,y) is nice and maybe even expected in a partially functional language as D, but that's _not_ going to improve D usability a lot. What I am asking for is different: I'd like D tuples to support handy unpacking syntax: 1) In function signatures; 2) In foreach; 3) At assignment points; 4) In switch cases. +1 -- /Jacob Carlborg
Re: Infer function template parameters
On Monday, September 24, 2012 10:37:04 Jonas Drewsen wrote: > On Saturday, 22 September 2012 at 07:48:14 UTC, Simen Kjaeraas > > wrote: > > On 2012-09-21, 21:29, Jonas Drewsen wrote: > >> A mentioned in the proposal (albeit not very clear) it > >> requires non-templated function definitions to include both > >> type and param names. If only one name is provided in a > >> definition is always a param name. Unfortunately this is a > >> breaking change for some code and that does speak against the > >> proposal. > > > > Not only is it a breaking change, it breaks one of the basic > > design > > desiderata of D - if it's valid C it either fails to compile or > > compiles > > with the same behavior as in C. > > I guess it is not that basic of a desiderata after all :) > > http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19 It has been broken upon rare occasion (e.g. static arrays are value types in D, not reference types like in C), but it's quite rare, and removing the comera operator doesn't necessarily break it. In fact, just removing the comma operator _definitely_ doesn't break it, because it just makes more C code invalid. The point is that C/C++ will compile as valid D code with the same semantics or that it won't compile, _not_ that C/C++ will compile as valid D code. The whole point is to avoid silent behavioral changes when porting C/C++ code to D. Now, that being said, if tuples are added to the language proper (which that DIP doesn't do), that may or may not make it so that C/C++ code will end up compiling with different semantics when ported. I'd have to study the situation much more closely to be sure, but I suspect that it wouldn't, precisely because the types involved change and C doesn't have auto in the same way that D does (or any kind of type inferrence at all really), so the change in type would cause compilation failure, thereby avoiding silent behavioral changes. - Jonathan M Davis
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 10:56:40 +0200
Jacob Carlborg wrote:
> On 2012-09-24 07:01, Nick Sabalausky wrote:
>
> > I think one of us is missing something, and I'm not entirely sure
> > who.
> >
> > As I explained (perhaps poorly), the zero- and one-element tuples
> > *would still be* tuples. They would just be implicitly convertible
> > to non-tuple form *if* needed, and vice versa. Do you see a reason
> > why that would *necessarily* not be the case?
>
> Would that mean you could start doing things like:
>
> int a = 3;
> int b = a[0];
>
> That feels very weird.
>
No, because there's nothing typed (int) involved there. But you could do
this:
int a = 3;
(int) b = a;
a = b;
Or this:
void foo((int) a)
{
int b1 = a[0];
int b2 = a;
}
int c = 3;
foo(c);
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 10:47:38 +0200
"foobar" wrote:
>
> Nope.
> One of the ways in math to "build" the positive numbers based on
> set theory is via singletons:
> n := |tuple of empty tuples|
> so "1" is defined as { {} } whereas "0" is simply {}. That does
> not work with the above suggestion. Now, I realize this is an
> arguably convoluted math example but it does show that the
> treating { {} } as {} is limiting the expressive power of tuples.
>
And int's are limiting compared to mathematical integers. So what?
So ok, maybe this is limiting from a theoretical standpoint. But
practically speaking? I dunno. We're not making tuples to emulate
set theory here, we're just looking for ad-hoc anonymous structs.
Besides, I only said they were logically the same thing, not
mechanically. I'm only suggesting that a one-element tuple be implicitly
convertible to/from the type of its element. So there would likely
still be the different types, it just makes sense that you should be
able to use one as the other.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 06:20:55 -0400
Nick Sabalausky wrote:
> On Mon, 24 Sep 2012 10:47:38 +0200
> "foobar" wrote:
> >
> > Nope.
> > One of the ways in math to "build" the positive numbers based on
> > set theory is via singletons:
> > n := |tuple of empty tuples|
> > so "1" is defined as { {} } whereas "0" is simply {}. That does
> > not work with the above suggestion. Now, I realize this is an
> > arguably convoluted math example but it does show that the
> > treating { {} } as {} is limiting the expressive power of tuples.
> >
>
> And int's are limiting compared to mathematical integers. So what?
> So ok, maybe this is limiting from a theoretical standpoint. But
> practically speaking? I dunno. We're not making tuples to emulate
> set theory here, we're just looking for ad-hoc anonymous structs.
>
> Besides, I only said they were logically the same thing, not
> mechanically. I'm only suggesting that a one-element tuple be
> implicitly convertible to/from the type of its element. So there
> would likely still be the different types, it just makes sense that
> you should be able to use one as the other.
>
I guess what I mean is: If you really need a strict separation between
a "tuple of one" and a non-tuple, then maybe it's an indication
that you're just using the wrong tool?
That said, I'm not necessarily opposed to the strict separation if we
had a good candidate for built-in tuple literal syntax. But *if* the
best we have is parens (and maybe there *is* something better?) then
maybe this would be an acceptable way to achieve it?
Ie:
// (3) is polysemous: Either int or (int)
int a = (3); // Normal value
(int) b = (3); // One-element tuple
auto c = (3); // Default to normal "int"?
void foo(int z) {}
void foo((int) z) {}
void takeInt(int z) {}
void takeTuple((int) z) {}
foo(a); // Calls first overload
foo(b); // Calls second overload
takeInt(a); // ok
takeInt(b); // ok
takeTuple(a); // ok
takeTuple(b); // ok
Re: A partial template application literal syntax
18.09.2012 1:56, bearophile пишет:
Denis Shelomovskij:
Just want to mention about existent (and more flexible than this
syntax) library solution.
Search for `Bind` here:
https://bitbucket.org/denis_sh/misc/src/tip/stdd/typetuple.d
Its ddocs show this:
import std.traits;
static assert(is(staticBind!(CommonType, long, allArgs).Res!int == long));
static assert(!staticBind!(isImplicitlyConvertible, arg!0, int).Res!long);
static assert( staticBind!(isImplicitlyConvertible, int ,
arg!0).Res!long);
alias staticBind!(staticMap, Unqual, allArgs).Res UnqualAll;
static assert(is(UnqualAll!(const(int), immutable(bool[])) T) &&
T.length == 2 && is(T[0] == int) && is(T[1] ==
immutable(bool)[]));
I have understood the meaning and usage of those "type lambdas" that use
? in Scala as soon I have seen them, while I don't get much from this
noisy stuff :-(
Bye,
bearophile
Yes, my library solution is rather ugly (but still doesn't know why it
isn't as obvious as Scala's one). Just added a clearer one (if somebody
needs this). Search for "Binds template arguments using format string."
(second `Bind` template) here (if you want):
https://bitbucket.org/denis_sh/misc/src/tip/stdd/typetuple.d
To conclude:
Your proposal:
alias Tuple!(int, ?, ?) T;
My first solution:
alias staticBind!(Tuple, int, arg!0, arg!1).Res T;
My second solution:
mixin Bind!q{ Tuple!(int, %0, %1) T };
From docs:
Binds template arguments using format string.
Example:
import std.traits;
mixin Bind!q{ CommonType!(long, %*) CommonTypeToLong };
static assert(is(CommonTypeToLong!int == long));
mixin Bind!q{ isImplicitlyConvertible!(%0, int)
isImplicitlyConvertibleToInt };
static assert(!isImplicitlyConvertibleToInt!long);
mixin Bind!q{ isImplicitlyConvertible!(int, %0)
isImplicitlyConvertibleFromInt };
static assert( isImplicitlyConvertibleFromInt!long);
mixin Bind!q{ staticMap!(Unqual, %*) UnqualAll };
static assert(is(UnqualAll!(const(int), immutable(bool[])) T) &&
T.length == 2 && is(T[0] == int) && is(T[1] ==
immutable(bool)[]));
--
Денис В. Шеломовский
Denis V. Shelomovskij
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-24 12:06, Nick Sabalausky wrote: No, because there's nothing typed (int) involved there. But you could do this: int a = 3; (int) b = a; a = b; But you said: "They would just be implicitly convertible to non-tuple form *if* needed, and vice versa." To me that sounds like a tuple of one element of the type int would be implicitly convertible to an int. And, an int would be implicitly convertible to a tuple of one element. -- /Jacob Carlborg
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 05:25 AM, Andrei Alexandrescu wrote: On 9/23/12 9:31 PM, deadalnix wrote: Le 24/09/2012 03:14, Andrei Alexandrescu a écrit : On 9/23/12 7:20 PM, Adam D. Ruppe wrote: On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote: I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet. Yeah, I thought it was already defined. Actually it's right to left for assignments. In expr1 = expr2, expr2 gets evaluated first. Andrei Is it by implementation or by design ? Currently probably neither :o). I used to oppose it, then I figured it's actually nice because of things like: int[int] stuff; stuff[42] = stuff.length; Andrei So you are arguing for computing the arguments for a method call before the receiver is computed? (What about UFCS?) Or should opAssign behave specially?
Re: References in D
On Sun, 16 Sep 2012 23:46:34 +0100, deadalnix wrote: Le 15/09/2012 19:13, Jonathan M Davis a écrit : On Saturday, September 15, 2012 15:24:27 Henning Pohl wrote: On Saturday, 15 September 2012 at 12:49:23 UTC, Russel Winder wrote: On Sat, 2012-09-15 at 14:44 +0200, Alex Rønne Petersen wrote: […] Anyway, it's too late to change it now. I disagree. There are always opportunities to make changes to things, you just have manage things carefully. I don't know if people really use the ability of references being null. If so, large amounts of code will be broken. Of course people use it. Having nullable types is _highly_ useful. It would suck if references were non-nullable. That would be _horrible_ IMHO. Having a means to have non-nullable references for cases where that makes sense isn't necessarily a bad thing, but null is a very useful construct, and I'd _hate_ to see normal class references be non-nullable. - Jonathan M Davis Years of java have proven me the exact opposite. Nullable is a usefull construct, but nullable by default is on the wrong side of the force. I think it depends on your background. Most of my experience has been with C and C++ and I agree with Jonathan that null is incredibly useful, and something I use a lot. In fact, I am often annoyed that 'int' doesn't have an equivalent value, and instead I have to invent a magic number and ensure it's never a possible valid value. What I've noticed looking at Java code written by others is that null as a possible state is ignored by the vast bulk of the code, which is completely the opposite when reviewing C/C++ code where null is checked for and handled where applicable. I think it's a mindset thing brought on by the language, or how it's taught, or something. It seems to me that Java would have benefited from non-null references :p My uses of null all seem to boil down to being able to represent something as being "not there yet" or "not specified" etc without having to resort to a magic value, or 2nd flag/boolean/parameter. I find null is a nice clean way to do this. As to whether it should be the default or not.. well, you might have a point there. I think I probably want to use null less than otherwise. But, all we need is a compiler which says "Oi, you haven't initialised this" forcing me to explicitly set it to null where desired, or a valid value and problem solved, right? That combined with a construct like NotNull!(T) which would assert in debug that the reference is not null and you can basically stop doing null checks in release code. Win win, right? R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: References in D
Regan Heath: In fact, I am often annoyed that 'int' doesn't have an equivalent value, and instead I have to invent a magic number and ensure it's never a possible valid value. Try to start using Nullable of Phobos: http://dlang.org/phobos/std_typecons.html#Nullable Bye, bearophile
Re: References in D
On Mon, 24 Sep 2012 13:30:29 +0100, bearophile wrote: Regan Heath: In fact, I am often annoyed that 'int' doesn't have an equivalent value, and instead I have to invent a magic number and ensure it's never a possible valid value. Try to start using Nullable of Phobos: http://dlang.org/phobos/std_typecons.html#Nullable In C? :p R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 24/09/2012 14:15, Jacob Carlborg a écrit : On 2012-09-24 12:06, Nick Sabalausky wrote: No, because there's nothing typed (int) involved there. But you could do this: int a = 3; (int) b = a; a = b; But you said: "They would just be implicitly convertible to non-tuple form *if* needed, and vice versa." To me that sounds like a tuple of one element of the type int would be implicitly convertible to an int. And, an int would be implicitly convertible to a tuple of one element. I understand your example, but in it, no (int) are involved. So no conversion have to be done (and you get an error). You see in example above that conversion is done when int is given where (int) is expected or vice versa, not whenever the compiler feels to.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
wrote:
> That said, I'm not necessarily opposed to the strict separation if we
> had a good candidate for built-in tuple literal syntax. But *if* the
> best we have is parens (and maybe there *is* something better?) then
> maybe this would be an acceptable way to achieve it?
If the problems in DIP 19 are deemed mostly syntactic (1- and 0-
element tuples), then maybe *for once* a simple syntax change could
solve them? I know syntax proposals are a dime a dozen in this
newsgroup, but why not here, to avoid the ((1)) problem?
For example choosing { 1, 2} to represent a tuple? { } blocks in D
enclose semi-colon terminated declarations or expressions, but here
it's enclosing comma-separated expressions. And, since { } is probably
dangerous without a completly integrated type systems giving a type to
all expressions ( (){} anyone?) , why not use (| 1, 2 |), or whatever
syntax strikes our collective fancy? (I propose *not* to use < , >)
Then, the compiler has to change the way it prints its internal tuple,
to follow the new syntax.
> Ie:
>
> // (3) is polysemous: Either int or (int)
> int a = (3); // Normal value
> (int) b = (3); // One-element tuple
> auto c = (3); // Default to normal "int"?
For the third case, I'd say it defaults to a tuple. But then again,
using another syntax solves this problem.
auto c = (| 3 |); // or c = { 3 };
Re: Neat: UFCS for integer dot operator suffix
On Mon, Sep 24, 2012 at 2:28 PM, bearophile wrote: > monarch_dodra: > > >> I tried this, and found it neat that it works: I used this in a small unit library (partially accessible on github), to obtain code like: auto distance = 100.km; auto speed = 130.km/h; // division works, too. auto timeToDestination = (distance/speed).hour; // distance/speed gives seconds => transformed in hours. It was a nice exercise in using UFCS and mixins to create your own unit library (not only IS, but ay kind of unit library). And, you know what? I *never* used it after coding it. These examples are cute, they make for nice blog posts for F#, but the real-world usage is dubious to me (I know they were space-programs crashes) I quite like the implicit message in units: use the type system to help you catch errors are compile-time. Add to that a nice syntax and a showcase for D's generational capabilities and it's quite nice. But, to my eyes, it's but a toy.
Re: 2.060 deb package on Linux Mint 13
On Sunday, 23 September 2012 at 18:38:01 UTC, Jordi Sayol wrote: first of all, upgrade your system Those are minor and green upgrades, not pertinent to dmd install. Why did you try to install 32-bit dmd deb package on a 64-bit system? Guess I missed that chapter in the owner's manual. I assumed amd was specific to amd architecture. Yay!, tribal knowledge! You MUST install "dmd_2.060-0_amd64.deb" on a 64-bit system, like yours. Yep, that worked just fine. Thanks for getting me through.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 8:18 AM, Timon Gehr wrote: On 09/24/2012 05:25 AM, Andrei Alexandrescu wrote: On 9/23/12 9:31 PM, deadalnix wrote: Le 24/09/2012 03:14, Andrei Alexandrescu a écrit : On 9/23/12 7:20 PM, Adam D. Ruppe wrote: On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote: I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet. Yeah, I thought it was already defined. Actually it's right to left for assignments. In expr1 = expr2, expr2 gets evaluated first. Andrei Is it by implementation or by design ? Currently probably neither :o). I used to oppose it, then I figured it's actually nice because of things like: int[int] stuff; stuff[42] = stuff.length; Andrei So you are arguing for computing the arguments for a method call before the receiver is computed? (What about UFCS?) Or should opAssign behave specially? Ha, good point about opAssign! Probably we should go with left-to-right everywhere, including in assignment. Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
The analysis in there fails to construct a case even half
strong that deprecating the comma operator could significantly
help tuples.
That is because it does not base the discussion on the right
limitations of built-in tuples:
auto (a,b) = (1,"3");
(auto a, string b) = (1, "3");
Agreed, this is the key thing missing from D.
There is also no consideration in the DIP of what I consider one
of D's most confusing "features": "pre-expanded tuples" or in
other words, type tuples. These beasts can be very confusing when
first encountered, and they do not behave like any data type in
any other language I know of:
import std.typecons; // Contains Tuple!(...), which reminds me,
// how do I know which module contains a given feature?
// http://dlang.org/phobos/index.html doesn't mention it.
void call() { humm(1, 2); }
void humm(T...)(T x) // x, a pre-expanded tuple
{
//auto c = [x.expand]; // ERROR, expand undefined
// (it's already expanded!)
auto a = x;// a is also pre-expanded
auto b = [ a, a ]; // int[], not Tuple!(int,int)[]
//int d = derr(x); // ERROR, have to un-expand it
writeln(a);// "12"
writeln(b);// "[1, 2, 1, 2]"
}
int derr(Tuple!(int,int) a) { return a[0] + a[1]; }
I know you guys are all used to this behavior but I'm telling
you, pre-expanding is very weird. It would be nice if type tuples
could somehow be unified with library tuples and behave like the
latter.
Re: [OT] Was: totally satisfied :D
On Fri, 21 Sep 2012 17:22:32 -0400, Nick Sabalausky wrote: On Fri, 21 Sep 2012 08:24:07 -0400 "Steven Schveighoffer" wrote: That works too, but doesn't warrant rants about how you haven't learned how to use the fucking thing :) It's *volume* controls, there doesn't need to be *anything* to learn. OK, so this is what you'd rather have: 1. Want to listen to music in the library on my headphones. But I have the silent switch on to prevent calls, and since there is only one volume, I have to turn it off, and turn up the volume. Then a phone call arrives, and I can't make that silent because it's all the same volume, bothers everyone else in the library. 2. Want my ringer as high as possible so I can hear it when a call arrives. But I start playing a game, and it BLASTS the initial music have to quicky turn down the volume. No, I think the current design, while not perfect, is *WAY* better than a single volume. I would rather actually have *more* granularity in volume. Doing it your way means everyone, not just you, needs to fiddle with the volume knob for every single thing they want to do. That may make you happy, but it would piss off the rest of the users :) 1. ringer volume affects all sounds except for music/video/games 2. Silent switch will ringer volume to 0 for all sounds except for find-my-iphone and alarm clock 3. If playing a game/video/music, the volume buttons affect that volume, otherwise, they affect ringer volume. Wow, you are right, three whole rules. And each one with exceptions, the rules as a whole aren't particularly intuitive. They aren't? They make complete sense to me. You even admit that it makes sense to have find my iphone play its alerts as loud as possible. I contend that if you use alarm clock what it is for, (i.e. waking you up) there is no problem there either. Those are the only exceptions. Besides, you don't have to "memorize" these rules, most of the time, it is what a normal person would expect. And then there's the question of what rules you forgot. I can think of one right now: 4. If you're in the camera app then the volume button takes a picture instead of adjusting volume. I admit, I completely forgot about this one. Simply because I rarely use it :) It was a gimmicky feature, and doesn't hurt anything, but I find it unusable, simply because my natural inclination, being a right-handed person, is to rotate the phone left to go into landscape mode, If I want to use the button, my sequence is to rotate left, then realize the button's on the other side, flip 180 degrees, then realize my finger is in front of the lens, etc. I think this is essentially an orthogonal problem because there is no volume control in camera, and that "feature" doesn't interfere with any other use of the phone. When I read about it though, I thought it was a good idea. Interestingly enough, Apple doesn't even *let* you use the volume control for anything but volume in your own apps. Doing it is clunky in any case, you have to take over the volume, disable anything that is playing, then make sure the volume is not at min/max. When you detect the "volume" goes up or down, take action, then reset the volume. Very lame. That's way more than 1. I stand corrected :) Now compare that to a normal device: 1. The volume control adjusts the volume. Gee, how horrible to have one trivially intuitive rule and no exceptions. Right, and now I'm stuck in "Nick mode", where I'm constantly worrying about and changing the volume to deal with the current situation. No thanks. Bottom line, they took something trivial, complicated it, and people hail them as genius visionaries. s/complicated/improved/ This isn't really genius, nor is it unprecedented (iPhone is not the first to control ringer and game/music volume separately). It's just common sense. > You might like Win7. It's very Mac-like out-of-the-box which is > exactly why I hate it ;) No, it's nowhere near the same level. I have Win 7, had it from the day of its release, and while it's WAY better than XP, Heh, yea I had a feeling. Like I said, Win7 is very Mac-like as far as windows goes. I find it interesting that while I absolutely can't stand Win7 (at least without *heavy* non-standard configuring and some hacks), Mac people OTOH tend to see it as a big improvement over XP. It's Microsoft OSX. I wasn't a mac user until november of last year. And even then I didn't start using it in earnest until February of this year, when my iOS side business picked up. I still used my Linux laptop for almost everything else, and my Win7 machine at home. I barely used the Mac, and that was just to run xcode. About 4 months ago, I had to start developing for an arm-based single-board-computer. The manufacturer provided a fully-configured VMWare Linux image. Only option for the MAC was to try/buy VMWare Fusion (VMWar
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 01:01:29 -0400, Nick Sabalausky
wrote:
On Sun, 23 Sep 2012 18:48:22 -0400
Andrei Alexandrescu wrote:
Once a one-element tuple becomes equivalent to the actual item,
there's an explosion of trouble and special cases in the language and
in code that uses it. For example, divide and conquer code that
manipulates tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would
suddenly get to cases in which the slices are no longer tuples, and
so on. And that's only the beginning.
I think one of us is missing something, and I'm not entirely sure
who.
As I explained (perhaps poorly), the zero- and one-element tuples *would
still be* tuples. They would just be implicitly convertible to
non-tuple form *if* needed, and vice versa. Do you see a reason why
that would *necessarily* not be the case?
(int[]) x;
int a = x.length;
is a == 0 or 1?
I agree with Andrei, we need something different.
I don't profess to be even close to an expert on tuples, but I feel they
should be built-in to the language, since they are actually language
constructs that we are declaring types for.
Without any research or investigation, what about using a different set of
delimiters for tuples? Like {1,2,3}
Right now, I think that is reserved for static struct initializers. But
can't those be considered a tuple also? Someone will probably destroy
this 10 milliseconds after I send it :)
-Steve
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Monday, 24 September 2012 at 10:05:18 UTC, Nick Sabalausky
wrote:
On Mon, 24 Sep 2012 10:56:40 +0200
Jacob Carlborg wrote:
On 2012-09-24 07:01, Nick Sabalausky wrote:
> I think one of us is missing something, and I'm not entirely
> sure
> who.
>
> As I explained (perhaps poorly), the zero- and one-element
> tuples
> *would still be* tuples. They would just be implicitly
> convertible
> to non-tuple form *if* needed, and vice versa. Do you see a
> reason
> why that would *necessarily* not be the case?
Would that mean you could start doing things like:
int a = 3;
int b = a[0];
That feels very weird.
No, because there's nothing typed (int) involved there. But you
could do
this:
int a = 3;
(int) b = a;
a = b;
Or this:
void foo((int) a)
{
int b1 = a[0];
int b2 = a;
}
int c = 3;
foo(c);
What's the point than?
here's equivalent code without this "feature":
int a = 3;
(int) b = (a); // explicitly make 1-tuple
(a) = b; // unpacking syntax
void foo((int) a) {
int b1 = a[0];
(int b2) = a; // one possible syntax
}
int c = 3;
foo ((c));
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Monday, 24 September 2012 at 10:20:01 UTC, Nick Sabalausky
wrote:
On Mon, 24 Sep 2012 10:47:38 +0200
"foobar" wrote:
Nope.
One of the ways in math to "build" the positive numbers based
on set theory is via singletons:
n := |tuple of empty tuples|
so "1" is defined as { {} } whereas "0" is simply {}. That
does not work with the above suggestion. Now, I realize this
is an arguably convoluted math example but it does show that
the treating { {} } as {} is limiting the expressive power of
tuples.
And int's are limiting compared to mathematical integers. So
what?
So ok, maybe this is limiting from a theoretical standpoint. But
practically speaking? I dunno. We're not making tuples to
emulate
set theory here, we're just looking for ad-hoc anonymous
structs.
Besides, I only said they were logically the same thing, not
mechanically. I'm only suggesting that a one-element tuple be
implicitly
convertible to/from the type of its element. So there would
likely
still be the different types, it just makes sense that you
should be
able to use one as the other.
I'm a bit confused about what is specifically proposed here:
- Is the suggestion to limit tuples to >1 elements? *This* I'm
against for practical as well as completeness reasons. Andrei
already provided one example, and another would be a proper unit
type. e.g.
void foo(int a) {}
void bar (int b) { return foo(b); }
- Is the suggestion to allow implicit conversion between (T) and
T?
This brings almost no benefit - (you save two keystrokes?) and
adds a special case to the language. The added complexity really
does not justify this.
Re: Neat: UFCS for integer dot operator suffix
Philippe Sigaud: But, to my eyes, it's but a toy. There are features (like tuples) that I use all the time in other languages (and in D too), so I know they are useful for me. I have not used units in normal languages (only a little in Frink: http://futureboy.us/frinkdocs/ ), so I don't know for sure they are useful for me :-) On the other hand both in D and other languages I feel the need for strongly typing single values (like typedef in D1). For me telling apart differently typed double values or array types is handy for documentation and improve code readability (and for this a D alias is enough), and the type system enforcement makes me more relaxed while I write code, because I know the compiler catches more mistakes. Bye, bearophile
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 1:01 AM, Nick Sabalausky wrote: On Sun, 23 Sep 2012 18:48:22 -0400 Andrei Alexandrescu wrote: Once a one-element tuple becomes equivalent to the actual item, there's an explosion of trouble and special cases in the language and in code that uses it. For example, divide and conquer code that manipulates tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would suddenly get to cases in which the slices are no longer tuples, and so on. And that's only the beginning. I think one of us is missing something, and I'm not entirely sure who. As I explained (perhaps poorly), the zero- and one-element tuples *would still be* tuples. They would just be implicitly convertible to non-tuple form *if* needed, and vice versa. Do you see a reason why that would *necessarily* not be the case? It just creates endless little problems and confusion coming outta the woodwork, as others have pointed out in response to this. There are languages that have also explored a similar approach - a value can be automatically converted to a one-element array and vice versa. It's problematic, especially in a language with generics and function overloading. I think it's safe to just not even discuss it. A nice way to put it :/ Part politician perhaps? ;) I meant it in a simple and forward way - all I want is to save time and trouble in exploring a no-win design. From sheer experience gathered from years at hacking at this stuff I know this can be done but is not worth the trouble. Since it can be done, there's no argument that would definitively close the discussion, and that demotivates me from coming up with explanations. Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 4:17 AM, Don Clugston wrote:
Regarding the comma operator: I'd love to deprecate it, but even if we
don't, could we at least ensure that this kind of rubbish doesn't compile:
void main()
{
int x;
x > 0, x += 5;
}
At present, because comma expressions are expressions, not statements,
the "x > 0" doesn't generate a "statement has no effect" error, despite
the fact that it is meaningless and gets completely discarded.
Interesting. The comma operator is probably the only one in which an
expression is evaluated only for the sake of its side effects. So
eliminating the comma operator would just get rid of that case by design.
Of course, there's always the option of adding more checks or rewriting
the comma operator from "expr1, expr2, expr3" to "{ expr1; expr2; return
expr3; }()".
Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Monday, 24 September 2012 at 14:52:21 UTC, Steven
Schveighoffer wrote:
(int[]) x;
int a = x.length;
is a == 0 or 1?
I agree with Andrei, we need something different.
This is exactly the question I was going to ask ...
I don't profess to be even close to an expert on tuples, but I
feel they should be built-in to the language, since they are
actually language constructs that we are declaring types for.
Without any research or investigation, what about using a
different set of delimiters for tuples? Like {1,2,3}
... and exactly the syntax I was going to propose! {} is already
used in C languages for heterogeneous data
structures(structs/classes, JSON etc). Using () creates too many
special cases, especially in generic programming and seeing how
other languages are dealing with them we'd rather avoid them from
the very beginning.
Right now, I think that is reserved for static struct
initializers. But can't those be considered a tuple also?
Someone will probably destroy this 10 milliseconds after I send
it :)
-Steve
It would be awesome if we could make tuples generic initializers
for various data types in D. Not just structs but for instance
arrays:
int[] a = {1, 2, 3, 4};
Compiler possesses enough type information to know that this
tuple could be converted to the int[].
P.S. The only collision I see with {} is a delegate literal, but
to be honest it's not worth the merit and quite confusing in
fact. There are 3 other ways to define a delegate in D which will
cover all of the user's needs.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 9:27 AM, Philippe Sigaud wrote:
On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
wrote:
That said, I'm not necessarily opposed to the strict separation if we
had a good candidate for built-in tuple literal syntax. But *if* the
best we have is parens (and maybe there *is* something better?) then
maybe this would be an acceptable way to achieve it?
If the problems in DIP 19 are deemed mostly syntactic (1- and 0-
element tuples), then maybe *for once* a simple syntax change could
solve them? I know syntax proposals are a dime a dozen in this
newsgroup, but why not here, to avoid the ((1)) problem?
For example choosing { 1, 2} to represent a tuple? { } blocks in D
enclose semi-colon terminated declarations or expressions, but here
it's enclosing comma-separated expressions. And, since { } is probably
dangerous without a completly integrated type systems giving a type to
all expressions ( (){} anyone?) , why not use (| 1, 2 |), or whatever
syntax strikes our collective fancy? (I propose *not* to use< ,>)
Then, the compiler has to change the way it prints its internal tuple,
to follow the new syntax.
Ie:
// (3) is polysemous: Either int or (int)
int a = (3); // Normal value
(int) b = (3); // One-element tuple
auto c = (3); // Default to normal "int"?
For the third case, I'd say it defaults to a tuple. But then again,
using another syntax solves this problem.
auto c = (| 3 |); // or c = { 3 };
I think my main problem with this is that I'm perfectly happy with the
baseline, which has "tuple(" as the left delimiter and ")" as the right
delimiter. I'd be more excited to invent notation if there was
overwhelming or at least considerable evidence that the notation
considerably helps certain use cases, or is very frequent. As things
are, I'd be quite "meh" about suddenly adding lenses.
Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:
On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer wrote:
Without any research or investigation, what about using a different
set of delimiters for tuples? Like {1,2,3}
and exactly the syntax I was going to propose!
Assume you had this syntax working today. So instead of writing
"tuple(a. b. c)" you write "{ a, b, c }". To what extent would your code
be better? (Honest question. Don't forget that adding the => syntax for
lambda /did/ make for better code.)
Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 11:29 AM, Andrei Alexandrescu wrote:
On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:
On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer wrote:
Without any research or investigation, what about using a different
set of delimiters for tuples? Like {1,2,3}
and exactly the syntax I was going to propose!
Assume you had this syntax working today. So instead of writing
"tuple(a. b. c)" you write "{ a, b, c }". To what extent would your code
be better? (Honest question. Don't forget that adding the => syntax for
lambda /did/ make for better code.)
Andrei
Hrm, I meant "tuple(a, b, c)".
Andrei
Re: Neat: UFCS for integer dot operator suffix
On 9/24/12 9:36 AM, Philippe Sigaud wrote: On Mon, Sep 24, 2012 at 2:28 PM, bearophile wrote: monarch_dodra: I tried this, and found it neat that it works: I used this in a small unit library (partially accessible on github), to obtain code like: auto distance = 100.km; auto speed = 130.km/h; // division works, too. auto timeToDestination = (distance/speed).hour; // distance/speed gives seconds => transformed in hours. It was a nice exercise in using UFCS and mixins to create your own unit library (not only IS, but ay kind of unit library). And, you know what? I *never* used it after coding it. These examples are cute, they make for nice blog posts for F#, but the real-world usage is dubious to me (I know they were space-programs crashes) I quite like the implicit message in units: use the type system to help you catch errors are compile-time. Add to that a nice syntax and a showcase for D's generational capabilities and it's quite nice. But, to my eyes, it's but a toy. I wouldn't read too much into it. You're a library author, not (I assume) a scientific computing guy. So beyond playing with a few examples, your work on this library is done - you wouldn't be a client of it for the simple reason you don't intensively work with kilometers, speeds, dollars, and such. It's possible that a good and usable library of units could add value to a category of users. Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Monday, September 24, 2012 16:00:06 David Piepgrass wrote: > There is also no consideration in the DIP of what I consider one > of D's most confusing "features": "pre-expanded tuples" or in > other words, type tuples. That's a completely separate issue. The DIP doesn't even introduce normal tuples into the language. It merely proposes that the comma operator be deprecated and uses the _possibility_ of introducing tuples into the language as an argument for that deprecation. - Jonathan M Davis
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 11:29:53 -0400, Andrei Alexandrescu
wrote:
On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:
On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer
wrote:
Without any research or investigation, what about using a different
set of delimiters for tuples? Like {1,2,3}
and exactly the syntax I was going to propose!
Assume you had this syntax working today. So instead of writing
"tuple(a. b. c)" you write "{ a, b, c }". To what extent would your code
be better? (Honest question. Don't forget that adding the => syntax for
lambda /did/ make for better code.)
I can't honestly say I've used either tuple(a, b, c), or tuples in other
languages very much.
I can say that I have *avoided* tuples as return values because I don't
want to type Tuple!(x, y) as the return type. But I haven't come across
that need very much. You can say "yeah, but what about auto?" Cases I'm
referring to were to make interface declarations -- can't use auto.
I can similarly say I have never had need to type x, b (i.e. use the
current comma operator), except in for statements.
I'd be fine with getting rid of comma operator and not doing tuples in the
language, but it certainly feels weird that we have a tuple type in the
language, without any formal type unless you alias it (as std.tuple does).
It's almost like instead of saying:
int[] x;
you had to do:
typeof([1,2]) x;
Yeah, with alias, we could arrive at:
Array!int x;
But really, it seems odd that the language has a type for something that
doesn't have a name/syntax. Odd, but not unworkable.
I just wanted to point out that it seems the largest trouble,
implementation-wise, for DIP19 is the choice of parentheses to denote a
tuple. If we do want to add built-in tuples, maybe we should be looking
at a different delimiter.
-Steve
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 11:47:09 -0400, Steven Schveighoffer
wrote:
I can say that I have *avoided* tuples as return values because I don't
want to type Tuple!(x, y) as the return type. But I haven't come across
that need very much. You can say "yeah, but what about auto?" Cases
I'm referring to were to make interface declarations -- can't use auto.
To further this, I would love to see something where "quick POD structs"
can be constructed using some builtin syntax.
For example:
{valid:bool, value:int}
which would be equivalent to Tuple!(bool, "valid", int, "value")
I would *definitely* like to see that. This might be on par with the =>
addition.
-Steve
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, Sep 24, 2012 at 5:24 PM, Andrei Alexandrescu
wrote:
>
> I think my main problem with this is that I'm perfectly happy with the
> baseline, which has "tuple(" as the left delimiter and ")" as the right
> delimiter.
I found it a bit long compared to other languages in the beginning,
but I've been using them heavily since you added them to Phobos and
I'm now quite happy with them. I even like the .expand thingy.
(I have a few nitpicks, about std.typecons.tuple, but those would be
the subject of another thread)
> I'd be more excited to invent notation if there was overwhelming
> or at least considerable evidence that the notation considerably helps
> certain use cases, or is very frequent. As things are, I'd be quite "meh"
> about suddenly adding lenses.
OK.
One standard use for tuples is assignment:
a,b = someTuple; // a and b already exist in this scope
auto (c,d) = someTuple; // creates c and d
and similar variations, which Phobos' tuples do not provide.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
If tuples are ever introduced, I hope parentheses will not be used. I would prefer something like this: tuple<2,1,8>
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Caligo: If tuples are ever introduced, I hope parentheses will not be used. I would prefer something like this: tuple<2,1,8> That both breaks code, doesn't improve the syntax, but makes it worse. Bye, bearophile
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 11:47 AM, Steven Schveighoffer wrote:
On Mon, 24 Sep 2012 11:29:53 -0400, Andrei Alexandrescu
wrote:
On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:
On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer
wrote:
Without any research or investigation, what about using a different
set of delimiters for tuples? Like {1,2,3}
and exactly the syntax I was going to propose!
Assume you had this syntax working today. So instead of writing
"tuple(a. b. c)" you write "{ a, b, c }". To what extent would your
code be better? (Honest question. Don't forget that adding the =>
syntax for lambda /did/ make for better code.)
I can't honestly say I've used either tuple(a, b, c), or tuples in other
languages very much.
I can say that I have *avoided* tuples as return values because I don't
want to type Tuple!(x, y) as the return type. But I haven't come across
that need very much. You can say "yeah, but what about auto?" Cases I'm
referring to were to make interface declarations -- can't use auto.
Yah, after writing DIP19 I was like, "creating tuples is nice and easy,
but expressing function returns is less so". Besides, the comma operator
does not hurt the syntax for types all that much.
I just wanted to point out that it seems the largest trouble,
implementation-wise, for DIP19 is the choice of parentheses to denote a
tuple. If we do want to add built-in tuples, maybe we should be looking
at a different delimiter.
Indeed. The question is what mileage we get out of it.
Andrei
Re: 2.060 deb package on Linux Mint 13
On Monday, 24 September 2012 at 13:48:57 UTC, Jason Spencer wrote: Why did you try to install 32-bit dmd deb package on a 64-bit system? Guess I missed that chapter in the owner's manual. I assumed amd was specific to amd architecture. Yay!, tribal knowledge! All x86-64(is that even proper?) bit processors use the AMD 64bit architecture. AMD won so they get the name (at least that is what team Debian decided).
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sunday, September 23, 2012 16:40:34 Andrei Alexandrescu wrote: > http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19 My #1 concern here is that for loops do _not_ ever change how they function with regards to commas (which the DIP seems to do, but it also seems to imply that we might want to get rid of that later - which I do _not_ agree with). The comma operator is occasionally useful beyond for loops, but it's usually considered bad practice to do so, so if we want to get rid of it aside from for loops, then I have no problem with that. If anything, I'd argue that bringing tuples into the mix is muddying matters, since I think that there's a solid argument for deprecating the comma operator based solely on the problems that it causes even if we never add any other syntax which uses commas in a way that the comma operator prevents. As to whether we add tuples or not, I don't know. Being able to do something like. int i; string s; (i, s) = foo(); or (auto i, string is) = foo(); would be useful, but I can live without it. std.typecons.tuple takes care of most of what you need from tuples IMHO. So, if we can find a way to cleanly add tuples to the language, I'm fine with that, but I'm also fine with leaving tuples as they are. - Jonathan M Davis
Re: 2.060 deb package on Linux Mint 13
On Mon, 24 Sep 2012 08:49:48 -0500, Jason Spencer wrote: On Sunday, 23 September 2012 at 18:38:01 UTC, Jordi Sayol wrote: first of all, upgrade your system Those are minor and green upgrades, not pertinent to dmd install. Why did you try to install 32-bit dmd deb package on a 64-bit system? Guess I missed that chapter in the owner's manual. I assumed amd was specific to amd architecture. Yay!, tribal knowledge! Quick, which architecture is your computer running!? amd64, armel, kfreebsd-i386, kfreebsd-amd64, i386, ia64, mips, mipsel, powerpc, sparc Took me 30 minutes the first time I decided to try debian to figure it out... Mostly because I kept associating amd64 with AMD and ia64 with INTEL. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Infer function template parameters
On Monday, 24 September 2012 at 10:05:49 UTC, Jonathan M Davis
wrote:
On Monday, September 24, 2012 10:37:04 Jonas Drewsen wrote:
On Saturday, 22 September 2012 at 07:48:14 UTC, Simen Kjaeraas
wrote:
> On 2012-09-21, 21:29, Jonas Drewsen wrote:
>> A mentioned in the proposal (albeit not very clear) it
>> requires non-templated function definitions to include both
>> type and param names. If only one name is provided in a
>> definition is always a param name. Unfortunately this is a
>> breaking change for some code and that does speak against
>> the
>> proposal.
>
> Not only is it a breaking change, it breaks one of the basic
> design
> desiderata of D - if it's valid C it either fails to compile
> or
> compiles
> with the same behavior as in C.
I guess it is not that basic of a desiderata after all :)
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
It has been broken upon rare occasion (e.g. static arrays are
value types in
D, not reference types like in C), but it's quite rare, and
removing the
comera operator doesn't necessarily break it. In fact, just
removing the comma
operator _definitely_ doesn't break it, because it just makes
more C code
invalid. The point is that C/C++ will compile as valid D code
with the same
semantics or that it won't compile, _not_ that C/C++ will
compile as valid D
code. The whole point is to avoid silent behavioral changes
when porting C/C++
code to D.
Now, that being said, if tuples are added to the language
proper (which that
DIP doesn't do), that may or may not make it so that C/C++ code
will end up
compiling with different semantics when ported. I'd have to
study the situation
much more closely to be sure, but I suspect that it wouldn't,
precisely
because the types involved change and C doesn't have auto in
the same way that
D does (or any kind of type inferrence at all really), so the
change in type
would cause compilation failure, thereby avoiding silent
behavioral changes.
- Jonathan M Davis
What about:
int fun() {
return (0, "abc")[0];
}
in the comma operator case it would return 'a' as an int.
in the tuple case it would return 0
/Jonas
Re: Infer function template parameters
On Monday, September 24, 2012 19:18:09 Jonas Drewsen wrote:
> What about:
>
> int fun() {
> return (0, "abc")[0];
> }
>
> in the comma operator case it would return 'a' as an int.
> in the tuple case it would return 0
Like I said, I'd have to examine the situation more closely to be certain that
there are no places where C code would compile but change semantics. It looks
like you found one. That may or may not be enough to make it so that tuples
wouldn't be done that way. On rare occasions, C compatability has been broken
in this regard, but it's very rare. So, it's a very strong rule, but it's not
unbreakable.
Also, it's already been suggested in the thread on DIP 19 that we just give
different syntax to tuples to fix the problem. And it's not at all clear that
there's agreement that adding tuples to the language buys enough to make it
worth it anyway. So, who knows what will happen.
- Jonathan M Davis
Re: Neat: UFCS for integer dot operator suffix
I used this in a small unit library (partially accessible on
github),
to obtain code like:
auto distance = 100.km;
auto speed = 130.km/h; // division works, too.
auto timeToDestination = (distance/speed).hour; //
distance/speed
gives seconds => transformed in hours.
It was a nice exercise in using UFCS and mixins to create your
own
unit library (not only IS, but ay kind of unit library).
And, you know what? I *never* used it after coding it. These
examples
are cute, they make for nice blog posts for F#, but the
real-world
usage is dubious to me (I know they were space-programs
crashes)
I quite like the implicit message in units: use the type
system to
help you catch errors are compile-time. Add to that a nice
syntax and
a showcase for D's generational capabilities and it's quite
nice.
But, to my eyes, it's but a toy.
I wouldn't read too much into it. You're a library author, not
(I assume) a scientific computing guy. So beyond playing with a
few examples, your work on this library is done - you wouldn't
be a client of it for the simple reason you don't intensively
work with kilometers, speeds, dollars, and such. It's possible
that a good and usable library of units could add value to a
category of users.
IMO, you don't need to be a scientific computing guy to find unit
checking useful, since almost any number conceptually has a unit
on it. I would ask any programmer, how often do you accidentally
use a measurement of 'bytes' where 'dwords' were expected, or use
a variable as an array index when it was actually something
totally different?
However, unit checking cannot be done satisfactorially in a
library; it has two main problems when provided that way:
1. It's too bulky (too much syntax required, as units have to be
spelled out constantly)
2. Values with traditionally-typed units don't interoperate with
existing libraries, including very simple functions such as
int abs(int x) { return x > 0 ? x : -x; }
int square(int x) { return x*x; }
You can define an inplicit conversion from e.g. 'Unit!"pixels"'
to 'int' but then you'll need to manually cast it back, and the
compiler can't check your cast to make sure it's correct.
IMO, solving these two problems requires a parallel type system
to infer unit relationships automatically, either with direct
language support, or a separate analysis tool that uses the
compiler as a service (currently not possible with D).
Re: 2.060 deb package on Linux Mint 13
On Monday, 24 September 2012 at 17:14:25 UTC, 1100110 wrote: On Mon, 24 Sep 2012 08:49:48 -0500, Jason Spencer wrote: On Sunday, 23 September 2012 at 18:38:01 UTC, Jordi Sayol wrote: first of all, upgrade your system Those are minor and green upgrades, not pertinent to dmd install. Why did you try to install 32-bit dmd deb package on a 64-bit system? Guess I missed that chapter in the owner's manual. I assumed amd was specific to amd architecture. Yay!, tribal knowledge! Quick, which architecture is your computer running!? amd64, armel, kfreebsd-i386, kfreebsd-amd64, i386, ia64, mips, mipsel, powerpc, sparc Took me 30 minutes the first time I decided to try debian to figure it out... Mostly because I kept associating amd64 with AMD and ia64 with INTEL. For future reference: dkpg --print-architecture ...will confirm the architecture that dpkg expects on your system. Best, Graham
Re: Neat: UFCS for integer dot operator suffix
On Monday, 24 September 2012 at 17:47:33 UTC, David Piepgrass
wrote:
However, unit checking cannot be done satisfactorially in a
library; it has two main problems when provided that way:
1. It's too bulky (too much syntax required, as units have to
be spelled out constantly)
2. Values with traditionally-typed units don't interoperate
with existing libraries, including very simple functions such as
int abs(int x) { return x > 0 ? x : -x; }
int square(int x) { return x*x; }
You can define an inplicit conversion from e.g. 'Unit!"pixels"'
to 'int' but then you'll need to manually cast it back, and the
compiler can't check your cast to make sure it's correct.
IMO, solving these two problems requires a parallel type system
to infer unit relationships automatically, either with direct
language support, or a separate analysis tool that uses the
compiler as a service (currently not possible with D).
+1
You can partially solve the function arg/return value problem by
making those functions templates but:
(a) This doesn't help you with existing functions (e.g. trig
function in std.math)
(b) It stops those functions from being virtual.
(c) Generally makes the functions more difficult to work with (no
common type, horrible compilation errors)
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-24 15:05, deadalnix wrote: I understand your example, but in it, no (int) are involved. So no conversion have to be done (and you get an error). What has that to do with anything. Example: auto a = 3; There's no mention of "int" in that example, yet "a" is still an int. You see in example above that conversion is done when int is given where (int) is expected or vice versa, not whenever the compiler feels to. int b = 4; b[0] Why isn't that an example of where a (int) is expected? I'm no expert on how the compiler does semantic analyze but if it sees something like "b[0]" then it thinks: it's either an array, a pointer, an associate array, opAssign or now a tuple. Then it thinks: hey an int is implicitly convertible to a one element tuple, I do that. -- /Jacob Carlborg
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-24 17:24, Andrei Alexandrescu wrote:
I think my main problem with this is that I'm perfectly happy with the
baseline, which has "tuple(" as the left delimiter and ")" as the right
delimiter. I'd be more excited to invent notation if there was
overwhelming or at least considerable evidence that the notation
considerably helps certain use cases, or is very frequent. As things
are, I'd be quite "meh" about suddenly adding lenses.
Declaring a tuple is still quire verbose can could really benefit from a
shorter syntax.
(int, int) foo ();
Vs
import std.typecons;
Tuple!(int, int) foo (); // or what the correct syntax is
--
/Jacob Carlborg
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
foo(<11,2,8>, a, b) vs foo((11,2,8), a, b) Parentheses are everywhere in D. Sometimes it looks like Lisp. On Mon, Sep 24, 2012 at 11:37 AM, bearophile wrote: > > That both breaks code, doesn't improve the syntax, but makes it worse. > > Bye, > bearophile
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sunday, 23 September 2012 at 21:51:35 UTC, Nick Sabalausky wrote: *Logically* speaking, is there really any difference between a one-element tuple and an ordinary single value? I don't think so, and here's why: What is a tuple, logically speaking? Multiple values being handled as if they were a single value. So what's a one-element tuple? *One* value being handled as if it were one value - which is *is*. Similarly, a zero-element tuple is logically equivalent to void (or the one value a void can have: the value void, a concept which has been argued in the past that might be useful for D, particularly in metaprogramming). (I admit this is a little weaker than my argument for one-element tuples.) So perhaps zero- and one-element tuples should be implicitly convertible back and forth with void and ordinary non-tuple values, respectively (polysemous values?), because that's what they essentially are. It's informative to look a bit at the Ocaml language: - no distinction between 1-tuple and single value: # 1;; - : int = 1 # (1);; - : int = 1 - "void" type is called unit and its notation is the empty tuple: # ();; - : unit = () - for some reason tuples can't be indexed in Ocaml
Re: References in D
On Mon, 24 Sep 2012 14:38:56 +0200, Regan Heath wrote: On Mon, 24 Sep 2012 13:30:29 +0100, bearophile wrote: Regan Heath: In fact, I am often annoyed that 'int' doesn't have an equivalent value, and instead I have to invent a magic number and ensure it's never a possible valid value. Try to start using Nullable of Phobos: http://dlang.org/phobos/std_typecons.html#Nullable In C? :p Worth a try. :p -- Simen
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 21:16:06 +0200 Jacob Carlborg wrote: > On 2012-09-24 15:05, deadalnix wrote: > > > I understand your example, but in it, no (int) are involved. So no > > conversion have to be done (and you get an error). > > What has that to do with anything. Example: > > auto a = 3; > > There's no mention of "int" in that example, yet "a" is still an int. > Of course there is, it's the default type for the literal you have there. > > You see in example above that conversion is done when int is given > > where (int) is expected or vice versa, not whenever the compiler > > feels to. > > int b = 4; > b[0] > > Why isn't that an example of where a (int) is expected? Because 'b' is neither being assigned to an (int) nor passed into a template/func parameter that's expecting an (int).
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 16:50:47 +0200
"foobar" wrote:
> On Monday, 24 September 2012 at 10:05:18 UTC, Nick Sabalausky
> wrote:
> > On Mon, 24 Sep 2012 10:56:40 +0200
> > Jacob Carlborg wrote:
> >
> >> On 2012-09-24 07:01, Nick Sabalausky wrote:
> >>
> >> > I think one of us is missing something, and I'm not entirely
> >> > sure
> >> > who.
> >> >
> >> > As I explained (perhaps poorly), the zero- and one-element
> >> > tuples
> >> > *would still be* tuples. They would just be implicitly
> >> > convertible
> >> > to non-tuple form *if* needed, and vice versa. Do you see a
> >> > reason
> >> > why that would *necessarily* not be the case?
> >>
> >> Would that mean you could start doing things like:
> >>
> >> int a = 3;
> >> int b = a[0];
> >>
> >> That feels very weird.
> >>
> >
> > No, because there's nothing typed (int) involved there. But you
> > could do
> > this:
> >
> > int a = 3;
> > (int) b = a;
> > a = b;
> >
> > Or this:
> >
> > void foo((int) a)
> > {
> > int b1 = a[0];
> > int b2 = a;
> > }
> > int c = 3;
> > foo(c);
>
> What's the point than?
> here's equivalent code without this "feature":
>
> int a = 3;
> (int) b = (a); // explicitly make 1-tuple
My understanding is that *can't* be made to work in the general
case (without those ugly trailing commas) because, in general, how's the
compiler supposed to know if (a) is a parenthesis expression or a tuple
literal?
That's exactly what my suggestion was attempting to solve: The '(a)'
would be a paren expression (with type 'int') just as right now, but
then in order to make it still assignable to '(int)', just as you've
done, we say "Ok, you can assign an 'int' to an '(int)' and it
implicitly converts."
All the stuff I said earlier about one-element tuples being
conceptually the same as non-tuples was just my way of explaining that
it's not too much of an unintuitive inconsistency if we allow implicit
packing/unpacking of one-element tuples, but not two-or-more-element
tuples.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 15:27:19 +0200
Philippe Sigaud wrote:
> On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
> wrote:
>
> > That said, I'm not necessarily opposed to the strict separation if
> > we had a good candidate for built-in tuple literal syntax. But *if*
> > the best we have is parens (and maybe there *is* something better?)
> > then maybe this would be an acceptable way to achieve it?
>
> If the problems in DIP 19 are deemed mostly syntactic (1- and 0-
> element tuples), then maybe *for once* a simple syntax change could
> solve them? I know syntax proposals are a dime a dozen in this
> newsgroup, but why not here, to avoid the ((1)) problem?
>
I'm all for that. In fact, I was was just about to post the same
suggestion.
My bikeshed is colored one of these:
(:1,2)
(|1,2)
Minimal syntax (one extra character), no ambiguities with anything
else AFAIK. Looks kinda funny, but so did !() at first and we all got
used to that.
> For example choosing { 1, 2} to represent a tuple?
I like it, but what about zero-element tuples vs empty code blocks?
(Or is it ok because code blocks can't be used inside, or as,
expressions?)
Also, it may be too easy to accidentally get mixups between one-element
tuples and certain one-statement blocks:
{ foo(); } // Block
vs
{ foo() } // Either a tuple or a forgotten semicolon
Not sure if that's a big enough deal, though.
> > Ie:
> >
> > // (3) is polysemous: Either int or (int)
> > int a = (3); // Normal value
> > (int) b = (3); // One-element tuple
> > auto c = (3); // Default to normal "int"?
>
> For the third case, I'd say it defaults to a tuple. But then again,
> using another syntax solves this problem.
>
My reasoning for defaulting to non-tuple was minimizing code breakage
and simplifying the handling of general expresssions that happen to
involve parens (ie, it's always a mere expression until it gets
assigned/passed-in to a tuple). But I agree, just using a syntax that's
unambiguous from the start is better.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 10:53:14 -0400 "Steven Schveighoffer" wrote: > > (int[]) x; > > int a = x.length; > > is a == 0 or 1? > It'd be 1, but I agree that's a pretty solid counter-argument.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 12:51:18 -0400 Andrei Alexandrescu wrote: > On 9/24/12 11:47 AM, Steven Schveighoffer wrote: > > I just wanted to point out that it seems the largest trouble, > > implementation-wise, for DIP19 is the choice of parentheses to > > denote a tuple. If we do want to add built-in tuples, maybe we > > should be looking at a different delimiter. > > Indeed. The question is what mileage we get out of it. > Since the issues with current tuples tend to discourage their use (at least for me anyway), it's hard to say without having them. Maybe it would help to look at languages that do have good tuples and see what kind of mileage they get out of them?
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 11:22 PM, Nick Sabalausky wrote:
On Mon, 24 Sep 2012 15:27:19 +0200
Philippe Sigaud wrote:
On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
wrote:
That said, I'm not necessarily opposed to the strict separation if
we had a good candidate for built-in tuple literal syntax. But *if*
the best we have is parens (and maybe there *is* something better?)
then maybe this would be an acceptable way to achieve it?
If the problems in DIP 19 are deemed mostly syntactic (1- and 0-
element tuples), then maybe *for once* a simple syntax change could
solve them? I know syntax proposals are a dime a dozen in this
newsgroup, but why not here, to avoid the ((1)) problem?
I'm all for that. In fact, I was was just about to post the same
suggestion.
My bikeshed is colored one of these:
(:1,2)
(|1,2)
At that point you might as well just use
import std.typecons : q = tuple, Q = Tuple;
Q!(int, int) foo(){
return q(1, 2);
}
If built-in tuples are not going to look like
(1, 2)
then imho we might as well leave them out, while still addressing
unpacking in the locations bearophile has designated.
Minimal syntax (one extra character), no ambiguities with anything
else AFAIK. Looks kinda funny, but so did !() at first and we all got
used to that.
For example choosing { 1, 2} to represent a tuple?
I like it, but what about zero-element tuples vs empty code blocks?
(Or is it ok because code blocks can't be used inside, or as,
expressions?)
Also, it may be too easy to accidentally get mixups between one-element
tuples and certain one-statement blocks:
{ foo(); } // Block
vs
{ foo() } // Either a tuple or a forgotten semicolon
Not sure if that's a big enough deal, though.
...
q(foo())
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 09:50 PM, Caligo wrote: On Mon, Sep 24, 2012 at 11:37 AM, bearophile wrote: That both breaks code, doesn't improve the syntax, but makes it worse. Bye, bearophile foo(<11,2,8>, a, b) vs foo((11,2,8), a, b) I don't spot a significant difference. Parentheses are everywhere in D. Sometimes it looks like Lisp. Lisp is beautiful.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Timon Gehr:
My bikeshed is colored one of these:
(:1,2)
(|1,2)
At that point you might as well just use
import std.typecons : q = tuple, Q = Tuple;
Q!(int, int) foo(){
return q(1, 2);
}
If built-in tuples are not going to look like
(1, 2)
then imho we might as well leave them out,
But the banana syntax doesn't look bad:
(||)
(|1|)
(|1, 2|)
(|1, 2, 3|)
It's short enough, it's not visually noisy, it's simple enough to
type, it consistently avoids the problems with literals for
0-tuples and 1-tuples, and it's sufficiently intuitive once you
have seen it one time. It's just a bit longer to type than the
syntax with simple (), that has problems with the shorter tuples.
The now dead Fortress language used several similar syntaxes,
like (|...|), {|...|}, [|...|], etc.
Bye,
bearophile
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 21:50:34 +0200, Caligo wrote: foo(<11,2,8>, a, b) vs foo((11,2,8), a, b) Parentheses are everywhere in D. Sometimes it looks like Lisp. And <> is ambiguous, ugly, an affront before Walter, and an abomination born in the fiery depths of hell. Can we please just leave it behind? -- Simen
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/25/2012 12:28 AM, bearophile wrote:
Timon Gehr:
My bikeshed is colored one of these:
(:1,2)
(|1,2)
At that point you might as well just use
import std.typecons : q = tuple, Q = Tuple;
Q!(int, int) foo(){
return q(1, 2);
}
If built-in tuples are not going to look like
(1, 2)
then imho we might as well leave them out,
But the banana syntax doesn't look bad:
(||)
(|1|)
(|1, 2|)
(|1, 2, 3|)
It's short enough,
It's not shorter than q()
it's not visually noisy,
It adds more noise than q()
it's simple enough to type,
It is harder to type than q().
it consistently avoids the problems with literals for
0-tuples and 1-tuples, and it's sufficiently intuitive once you
have seen it one time. It's just a bit longer to type than the
syntax with simple (), that has problems with the shorter tuples.
I still think any built-in special syntax that differs from (1,2,3) is
not worth it.
The now dead Fortress language used several similar syntaxes,
like (|...|), {|...|}, [|...|], etc.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 6:28 PM, bearophile wrote:
Timon Gehr:
My bikeshed is colored one of these:
(:1,2)
(|1,2)
At that point you might as well just use
import std.typecons : q = tuple, Q = Tuple;
Q!(int, int) foo(){
return q(1, 2);
}
If built-in tuples are not going to look like
(1, 2)
then imho we might as well leave them out,
But the banana syntax doesn't look bad:
(||)
(|1|)
(|1, 2|)
(|1, 2, 3|)
tuple()
tuple(1)
tuple(1, 2)
tuple(1, 2, 3)
also arguably enjoys the same advantages and in fact is much more
intuitive. Like, totally intuitive. Like, it says "tuple" to create a
tuple. And one advantage is, there's never ever going to be butt jokes
about tuple() as there'd be with "(||)".
It's short enough, it's not visually noisy, it's simple enough to
type, it consistently avoids the problems with literals for
0-tuples and 1-tuples, and it's sufficiently intuitive once you
have seen it one time. It's just a bit longer to type than the
syntax with simple (), that has problems with the shorter tuples.
The now dead Fortress language used several similar syntaxes,
like (|...|), {|...|}, [|...|], etc.
Well let's not take inspiration from dead languages :o).
Andrei
Re: [OT] Was: totally satisfied :D
On Mon, 24 Sep 2012 10:02:57 -0400 "Steven Schveighoffer" wrote: > On Fri, 21 Sep 2012 17:22:32 -0400, Nick Sabalausky > wrote: > > > On Fri, 21 Sep 2012 08:24:07 -0400 > > "Steven Schveighoffer" wrote: > >> > >> That works too, but doesn't warrant rants about how you haven't > >> learned how to use the fucking thing :) > >> > > > > It's *volume* controls, there doesn't need to be *anything* to > > learn. > > OK, so this is what you'd rather have: > [...single volume...] > > No, I think the current design, while not perfect, is *WAY* better > than a single volume. > No, that's not it at all. The problem is the *lack* of any master volume control whatsoever, not the existence of finer-grained volume controls. My walkman example was perhaps misleading. > >> > >> 1. ringer volume affects all sounds except for music/video/games > >> 2. Silent switch will ringer volume to 0 for all sounds except for > >> find-my-iphone and alarm clock > >> 3. If playing a game/video/music, the volume buttons affect that > >> volume, otherwise, they affect ringer volume. > >> > >> Wow, you are right, three whole rules. > > > > And each one with exceptions, the rules as a whole aren't > > particularly intuitive. > > They aren't? They make complete sense to me. You even admit that > it makes sense to have find my iphone play its alerts as loud as > possible. No, only the "find iPhone" one. The iPhone has no fucking idea what environment I'm in. I *definitely* don't want it screeching "PAY ATTENTION TO M" indiscriminately whenever it damn well feels like it. > I contend that if you use alarm clock what it is for, > (i.e. waking you up) there is no problem there either. Those are the > only exceptions. > Keep in mind, when I started talking "alarms" I didn't just mean "alarm clock". Pardon if I'm not completely up on official iTerminology. > Besides, you don't have to "memorize" these rules, most of the time, > it is what a normal person would expect. > What a normal person expects is for turning down a device's volume to...turn down the device's volume. Or for "silent" to actually *be* silent. What a normal person does not expect is for the device to take the user's commands as mere suggestions. > > And then there's the question of what rules you forgot. I can think > > of one right now: > > > > 4. If you're in the camera app then the volume button takes a > > picture instead of adjusting volume. > > I admit, I completely forgot about this one. Simply because I rarely > use it :) It was a gimmicky feature, and doesn't hurt anything, but > I find it unusable, simply because my natural inclination, being a > right-handed person, is to rotate the phone left to go into landscape > mode, If I want to use the button, my sequence is to rotate left, > then realize the button's on the other side, flip 180 degrees, then > realize my finger is in front of the lens, etc. I think this is > essentially an orthogonal problem because there is no volume control > in camera, and that "feature" doesn't interfere with any other use of > the phone. When I read about it though, I thought it was a good idea. > I can never remember which way I'm supposed to tilt the stupid thing for landscape photos. It *shouldn't* matter, but then when you go grab your photos (and videos!!) off the device you find the stupid thing decided to ignore the accelerometer and save them upside-down. As for buttons and such, the Zire 71 had a great design for the camera: Slide the face upward and the normally-protected lens is revealed, along with a "shutter" button (no need for modal "volume button" contrivances), *and* it goes directly into the camera program. So basically a real camera instead of a mere a camera "app", always trivially accessible, and always the same easy way. And yea, it's a moving part, but it *still* far outlasted the life of the (unfortunately non-replaceable) battery. *That* was brilliant design. I wish apple had copied it. It didn't have an accelerometer (this *was* a decade ago, after all) so it couldn't determine the current "tilt" and auto-rotate photos accordingly (like the iPhone *should* have been able to do), but it had an easy built-in "rotate photo" feature that even iPhone's built-ins won't do (at least not in any realistically discoverable way). > >> That's way more than 1. I stand corrected :) > >> > > > > Now compare that to a normal device: > > > > 1. The volume control adjusts the volume. > > > > Gee, how horrible to have one trivially intuitive rule and no > > exceptions. > > Right, and now I'm stuck in "Nick mode", where I'm constantly > worrying about and changing the volume to deal with the current > situation. No thanks. > No, as I said above. > > Bottom line, they took something trivial, complicated it, and people > > hail them as genius visionaries. > > s/complicated/improved/ > > This isn't really genius, nor is it unprecedented (iPhone is not the > first to control ringer a
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 17:31:27 -0400, Nick Sabalausky wrote: On Mon, 24 Sep 2012 10:53:14 -0400 "Steven Schveighoffer" wrote: (int[]) x; int a = x.length; is a == 0 or 1? It'd be 1, but I agree that's a pretty solid counter-argument. It would be if it were valid code :) d complains (and rightly so) that you can't use C-style casts anymore! This is what I really meant: int[] x; int a = (x).length; But I think you got the point. However, this brings up another issue, what about porting C code? All of a sudden c style casts are no loner errors, but are type tuples! -Steve
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/25/12, Steven Schveighoffer wrote: > However, this brings up another issue, what about porting C code? All of > a sudden c style casts are no loner errors, but are type tuples! I think they're still errors: int x = (int)foo; Maybe the compiler could figure out if a cast was attempted rather than a tuple, and could print out the ol' "Can't use C shenanigans in D" error.
Re: [OT] Was: totally satisfied :D
On Mon, Sep 24, 2012 at 07:52:15PM -0400, Nick Sabalausky wrote: [...] > Independently controllable ringer/game/music volumes: Good > > Complete *lack* of any way to control *overall* volume: Bad I have to agree with that. It's OK, and sometimes even useful, to have multiple independent volumes, but it makes no sense to NOT have a master volume that controls everything else. Sometimes you just want to mute the whole dang device, and that should not require fiddling with every single independent volume setting. > A lot of the videogames I've played have independent adjustable > SFX/music/voice volumes. I've even happily made use of that. And I'm > damn glad that the TV *still* has a properly working volume control > despite that because I make even more use of that. Yeah I almost never play games with music on, 'cos I generally find the music not to my liking. SFX I sometimes leave on low, though on handhelds I generally turn both off. But the option to only have SFX without music is a plus. I *have* deleted apps before that didn't allow independent settings. [...] > > I feel like I get the best of all worlds. > > Yea, but to get that, you have to use OSX as your *primary* > environment, and stick with expensive iHardware. Might work for you, > but those are all deal-breakers for me. I find it sad that Apple has left its original philosophy of open protocols and specs so that you can make it interoperate with stuff. For all their flaws, PCs are much more palatable 'cos you can replace parts that you don't like with alternatives. With closed hardware and vendor lock-in, I can't say that Macs are exactly near the top of the list for hardware I'd consider buying. I've had a bad experience with PC laptops already (after 2 years parts starting wearing out and I can't replace them 'cos they need specialized tools that vary from vendor to vendor -- no choice but to buy a brand new one though the old one could've continued to work if a few basic parts were replaced) -- I don't feel like I want to repeat that experience. So yeah, this is a deal-breaker for me too. [...] > > The one thing I would rip out of OSX and throw against the wall is > > the mail app. Its interface and experience is awesome. But it > > frequently corrupts messages and doesn't properly save outgoing > > mail. Not good for a mail application. Ahhh how I love Mutt. ;-) > I didn't have corruption issues with it, but I did find it to be > rather gimped and straight-jacketed much like the rest of the system. [...] I find pretty much all GUI mail apps (both webmail and local MUAs) strait-jacketed. Anything that doesn't let you configure mail headers is unusable to me, and HTML by default gets on my nerves so much it's not even funny. I want my mail to NOT have stupid extraneous headers that are completely unnecessary for what I use mail for, and yes most people don't care, but as the adage goes: easy things should be easy, hard things should be possible. I find in pretty much every GUI mail app that easy things are hard and hard things are impossible. But anyway, I stumbled across this cute little thing just today: http://daringfireball.net/projects/markdown/ I'd love to start a trend for a new kind of email: one in which the message is transmitted as markdown text, and, should the receiver so wish, the receiving end automatically converts that into HTML. This way you can either write directly in plaintext (like I do) or use a GUI front-end for composing messages (like most normal people do), the transmission won't have stupid useless HTML clutter (or worse, JS viruses and other detritus), and the receiver can get all mails in plaintext or HTML according to their choice. AND there is no need for multiple MIME parts; the markdown text can be read directly as plaintext or translated into HTML for people who prefer that. Now, somebody just has to cook up this MUA in D, and make it the killer D app that will take over the world. ;-) T -- When solving a problem, take care that you do not become part of the problem.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
What would a special case where the first level of tuple (with
higher levels being tuples in tuples) didn't require parens
break? This would be a beautiful syntax:
auto a = 1, 2; // A tuple of two ints
int, string fun(double, double d) {
return cast(int) (d[0] * d[1]), "hello";
}
auto a, b = 1, 2; // Two ints
auto a = fun(1.0, 1.0); // Tuple of 1 and "hello".
auto a, b = fun(1.0, 1.0); // An int and a string.
Re: [OT] Was: totally satisfied :D
On Mon, 24 Sep 2012 19:52:15 -0400, Nick Sabalausky wrote: On Mon, 24 Sep 2012 10:02:57 -0400 "Steven Schveighoffer" wrote: On Fri, 21 Sep 2012 17:22:32 -0400, Nick Sabalausky wrote: > On Fri, 21 Sep 2012 08:24:07 -0400 > "Steven Schveighoffer" wrote: >> >> That works too, but doesn't warrant rants about how you haven't >> learned how to use the fucking thing :) >> > > It's *volume* controls, there doesn't need to be *anything* to > learn. OK, so this is what you'd rather have: [...single volume...] No, I think the current design, while not perfect, is *WAY* better than a single volume. No, that's not it at all. The problem is the *lack* of any master volume control whatsoever, not the existence of finer-grained volume controls. My walkman example was perhaps misleading. There is a master volume control. It has two volumes, on and off, and it's called the silent switch ;) >> >> 1. ringer volume affects all sounds except for music/video/games >> 2. Silent switch will ringer volume to 0 for all sounds except for >> find-my-iphone and alarm clock >> 3. If playing a game/video/music, the volume buttons affect that >> volume, otherwise, they affect ringer volume. >> >> Wow, you are right, three whole rules. > > And each one with exceptions, the rules as a whole aren't > particularly intuitive. They aren't? They make complete sense to me. You even admit that it makes sense to have find my iphone play its alerts as loud as possible. No, only the "find iPhone" one. The iPhone has no fucking idea what environment I'm in. I *definitely* don't want it screeching "PAY ATTENTION TO M" indiscriminately whenever it damn well feels like it. When does it do that? I contend that if you use alarm clock what it is for, (i.e. waking you up) there is no problem there either. Those are the only exceptions. Keep in mind, when I started talking "alarms" I didn't just mean "alarm clock". Pardon if I'm not completely up on official iTerminology. All other alerts are silenced by the silent switch. I don't even know if that's the correct term for that switch. I just discovered through testing that timer has the same feature as alarm. I find that incorrect. If I have the silent switch enabled, the timer should just vibrate. In fact, I don't think there's a way to make the timer "just vibrate" in any way. That's counter-intuitive and I will agree with you on that one. Besides, you don't have to "memorize" these rules, most of the time, it is what a normal person would expect. What a normal person does not expect is for the device to take the user's commands as mere suggestions. At least in the case of alarm clock, the user has said both "wake me up at this time" and "be silent." Apple chose "wake me up". The alternative is that the phone stays silent, and you don't wake up. Much worse. > 4. If you're in the camera app then the volume button takes a > picture instead of adjusting volume. I admit, I completely forgot about this one. Simply because I rarely use it :) It was a gimmicky feature, and doesn't hurt anything, but I find it unusable, simply because my natural inclination, being a right-handed person, is to rotate the phone left to go into landscape mode, If I want to use the button, my sequence is to rotate left, then realize the button's on the other side, flip 180 degrees, then realize my finger is in front of the lens, etc. I think this is essentially an orthogonal problem because there is no volume control in camera, and that "feature" doesn't interfere with any other use of the phone. When I read about it though, I thought it was a good idea. I can never remember which way I'm supposed to tilt the stupid thing for landscape photos. It *shouldn't* matter, but then when you go grab your photos (and videos!!) off the device you find the stupid thing decided to ignore the accelerometer and save them upside-down. I have seen strange things there, sometimes a photo/video comes in rotated (I see it pass by the Windows photo import preview), but then when I look at the photo in Explorer, it's correctly rotated. I have not seen it show photos or videos incorrectly rotated once downloaded. As for buttons and such, the Zire 71 had a great design for the camera: Slide the face upward and the normally-protected lens is revealed, along with a "shutter" button (no need for modal "volume button" contrivances), *and* it goes directly into the camera program. So basically a real camera instead of a mere a camera "app", always trivially accessible, and always the same easy way. And yea, it's a moving part, but it *still* far outlasted the life of the (unfortunately non-replaceable) battery. *That* was brilliant design. I wish apple had copied it. Hehe, they have something like that, the photo icon on the lock screen slides up to reveal the photo app. Yeah, it's not a hardware button, but it does sound similar. I have to say, this is one of the better improvements
Re: [OT] Was: totally satisfied :D
On Mon, 24 Sep 2012 19:52:15 -0400, Nick Sabalausky wrote: On Mon, 24 Sep 2012 10:02:57 -0400 "Steven Schveighoffer" wrote: On Fri, 21 Sep 2012 17:22:32 -0400, Nick Sabalausky wrote: > On Fri, 21 Sep 2012 08:24:07 -0400 > "Steven Schveighoffer" wrote: >> >> That works too, but doesn't warrant rants about how you haven't >> learned how to use the fucking thing :) >> > > It's *volume* controls, there doesn't need to be *anything* to > learn. OK, so this is what you'd rather have: [...single volume...] No, I think the current design, while not perfect, is *WAY* better than a single volume. No, that's not it at all. The problem is the *lack* of any master volume control whatsoever, not the existence of finer-grained volume controls. My walkman example was perhaps misleading. There is a master volume control. It has two volumes, on and off, and it's called the silent switch ;) >> >> 1. ringer volume affects all sounds except for music/video/games >> 2. Silent switch will ringer volume to 0 for all sounds except for >> find-my-iphone and alarm clock >> 3. If playing a game/video/music, the volume buttons affect that >> volume, otherwise, they affect ringer volume. >> >> Wow, you are right, three whole rules. > > And each one with exceptions, the rules as a whole aren't > particularly intuitive. They aren't? They make complete sense to me. You even admit that it makes sense to have find my iphone play its alerts as loud as possible. No, only the "find iPhone" one. The iPhone has no fucking idea what environment I'm in. I *definitely* don't want it screeching "PAY ATTENTION TO M" indiscriminately whenever it damn well feels like it. When does it do that? I contend that if you use alarm clock what it is for, (i.e. waking you up) there is no problem there either. Those are the only exceptions. Keep in mind, when I started talking "alarms" I didn't just mean "alarm clock". Pardon if I'm not completely up on official iTerminology. All other alerts are silenced by the silent switch. I don't even know if that's the correct term for that switch. I just discovered through testing that timer has the same feature as alarm. I find that incorrect. If I have the silent switch enabled, the timer should just vibrate. In fact, I don't think there's a way to make the timer "just vibrate" in any way. That's counter-intuitive and I will agree with you on that one. Besides, you don't have to "memorize" these rules, most of the time, it is what a normal person would expect. What a normal person does not expect is for the device to take the user's commands as mere suggestions. At least in the case of alarm clock, the user has said both "wake me up at this time" and "be silent." Apple chose "wake me up". The alternative is that the phone stays silent, and you don't wake up. Much worse. > 4. If you're in the camera app then the volume button takes a > picture instead of adjusting volume. I admit, I completely forgot about this one. Simply because I rarely use it :) It was a gimmicky feature, and doesn't hurt anything, but I find it unusable, simply because my natural inclination, being a right-handed person, is to rotate the phone left to go into landscape mode, If I want to use the button, my sequence is to rotate left, then realize the button's on the other side, flip 180 degrees, then realize my finger is in front of the lens, etc. I think this is essentially an orthogonal problem because there is no volume control in camera, and that "feature" doesn't interfere with any other use of the phone. When I read about it though, I thought it was a good idea. I can never remember which way I'm supposed to tilt the stupid thing for landscape photos. It *shouldn't* matter, but then when you go grab your photos (and videos!!) off the device you find the stupid thing decided to ignore the accelerometer and save them upside-down. I have seen strange things there, sometimes a photo/video comes in rotated (I see it pass by the Windows photo import preview), but then when I look at the photo in Explorer, it's correctly rotated. I have not seen it show photos or videos incorrectly rotated once downloaded. As for buttons and such, the Zire 71 had a great design for the camera: Slide the face upward and the normally-protected lens is revealed, along with a "shutter" button (no need for modal "volume button" contrivances), *and* it goes directly into the camera program. So basically a real camera instead of a mere a camera "app", always trivially accessible, and always the same easy way. And yea, it's a moving part, but it *still* far outlasted the life of the (unfortunately non-replaceable) battery. *That* was brilliant design. I wish apple had copied it. Hehe, they have something like that, the photo icon on the lock screen slides up to reveal the photo app. Yeah, it's not a hardware button, but it does sound similar. I have to say, this is one of the better improvements
Re: [OT] Was: totally satisfied :D
On Mon, 24 Sep 2012 18:10:09 -0700 "H. S. Teoh" wrote: > On Mon, Sep 24, 2012 at 07:52:15PM -0400, Nick Sabalausky wrote: > > > A lot of the videogames I've played have independent adjustable > > SFX/music/voice volumes. I've even happily made use of that. And I'm > > damn glad that the TV *still* has a properly working volume control > > despite that because I make even more use of that. > > Yeah I almost never play games with music on, 'cos I generally find > the music not to my liking. SFX I sometimes leave on low, though on > handhelds I generally turn both off. But the option to only have SFX > without music is a plus. I *have* deleted apps before that didn't > allow independent settings. > I never used to mute videogame music until they started licensing stuff from the record labels. Like all that "EA Trax" stuff. Blech. Last generation, that was one of the great things about the XBox: custom soundtracks. My brother introduced me to Quarashi's Jinx album which made for a far better soundtrack for THPS2X than the built-in songs. The Tony Hawk games from 3 onward were almost unplayable with the built-in music enabled. Unfortunately, my most frequent use of game audio controls is to fix the piss-poor mixing that's common in a lot of games. When you can't hear important voiceovers because they're quieter than the music or sfx (example: Splinter Cell 3), it's nice to be able to fix that screwup by cranking up the voice volume, and turning everything else down. I've often wished I could turn off the elevator music in Wii Sports Resort without having to mute the whole thing. But of course, all that still doesn't mean I'd ever be willing to give up the TV's "adjust *everything's* volume". Individual controls let you adjust the "mix" ie relative volume relations, and then a master volume is indispensible for normal "I need this thing louder/quieter". > > [...] > > > I feel like I get the best of all worlds. > > > > Yea, but to get that, you have to use OSX as your *primary* > > environment, and stick with expensive iHardware. Might work for you, > > but those are all deal-breakers for me. > > I find it sad that Apple has left its original philosophy of open > protocols and specs so that you can make it interoperate with stuff. Absolutely. That's one of my biggest irritations with modern Apple. > For all their flaws, PCs are much more palatable 'cos you can replace > parts that you don't like with alternatives. With closed hardware and > vendor lock-in, I can't say that Macs are exactly near the top of the > list for hardware I'd consider buying. I've had a bad experience with > PC laptops already (after 2 years parts starting wearing out and I > can't replace them 'cos they need specialized tools that vary from > vendor to vendor -- no choice but to buy a brand new one though the > old one could've continued to work if a few basic parts were > replaced) -- I don't feel like I want to repeat that experience. So > yeah, this is a deal-breaker for me too. > Yeah. > > [...] > > > The one thing I would rip out of OSX and throw against the wall is > > > the mail app. Its interface and experience is awesome. But it > > > frequently corrupts messages and doesn't properly save outgoing > > > mail. Not good for a mail application. > > Ahhh how I love Mutt. ;-) > I've been finding Mutt very useful for when I'm ssh'ed into my server to create a temporary throwaway address. Doing "mutt -f /path/to/mailbox" is so much more convenient than setting up a POP3 GUI client. I need to learn how to use mutt better though, as I've just been fumbling around with it. For my usual mailboxes though, I prefer typical GUI desktop clients. Unfortunately, I still haven't been able to find one that I like. Outlook Express has a bunch of problems (no spellcheck, can't send UTF, proprietary storage, etc). Windows Mail won't be an option when I move to Linux or upgrade back to XP. Claws mail is just generally buggy and never does anything in the background (feels almost like it might be purely single-threaded). And I'm not a big fan of Opera and don't really want to use a web browser as my desktop mail client. I think I might actually try moving to Thunderbird even though I'm generally unhappy with Mozilla software/practices, and didn't like it last time I tried (for example, it kept trying to bold/italic/underline parts of text in my *plaintext* views, and the people on the "help" forums just complained that I should shut up and like it - which is consistent with what usually happens when I inquire about customizing parts of Mozilla's so-called "most customizable browser in the world"). > > > I didn't have corruption issues with it, but I did find it to be > > rather gimped and straight-jacketed much like the rest of the > > system. > [...] > > I find pretty much all GUI mail apps (both webmail and local MUAs) > strait-jacketed. Anything that doesn't let you configure mail headers > is unusable to me, and HTML
C# wish list
Seen on Reddit: the wish list for C#:
http://visualstudio.uservoice.com/forums/121579-visual-studio/category/30931-languages-c-
The wish #2 is to catch multiple exceptions:
try
{
// smth}
catch (RemoteException, NamingException , CreateException e)
{
// smth
}
The wish #15 for C# is nonnullable references, also discussed
here:
http://www.reddit.com/r/programming/comments/10eq96/nonnullable_types_vs_c_fixing_the_billion_dollar/
http://twistedoakstudios.com/blog/?p=330
The wish list for F#:
http://visualstudio.uservoice.com/forums/121579-visual-studio/category/30935-languages-f-
The #10 F# wish F# wish is for "Parameterized Modules":
open Module1(p = 100)
Bye,
bearophile
Re: reference to 'self' inside a function
On Sunday, 23 September 2012 at 17:15:13 UTC, Ben Davis wrote:
Here's another one that might work, and be less error-prone:
mixin template Self() {
auto self = __traits(identifier, __traits(parent, {}));
}
void test() {
mixin Self;
writeln(self);
}
OK, we've managed to get the calling function symbol name without
re-specifying it. Now I wonder if we can perform mixin magic to
execute a function recursively without re-specifying the function
name?
Example recursive function
int Recurse(int a)
{
if (a <= 1)
return 1;
else
// can we replace explicit call to "Recurse"
// with "self" using a mixin or some other means?
return a * Recurse(a - 1);
}
We could try and get the function pointer, but that seems like
the wrong approach. I'd rather get the function name, do some
mixin magic with it to generate the compile time code that uses
the function name directly. Can we mixin a mixin???
--rt
Should this be flagged as a warning?
I just found a bug in my code that showed up in this fragment: match(ts, TokenType.OpenParen); ie.type == parseType(ts); Obviously I meant ie.type = parseType(ts); but wrote == because I'm an idiot. If parseType wasn't a function with side effects, -w would have flagged it as an expression with no effect. But the comparison still has no side effects. Thoughts? -Bernard. p.s. as a side note, I think this is the first time I've had a bug from writing == where I meant = instead of the other way around!
Re: reference to 'self' inside a function
This is a little insane, but it works.
int Recurse(int a)
{
if (a <= 1)
return 1;
else
// can we replace explicit call to "Recurse"
// with "self" using a mixin or some other means?
// return a * Recurse(a - 1);
mixin("return a * mixin(__traits(identifier,
__traits(parent, {})))(a - 1);");
}
--rt
On Tuesday, 25 September 2012 at 04:42:43 UTC, Rob T wrote:
On Sunday, 23 September 2012 at 17:15:13 UTC, Ben Davis wrote:
Here's another one that might work, and be less error-prone:
mixin template Self() {
auto self = __traits(identifier, __traits(parent, {}));
}
void test() {
mixin Self;
writeln(self);
}
OK, we've managed to get the calling function symbol name
without re-specifying it. Now I wonder if we can perform mixin
magic to execute a function recursively without re-specifying
the function name?
Example recursive function
int Recurse(int a)
{
if (a <= 1)
return 1;
else
// can we replace explicit call to "Recurse"
// with "self" using a mixin or some other means?
return a * Recurse(a - 1);
}
We could try and get the function pointer, but that seems like
the wrong approach. I'd rather get the function name, do some
mixin magic with it to generate the compile time code that uses
the function name directly. Can we mixin a mixin???
--rt
Re: [OT] Was: totally satisfied :D
On Mon, 24 Sep 2012 21:52:05 -0400 "Steven Schveighoffer" wrote: > > There is a master volume control. It has two volumes, on and off, and > it's called the silent switch ;) > Calling that a master volume control is a stretch. > >> They aren't? They make complete sense to me. You even admit that > >> it makes sense to have find my iphone play its alerts as loud as > >> possible. > > > > No, only the "find iPhone" one. The iPhone has no fucking idea what > > environment I'm in. I *definitely* don't want it screeching "PAY > > ATTENTION TO M" indiscriminately whenever it damn well feels > > like it. > > When does it do that? > I thought you were just saying that the iPhone plays it's alerts as loud as possible? > > I just discovered through testing that timer has the same feature as > alarm. I find that incorrect. If I have the silent switch enabled, > the timer should just vibrate. > > In fact, I don't think there's a way to make the timer "just vibrate" > in any way. That's counter-intuitive and I will agree with you on > that one. > Yea, see there's just too much "surprise" involved, IMO. > I have seen strange things there, sometimes a photo/video comes in > rotated (I see it pass by the Windows photo import preview), but then > when I look at the photo in Explorer, it's correctly rotated. > I'm looking at the photos on my iPhone through Explorer right now and aside from the screenshots, the majority of them are either sideways or upside-down. The bizarre thing is, when I look at them through "Photos" on the device itself, it actually shows them all correctly. Which means that the device *knows* how they're supposed to be but doesn't bother to actually save them correctly. > I have not seen it show photos or videos incorrectly rotated once > downloaded. > I just copied all of them to my local machine, and they're still rotated wrong. Makes sense though, I wouldn't expect (or want) a file copy to affect content. > > Hehe, they have something like that, the photo icon on the lock screen > slides up to reveal the photo app. Yeah, it's not a hardware button, > but it does sound similar. > Doesn't protect the lens though, and it doesn't provide a physical button which would obviate the need to hijack the volume button. (It *is* at least a little better than not being able to access the camera from the lock screen at all.) I can't even tell you how many times I've accidentally gone back to the home screen when trying to take a picture. But I'll at least grant that *that* error was due to me being accustomed to my Zire71 (which, when slid open, has the "shutter" button exactly where the iPhone's home button is). > I have to say, this is one of the better improvements, especially with > those of us who have kids. > Yea, one-size-fits-all design :/ That said, I do like to use "kids" as an argument for having an OS-level "disable software eject" option for optical drives. ;) "Ok, I'll just leave that to burn..." Walk away. It finishes and ejects. Kid waddles by. "Ohh, a pretty shiny object! Should I eat it or flush it?" > > > > It didn't have an accelerometer (this *was* a decade ago, after > > all) so it couldn't determine the current "tilt" and auto-rotate > > photos accordingly (like the iPhone *should* have been able to do), > > but it had an easy built-in "rotate photo" feature that even > > iPhone's built-ins won't do (at least not in any realistically > > discoverable way). > > While viewing a photo, tap the screen to bring up the controls. Click > "Edit" (upper right corner), then you can rotate the photo. Don't > think you can do the same with a video. > > Don't think I agree that an Edit button on the main photo viewing > screen is not realistically discoverable. > I don't see any rotate there: http://semitwist.com/download/img/shots/IMG_0859.PNG I just see the "Back" button then...umm "Do a Magic Trick?" (WTF?), then I'm guessing maybe "Anti-Red-Eye", and...ok, I'm pretty sure that last one's crop, I remember seeing it in one or two image editing programs. > I will say though, like any UI, you have to get used to the mechanisms > that are standard. One of the things that I didn't know for a while > is how to get controls to come up. Generally that's a single tap in > the middle of the screen. If you didn't know that, it would be > difficult to discover. > Android has an actual button for "Settings". Much easier to discover (despite not actually saying "settings" - or anything at all, really). And easier to use since it usually brings up a list of real words unlike the contrived hieroglyphs used throughout most of Android and iOS. Or...at least the older Androids did. The damn newer ones replaced the few buttons it used to have with on-screen touch abominations. At least, for the buttons they didn't eliminate outright in their quest to clone the iPhone misfeature-for-misfeature. The settings button might have been one of the ones they killed o
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-24 22:45, Nick Sabalausky wrote:
Because 'b' is neither being assigned to an (int) nor passed into a
template/func parameter that's expecting an (int).
Either I'm just stupid or I've failed completely to understand "implicit
convertible to".
Another example:
struct Foo
{
int[] arr;
alias arr this;
}
void main ()
{
auto foo = Foo([3, 4]);
auto i = foo[0];
}
Have a look at the last line. In that line "foo" is implicitly converted
to "int[]" with the help of the "alias this" in Foo, because the context
requires something "indexable". Since you cannot index a struct the
implicit conversion kicks in. What's the difference?
--
/Jacob Carlborg
