[OT] Re: Card on fire

[Leandro Motta Barros via Digitalmars-d]

https://en.wikipedia.org/wiki/Magic_smoke

On Tue, Jul 12, 2016 at 3:42 PM, deadalnix via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> On Tuesday, 12 July 2016 at 12:17:00 UTC, Steven Schveighoffer wrote:
>
>> I seriously doubt a fan would stop an electrical fire (in fact, probably
>> makes it worse). It's not overheating, it's arcing.
>>
>>
> Actually, it would probably make it worse by providing fresh O2 to the
> fire.
>
> BTW, this reminds me of a old goodie:
>>
>> http://www.netfunny.com/rhf/jokes/96/Jun/nosmoke.html
>>
>> A old colleague of mine always said when you see smoke, there's no way to
>> fix it, because it's really hard to get the smoke back in there.
>>
>> -Steve
>>
>
> We had a similar saying when I was involved int he electronic world: Chips
> must be powered by smoke. We know this because once it is gone, the chip
> doesn't work anymore.
>
>

Re: Normal distribution

[Leandro Motta Barros via Digitalmars-d]

Maybe not good quality, but I like this one for my ludic purposes:


https://github.com/lmbarros/sbxs_dlang/blob/master/src/sbxs/rand/rng.d#L283

It is an implementation of an approximation algorithm that used to be
described here:

http://home.online.no/~pjacklam/notes/invnorm/

But appears to be offline right now. On the Wayback Machine:


http://web.archive.org/web/20151030212409/http://home.online.no/~pjacklam/notes/invnorm


LMB


On Sat, Feb 20, 2016 at 12:01 PM, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> Do we have a good quality converter of uniform numbers to
> Gaussian-distributed numbers around? -- Andrei
>

Re: Lost & found: laser pen

[Leandro Motta Barros via Digitalmars-d]

On Thu, Jun 18, 2015 at 5:13 PM, Jacob Carlborg via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> On 17/06/15 21:02, Walter Bright wrote:
>
>  If it looks like this, it's mine.
>>
>>
>> http://www.independent.co.uk/incoming/article8435194.ece/alternates/w620/Goldfinger.jpg
>>
>>
> Can you fit that in your pocket ;)
>

Of course not. That's precisely why he forgot it in the room!

LMB

Re: std.allocator: nomenclature needed

[Leandro Motta Barros via Digitalmars-d]

Not a naming suggestion, but a suggestion for a guideline on how to chose
names: make it simpler for most users.

If we still want one million users:

1. Most of them will never bother with std.allocator (by which I don't mean
it is not necessary!)
2. Of those relatively few using std.allocator, most will use the canned,
easy-to-use, high-level stuff
3. Just a few users will reach the plumbing.

As someone personally prefering to remain in group 1 forever, but I willing
to visit group 2 occasionally if necessary, I'd prefer to simply say

import std.allocator;

and get access to the higher-level stuff instead of

import std.allocator.whatever;

This has implications even for the hypothetical day in which I'll be
required to use std.allocator. The closer to the root I find the stuff I
need (that is, the high-level stuff), the quicker I'll find it. If I find
lower-level stuff before finding the higher-level ones, I might even be
fooled to believe that I don't have better (better for me) alternatives,
and start a path of unnecessary suffering.

The bottom line: please make the naming reflect the expected usage, taking
into account the mythical one million users. Simpler names for the stuff
that will be used by most of us.

Cheers,

LMB









On Fri, May 15, 2015 at 12:27 AM, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> Ready for yet another name debate? Here's an opportunity!
>
> I just added:
>
>
> http://erdani.com/d/phobos-prerelease/std_experimental_allocator_auto_deallocator.html
>
>
> https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/auto_deallocator.d
>
> It's very useful, but it seems the name doesn't do it justice.
>
> Also, I need two more good names: one for what's now called "porcelain" -
> high-level typed interface for allocators, and one for "best of Beatles"
> (not defined yet) - a module collecting a number of canned good allocator
> designs by connecting together components.
>
>
> Thanks,
>
> Andrei
>

