Re: Is this D or is it Javascript?
Seems like vibe.d runs a blog http://vibed.org/blog/ doesn't it suit you?
Re: My first email to Walter, ever
On 7/7/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: While doing some unrelated research I stumbled upon my very first email to Walter, dated April 26, 2004. That's a cool teaser, but how did the discussion continue? :)
Re: My first email to Walter, ever
Am Sat, 06 Jul 2013 20:02:16 -0700 schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org: * The venerable typeof check * For a class, enumerate all of its members, and figure out their attributes (protection level, static or not, type...) check * For a module/namespace, enumerate all of its symbols and figure out their attributes. check * For a function, figure out its return type and the type of each of its formal arguments. check * Figure out if a certain function exists (that should be easy if you have the tools above). That will be useful to decide, for example, if an iterator supports random access. check * And if you really want to go meta, define metacode that can take an AST node as a parameter and can visit the AST and figure out what each node is. That would allow things such as loop fusion and other advanced stuff. But for now, let's leave those aside. che... oh _that_ topic. I think you have done some really good team work there. And I may add Walter's good intuition to make the front end reusable for GDC and LDC. Btw, you didn't want to start a new discussion about AST manipulation through the back door, did you? ;) -- Marco
Re: My first email to Walter, ever
On Sunday, 7 July 2013 at 03:03:03 UTC, Andrei Alexandrescu wrote:
Terrible. If you have conditionals, iteration, functions, and
objects
in D's straight programming support, you should have
conditionals,
iteration, functions, and objects in D's metalanguage.
:-(
template allSatisfy(alias F, T...)
{
static if (T.length == 0)
{
enum allSatisfy = true;
}
else static if (T.length == 1)
{
enum allSatisfy = F!(T[0]);
}
else
{
enum allSatisfy =
allSatisfy!(F, T[ 0 .. $/2])
allSatisfy!(F, T[$/2 .. $ ]);
}
}
Still looks like half-assed functional programming to me.
Where's the iteration? Why can't I write this?
template allSatisfy(alias F, T...) {
foreach(t; T)
if (!F!(t))
return false;
return true;
}
(Those are rhetorical questions btw, before anyone links me to a
D tutorial).
We're almost there with CTFE, but CTFE can only run functions
that could run at runtime. In a crazy world where types were
first class objects, stuff like this would be feasible. Or
perhaps we just need a compile-time metalanguage that allows
things like this to be run with CTFE?
Re: My first email to Walter, ever
On Sunday, 7 July 2013 at 03:03:03 UTC, Andrei Alexandrescu wrote: On 4/26/04 6:54 PM, Andrei Alexandrescu wrote: I was bitching to myself and then together with a friend (e-meet [...]) about how hard it is to do metaprogramming in C++. He mentioned D is much better at it, and we browsed the online documentation for D's templates (http://www.digitalmars.com/d/template.html), which we noticed (apologies if I am wrong) is not much more more than a cleaned-syntax version of C++'s templates, which in turn are [...]. You may hold a different opinion today, and my opinion is worthless this point. But my two cents, I think (1) static-if and (2) making templates independent of classes and functions were both huge steps forward.
Re: My first email to Walter, ever
On 07/07/2013 02:27 PM, Peter Alexander wrote: ... We're almost there with CTFE, but CTFE can only run functions that could run at runtime. In a crazy world where types were first class objects, stuff like this would be feasible. Or perhaps we just need a compile-time metalanguage that allows things like this to be run with CTFE? Almost there indeed. http://d.puremagic.com/issues/show_bug.cgi?id=9945
Re: My first email to Walter, ever
On 07/07/13 14:27, Peter Alexander wrote:
template allSatisfy(alias F, T...)
{
static if (T.length == 0)
{
enum allSatisfy = true;
}
else static if (T.length == 1)
{
enum allSatisfy = F!(T[0]);
}
else
{
enum allSatisfy =
allSatisfy!(F, T[ 0 .. $/2])
allSatisfy!(F, T[$/2 .. $ ]);
}
}
Still looks like half-assed functional programming to me.
Where's the iteration? Why can't I write this?
template allSatisfy(alias F, T...) {
foreach(t; T)
if (!F!(t))
return false;
return true;
}
(Those are rhetorical questions btw, before anyone links me to a D tutorial).
template allSatisfy(alias F, T...) {
enum allSatisfy = {
foreach (E; T)
if (!F!E)
return false;
return true;
}();
}
// And no, it isn't perfect. But not /that/ much is missing.
// It's the more complex cases that would benefit from more meta features.
artur
Re: My first email to Walter, ever
On 7/7/13, Peter Alexander peter.alexander...@gmail.com wrote:
Still looks like half-assed functional programming to me.
Yep I agree.
Where's the iteration? Why can't I write this?
template allSatisfy(alias F, T...) {
foreach(t; T)
if (!F!(t))
return false;
return true;
}
Also why not be able to write this (yes I know we can use Filter!()
but this is just an example):
template GetIntegrals(Types...)
{
foreach (T; Types)
{
static if (isIntegral!T)
GetIntegrals ~= T; // GetIntegrals becomes a typetuple
}
}
This beats the whole recursive template madness which we always have
to write (again there's the D language, and the template language,
just like in C++)
Maybe it would even speed things up not having to recursively
instantiate the template many times.
Re: My first email to Walter, ever
On Sunday, 7 July 2013 at 13:20:14 UTC, Timon Gehr wrote:
On 07/07/2013 02:27 PM, Peter Alexander wrote:
...
We're almost there with CTFE, but CTFE can only run functions
that could
run at runtime. In a crazy world where types were first class
objects,
stuff like this would be feasible. Or perhaps we just need a
compile-time metalanguage that allows things like this to be
run with CTFE?
Almost there indeed.
http://d.puremagic.com/issues/show_bug.cgi?id=9945
Hmmm I was thinking about encoding/decoding types, but it
doesn't help with template instantiations. You still need a
separate compile time language.
bool allSatisfy(alias F)(TypeInfo[] typeIds) {
foreach(t; typeIds)
if (!F!(__traits(typeFromId, t))) How do you do
this step?
return false;
return true;
}
Or am I missing something?
A very basic blog about D
I had some free time so I decided I should start a simple blog about D, implementing some unix utilities. I've (unsurprisingly) started with echo. http://foreach-hour-life.blogspot.co.uk/ It's nothing ground-breaking, but every little helps :)
Re: A very basic blog about D
On 7/7/13 8:00 AM, John Colvin wrote: I had some free time so I decided I should start a simple blog about D, implementing some unix utilities. I've (unsurprisingly) started with echo. http://foreach-hour-life.blogspot.co.uk/ It's nothing ground-breaking, but every little helps :) Nice idea! Comments: - The imperative version writes an extra space at the end (the joiner version does not have that problem). - The echo utility has an odd way to process the cmdline: if exactly the first argument is a -n, then do not writeln at the end. - It's quite likely the joiner-based version will be slower because it writes one character at a time. (Would be great to test and discuss performance as well.) Here's a conformant implementation for reference: http://www.scs.stanford.edu/histar/src/pkg/echo/echo.c Andrei
Re: A very basic blog about D
On 7/7/13 8:55 AM, Andrei Alexandrescu wrote:
Here's a conformant implementation for reference:
http://www.scs.stanford.edu/histar/src/pkg/echo/echo.c
Hmm, that's actually not so good, it doesn't ensure that I/O was
successful. Anyhow, here's a possibility:
import std.stdout;
void main(string[] args)
{
const appendNewline = args.length 1 args[1] == -n;
foreach (i, arg; args[appendNewline + 1 .. $])
{
if (i) write(' ');
write(arg);
}
if (nl) writeln();
}
But then I figured echo must do escape character processing, see e.g.
http://www.raspberryginger.com/jbailey/minix/html/echo_8c-source.html.
With that the blog entry would become quite interesting.
Andrei
Re: A very basic blog about D
On Sunday, 7 July 2013 at 15:55:31 UTC, Andrei Alexandrescu wrote: On 7/7/13 8:00 AM, John Colvin wrote: I had some free time so I decided I should start a simple blog about D, implementing some unix utilities. I've (unsurprisingly) started with echo. http://foreach-hour-life.blogspot.co.uk/ It's nothing ground-breaking, but every little helps :) Nice idea! Comments: - The imperative version writes an extra space at the end (the joiner version does not have that problem). Woops, missed that. - The echo utility has an odd way to process the cmdline: if exactly the first argument is a -n, then do not writeln at the end. As mentioned in the blog, i'll be covering the various flags later. - It's quite likely the joiner-based version will be slower because it writes one character at a time. (Would be great to test and discuss performance as well.) I plan on continuing both versions through successive posts, so when they're complete I'll do a head-to-head between them, including performance.
Re: A very basic blog about D
On Sunday, 7 July 2013 at 16:06:43 UTC, Andrei Alexandrescu wrote:
On 7/7/13 8:55 AM, Andrei Alexandrescu wrote:
Here's a conformant implementation for reference:
http://www.scs.stanford.edu/histar/src/pkg/echo/echo.c
Hmm, that's actually not so good, it doesn't ensure that I/O
was successful. Anyhow, here's a possibility:
import std.stdout;
void main(string[] args)
{
const appendNewline = args.length 1 args[1] == -n;
foreach (i, arg; args[appendNewline + 1 .. $])
{
if (i) write(' ');
write(arg);
}
if (nl) writeln();
}
Right structure, wrong logic? Shouldn't it be:
import std.stdio;
void main(string[] args)
{
const noNewline = args.length 1 args[1] == -n;
foreach (i, arg; args[noNewline + 1 .. $])
{
if (i) write(' ');
write(arg);
}
if (!noNewline) writeln();
}
or am I being dumb?
But then I figured echo must do escape character processing,
see e.g.
http://www.raspberryginger.com/jbailey/minix/html/echo_8c-source.html.
With that the blog entry would become quite interesting.
Andrei
Yeah, I reckon it will get quite interesting as I get in to the
details. It's easy to see these basic utilities as trivial but
they most certainly aren't, if you want to get them 100% right
for all the options.
Re: A very basic blog about D
On 7/7/13 10:08 AM, John Colvin wrote:
On Sunday, 7 July 2013 at 16:06:43 UTC, Andrei Alexandrescu wrote:
On 7/7/13 8:55 AM, Andrei Alexandrescu wrote:
Here's a conformant implementation for reference:
http://www.scs.stanford.edu/histar/src/pkg/echo/echo.c
Hmm, that's actually not so good, it doesn't ensure that I/O was
successful. Anyhow, here's a possibility:
import std.stdout;
void main(string[] args)
{
const appendNewline = args.length 1 args[1] == -n;
foreach (i, arg; args[appendNewline + 1 .. $])
{
if (i) write(' ');
write(arg);
}
if (nl) writeln();
}
Right structure, wrong logic? Shouldn't it be:
import std.stdio;
void main(string[] args)
{
const noNewline = args.length 1 args[1] == -n;
foreach (i, arg; args[noNewline + 1 .. $])
{
if (i) write(' ');
write(arg);
}
if (!noNewline) writeln();
}
or am I being dumb?
No, I am :o).
Yeah, I reckon it will get quite interesting as I get in to the details.
It's easy to see these basic utilities as trivial but they most
certainly aren't, if you want to get them 100% right for all the options.
Cool!
Andrei
Re: My first email to Walter, ever
On Sun, 07 Jul 2013 15:23:03 +0200
Artur Skawina art.08...@gmail.com wrote:
template allSatisfy(alias F, T...) {
enum allSatisfy = {
foreach (E; T)
if (!F!E)
return false;
return true;
}();
}
// And no, it isn't perfect. But not /that/ much is missing.
// It's the more complex cases that would benefit from more meta
features.
It'd be even nicer when/if this becomes possible (I *think* I remember
Walter saying it was planned...):
enum allSatisfy(alias F, T...) = {
foreach (E; T)
if (!F!E)
return false;
return true;
}();
Re: A very basic blog about D
Andrei Alexandrescu, el 7 de July a las 09:06 me escribiste:
On 7/7/13 8:55 AM, Andrei Alexandrescu wrote:
Here's a conformant implementation for reference:
http://www.scs.stanford.edu/histar/src/pkg/echo/echo.c
Hmm, that's actually not so good, it doesn't ensure that I/O was
successful. Anyhow, here's a possibility:
import std.stdout;
void main(string[] args)
{
const appendNewline = args.length 1 args[1] == -n;
foreach (i, arg; args[appendNewline + 1 .. $])
{
if (i) write(' ');
write(arg);
}
if (nl) writeln();
}
But then I figured echo must do escape character processing, see
e.g. http://www.raspberryginger.com/jbailey/minix/html/echo_8c-source.html.
With that the blog entry would become quite interesting.
If you want the specification, here it is :)
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
All fathers are intimidating. They're intimidating because they are
fathers. Once a man has children, for the rest of his life, his
attitude is, To hell with the world, I can make my own people. I'll eat
whatever I want. I'll wear whatever I want, and I'll create whoever
I want.
-- Jerry Seinfeld
Re: My first email to Walter, ever
On Sunday, 7 July 2013 at 12:27:02 UTC, Peter Alexander wrote:
On Sunday, 7 July 2013 at 03:03:03 UTC, Andrei Alexandrescu
wrote:
Terrible. If you have conditionals, iteration, functions, and
objects
in D's straight programming support, you should have
conditionals,
iteration, functions, and objects in D's metalanguage.
:-(
template allSatisfy(alias F, T...)
{
static if (T.length == 0)
{
enum allSatisfy = true;
}
else static if (T.length == 1)
{
enum allSatisfy = F!(T[0]);
}
else
{
enum allSatisfy =
allSatisfy!(F, T[ 0 .. $/2])
allSatisfy!(F, T[$/2 .. $ ]);
}
}
Still looks like half-assed functional programming to me.
Where's the iteration? Why can't I write this?
template allSatisfy(alias F, T...) {
foreach(t; T)
if (!F!(t))
return false;
return true;
}
(Those are rhetorical questions btw, before anyone links me to
a D tutorial).
We're almost there with CTFE, but CTFE can only run functions
that could run at runtime. In a crazy world where types were
first class objects, stuff like this would be feasible. Or
perhaps we just need a compile-time metalanguage that allows
things like this to be run with CTFE?
Static foreach would help, at least in my case:
http://forum.dlang.org/post/ebvrirxozwllqjbff...@forum.dlang.org
Sadly, there are more important issues (shared libs, 83 PRs in
dmd) so this will probably have to wait for better times.
Re: A very basic blog about D
On Sunday, 7 July 2013 at 20:08:19 UTC, Leandro Lucarella wrote:
Andrei Alexandrescu, el 7 de July a las 09:06 me escribiste:
On 7/7/13 8:55 AM, Andrei Alexandrescu wrote:
Here's a conformant implementation for reference:
http://www.scs.stanford.edu/histar/src/pkg/echo/echo.c
Hmm, that's actually not so good, it doesn't ensure that I/O
was
successful. Anyhow, here's a possibility:
import std.stdout;
void main(string[] args)
{
const appendNewline = args.length 1 args[1] == -n;
foreach (i, arg; args[appendNewline + 1 .. $])
{
if (i) write(' ');
write(arg);
}
if (nl) writeln();
}
But then I figured echo must do escape character processing,
see
e.g.
http://www.raspberryginger.com/jbailey/minix/html/echo_8c-source.html.
With that the blog entry would become quite interesting.
If you want the specification, here it is :)
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html
I prefer this one :p http://www.gnu.org/fun/jokes/echo-msg.html
From the opengroup spec:
If the first operand is -n, or if any of the operands contain a
backslash character, the results are implementation-defined.
Ah...specifications...
I'm gonna stick with normal linux implementation, as described
here: http://linux.die.net/man/1/echo
However, on my machine, echo --version claims it's part of the
GNU coreutils, but when you look at the coreutils docs:
http://www.gnu.org/software/coreutils/manual/html_node/echo-invocation.html#echo-invocation
You get the sentence the normally-special argument ‘--’ has no
special meaning and is treated like any other string., which
should preclude the identifying message being printed in the
first place!
Re: My first email to Walter, ever
On 7/7/2013 5:09 AM, Andrej Mitrovic wrote: On 7/7/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: While doing some unrelated research I stumbled upon my very first email to Walter, dated April 26, 2004. That's a cool teaser, but how did the discussion continue? :) Generally along these lines: And you, Scarecrow, have the effrontery to ask for a brain, you billowing bale of bovine fodder!
GDC D2 port status
Not sure this is common knowledge, as am still getting questions / propositions off people for this. Through collaboration of the gcc maintainers at Debian/Ubuntu, gdc has been merged in with the gcc source package, and is available for all architectures supported by Debian (albeit, with the majority shipping without a library). You can view binary packages here: http://packages.debian.org/sid/gdc-4.8 And for those interested, can track testsuite/unittester pass/failures at this link (Click on the installed, link, and do a search for gdc tests) https://buildd.debian.org/status/package.php?p=gcc-4.8 I think a thanks to Matthias and Peter are in order for their efforts for this. :) Obviously we will need to port at least druntime to these architectures that don't currently ship the D standard libraries to allow people to start using, and testing D on their favourite non-x86 architecture. Should be getting access to Debian port boxes pretty soon, but if anyone has any hardware running Debian, any donations or ssh access would be gladly appreciated. It would be good to get this done by the end of the year. Lastly, if anyone has ties with other distributions, it would be great to see if you can get talking with other distributions - in particular, fedora/centos - to see if we can get them to follow suit. As always, the agenda is lets show the world that D2 is both portable in implementation, and rox on their hardware. :o) Regards Iain.
Re: GDC D2 port status
Awesome! Would be great to see on the official Arch repos! :)
Re: My first email to Walter, ever
On Sunday, 7 July 2013 at 03:03:03 UTC, Andrei Alexandrescu wrote: * And if you really want to go meta, define metacode that can take an AST node as a parameter and can visit the AST and figure out what each node is. That would allow things such as loop fusion and other advanced stuff. But for now, let's leave those aside. h :P
Re: Fun with templates
On Saturday, 6 July 2013 at 23:11:26 UTC, Manu wrote: [..] I feel like it would be a much cleaner solution than any of the others presented in this thread... I think Artur's solution is the cleanest one because it changes the default behaviour to a more sensible one: it is useful to keep the full type information only if the type isn't implicitly convertible from immutable to mutable and back again... otherwise keeping the full type information along only causes inconvenience.
Re: Feature request: Path append operators for strings
On Saturday, 6 July 2013 at 22:25:59 UTC, Walter Bright wrote: On 7/5/2013 3:48 PM, H. S. Teoh wrote: For example, consider the sentence he's such an office Romeo!. It's relatively easy to parse -- no convoluted nested subordinate clauses or anything tricky like that. But it's extremely difficult for a machine to *interpret*, because to fully understand what office Romeo refers to, requires a cultural background of Shakespeare, the fact that he wrote a play in which there was a character named Romeo, what the role of that character is, what that implies about his personality, how that implication about his personality translates into an office context, and what it might mean when applied to someone other than said character. How to even remotely model such a thought process in a machine is an extremely hard problem indeed! Human speech is also littered with sarcasm, meaning reversal (that's one nasty car!), meaning based on who you are, your social status, age, etc., meaning based on who the recipient is, social status, age, etc. Etc. I can see machine translation that is based on statistical correlation with a sufficiently large corpus of human translations, but I don't see much hope for actual understanding of non-literal speech in the foreseeable future, and I'm actually rather glad of that. You haven't read Ray Kurzweil's latest books then or you just don't think he's right?
Re: Fun with templates
On 7 July 2013 16:02, TommiT tommitiss...@hotmail.com wrote: On Saturday, 6 July 2013 at 23:11:26 UTC, Manu wrote: [..] I feel like it would be a much cleaner solution than any of the others presented in this thread... I think Artur's solution is the cleanest one because it changes the default behaviour to a more sensible one: it is useful to keep the full type information only if the type isn't implicitly convertible from immutable to mutable and back again... otherwise keeping the full type information along only causes inconvenience. Maybe so, but I just have my suspicions that it will never fly, and I think a solution here is actually pretty important. This is demonstrably one of the biggest issues with C++, and since templates are so much more convenient in D, I expect time will show it to be far worse in D than it already is in C++.
Re: Poll: how long have you been into D
On Sat, 6 Jul 2013 14:08:20 -0700 H. S. Teoh hst...@quickfur.ath.cx wrote: I resisted upgrading to a smartphone for many years (people used to laugh at me for carrying around such a prehistoric antique -- to a point I took pride in showing it off to the kids), until the battery life started to wear out and require charging once a day. Finally I succumbed to my phone company who kept bugging me about upgrading (and of course, I chose an Android instead of an iPhone). Well, it's nice to upgrade, I suppose, but I found that I *still* have to recharge once a day 'cos of the battery drain from all those advanced features that were never there in the old phone. Sigh... Yea. I don't accept that smartphones are really phones. They're PDA's with telephony tacked on. Not saying that's necessarily a bad way to go - it's fine if PDA is your primary use-case. But if you're mainly interested in a phone it's not only complete overkill, but also the wrong set of design compromises. They do, like you say, soak up ridiculous amounts of battery power too. Especially Androids. Maybe it's all the VM/dynamic shit. I did generally get a couple days out of the iPhone (as long as I didn't play Rage), instead of the just *barely* one day I got with the Nexus S (even with the cellular stuff disabled). That may not sound too bad to some people, but with the phones, the near-daily recharging got to feel like an enormous ball-and-chain (not to mention *trying* to turn off the damn sound globally every night so the stupid things wouldn't wake me up for notifications and other shit that I don't care about when I'm sleeping). I already have enough shit to do every time I go to bed and wake up, I don't need that added to my daily overhead. I was *sooo* glad when the project I was doing ended and I got to send back the damn things (they were loaners) to the guy I was working for. Although, I probably will pick up a used WiFi-only Android at some point for development and because an internet-connected PDA does come in handy. I just wish that instead of Google iClone they were running some sort of PalmOS 9 or something (a modern version of the Palm Zire 71 with a multi-tasking wifi-internet-capable version of PalmOS 6 would make me geek out). And with a proper resistive screen and built-in stylus slot, none of that imprecise capacitive shit. And *real* freaking buttons (Even Android's gotten rid of the few buttons they used to have.) At least Android actually has a task manager that lets you kill off misbehaving apps and things that shouldn't be running that are taking up 50MB of RAM for no good reason. On my old iPod, I'd have to hard-reset every few days 'cos some misbehaving app would soak up 100% RAM and 100% CPU and the thing would brick. Yea, that's one of the zillions of things that bug me about iOS/Android: There's no equivalents to the taskbar or close program buttons. Sure, they both have something that pretends to be like a taskbar, but on Android it tosses in recently used stuff with no indication which ones are actually running. And on iOS - well, it *might* be working like a taskbar, but honestly I never could really tell what the hell its semantics were. I was always just *guessing* that it was the list of running programs...which made me wonder why it would (apparently?) keep freaking *everything* I was done using running in the background (at least, as far as I could tell). They're too damn opaque. At least Android actually has a decent task manager. It's just too bad you have to dig so far to get to it, which prevents it from being a real taskbar substitute. *And* I can actually write my own apps for Android without needing to buy a Mac just to install the dev tools. Amen to that. BTW, if you don't mind using a proprietary toolkit (Marmalade: http://madewithmarmalade.com), you *can* develop iOS stuff without ever having to touch a Mac. But to put it on your actual device you still have to pay Apple's Developer iRansom (well, or better yet just jailbreak the stupid thing instead). Last I heard you do still have to use a Mac to submit to the App Store, and again, you have to use that one particular proprietary toolkit (which also means no D), but at least it's *possible* to make iOS stuff without putting up with OSX. The only thing missing now is a working D dev environment for Android. Once I have *that*, then perhaps the smart in smartphone will be forgiveable, for once. :-P Yea, I really look forward to that, too.
Re: Unhelpful error messages
http://d.puremagic.com/issues/
Re: Current version of D.
On Sat, 2013-07-06 at 15:24 +0200, mike james wrote: The current release is 2.063.2, but it's the first time that we've actually released point releases like that, so there are likely to be places saying 2.063 instead of 2.063.2. Maybe it's time to make the odd-numbered releases the work in progress releases and the even-numbered releases the official releases? Everyone, cf. Linux, who used to operate such a strategy has now stopped. A release is a release and should be releasable. Finding problems in a release is natural which is why the maj.min.bug release numbering is so popular. The issue here is that the releases should be numbered this way always so as to make a monotonic increasing sequence. Thus 2.063 should have been numbered 2.63.0. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Poll: how long have you been into D
On Saturday, 6 July 2013 at 21:09:59 UTC, H. S. Teoh wrote: but I found that I *still* have to recharge once a day 'cos of the battery drain from all those advanced features that were never there in the old phone. Sigh... I heard, wifi consumes the lion share of battery charge, try to disable it.
Re Typing [ was Re: Poll: how long have you been into D ]
On Sat, 2013-07-06 at 08:13 -0700, H. S. Teoh wrote: […] Y'know, I've always found correct-as-you-type features extremely annoying. I encountered it first in MS Word, and it annoyed me so much I crawled back into my Vim cave. :-P When I upgraded to a smartphone, I decided to give it an honest try ... but after about half a year or so, I'm starting to regret it. I mean, it's nice that once in a while you can just type approximately and it will correctly guess what you intended. But other times, it makes the wrong guesses and completely mangles your text -- but you're so accustomed to it that you don't notice the mistake until it's too late! And yet other times, it will add random nonsense words to your custom dictionary just because you hit the wrong sequence of keys by accident. (Mistype a word, hit space, get the wrong guess, hit backspace, get the mistyped word back, erase a few characters, then accidentally hit space instead of, say, B, and now the *partial* mistyped word is in your dictionary. Wonderful.) I'm feeling quite tempted to turn off the feature, right now. On my Android phone, I am finding Swype to be extremely good most of the time. I tried the free tester and was sufficiently happy to pay money. I will be renewing the subscription which is of course the real test of happiness. Pop-up in IDEs are however another matter, they are so wrong so much of the time that I tend to switch them off or ignore them if I cannot do this – which is surprisingly difficult in some IDEs. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Smartphone properties [was Poll: how long have you been into D]
On Sun, 2013-07-07 at 09:38 +0200, Kagamin wrote: […] I heard, wifi consumes the lion share of battery charge, try to disable it. WiFi can be a big battery drain, but so is the screen, and (perhaps most importantly) the mobile aerial. The second of these is perhaps obvious, the first and third depend on distance to the receiver since the output signal of the phone is variable, the mobile signal much more than the WiFi. If a phone is continually searching for a mobile base station battery power will plummet. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Feature request: Path append operators for strings
On 7/6/2013 11:11 PM, TommiT wrote: I can see machine translation that is based on statistical correlation with a sufficiently large corpus of human translations, but I don't see much hope for actual understanding of non-literal speech in the foreseeable future, and I'm actually rather glad of that. You haven't read Ray Kurzweil's latest books then or you just don't think he's right? Spend a little quality time with Siri. I did, and discovered it was hardly any better than Eliza, which is a few lines of BASIC written in the 1970's.
Re: Feature request: Path append operators for strings
On 7/7/13 1:26 AM, Walter Bright wrote: On 7/6/2013 11:11 PM, TommiT wrote: I can see machine translation that is based on statistical correlation with a sufficiently large corpus of human translations, but I don't see much hope for actual understanding of non-literal speech in the foreseeable future, and I'm actually rather glad of that. You haven't read Ray Kurzweil's latest books then or you just don't think he's right? Spend a little quality time with Siri. I did, and discovered it was hardly any better than Eliza, which is a few lines of BASIC written in the 1970's. Ow come on. Andrei
Re: Fun with templates
On 07/07/13 08:22, Manu wrote:
On 7 July 2013 16:02, TommiT tommitiss...@hotmail.com
mailto:tommitiss...@hotmail.com wrote:
On Saturday, 6 July 2013 at 23:11:26 UTC, Manu wrote:
[..] I feel like it would be a much cleaner solution than any of
the others presented in this thread...
I think Artur's solution is the cleanest one because it changes the
default behaviour to a more sensible one: it is useful to keep the full type
information only if the type isn't implicitly convertible from immutable to
mutable and back again... otherwise keeping the full type information along
only causes inconvenience.
Maybe so, but I just have my suspicions that it will never fly, and I think a
solution here is actually pretty important.
This is demonstrably one of the biggest issues with C++, and since templates
are so much more convenient in D, I expect time will show it to be far worse
in D than it already is in C++.
It's like the virtual-by-default situation - if the default isn't fixed
everybody will ignoring this issue, until it actually becomes a problem.
Then they (or more likely somebody else) will have tp do a clean up pass,
and then the cycle will repeat. Almost nobody will start with
auto f(T=Unqual!_T)(_T val) { /*...*/ } // example new syntax
Fixing just IFTI should be relatively safe, affecting only a tiny
amount of code, if any. These kind of const changes happen more
or less randomly anyway, from the POV of the called function.
const a=1; f(a+a); f(a+1); -- this already creates two different
instances of 'f(T)(T).
Yeah, fixing the expression types would be an even better idea (so
that const int + const int == int etc) but that could have a
larger impact, as it would affect a lot of 'auto' declarations.
artur
Re: Fun with templates
On Sunday, 7 July 2013 at 06:22:17 UTC, Manu wrote:
On 7 July 2013 16:02, TommiT tommitiss...@hotmail.com wrote:
I think Artur's solution is the cleanest one [..]
Maybe so, but I just have my suspicions that it will never fly,
and I think a solution here is actually pretty important.
You think it won't fly because it's a breaking change? I also
think a solution is needed.
Earlier you said that your suggestion either is implementable or
it isn't. If you put it that way, the answer must be that it is
implementable, because if a problem is computable then it is
possible to write a compiler that can compute it given that
there's an ambiguous solution to the problem. But since compiler
writers are only human, I think there might the third possibility
which is that it's just a too big of an undertaking for a small
group of humans to write that compiler. For example here's an
example where the compiler would need to solve the equation:
cast(int) (3.5 ^^ x * x ^^ 4 + 5 * x) == 206
for x. And not only does the compiler need to figure out an
answer to the problem, it needs to figure out that there aren't
multiple answers to the problem.
struct Soo(int n) { }
template Too(int x)
{
alias Too = Soo!(cast(int) (3.5 ^^ x * x ^^ 4 + 5 * x));
}
void foo(int n)(Too!n) { }
void main()
{
Soo!206 s;
foo(s); // should call foo!2(s)
}
Re: Feature request: Path append operators for strings
On Sunday, 7 July 2013 at 08:26:03 UTC, Walter Bright wrote: On 7/6/2013 11:11 PM, TommiT wrote: I can see machine translation that is based on statistical correlation with a sufficiently large corpus of human translations, but I don't see much hope for actual understanding of non-literal speech in the foreseeable future, and I'm actually rather glad of that. You haven't read Ray Kurzweil's latest books then or you just don't think he's right? Spend a little quality time with Siri. I did, and discovered it was hardly any better than Eliza, which is a few lines of BASIC written in the 1970's. One word: Watson.
Re: Feature request: Path append operators for strings
On 7/7/2013 2:16 AM, John Colvin wrote: On Sunday, 7 July 2013 at 08:26:03 UTC, Walter Bright wrote: On 7/6/2013 11:11 PM, TommiT wrote: I can see machine translation that is based on statistical correlation with a sufficiently large corpus of human translations, but I don't see much hope for actual understanding of non-literal speech in the foreseeable future, and I'm actually rather glad of that. You haven't read Ray Kurzweil's latest books then or you just don't think he's right? Spend a little quality time with Siri. I did, and discovered it was hardly any better than Eliza, which is a few lines of BASIC written in the 1970's. One word: Watson. Ask Watson what its favorite color is. Oh well.
Re: Feature request: Path append operators for strings
On 7/7/2013 1:30 AM, Andrei Alexandrescu wrote: On 7/7/13 1:26 AM, Walter Bright wrote: On 7/6/2013 11:11 PM, TommiT wrote: I can see machine translation that is based on statistical correlation with a sufficiently large corpus of human translations, but I don't see much hope for actual understanding of non-literal speech in the foreseeable future, and I'm actually rather glad of that. You haven't read Ray Kurzweil's latest books then or you just don't think he's right? Spend a little quality time with Siri. I did, and discovered it was hardly any better than Eliza, which is a few lines of BASIC written in the 1970's. Ow come on. All Siri does is recognize a set of stock patterns, just like Eliza. Step out of that, even slightly, and it reverts to a default, again, just like Eliza. Of course, Siri had a much larger set of patterns it recognized, but with a bit of experimentation you quickly figure out what those stock patterns are. There's nothing resembling human understanding there.
Re: Fun with templates
Am Sat, 6 Jul 2013 20:24:41 +1000 schrieb Manu turkey...@gmail.com: On 6 July 2013 18:23, Namespace rswhi...@googlemail.com wrote: That doesn't do what I want at all. The signature is still f(T) not f(Unqual!T). For non-const, const and immutable inout would do it. void f(T)(inout T var) Not if there's more than 1 argument, and 'inout T' is still not 'T'. Hey, inout looks like a neat solution! And it only creates one template instance no matter how many arguments of type inout(T) you use! -- Marco
Emacs D Mode and __vector
It has been mooted that we actually formally release 2.0.6 of the Emacs D Mode. It has also been mooted that __vector is now an official part of D and should be highlighted accordingly. Is __vector part of D? If so what type of thing is it? Thanks. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Fun with templates
Am Sun, 7 Jul 2013 00:06:26 +1000
schrieb Manu turkey...@gmail.com:
On 6 July 2013 22:27, Namespace rswhi...@googlemail.com wrote:
The way that makes the most sense to me is:
void f(T)(Unqual!T t) {}
Given an immutable(T) for instance that I want to call with, it would
instantiate the template with the signature void f(T), and then attempt to
call it with the immutable(T). If immutable(T) is not convertible to the
argument T, then it would produce a compile error as if attempting to call
any such function that just receives T.
The point here is that I want more control over the signature of the
instantiated template (reduce the number of permutations generated for
various calls). Template blow-out is perhaps the biggest and most well
known day-to-day problem in C++, and tools like this may be very valuable
to mitigate the disaster.
It seems that your code works if you put the Template Type explicit:
import std.stdio;
import std.traits : Unqual;
void foo(T)(Unqual!T a) {
writeln(typeof(a).stringof, - , T.stringof);
}
void main() {
int a;
const int b;
immutable int c;
//foo(c); /// Error
foo!(typeof(a))(a);
foo!(typeof(b))(b);
foo!(typeof(c))(c);
}
Indeed, hence my point that the type deduction is the key issue here.
It should be possible... maybe a bit tricky though.
If you wanted to save on template instantiations for every
possible attribute combination, you are doing it wrong. Those
are already 3 duplicate templates with binary identical
functions foo(int a) in them, which makes me cry on the inside.
--
Marco
Re: Fun with templates
On Sunday, 7 July 2013 at 11:07:44 UTC, Marco Leise wrote:
Am Sat, 6 Jul 2013 20:24:41 +1000
schrieb Manu turkey...@gmail.com:
On 6 July 2013 18:23, Namespace rswhi...@googlemail.com
wrote:
That doesn't do what I want at all. The signature is still
f(T) not
f(Unqual!T).
For non-const, const and immutable inout would do it.
void f(T)(inout T var)
Not if there's more than 1 argument, and 'inout T' is still
not 'T'.
Hey, inout looks like a neat solution! And it only creates one
template instance no matter how many arguments of type
inout(T) you use!
const would have the same effect:
void f(T)(const T var) { ... }
...but then you can't mutate var.
Re: Feature request: Path append operators for strings
On Sunday, 7 July 2013 at 10:07:51 UTC, Walter Bright wrote: On 7/7/2013 2:16 AM, John Colvin wrote: One word: Watson. Ask Watson what its favorite color is. Oh well. That would require self-awareness. But self-awareness is not a requirement of understanding natural language as long as the speaker doesn't refer to the entity doing the understanding.
Re: Fun with templates
Am Sat, 06 Jul 2013 17:10:24 +0200
schrieb Dicebot pub...@dicebot.lv:
On Saturday, 6 July 2013 at 15:05:51 UTC, Artur Skawina wrote:
...
It is not that simple. Consider:
void f(T)(T t)
{
static if (T == Unqual!T)
// one function body
else
// completely different one
}
Currently every template instance is completely independent and
tied to exact type. I don't know of any tool to express group of
related types concept in D other than built-in inout.
Hmm, this inout stuff sounds like a possible solution...
--
Marco
Re: Fun with templates
Am Sun, 07 Jul 2013 01:04:52 +0400 schrieb Dmitry Olshansky dmitry.o...@gmail.com: I've seen an aggressive proposal back in the day to just do a shallow unqual on all aggregates passed by value. I came to the same conclusion. If feasible, type inference should always produce tail-const versions. Well, Rebinable!T then for classes. ;) It is really annoying to have value types like ints passed in as immutable/const, just because they were at the call site. Even for array slices arguments it's sometimes neat to be able to shrink the passed slice to remove elements that you don't need to process (whitespace, zeroes, ...) -- Marco
Re: Fun with templates
Am Sat, 06 Jul 2013 17:24:23 +0200 schrieb Dicebot pub...@dicebot.lv: On Saturday, 6 July 2013 at 01:35:09 UTC, Manu wrote: ... If this is about template bloat I think much better is to address problem in general. For example, internal linkage or strict export requirements - anything that will allow to inline and completely eliminate trivial templates leaving no traces of it in final executable. Less duplicate instantiations results in faster compile times. An area where DMD is really good and should strive to keep its pole position. -- Marco
Re: Emacs D Mode and __vector
On Sunday, 7 July 2013 at 11:11:54 UTC, Russel Winder wrote: Is __vector part of D? Yep, it's officially in the list of keywords and in the language spec. If so what type of thing is it? It's kind of a type constructor, like const, shared, etc., so I'd put it in that category for syntax highlighting.
Re: Fun with templates
Am Sun, 07 Jul 2013 13:17:23 +0200
schrieb TommiT tommitiss...@hotmail.com:
const would have the same effect:
void f(T)(const T var) { ... }
...but then you can't mutate var.
That doesn't handle shared.
--
Marco
Re: Unhelpful error messages
On Sunday, 7 July 2013 at 06:58:29 UTC, Maxim Fomin wrote: http://d.puremagic.com/issues/ Ironically, this isn't helpful. H. S. Teoh is opening up a discussion, not reporting a bug. The problem here is more general than this specific case. Any template constraint on any function could fail to pass, and the best error you'll get is that it couldn't match any function. Even if the error messages were improved to tell you what part of the constraint failed, you still have no idea *why* it failed (e.g. *why* is my range not a forward range?) Overloads just make matters exponentially worse. Not only can the compiler fail to provide a good error for a single function, but needs to provide a good error for every possible candidate function. If a constraint checks if another overloaded function is callable then you end up with a combinatorial explosion of reasons why your function didn't compile. It's a tough situation and I think the only way this could even reasonably be resolved is through some sophisticated IDE integration. There is no way to display this kind of error report in a blob of command line text.
Feature request: assert expressions should live inside version(assert)
Sometimes you need to have some extra data to check against in
the assert expression. That data isn't needed in release mode
when assertions are ignored. Therefore, you put that extra data
inside a version(assert). But then those assertions fail to
compile in release mode because the symbol lookup for that extra
data fails. For this reason, assert statements should live inside
version(assert) blocks by default.
Example:
version (assert)
{
const int[1000] maximums = 123;
}
void foo(int value, int index)
{
assert(value maximums[index]); // [1]
}
void main()
{
foo(11, 22);
}
[1] (In release mode) Error: undefined identifier maximums
...so you need to introduce a redundant version(assert):
void foo(int value, int index)
{
version (assert)
{
assert(value maximums[index]);
}
}
Re: Fun with templates
On Sunday, 7 July 2013 at 11:59:36 UTC, Marco Leise wrote:
Am Sun, 07 Jul 2013 13:17:23 +0200
schrieb TommiT tommitiss...@hotmail.com:
const would have the same effect:
void f(T)(const T var) { ... }
...but then you can't mutate var.
That doesn't handle shared.
That seems like a compiler bug to me.
Re: Feature request: assert expressions should live inside version(assert)
On 7/7/13, Tommi tommitiss...@hotmail.com wrote: Sometimes you need to have some extra data to check against in the assert expression. That data isn't needed in release mode when assertions are ignored. Therefore, you put that extra data inside a version(assert). But then those assertions fail to compile in release mode because the symbol lookup for that extra data fails. For this reason, assert statements should live inside version(assert) blocks by default. I've ran into an issue when implementing this feature back in February (see the pull request): http://d.puremagic.com/issues/show_bug.cgi?id=9450 https://github.com/D-Programming-Language/dmd/pull/1614
Re: Fun with templates
06-Jul-2013 05:34, Manu пишет:
Okay, so I feel like this should be possible, but I can't make it work...
I want to use template deduction to deduce the argument type, but I want
the function arg to be Unqual!T of the deduced type, rather than the
verbatim type of the argument given.
I've tried: void f(T : Unqual!U, U)(T a) {}
and: void f(T)(Unqual!T a) {}
The thing is that if even if you somehow force your way past IFTI what
would be generated is:
f!(const int)(int arg);
f!(immutable int)(int arg);
f!(shared int)(int arg);
f!(const shared int)(int arg);
Which IMHO falls short of desired goal.
Short of using a forwarding thunk (that you don't like, but if there was
force_inline?) we'd have to hack the compiler.
Ie, if called with:
const int x;
f(x);
Then f() should be generated void f(int) rather than void f(const int).
I don't want a million permutations of the template function for each
combination of const/immutabe/shared/etc, which especially blows out
when the function has 2 or more args.
Note: T may only be a primitive type. Obviously const(int*) can never be
passed to int*.
--
Dmitry Olshansky
Re: Feature request: Path append operators for strings
On Sunday, 7 July 2013 at 10:07:51 UTC, Walter Bright wrote: On 7/7/2013 2:16 AM, John Colvin wrote: On Sunday, 7 July 2013 at 08:26:03 UTC, Walter Bright wrote: On 7/6/2013 11:11 PM, TommiT wrote: I can see machine translation that is based on statistical correlation with a sufficiently large corpus of human translations, but I don't see much hope for actual understanding of non-literal speech in the foreseeable future, and I'm actually rather glad of that. You haven't read Ray Kurzweil's latest books then or you just don't think he's right? Spend a little quality time with Siri. I did, and discovered it was hardly any better than Eliza, which is a few lines of BASIC written in the 1970's. One word: Watson. Ask Watson what its favorite color is. Oh well. That's asking for an awful lot more than good natural language processing.
Re: Feature request: assert expressions should live inside version(assert)
On Sunday, 7 July 2013 at 12:30:28 UTC, Andrej Mitrovic wrote: I've ran into an issue when implementing this feature back in February (see the pull request): http://d.puremagic.com/issues/show_bug.cgi?id=9450 https://github.com/D-Programming-Language/dmd/pull/1614 WTF: Hmm.. I think we might have to close the report as invalid. The trouble is, you can't just ignore running semantic during -release because the assert expression could be a compile-time false value, which turns the assert into a halt instruction regardless of the -release switch. I had no idea of this. What a terrible decision!
Re: Feature request: assert expressions should live inside version(assert)
On Sunday, 7 July 2013 at 12:30:28 UTC, Andrej Mitrovic wrote: On 7/7/13, Tommi tommitiss...@hotmail.com wrote: Sometimes you need to have some extra data to check against in the assert expression. That data isn't needed in release mode when assertions are ignored. Therefore, you put that extra data inside a version(assert). But then those assertions fail to compile in release mode because the symbol lookup for that extra data fails. For this reason, assert statements should live inside version(assert) blocks by default. I've ran into an issue when implementing this feature back in February (see the pull request): http://d.puremagic.com/issues/show_bug.cgi?id=9450 https://github.com/D-Programming-Language/dmd/pull/1614 Oh, should have searched bugzilla before posting this. But would it be possible to implement it something like: During a release build, even though version(assert) blocks are compiled out of existence, the compiler would keep a separate list of symbols (and other info) of the things declared inside those version(assert) blocks. Then, when parsing assert expressions, if an undefined symbol is found, the compiler would check that separate list of symbols that it has been keeping, and if the symbol is found there and use of the symbol is syntactically correct, the compiler would just keep on going instead of spewing an unidentified identifier error. That way we'd make sure that things like: assert(this_identifier_doesnt_exist 12); ...wouldn't compile.
Re: Feature request: assert expressions should live inside version(assert)
On Sunday, 7 July 2013 at 13:12:06 UTC, Tommi wrote: [..] Then, when parsing assert expressions, if an undefined symbol is found, the compiler would check that separate list of symbols that it has been keeping, and if the symbol is found there and use of the symbol is syntactically correct, the compiler would just keep on going instead of spewing an unidentified identifier error. One thing that might also help there, is the fact that once an unidentified identifier is encountered in an assert expression and that same identifier is found on that separate list of things we've been keeping, then we know that the current assert expression can only end up either being an unidentified identifier error or being compiled out of existence, but it can't end up being turned into an assert(0).
Re: Struct hidden context pointers
On 6 July 2013 22:41, Jonathan M Davis jmdavisp...@gmx.com wrote: On Saturday, July 06, 2013 14:13:29 H. S. Teoh wrote: Shouldn't the frame pointer be generated only if f() actually tries to access something outside of the definition of T? Probably, but that's arguably an optimization. Regardless, marking it as static will force the issue. An optimization that is on similar boundaries as virtual by default. :) What I see is a non-POD nested struct, one that requires a 'this' pointer to the outer context to be set-up. However I know that gdc probably smarter than the front-end implementation about this in that it (the gcc glue part of the front-end) will acknowledge that there's no outer context and will set the outer 'this' pointer to null. Whilst still producing an error if a non-static member tries to access it's outer context in this situation. -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Feature request: assert expressions should live inside version(assert)
07.07.2013 17:12, Tommi пишет: On Sunday, 7 July 2013 at 12:30:28 UTC, Andrej Mitrovic wrote: On 7/7/13, Tommi tommitiss...@hotmail.com wrote: Sometimes you need to have some extra data to check against in the assert expression. That data isn't needed in release mode when assertions are ignored. Therefore, you put that extra data inside a version(assert). But then those assertions fail to compile in release mode because the symbol lookup for that extra data fails. For this reason, assert statements should live inside version(assert) blocks by default. I've ran into an issue when implementing this feature back in February (see the pull request): http://d.puremagic.com/issues/show_bug.cgi?id=9450 https://github.com/D-Programming-Language/dmd/pull/1614 Oh, should have searched bugzilla before posting this. But would it be possible to implement it something like: During a release build, even though version(assert) blocks are compiled out of existence, the compiler would keep a separate list of symbols (and other info) of the things declared inside those version(assert) blocks. Then, when parsing assert expressions, if an undefined symbol is found, the compiler would check that separate list of symbols that it has been keeping, and if the symbol is found there and use of the symbol is syntactically correct, the compiler would just keep on going instead of spewing an unidentified identifier error. That way we'd make sure that things like: assert(this_identifier_doesnt_exist 12); ...wouldn't compile. It's always a bad idea to add special cases like this one for `version(assert)`. Anyway one will get into huge troubles trying to implement such stuff as I even can't imagine how it can be implemented consistently. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Feature request: assert expressions should live inside version(assert)
On Sunday, 7 July 2013 at 13:12:06 UTC, Tommi wrote:
But would it be possible to implement it something like:
[..]
Although, I don't know if the best possible behaviour is to
silently compile the following assert out of existence in release
mode:
version (assert)
{
enum cond = false;
}
void main()
{
assert(cond);
}
A better behaviour probably would be to spew a warning message
asking the user if he's sure he knows what he's doing.
Then, yet another solution (a code breaking one) would be to make
it so that only literally saying:
assert(0);
or
assert(false);
or
assert(null);
...would exhibit that special assert behaviour.
Anything else would be semantically runtime-evaluated and no
other forms of assert would remain in release builds. For
example, this kind of an assert would be compiled out of
existence in release mode:
enum bool cond = false;
assert(cond);
Re: Feature request: assert expressions should live inside version(assert)
On Sunday, 7 July 2013 at 13:42:52 UTC, Tommi wrote: Then, yet another solution (a code breaking one) would be to make it so that only literally saying: assert(0); or assert(false); or assert(null); ...would exhibit that special assert behaviour. Anything else would be semantically runtime-evaluated and no other forms of assert would remain in release builds. For example, this kind of an assert would be compiled out of existence in release mode: enum bool cond = false; assert(cond); The programmer can always work around this new behaviour. Old code: enum bool shouldHalt = someExpression(); assert(shouldHalt); New code: enum bool shouldHalt = someExpression(); static if (shouldHalt) assert(0);
Re: Feature request: Path append operators for strings
On 7/7/13 3:07 AM, Walter Bright wrote: On 7/7/2013 1:30 AM, Andrei Alexandrescu wrote: On 7/7/13 1:26 AM, Walter Bright wrote: On 7/6/2013 11:11 PM, TommiT wrote: I can see machine translation that is based on statistical correlation with a sufficiently large corpus of human translations, but I don't see much hope for actual understanding of non-literal speech in the foreseeable future, and I'm actually rather glad of that. You haven't read Ray Kurzweil's latest books then or you just don't think he's right? Spend a little quality time with Siri. I did, and discovered it was hardly any better than Eliza, which is a few lines of BASIC written in the 1970's. Ow come on. All Siri does is recognize a set of stock patterns, just like Eliza. Step out of that, even slightly, and it reverts to a default, again, just like Eliza. Of course, Siri had a much larger set of patterns it recognized, but with a bit of experimentation you quickly figure out what those stock patterns are. There's nothing resembling human understanding there. But that applies to humans, too - they just have a much larger set of patterns they recognize. But they don't overlap perfectly for all humans. Try to ask your mailman whether a hash table is better than a singly-linked list for a symbol table. Andrei
Re: Emacs D Mode and __vector
On Sun, 2013-07-07 at 13:53 +0200, Peter Alexander wrote: On Sunday, 7 July 2013 at 11:11:54 UTC, Russel Winder wrote: Is __vector part of D? Yep, it's officially in the list of keywords and in the language spec. If so what type of thing is it? It's kind of a type constructor, like const, shared, etc., so I'd put it in that category for syntax highlighting. Thanks, I have amended the mode file accordingly. I have also marked it as 2.0.6-RC-1. MELPA should automatically update, so Emacs 24 users using packaging should just get the update. Others will need to download from the GitHub repository – it is just a single file :-) In two weeks time, if there are no problems reported, I will tag the repository and formally release this as 2.0.6. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Poll: how long have you been into D
On 07/06/2013 02:20 PM, Nick Sabalausky wrote: On Fri, 05 Jul 2013 23:48:40 -0700 Jonathan M Davis jmdavisp...@gmx.com wrote: On Saturday, July 06, 2013 08:36:31 Joseph Rushton Wakeling wrote: Typing replies on a smartphone seems to carry a bit of a cost in textual accuracy :-( Typing on smartphones is hell. I generally try and avoid it unless I absolutely have to. +1k. I genuinely miss Palm's Graffiti 1...Thanks, Xerox! (And tactile inputs in general, which Apple killed off and everyone else now idiotically apes.) I like being able to, for example, switch songs and adjust volume while driving or walking without having to bury my head in a tiny screen to do so, like some twitter-obsessed social-whore Millennial. Anyway, typing on a mobile device was more or less a solved problem until that sack of shit Steve Jobs moronically convinced everyone that physical buttons and styluses were bad things (Remember, that was the same dumbass who was convinced that Ctrl-Click was simpler for average users than Right-Click, and that Hold Up For 5 Seconds was a more sensible way to turn a device off than a power button or switch). And so *now* PDAs (erm, I mean smartphones) are horrible to type on. Please, I still have a physical keyboard on my new smartphone. Put your money where your mouth is.
Re: Poll: how long have you been into D
On Sunday, 7 July 2013 at 17:37:37 UTC, 1100110 wrote: Please, I still have a physical keyboard on my new smartphone. Put your money where your mouth is. I must admit it becomes increasingly harder to find ones. I am not ware of a single new model that has both physical keyboard and less than 4.5 screen. Any hints?
Re: Fun with templates
On Saturday, 6 July 2013 at 18:54:16 UTC, TommiT wrote: He's talking about changing the semantics only on POD types, like int, struct of ints, static array of ints... only types that can implicitly convert from immutable to mutable. Than it does not really solve anything. Have you measured how much template bloat comes from common meta-programming tools like std.algorithm and how much - from extra instances for qualified POD types? It is better to solve broad problem instead and get this special case for free, not add more special cases in a desperate attempts to contain it.
Re: Poll: how long have you been into D
On Sunday, 7 July 2013 at 17:37:37 UTC, 1100110 wrote: On 07/06/2013 02:20 PM, Nick Sabalausky wrote: Anyway, typing on a mobile device was more or less a solved problem until that sack of shit Steve Jobs moronically convinced everyone that physical buttons and styluses were bad things (Remember, that was the same dumbass who was convinced that Ctrl-Click was simpler for average users than Right-Click, and that Hold Up For 5 Seconds was a more sensible way to turn a device off than a power button or switch). And so *now* PDAs (erm, I mean smartphones) are horrible to type on. Please, I still have a physical keyboard on my new smartphone. Put your money where your mouth is. Yep, it's out there, well-reviewed too, though you _will_ have to put some money on it: http://www.notebookcheck.net/Review-BlackBerry-Q10-Smartphone.95264.0.html Personally, I got my first real smartphone a couple months back and I don't see why anyone would want to type on these things in the first place. I do a little bit to load some webpages or dial a new phone number occasionally, but that's about it. I don't understand why one of these mobile apps doesn't do voice messages instead, who the hell wants to type their messages out? It's a step backwards from voice mail, even considering the shitty voicemail boxes that most telcos provide. Anyway, everybody uses apps like Whatsapp these days, so you could just record voice messages on the app. Maybe you can't speak your message out loud occasionally, privacy or sensitive information, so you could add text messages as a fallback, but I don't understand the current fascination with low-bandwidth typing when we have higher-bandwidth voice on all these phones.
Re: Poll: how long have you been into D
On Sunday, 7 July 2013 at 17:44:20 UTC, Dicebot wrote: On Sunday, 7 July 2013 at 17:37:37 UTC, 1100110 wrote: Please, I still have a physical keyboard on my new smartphone. Put your money where your mouth is. I must admit it becomes increasingly harder to find ones. I am not ware of a single new model that has both physical keyboard and less than 4.5 screen. Any hints? http://www.sonymobile.com/gb/products/phones/xperia-pro/gallery/ or any other sony phone with pro in the name. I used to have the xperia-mini-pro and was very pleased with it, but the small screen got annoying. I guess none of them count as that new though.
Re: Poll: how long have you been into D
On Sunday, 7 July 2013 at 17:56:58 UTC, John Colvin wrote: I guess none of them count as that new though. Yeah, Android 2.3 has some legacy smell :) Looks nice, wish they released something similar but with fresh h/w and OS. Still may work with some cyanogen magic, thanks!
Re: Poll: how long have you been into D
On Sunday, 7 July 2013 at 17:44:20 UTC, Dicebot wrote: I must admit it becomes increasingly harder to find ones. I am not ware of a single new model that has both physical keyboard and less than 4.5 screen. Any hints? Blackberry Q10 = 3.1 with 720 x 720 resolution: http://tech.fortune.cnn.com/2013/06/23/youre-going-to-love-the-blackberry-q10-or-hate-it/ But be careful, because for what I saw, BB is in trouble to achieve Google and Apple's success: http://money.cnn.com/2013/06/28/technology/mobile/blackberry-earnings/index.html Matheus.
Re: Poll: how long have you been into D
On Sunday, 7 July 2013 at 18:09:24 UTC, MattCoder wrote: Blackberry Q10 = 3.1 with 720 x 720 resolution: Any piece of hardware I can't install some custom tweaked OS on is not an option and RIM attitude has always sucked hard in that regard. That is not something I will support with my money.
Re: Anybody using D's COM objects?
Am 06.07.2013 05:00, schrieb Andrej Mitrovic: On 6/26/13, Sönke Ludwig slud...@outerproduct.org wrote: Am 25.06.2013 20:29, schrieb Walter Bright: Any projects using AddRef() and Release()? I'm currently using it for Direct2D and Direct3D 9/10/11. Also, I have an MIDL - D translator for WinRT and plan to make a language projection for it as well. Are there any recent bindings to D3D/D2D for D? I remember trying some from dsource a long while ago but it didn't work. How are you using D3D? I'm using a modified version of the bindings project on dsource and recently hand ported some D2D 1.1 and D3D 11.1 headers to be able to target WinRT applications, but those are still pretty much untested (will happen in the coming days). I can merge my changes back to the bindings project and make a pull request once I have finished the WinRT stuff.
Re: Fun with templates
On Sunday, 7 July 2013 at 17:48:17 UTC, Dicebot wrote:
On Saturday, 6 July 2013 at 18:54:16 UTC, TommiT wrote:
He's talking about changing the semantics only on POD types,
like int, struct of ints, static array of ints... only types
that can implicitly convert from immutable to mutable.
Than it does not really solve anything. Have you measured how
much template bloat comes from common meta-programming tools
like std.algorithm and how much - from extra instances for
qualified POD types? It is better to solve broad problem
instead and get this special case for free, not add more
special cases in a desperate attempts to contain it.
Basically all I know about the performance issue being discussed
here is that: Code bloat is bad, m'kay. But note that Artur's
suggestion would also change language semantics to a more
sensible and convenient default. For example:
void foo(T)(T value)
if (isIntegral!T)
{
value = 42;
}
...I can feel free to mutate 'value' without having to worry
about somebody breaking my function by calling it with an
argument of type like const(int), immutable(short), shared(long)
...
Re: Feature request: Path append operators for strings
On 7/7/2013 8:38 AM, Andrei Alexandrescu wrote: All Siri does is recognize a set of stock patterns, just like Eliza. Step out of that, even slightly, and it reverts to a default, again, just like Eliza. Of course, Siri had a much larger set of patterns it recognized, but with a bit of experimentation you quickly figure out what those stock patterns are. There's nothing resembling human understanding there. But that applies to humans, too - they just have a much larger set of patterns they recognize. I don't buy that. Humans don't process data like computers do. But they don't overlap perfectly for all humans. Try to ask your mailman whether a hash table is better than a singly-linked list for a symbol table. A mailman can (will) also do things like pretend to know, make up a plausible answer, ask clarifying questions, figure it out, etc. Computers don't, for example, figure it out. They do not reason. Regex is not a thought process.
Re: Feature request: Path append operators for strings
On 7/7/2013 5:41 AM, John Colvin wrote: On Sunday, 7 July 2013 at 10:07:51 UTC, Walter Bright wrote: Ask Watson what its favorite color is. Oh well. That's asking for an awful lot more than good natural language processing. Is it? Yes, that's a serious question. I don't presume that human language is something independent from our self-awareness.
Re: Feature request: Path append operators for strings
On Sunday, 7 July 2013 at 20:38:31 UTC, Walter Bright wrote: On 7/7/2013 5:41 AM, John Colvin wrote: On Sunday, 7 July 2013 at 10:07:51 UTC, Walter Bright wrote: Ask Watson what its favorite color is. Oh well. That's asking for an awful lot more than good natural language processing. Is it? Yes, that's a serious question. I don't presume that human language is something independent from our self-awareness. Fair point. There is, however, a reasonable subset of language (note: not subset of words, phrases or grammar explicitly) that can be interpreted without said self-awareness.
Re: Struct hidden context pointers
On Sunday, July 07, 2013 14:30:12 Iain Buclaw wrote: On 6 July 2013 22:41, Jonathan M Davis jmdavisp...@gmx.com wrote: On Saturday, July 06, 2013 14:13:29 H. S. Teoh wrote: Shouldn't the frame pointer be generated only if f() actually tries to access something outside of the definition of T? Probably, but that's arguably an optimization. Regardless, marking it as static will force the issue. An optimization that is on similar boundaries as virtual by default. :) Indeed, though the compiler has a much better chance of determining that a nested function can be made static than determining that a virtual function can be made non-virtual. - Jonathan M Davis
Re: Feature request: Path append operators for strings
On Sunday, July 07, 2013 13:38:33 Walter Bright wrote: On 7/7/2013 5:41 AM, John Colvin wrote: On Sunday, 7 July 2013 at 10:07:51 UTC, Walter Bright wrote: Ask Watson what its favorite color is. Oh well. That's asking for an awful lot more than good natural language processing. Is it? Yes, that's a serious question. I don't presume that human language is something independent from our self-awareness. Well, it _is_ considered to be an AI-complete problem. http://en.wikipedia.org/wiki/AI-complete - Jonathan M Davis
Re: Feature request: Path append operators for strings
On Sunday, 7 July 2013 at 10:07:51 UTC, Walter Bright wrote: Ask Watson what its favorite color is. Ask /me/ what my favorite color is. I always hate questions like that because, and this might sound silly, but it bothers me because if I pick one, I think the others will feel left out, and I feel bad about that. Maybe this is an effect of me being picked last in gym for all those years in school. I'm not even that bad at sports! Anyway, the worst was when a friend would take me with her to the mall to shop, something she did a lot. Which shoes do I like better? idk, I might find one style weird, but who am /I/ to judge something for being weird? I don't think I'd want a computer that is too much like us!
Re: Feature request: Path append operators for strings
On 7/7/13 1:35 PM, Walter Bright wrote: A mailman can (will) also do things like pretend to know, make up a plausible answer, ask clarifying questions, figure it out, etc. Siri can also reply by doing a google search and reading the result. Computers don't, for example, figure it out. They do not reason. Regex is not a thought process. This started with you claiming that Siri is just Eliza with more memory. That's inaccurate to say the least. Andrei
Re: Feature request: Path append operators for strings
On 7/7/2013 2:11 PM, Andrei Alexandrescu wrote: On 7/7/13 1:35 PM, Walter Bright wrote: A mailman can (will) also do things like pretend to know, make up a plausible answer, ask clarifying questions, figure it out, etc. Siri can also reply by doing a google search and reading the result. Right, that's what it does when it doesn't match the pattern. There's no understanding at all. Computers don't, for example, figure it out. They do not reason. Regex is not a thought process. This started with you claiming that Siri is just Eliza with more memory. That's inaccurate to say the least. I argue it is dead on. I don't see a fundamental difference. Siri matches your statement against a set of canned patterns (just like Eliza) and gives a canned answer. Failing that, it feeds it to a search engine (Eliza, of course, had no search engine, so it just gave a canned default response). Back in college, I wrote a Zork-style game, and spent some time programming recognition of various patterns, enough to see what's happening behind the curtain with Siri. If you're not familiar with how these things work, it can superficially appear to be magical at understanding you, but nothing of the sort is happening. I'm sure Apple collects statements sent to Siri, looks at them, and regularly adds more patterns. But it's just that - more patterns. (Ask Siri to open the pod bay doors, for example.) I think Siri does a mahvelous job of voice recognition - but that's not what we're talking about.
Re: Feature request: Path append operators for strings
On 7/7/2013 2:05 PM, Adam D. Ruppe wrote: On Sunday, 7 July 2013 at 10:07:51 UTC, Walter Bright wrote: Ask Watson what its favorite color is. Ask /me/ what my favorite color is. I always hate questions like that because, and this might sound silly, but it bothers me because if I pick one, I think the others will feel left out, and I feel bad about that. Maybe this is an effect of me being picked last in gym for all those years in school. I'm not even that bad at sports! Anyway, the worst was when a friend would take me with her to the mall to shop, something she did a lot. Which shoes do I like better? idk, I might find one style weird, but who am /I/ to judge something for being weird? I don't think I'd want a computer that is too much like us! Exactly. Can you see Watson generating a response like yours? I don't, either. The top hit on google for that question is: http://www.youtube.com/watch?v=pWS8Mg-JWSg The people typing that into google are probably looking for that clip, they are not asking google what google's favorite color is. Google, of course, is programmed to be a search engine, not process natural language for anything other than search. If I was asked that question, the context would matter. If it was at a barbeque with the beer flowing, I'd answer blue, no ye- .. ahhg! If an architect working for me asked, I'd give a serious answer, and of course even that answer would depend on the context - I'd pick different colors for the kitchen walls than the bedroom floor. Good luck with Watson or Siri on such.
Re: Feature request: Path append operators for strings
On 7/7/13 2:44 PM, Walter Bright wrote: This started with you claiming that Siri is just Eliza with more memory. That's inaccurate to say the least. I argue it is dead on. I don't see a fundamental difference. Consider someone at a 1970s level of compiler technology coming to you and telling you in all seriousness: Yeah, I tried your D language. A few more keywords and tricks. Compiler supports lines over 80 columns. Other than that, it has nothing over Fortran77. Knowing the wealth of research and development in programming languages since then, you'd know that that's just an ignorant statement and would not even take the time to get offended. Similarly, it would be an ignorant thing to say that Siri is just a larger Eliza. There is a world of difference between Eliza's and Siri's approaches. In fact the difference is even larger than between 1970s compilers and today's ones. For a simple example, in the 1990s NLP has definitely departed from rule-based models to statistical models. I don't know of a similarly large change in programming language technology. Andrei
Re: Poll: how long have you been into D
On Sun, Jul 07, 2013 at 02:38:15AM -0400, Nick Sabalausky wrote: On Sat, 6 Jul 2013 14:08:20 -0700 H. S. Teoh hst...@quickfur.ath.cx wrote: I resisted upgrading to a smartphone for many years (people used to laugh at me for carrying around such a prehistoric antique -- to a point I took pride in showing it off to the kids), until the battery life started to wear out and require charging once a day. Finally I succumbed to my phone company who kept bugging me about upgrading (and of course, I chose an Android instead of an iPhone). Well, it's nice to upgrade, I suppose, but I found that I *still* have to recharge once a day 'cos of the battery drain from all those advanced features that were never there in the old phone. Sigh... Yea. I don't accept that smartphones are really phones. They're PDA's with telephony tacked on. Ah, what's in a name? If they want to call PDA's with telephony smartphones then so be it. I wouldn't sweat it with names that are arbitrary anyways. Not saying that's necessarily a bad way to go - it's fine if PDA is your primary use-case. But if you're mainly interested in a phone it's not only complete overkill, but also the wrong set of design compromises. I guess the whole point was to have PDA functionality that included telephony so that you didn't have to carry two devices around? Mind you, having two devices isn't always a bad thing... try looking up something buried deep in the device while talking on the phone, for example. A royal pain when it's the same device! They do, like you say, soak up ridiculous amounts of battery power too. Especially Androids. Really? I didn't find my Android significantly worse in battery usage than my old iPod (and that was an *iPod*, not an iPhone). Or maybe both are equally bad. :-P Maybe it's all the VM/dynamic shit. I did generally get a couple days out of the iPhone (as long as I didn't play Rage), instead of the just *barely* one day I got with the Nexus S (even with the cellular stuff disabled). That may not sound too bad to some people, but with the phones, the near-daily recharging got to feel like an enormous ball-and-chain (not to mention *trying* to turn off the damn sound globally every night so the stupid things wouldn't wake me up for notifications and other shit that I don't care about when I'm sleeping). I already have enough shit to do every time I go to bed and wake up, I don't need that added to my daily overhead. Yeah ever since my wife got an iPhone, our attempts to fall asleep have been constantly interrupted by annoying dings and zings every so often from stray emails, notifications, people sending text messages in the middle of the night for no good reason, etc.. We try to make the best of it, though. I set my morning alarm to a rooster call, and she set hers to dogs barking. A hilarious way to wake up. :-P [...] At least Android actually has a task manager that lets you kill off misbehaving apps and things that shouldn't be running that are taking up 50MB of RAM for no good reason. On my old iPod, I'd have to hard-reset every few days 'cos some misbehaving app would soak up 100% RAM and 100% CPU and the thing would brick. Yea, that's one of the zillions of things that bug me about iOS/Android: There's no equivalents to the taskbar or close program buttons. Sure, they both have something that pretends to be like a taskbar, but on Android it tosses in recently used stuff with no indication which ones are actually running. Just long-click the 'task manager' icon to the front screen and you can fire it up to kill off stray apps whenever you want. :-P And on iOS - well, it *might* be working like a taskbar, but honestly I never could really tell what the hell its semantics were. I was always just *guessing* that it was the list of running programs...which made me wonder why it would (apparently?) keep freaking *everything* I was done using running in the background (at least, as far as I could tell). Yeah I could never figure out what was running in the background on my old iPod. And couldn't find a way to manage background tasks either. It would just run slower and slower until a crawl, and then finally just freeze and fail to respond to anything (or run at 1 screen update every 5 minutes -- completely unusable). Then it's time for the two-finger salute -- power + home for 10 seconds to hard-reboot the contraption. After I got all the data and apps I needed on my Android, I retired the iPod and haven't turned back since. They're too damn opaque. At least Android actually has a decent task manager. It's just too bad you have to dig so far to get to it, which prevents it from being a real taskbar substitute. You *could* just move it to your front screen, y'know! ;-) That's what the home button's for. Two clicks to kill off a misbehaving app (of which there are too many, sad to say -- browsers being one of the frequent offenders).
Re: Feature request: Path append operators for strings
On Sun, Jul 07, 2013 at 04:03:39PM -0700, Andrei Alexandrescu wrote: On 7/7/13 2:44 PM, Walter Bright wrote: This started with you claiming that Siri is just Eliza with more memory. That's inaccurate to say the least. I argue it is dead on. I don't see a fundamental difference. Consider someone at a 1970s level of compiler technology coming to you and telling you in all seriousness: Yeah, I tried your D language. A few more keywords and tricks. Compiler supports lines over 80 columns. Other than that, it has nothing over Fortran77. Knowing the wealth of research and development in programming languages since then, you'd know that that's just an ignorant statement and would not even take the time to get offended. Similarly, it would be an ignorant thing to say that Siri is just a larger Eliza. There is a world of difference between Eliza's and Siri's approaches. In fact the difference is even larger than between 1970s compilers and today's ones. For a simple example, in the 1990s NLP has definitely departed from rule-based models to statistical models. I don't know of a similarly large change in programming language technology. [...] I look forward to the day programs will be written by statistical models. Random failure FTW! :-P Oh wait, it's already been done: http://p-nand-q.com/humor/programming_languages/java2k.html :-P T -- Doubtless it is a good thing to have an open mind, but a truly open mind should be open at both ends, like the food-pipe, with the capacity for excretion as well as absorption. -- Northrop Frye
Re: Feature request: Path append operators for strings
On 7/7/2013 4:03 PM, Andrei Alexandrescu wrote: Similarly, it would be an ignorant thing to say that Siri is just a larger Eliza. There is a world of difference between Eliza's and Siri's approaches. In fact the difference is even larger than between 1970s compilers and today's ones. I don't know how Siri is implemented. If it is using modern approaches, I'd love to sit down with you sometime and learn about it.
Re: Fun with templates
On 7 July 2013 22:31, Dmitry Olshansky dmitry.o...@gmail.com wrote:
06-Jul-2013 05:34, Manu пишет:
Okay, so I feel like this should be possible, but I can't make it work...
I want to use template deduction to deduce the argument type, but I want
the function arg to be Unqual!T of the deduced type, rather than the
verbatim type of the argument given.
I've tried: void f(T : Unqual!U, U)(T a) {}
and: void f(T)(Unqual!T a) {}
The thing is that if even if you somehow force your way past IFTI what
would be generated is:
f!(const int)(int arg);
f!(immutable int)(int arg);
f!(shared int)(int arg);
f!(const shared int)(int arg);
Which IMHO falls short of desired goal.
Short of using a forwarding thunk (that you don't like, but if there was
force_inline?) we'd have to hack the compiler.
Hmmm, this is an interesting point.
I initially thought this was desirable, it could be useful.
But now that you point it out, I guess the point you are making is that
they will all mangle separately anyway?
That seems problematic, because since all have the same return value and
physical arguments, how does the compiler choose an overload to call in
various circumstances?
I think I (mistakenly?) presumed they would all mangle the same, since they
have the same physical signature (return value + physical args), and
therefore all be the same function (eliminating the duplicates).
Re: Feature request: Path append operators for strings
On Sun, Jul 7, 2013 at 6:11 PM, Walter Bright newshou...@digitalmars.comwrote: On 7/7/2013 4:03 PM, Andrei Alexandrescu wrote: Similarly, it would be an ignorant thing to say that Siri is just a larger Eliza. There is a world of difference between Eliza's and Siri's approaches. In fact the difference is even larger than between 1970s compilers and today's ones. I don't know how Siri is implemented. If it is using modern approaches, I'd love to sit down with you sometime and learn about it. Can't speak for Siri, but the deep learning architecture used in google now has little to do with Eliza. Nor is the recognition accuracy. Try it if you haven't!
Re: Fun with templates
On 07/07/2013 01:19 PM, Marco Leise wrote: If you wanted to save on template instantiations for every possible attribute combination, you are doing it wrong. Those are already 3 duplicate templates with binary identical functions foo(int a) in them, which makes me cry on the inside. There is a linker optimization to get rid of the duplicates. http://msdn.microsoft.com/en-us/library/bxwfs976(v=vs.110).aspx
Re: Feature request: Path append operators for strings
On 7/7/13 6:11 PM, Walter Bright wrote: On 7/7/2013 4:03 PM, Andrei Alexandrescu wrote: Similarly, it would be an ignorant thing to say that Siri is just a larger Eliza. There is a world of difference between Eliza's and Siri's approaches. In fact the difference is even larger than between 1970s compilers and today's ones. I don't know how Siri is implemented. If it is using modern approaches, I'd love to sit down with you sometime and learn about it. Zat's the spirit! Andrei
Typeinfo.compare and opCmp woes
I have a partial fix for issues 8435 and 10118, but it's being blocked
by issue 10567. Basically, the problem is that opCmp *must* be declared
as:
struct T {
int opCmp(ref const T t) const { ... }
}
Only when it's declared this way, will T's typeinfo.compare pick up the
correct custom opCmp.
If 'ref' is dropped, typeinfo.compare reverts to the default bitwise
opCmp.
If opCmp is a template function, typeinfo.compare reverts to the default
bitwise opCmp.
If any of the const's are dropped, typeinfo.compare reverts to the
default bitwise opCmp.
This is *in spite* of the fact that == works perfectly fine in all of
these cases.
This makes it basically impossible to use structs with custom opCmp as
AA keys, because AA's use typeinfo.compare for key comparisons. When any
of the above conditions happen, == and typeinfo.compare are inconsistent
with each other, and the AA will malfunction. So you have bugs like:
int[T] aa;
auto t = T;
auto u = t;
assert(t==u); // N.B. t and u are equal
assert(typeid(t).getHash(t) == typeid(u).getHash(u)); // OK
aa[t] = 1;
assert(u in aa);// fails
aa[u] = 2;
assert(aa[t] == 2); // fails
assert(std.algorithm.count(aa.keys) == 1); // fails
// This is the cause of the problem:
assert(typeid(t).compare(t, u)==0); // fails
:-(
Bugzilla: http://d.puremagic.com/issues/show_bug.cgi?id=10567
T
--
Customer support: the art of getting your clients to pay for your own
incompetence.
Re: Typeinfo.compare and opCmp woes
On Sun, Jul 07, 2013 at 09:44:59PM -0700, H. S. Teoh wrote:
I have a partial fix for issues 8435 and 10118, but it's being blocked
by issue 10567. Basically, the problem is that opCmp *must* be
declared as:
struct T {
int opCmp(ref const T t) const { ... }
}
Only when it's declared this way, will T's typeinfo.compare pick up the
correct custom opCmp.
[...]
Upon further investigation (TypeInfoStructDeclaration::toDt in DMD), it
appears that the reason for this restriction is that typeinfo.compare is
implemented as a call to a func ptr of signature:
int function(in void*, in void*) xopCmp
the first argument of which is T.this, and the second of which must be
ABI-compatible with the argument to opCmp. Basically, it looks like
opCmp is simply cast into the appropriate func ptr and stored in
typeinfo.xopCmp.
This is unfortunate, because it means opCmp declared in any other way
cannot possibly be put into the typeinfo, unless DMD generates a wrapper
function that conforms to the above function signature.
So basically if opCmp is a template function, we're screwed, since due
to the bug that we can't have both a template and non-template method of
the same name, it's impossible to declare a non-template opCmp with the
correct signature. Then typeinfo.compare will always be wrong.
T
--
Unix was not designed to stop people from doing stupid things, because that
would also stop them from doing clever things. -- Doug Gwyn
Re: Typeinfo.compare and opCmp woes
On Sunday, July 07, 2013 22:13:59 H. S. Teoh wrote: since due to the bug that we can't have both a template and non-template method of the same name I believe that Kenji fixed that bug recently. - Jonathan M Davis
Re: Variadic template arguments unpacking
On 07/06/13 21:39, Max Strakhov wrote:
If anyine has any ideas how make this implementation simplier, bring it on :)
Well, you could just use the pseudo-code version that you posted,
almost verbatim:
string res = ;
for(i, rev v; args)
res ~= string.format(, f(args[%d]).val());
mixin(return G( ~ res ~ ););
Only without any actual looping and variables, so compiler could deal with it.
auto F(A...)(string format, A args) {
mixin({
string res;
foreach (I, _; A)
res ~= (I?, :) ~ conv(args[~I.stringof~]);
return return G(convformat(format), ~ res ~ );;
}());
}
The compiler can deal with this, no need to make it more complicated.
It's a good idea for non-obvious text-as-code manipulations to be
explicit, so I'd actually do it like that.
A problem when manipulating source code directly is that not
everything can be referred to by name - a non-local type or
symbol which isn't available in the current scope will work when
it's a template parameter or via typeof(), but you can't directly
name it and then mix it back in. Locals, including function args,
will work though.
For cases where the above restriction isn't a problem, we could
use something more generic, that will make it possible to solve
your problem with a one-liner. It will work with not just
argument-packs (ie arg-tuples), but also some symbols, types
and statically evaluable expressions. The oops line shows what
does *not* work and why these kinds of mixin tricks should
be used only when you have control over all args and users.
template evalExpMap(string C, string F, A...) {
enum evalExpMap = {
import std.array;
string s;
static if (is(typeof(A))) alias B = typeof(A);
else alias B = A;
foreach (I, _; B)
s ~= (I?, :) ~ replace(F, %, A[I].stringof);
return replace(C, %, s);
}();
}
import std.stdio;
void main() {
auto c = mixin (evalExpMap!(q{ foo(%) }, q{ getArray(%)[] }, 1, two,
3.14));
b1(c, 3_000_000_000u, 2.14, -43L);
auto s = S!(int, float, /4, blah)();
writeln(typeof(s.data).stringof, typeof(s.blah).stringof);
//auto oops = S!(typeof(as()), float, /4, blah)();
}
auto getArray(T)(T n) { T[2] data = n; return data; }
auto foo(A...)(A args) {
int c;
foreach (rs; args) foreach (v; rs) ++c, write(v, );
return c;
}
void b1(T...)(T values) {
mixin (evalExpMap!(q{b2('\n',1,2,3,%);}, q{%+1}, values));
}
void b2(T...)(T vs) { foreach (v; vs) writeln(v); }
template Q(A...) { alias Q=A; }
struct S(A...) {
mixin (evalExpMap!(q{alias T=Q!(%);}, q{%[16]}, A[0..$-2]));
T data;
mixin (evalExpMap!(q{Q!(%) }~A[3]~q{;}, q{%[16}~A[$-2]~q{]}, const A[1],
shared(A[0])*));
}
auto as() { struct An {} return An(); }
artur
Building from source for ubuntu
I'm building a nix environment for dmd, and am having problems buiding dmd from source on it. I'm following the instructions on the wiki: http://wiki.dlang.org/Building_DMD The first thing I've run into seems that the X64 instructions are out of date? it says to do make -f posix.mak MODEL=64, but that doesn't seem to do anything... Anyways, that's just minor detail. I'm hitting a wall at building phobos, because of curl: make -f posix.mak DMD=../dmd/src/dmd /usr/bin/ld: cannot find -lcurl I've isntalled curl via apt-get (sudo apt-get curl), and it seems to be installed. Just not in ld: which curl /usr/bin/curl cd /usr/bin/ld bash: cd: /usr/bin/ld: Not a directory Bit of help on either of these two isues? Then I'll update the wiki.
Re: Building from source for ubuntu
On Sunday, July 07, 2013 12:25:50 monarch_dodra wrote: I'm building a nix environment for dmd, and am having problems buiding dmd from source on it. I'm following the instructions on the wiki: http://wiki.dlang.org/Building_DMD The first thing I've run into seems that the X64 instructions are out of date? it says to do make -f posix.mak MODEL=64, but that doesn't seem to do anything... Anyways, that's just minor detail. make -f posix MODEL=64 is correct. I'm hitting a wall at building phobos, because of curl: make -f posix.mak DMD=../dmd/src/dmd /usr/bin/ld: cannot find -lcurl I've isntalled curl via apt-get (sudo apt-get curl), and it seems to be installed. Just not in ld: which curl /usr/bin/curl cd /usr/bin/ld bash: cd: /usr/bin/ld: Not a directory Bit of help on either of these two isues? Then I'll update the wiki. I don't use Ubuntu, but my guess is that it has a separate package (probably with devel in the name) which includes the static lib. Many distros don't include all of the stuff required to build against a library in the main package for a library - just the stuff required to dynamically link against it. - Jonathan M Davis
How to create RDM sockets?
Hello! I try to create a RDM socket, but all my attempts fails by Unable to create socket: Socket type not supported error. How can I create a RDM socket using std.socket module? Thanks.
Re: Building from source for ubuntu
http://packages.ubuntu.com/de/precise/libcurl-dev Should do it, on Ubuntu/Debian you always need the -dev or -devel packages if you want to link against something or use the header files
Re: Building from source for ubuntu
On Sunday, 7 July 2013 at 10:57:08 UTC, David wrote: http://packages.ubuntu.com/de/precise/libcurl-dev Should do it, on Ubuntu/Debian you always need the -dev or -devel packages if you want to link against something or use the header files Most awesome. Got it to work installing libcurl-dev. I wasted about 30 minutes after trying every flavor of curllib-[dev|devel], then typoing the work instal without reading the exact error message :D In any case, I got it to work. I'll update the wiki to be a bit more hand-holding in respect to a few things.