Re: Let's improve D's exceptions

[Leandro Motta Barros via Digitalmars-d]

I didn't give much attention to the details. but I like the spirit very
much.

LMB


On Wed, May 13, 2015 at 12:08 PM, Adam D. Ruppe via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> Have you ever done:
>
> if(something) {
>import std.conv;
>throw new Exception("some error " ~ to!string(some_value));
> }
>
> Don't you hate it?
>
> * having to import std.conv to see data from your exception is a pain
> * it allocates eagerly and thus isn't suitable for a lot of places
> * inspecting the data can be a pain as the string is unstructured
>
> This assumes the data is even bothered to be added. Anyone who has gotten
> a RangeError in D knows important information is often just dropped!
>
> A good solution is to make a new exception subclass for each error type,
> storing details as data members. However, that's a bit of a pain in D
> because of all the work you have to do to make a complete subclass:
>
> * you need to forward the constructors
> * you need to reimplement the toString to print out data members
> * you still have a string member there that is encouraged to be used
>
>
> Finally, with the discussion of @nogc exceptions, it would be nice to
> simplify the constructor and get file/line info separated from it at the
> same time too. Can we tackle all these problems at once?
>
> I propose we do some library changes, one minor compiler change, and a
> culture shift toward better exceptions. Here's my proof of concept:
>
> http://arsdnet.net/dcode/exception.d
>
>
> Read that code and the comments to see what I'm going for and what it
> looks like. Here's the summary:
>
> * The Exception constructor is simplified: no required arguments,
> everything else is done with members. (The Throwable next = null argument
> might come back, but it can also be set after construction anyway so I'd
> prefer not to worry about it in most places either.)
>
> * The string is de-emphasized. It is still there so we don't break all the
> code that uses it now, but it is no longer the main thing and we really
> would prefer that it isn't used at all. Exception messages are instead done
> with the class name and data members. The string may be gotten by the class
> though in cases like converting errno to a message.
>
> * File and line is set at the throw point instead of the construction
> point.
>
> * A mixin template uses reflection to print data to the user instead of
> constructing a string.
>
> * This is allocation-free, except for the exception object itself. User
> code would NOT have to import std.conv, it just stores the data in the
> object.
>
>
>
> Changes:
>
> TO THE COMPILER:
>   * make the call to d_throw add file and line number information. This is
> completely backward compatible and allows the runtime to store it in the
> object if it wants to. Then my "fly" method becomes unnecessary.
>
> TO THE LIBRARY:
>   * Throwable's toString implementation changes a bit to call a couple
> more virtual functions to print details. Very similar to the current code,
> as you can see in my file there, just some overridable hooks.
>
>   * A PrintMembers and perhaps other helper mixins are added to the
> library. Doesn't matter where they go, druntime might do a simpler one for
> its own needs and then Phobos offers a full featured one for user code. Or
> whatever. It'd need to be a bit more complex than my proof of concept to
> cover more data (at least let it try calling toString on types too) but
> this is already pretty useful as is.
>
>
> TO USER CODE:
>   * We start using subclasses with data members instead of string
> arguments, migrating to it incrementally and encouraging people to write
> exceptions this way going forward.
>
>   * Note that this should be completely backward compatible, it won't
> break old code, just encourage a new better way.
>
>
>
> What do you all think? I encourage you to grab my example there and play
> with it a bit to see how you like it too and see if you can think of any
> improvements.
>
> D's exceptions kinda suck right now but they don't have to!
>

Re: A few notes on choosing between Go and D for a quick project

[Leandro Motta Barros via Digitalmars-d]

I've not being following this list too closely, so forgive me if this has
been discussed before. Here's a simple suggestion that maybe could improve
D docs a bit.

Perhaps, psychologically, the worst about the docs is that the function
signature is used as a kind of section title. What about just reordering
things a bit? Something like:

--

**startsWith**  [this is the title, rendered in some very prominent way.
Just the function name, no parameters or anything else]

*Examples:*
// ...[the examples section we already have today.]

*Detailed description*:  [the complete docs, as we have today]

-

I believe the examples would do a better first impression than the full
function signature, with all runtime and template parameters. I guess most
people searching just want to see how to use the thing in the simplest
cases anyway.

This could be improved in many ways. I actually started to write some other
suggestions, but then gave up. My strongest point is that just reordering
the things could be a way to improve the perception of D with minimal
effort.

Cheers,

LMB







On Fri, Mar 13, 2015 at 12:17 PM, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> On 3/13/15 7:51 AM, Chris wrote:
>
>> On Friday, 13 March 2015 at 14:34:23 UTC, Russel Winder wrote:
>>
>>> On Fri, 2015-03-13 at 14:20 +, Chris via Digitalmars-d wrote:
>>> [...]
>>>
>>>  reluctant to learn something new. Crowd 2. we can win over, yet we
 have failed to communicate with them, to reach out to them. Most
 people I know have a look at D's homepage and say "Uh! Hm. Ah, I'll
 use Python." No, they are not hardcore programmers, they are
 engineers and scientists. But they are _users_, people who need to
 write software to analyze data, to create something. We should not
 ignore them, even if they are not (initially) interested in templates
 and metaprogramming. Neither was I, when I first learned D.

>>>
>>> It is not Python or R or Julia the language that people choose, it is
>>> the superstructure built on top. So for Python, it is Pandas,
>>> Matplotlib, SciPy, NumPy. And the ability to use ready made C, C++ and
>>> Fortran libraries.
>>>
>>
>> Exactly, that's part of it. People don't understand that they can use
>> all the C libraries with D as well. And if they do, "extern (C)" is too
>> "complicated", at least more complicated than "import numbergrind". I'm
>> really at loss here, I don't know how to communicate these things to
>> people. Colleagues and text books that talk about R and Python weigh so
>> much more than "D can actually interface to C without any effort".[1]
>>
>> Also, sometimes I have the impression that people use any excuse not to
>> use D.
>>
>
> That may as well be basic psychology at work. Curb appeal (or lack
> thereof) is difficult to explain but is easy to rationalize with unrelated
> arguments.
>
> There is something loosely related to curb appeal that has been discussed
> here before. Consider someone just starts with D and wants to figure
> whether there's a startsWith function in D.
>
> So they google for something like ``dlang startswith''. Nicely enough
> http://dlang.org/phobos/std_algorithm.html comes up first. (Ideally the
> individual page http://dlang.org/library/std/algorithm/starts_with.html
> would come up.)
>
> Anyhow, assuming the user clicks on the former, startsWith is easy to find
> at the top and then when you click on it...
>
> 
> uint startsWith(alias pred = "a == b", Range, Needles...)(Range
> doesThisStart, Needles withOneOfThese) if (isInputRange!Range &&
> Needles.length > 1 && is(typeof(.startsWith!pred(doesThisStart,
> withOneOfThese[0])) : bool) && is(typeof(.startsWith!pred(doesThisStart,
> withOneOfThese[1..$])) : uint));
> bool startsWith(alias pred = "a == b", R1, R2)(R1 doesThisStart, R2
> withThis) if (isInputRange!R1 && isInputRange!R2 &&
> is(typeof(binaryFun!pred(doesThisStart.front, withThis.front)) : bool));
> bool startsWith(alias pred = "a == b", R, E)(R doesThisStart, E withThis)
> if (isInputRange!R && is(typeof(binaryFun!pred(doesThisStart.front,
> withThis)) : bool));
> 
>
> This in big bold font, too. The HTML way of saying, "you wanted
> startsWith? I'll give you more startsWith than you can carry." Picture the
> effect this has on someone who just wanted to see if a string starts with
> another.
>
> We need to make the template constraints distinct for formatting in ddoc.
>
> Sadly http://dlang.org/library/std/algorithm/starts_with.html is bad in
> other ways. It doesn't have any examples! In contrast, the unified page
> does have some decent examples.
>
> This all is under the "curb appeal" category.
>
>
> Andrei
>
>

Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]

[Leandro Motta Barros via Digitalmars-d]

On Fri, Jan 2, 2015 at 7:26 AM, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> On 1/1/15 10:45 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:
>
>> On 29/12/14 05:13, Andrei Alexandrescu via Digitalmars-d wrote:
>>
>>> I did want to say something about this. I've given a close read to the
>>> "Lost a
>>> new commercial user this week" thread, through and through. It seems I've
>>> identified a problem that belongs to us. ("Us" is a vacuous term
>>> meaning "the
>>> leaders of the D community").
>>>
>>> My initial read of your complaint went like this: it's about Windows
>>> (I don't
>>> even have an installation), it's about vibe.d (haven't used it yet),
>>> and it's
>>> also discussing documentation (which is something we can indeed
>>> improve and I
>>> know how to). So a large part of the problem wasn't even mine to work on.
>>>
>>> Others harbored similar perceptions. The corollary has been that
>>> essentially
>>> you're asking them to stop working on D aspects they do care about and
>>> start
>>> working on D aspects you and others care about - all on their free time.
>>>
>>
>> A few thoughts on this.  (This turned a bit longer than expected in the
>> writing, so I've highlighted some TL;DR sections to highlight key ideas.)
>>
> [snip]
>
> Good stuff, thanks. Question about this:
>
>  TL;DR: I think it would be good to have a strong community guideline
>> that people are not to be criticized or treated badly for having
>> requests or suggestions, even if they are not willing to implement
>> them themselves.  The quid pro quo is that it's necessary to be
>> (calmly) candid with people about the limits of _only_ contributing
>> ideas or requests: "You can ask but not demand".
>>
>
> What would be an appropriate place to put this?
>

We could post an FAQ or something FAQ-like every month or so, including
things like "can I ask for things I want?" or "what should I post to each
forum?".

LMB

Re: RFC: std.concepts

[Leandro Motta Barros via Digitalmars-d]

Looks very nice! I think I could make use of it. (Though I use D only
recreationally :-) )

LMB


On Sun, Oct 19, 2014 at 7:10 PM, Shammah Chancellor via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> It was request that I create a NG thread about a module I was hoping to
> merge with phobos. (std.concepts)  Please take a look.
>
> Thanks in advance.
>
> -S
>
> Link to PR:
>
> https://github.com/D-Programming-Language/phobos/pull/2627
>
> Docs:
>
>
> bool isConcept(T, C, bool diagnostics = false, string errorPrefix = "")();
> Returns true if T supports the concept C. Note, templated member functions
> are not supported currently.
>
> Concepts should be defined as in the following example:
> 
> class CInputRange(E) : Concept
> {
> abstract void popFront();
> @property abstract E front();
> bool empty;
>
> //Optional axioms function.  This will be checked if it compiles,
> and that it returns true if it does.
> static bool axioms(T)()
> {
> return true;
> }
> }
>
> class CInfinite() : Concept
> {
> static bool axioms(T)() {
> enum empty = T.empty;
> return !empty;
> }
> }
>
> class CInfiniteInputRange(E) : CInputRange!E
> {
> mixin CInfinite;
> }
> ---
>
> template conceptDiagnostic(R, string F, int L, C...)
> Prints error messages for why template instantiation failed.
>
> Examples:
> ---
> bool DoStuff(R)(R infRange) if ( isConcept!(R, CInfiniteInputRange!string))
> {
> return true;
> }
>
> bool DoStuff(R)(R infRange) if ( isConcept!(R, COutputRange!string))
> {
> return true;
> }
>
> //Example of using conceptDiagnostic
> bool DoStuff(R, string F = __FILE__, size_t L = __LINE__ )(R infRange)
> {
> mixin conceptDiagnostic!(R, F, L, COutputRange!string,
> CInfiniteInputRange!string);
> return false;
> }
> ---
>
> class Concept;
> Base class for Concepts. All Concepts should derive from this, or another
> concept.
>
>
>

Re: Cumulative

[Leandro Motta Barros]

Hello,

I'm coming late to the discussion, but I believe that you can use the
following idiom to achieve the same results in a different way:

class C
{
   // This is not overridable
   public final void doStuff()
   {
  doSomethingWhichNeverChanges();
  doExtraStuff();
   }

   protected void doExtraStuff()
   {
  // This one can be overridden
   }
}

Or did I miss something?

Cheers,

LMB




On Mon, Feb 24, 2014 at 5:41 AM, Steve Teale
wrote:

> 25 years ago, when I was trying to write some sort of library to go with
> Walter's C++ compiler, I had a wish, and it still pops into my head from
> time to time.
>
> What I wanted was functions that were declared in a base class as
> 'cumulative', or something similar. They would have been generally like
> virtual functions, except that any derived class that wanted to do
> something extra - as opposed to something different, would simply define an
> 'extend', and just specify the extra code. The compiler would then
> automatically add a call to the same function in whatever base class last
> defined or extended the method.
>
> extend void foo()   // Declared in base class as cumulative void foo()
> {
>(cast(BaseClass) this).foo();  // Compiler does this for you
>   // similar to changing a light bulb ;=)
>
>// the extra stuff
> }
>
> I think also that it might be necessary for the base class function to
> return on behalf of the derived method as opposed to to it.
>
> Does this make any sense?
>
> Steve
>

Re: package.d behavior

[Leandro Motta Barros]

On Fri, Jan 24, 2014 at 12:45 AM, Jesse Phillips <
jesse.k.phillip...@gmail.com> wrote:

> [...]
> You should probably file a bug. I think this change should be valid (it
> sounds like it wouldn't work, but didn't test)
>

There it is: https://d.puremagic.com/issues/show_bug.cgi?id=12014

LMB

Re: package.d behavior

[Leandro Motta Barros]

Hi,

Do anyone has any feedback about his issue? I (and at least one more user)
believe that the "package.d" feature behaves strangely (please, see the
examples in my original post).

Thanks a lot,

LMB

PS: I am not a big fan of "bump" posts, but I believe this message may have
been ignored given some forum issues last week -- when it appeared, it was
already buried under several more recent messages.


On Sat, Jan 18, 2014 at 10:32 AM, Leandro Motta Barros  wrote:

> Hello!
>
> About a month ago I asked in D.learn about the expected behavior of the
> new package.d feature [1]. I got a cuple of responses, but not really
> answers. Today I noticed a second post [2] with similar but still
> unanswered questions. So it seemed like a good idea to bring the discussion
> to the main forum.
>
> Basically, I seems that the root of the issues we are facing is the way
> fully-qualified names work when using package.d (I have added some examples
> below showing what I mean).
>
> We also felt that the feature is under-documented (DIP37 and the changelog
> seem to be the only places where the feature is discussed, and some
> important details are missing.) I was actually about to fill bug a report
> about the behavior, but I ended up not doing so because I couldn't find out
> what the expected behavior is.
>
> So, any feedback and clarifications are welcome!
>
> Thanks for the attention, and keep up the great work :-)
>
> LMB
>
> [1]
> http://forum.dlang.org/thread/cany+vsmzlj5ehkgw8ce1kkomom7x3rokmvgmjycqzrwd9al...@mail.gmail.com
> [2] http://forum.dlang.org/thread/eeaslvjwenkygwszq...@forum.dlang.org
>
>
> ---
>
> EXAMPLE 1: Trying to simply replace the old "all.d" idiom with package.d
> doesn't work out-of-the-box:
>
> Originally, I had something like this:
>
>  // mylib/util.d:
>  module mylib.util;
>  class Foo { }
>
>  // mylib/all.d:
>  module mylib.all;
>  public import mylib.util;
>
>  // main.d:
>  import mylib.all;
>  void main()
>  {
> auto f = new mylib.util.Foo;
>  }
>
> And this used to work. Now, I added a new file:
>
>  // package.d
>  module mylib;
>  public import mylib.util;
>
> And changed the 'import' in the main one:
>
>  // main.d
>  import mylib;
>
>  void main()
>  {
> auto f = new mylib.util.Foo;
>  }
>
> Now, the compiler complains:
>
>  main.d(5): Error: undefined identifier 'util'
>  main.d(5): Error: mylib.util.Foo is used as a type
>
> [Using mylib.Foo instead of mylib.util.Foo works -- which makes sense when
> thnking about the use case of using package.d to split a large package into
> smaller ones. ]
>
>
> -
>
> EXAMPLE 2: Inconsistency with fully-qualified names
>
> // mylib/util.d
> module mylib.util;
> class Foo { }
>
> // mylib/package.d
> module mylib;
> public import mylib.util;
>
> // main.d
> import std.stdio;
> import mylib;
>
> void main()
> {
>auto f = new mylib.Foo;
>writefln("%s", f.classinfo.name);
> }
>
> This prints 'mylib.util.Foo'. So far so good, that's the name I originally
> expected.
>
> Then I try to instantiate a 'Foo' using this very fully-qualified name the
> compiler told me:
>
>auto f = new mylib.util.Foo;
>
> And DMD doesn't like it anymore:
>
> main.d(6): Error: undefined identifier 'util'
> main.d(6): Error: mylib.util.Foo is used as a type
>
> [This looks very much like a bug for me. The name given by 
> classinfo.nameshould be usable to instantiate a class, shouldn't it? ]
>
>
>

package.d behavior

[Leandro Motta Barros]

Hello!

About a month ago I asked in D.learn about the expected behavior of the new
package.d feature [1]. I got a cuple of responses, but not really answers.
Today I noticed a second post [2] with similar but still unanswered
questions. So it seemed like a good idea to bring the discussion to the
main forum.

Basically, I seems that the root of the issues we are facing is the way
fully-qualified names work when using package.d (I have added some examples
below showing what I mean).

We also felt that the feature is under-documented (DIP37 and the changelog
seem to be the only places where the feature is discussed, and some
important details are missing.) I was actually about to fill bug a report
about the behavior, but I ended up not doing so because I couldn't find out
what the expected behavior is.

So, any feedback and clarifications are welcome!

Thanks for the attention, and keep up the great work :-)

LMB

[1]
http://forum.dlang.org/thread/cany+vsmzlj5ehkgw8ce1kkomom7x3rokmvgmjycqzrwd9al...@mail.gmail.com
[2] http://forum.dlang.org/thread/eeaslvjwenkygwszq...@forum.dlang.org


---

EXAMPLE 1: Trying to simply replace the old "all.d" idiom with package.d
doesn't work out-of-the-box:

Originally, I had something like this:

 // mylib/util.d:
 module mylib.util;
 class Foo { }

 // mylib/all.d:
 module mylib.all;
 public import mylib.util;

 // main.d:
 import mylib.all;
 void main()
 {
auto f = new mylib.util.Foo;
 }

And this used to work. Now, I added a new file:

 // package.d
 module mylib;
 public import mylib.util;

And changed the 'import' in the main one:

 // main.d
 import mylib;

 void main()
 {
auto f = new mylib.util.Foo;
 }

Now, the compiler complains:

 main.d(5): Error: undefined identifier 'util'
 main.d(5): Error: mylib.util.Foo is used as a type

[Using mylib.Foo instead of mylib.util.Foo works -- which makes sense when
thnking about the use case of using package.d to split a large package into
smaller ones. ]


-

EXAMPLE 2: Inconsistency with fully-qualified names

// mylib/util.d
module mylib.util;
class Foo { }

// mylib/package.d
module mylib;
public import mylib.util;

// main.d
import std.stdio;
import mylib;

void main()
{
   auto f = new mylib.Foo;
   writefln("%s", f.classinfo.name);
}

This prints 'mylib.util.Foo'. So far so good, that's the name I originally
expected.

Then I try to instantiate a 'Foo' using this very fully-qualified name the
compiler told me:

   auto f = new mylib.util.Foo;

And DMD doesn't like it anymore:

main.d(6): Error: undefined identifier 'util'
main.d(6): Error: mylib.util.Foo is used as a type

[This looks very much like a bug for me. The name given by
classinfo.nameshould be usable to instantiate a class, shouldn't it? ]

Re: Singletons, alias this and DMD crashing

[Leandro Motta Barros]

Thanks for the comment! I noticed this wouldn't compile, though I
haven't really wondered why so. My email was more about the compiler
bug than about using alias this with singletons.

Anyway, while trying to circumvent the compiler bug, I did this:

import std.stdio;

class SImpl
{
   void foo()
   {
  writeln("foo!");
   }

   private this() { }
}

class S
{
   static @property SImpl instance()
   {
  if (_i is null)
 _i = new SImpl();

  return _i;
   }

   static SImpl _i;

   alias instance this;
}

void main()
{
   S.foo();
}

This works and compiles with DMD 2.062. (I don't like to have
to write this additional code manually, but I'll try to make something
about it :-) )

LMB



On Thu, May 9, 2013 at 7:04 AM, Jacob Carlborg  wrote:
> On 2013-05-09 11:48, Jacob Carlborg wrote:
>
>> This won't work. You need to be able to overload on static, which you
>> can't. I've tried this with opDispatch.
>
>
> To elaborate. Below is your original with the "foo" method added.
>
>
> class S
> {
>static @property S instance()
>{
>   if (_i is null) // #1
>  _i = new S();
>
>   return _i;
>}
>
>static S _i;
>
>alias instance this;  // #2
>
>void foo () {}
> }
>
> If you try to call it like this: S.foo(), the compiler will complain that
> "foo" need access to "this". The "alias this" won't kick in.
>
> --
> /Jacob Carlborg

Singletons, alias this and DMD crashing

[Leandro Motta Barros]

Hello,

I was toying with the idea of adding an 'alias instance this' to a
low-lock singleton, to allow calling MySingleton.method(), instead of
MySingleton.instance.method().

When I tried this, however, DMD 2.062 crashed. Under Linux, after
chewing the code for a long time, it exits with "Error: out of
memory". Under Windows (or rather, dmd.exe under Wine, which is what I
actually tried), it crashes with a "Stack overflow" error.

I reduced offending code to this:

class S
{
   static @property S instance()
   {
  if (_i is null) // #1
 _i = new S();

  return _i;
   }

   static S _i;

   alias instance this;  // #2
}

Commenting out either of the lines marked with "#n" avoids the crash
(but ruins my code, naturally :-P).

Is this a known bug? I didn't found it in the bug tracker, but I
couldn't really think of good keywords to look for.

Cheers,

LMB

Re: D rawkz! -- custom writefln formats

[Leandro Motta Barros]

*Great!* Thanks for posting this!

I think it will be much easier to get a critical mass of enthusiastic
D developers if we have some sort of "Effective D" (like Scott Meyer's
"Effective C++") book/conf presentations/wiki page/whatever.

This kind of stuff would fit in the "talk proposal for someone else" I
sent back in November, just after DConf was successfully funded:

-

TITLE: D Programming in D (Or: Writing idiomatic D code)

ABSTRACT: Every language has its own sanctified idioms. Beginners
learning a new language tend to use the idioms of the languages they
already know in the new language. This is no different for someone
learning D, so we have people doing, say, "C++ programing in D" or
"Lua programming in D". This is not the best way to go. Learning the D
idioms is a very important step to move from "I can write D programs"
to "I know D". This talk presents a survey of the most important
idioms commonly used by the D community. Hopefully, it will help you
to start doing "D programming in D".

SPEAKER BIO: < Your bio here :-) >

-

Cheers,

LMB

On Wed, Jan 16, 2013 at 4:13 PM, H. S. Teoh  wrote:
> It's been a while since the last "D rocks!" post. So here's one.
>
> I'm guessing that most D users don't realize extent of the flexibility
> of std.format -- I know I didn't until I discovered this little gem
> hidden in the docs (and then only implicitly!).
>
> But first, a motivating example. Suppose you have some kind of data
> structure, let's call it S, and at some point in your program, you want
> to output it. The most obvious way, of course, is to implement a
> toString() method:
>
> struct S {
> ... // my sooper sekret data here!
> string toString() const pure @safe {
> // Typical implementation to minimize overhead
> // of constructing string
> auto app = appender!string();
> ... // transform data into string
> return app.data;
> }
> }
>
> void main() {
> auto s = S();
> ... // do wonderful stuff with s
> writeln(s);
> }
>
> This is the "traditional" implementation, of course. A slight
> optimization that's possible is to realize that there's an alternative
> signature of toString() that alleviates the overhead of doing any string
> allocations at all:
>
> struct S {
> // This method now takes a delegate to send data to.
> void toString(scope void delegate(const(char)[]) sink) const
> {
> // So you can write your data piecemeal to its
> // destination, without having to construct a
> // string and then return it.
> sink("prelude");
> sink(... /* beautiful prologue */);
> sink("concerto");
> sink(... /* beautiful body */);
> sink("finale");
> sink(... /* beautiful trailer */);
>
> // Look, ma! No string allocations needed!
> }
> }
>
> So far so good. This is (or should be) all familiar ground.
>
> But suppose now you want to write your data to, say, a backup file in
> one format, but output your data to the user in another format. How
> would you do this?
>
> You could make toString() output one format, say the on-disk format,
> then add another method, say toUserReadableString() for outputting the
> other format. But this is ugly and non-extensible. What if you have a
> whole bunch of other formats that need to be output? You'd be drowning
> in toNetworkString(), toDatabaseString(), toHtmlEscapedString(), etc.,
> etc., which bloats your data's API and isn't very maintainable to boot.
>
> Here's where a little known feature of std.format comes in. Note that
> when you write:
>
> S s;
> writeln(s);
>
> This actually ultimately gets translated to the equivalent of:
>
> S s;
> writefln("%s", s);
>
> Where the %s specifier, of course, means "convert to the standard string
> representation". What is less known, though, is that this actually
> translates to something like this:
>
> Writer w = ... /* writer object that outputs to stdout */
> FormatSpec!Char fmt = ... /* object representing the meaning of "%s" 
> */
> s.toString((const(char)[] s) { w.put(s); }, fmt);
>
> In human language, this means that "%s" gets translated into a
> FormatSpec object containing "s" in its .spec field (and if you write,
> say, "%10s", the 10 gets stored in the .width field, etc.), and then
> this FormatSpec object gets passed to the toString method of the object
> being formatted, if it is defined with the correct signature. To see
> this in action, let's do this:
>
> struct S {
> 

Talk proposal (kinda): D Programming in D (Or: Writing idiomatic D code)

[Leandro Motta Barros]

Hello everyone!

Well, this is actually a "talk proposal for someone else". I'd be the
audience, not the speaker.

TITLE: D Programming in D (Or: Writing idiomatic D code)

ABSTRACT: Every language has its own sanctified idioms. Beginners
learning a new language tend to use the idioms of the languages they
already know in the new language. This is no different for someone
learning D, so we have people doing, say, "C++ programing in D" or
"Lua programming in D". This is not the best way to go. Learning the D
idioms is a very important step to move from "I can write D programs"
to "I know D". This talk presents a survey of the most important
idioms commonly used by the D community. Hopefully, it will help you
to start doing "D programming in D".

SPEAKER BIO: < Your bio here :-) >


I would *really* love to watch a talk (or read a book for that
matter), dealing with this kind of topic. I suppose many other
programmers coming from other languages would benefit from a talk like
this. And considering that we'll have the videos online after the
conference, I'd say that this would become a mostly valuable reference
for all the people that will join D. (We want a million users, right?
They'd all love this talk ;-) )

So, anyone else interested in watching a talk like this?

Anyone interested in *giving* a talk like this?

Cheers,

LMB

PS: It's really great we did it! The news made my day yesterday! I am
pretty sure it will be a great conference! (Even if no one decides to
give the "D Programming in D" talk ;-) )