Re: This is why I don't use D.

[lurker via Digitalmars-d]

On Wednesday, 5 September 2018 at 06:47:00 UTC, Everlast wrote:
On Wednesday, 5 September 2018 at 01:39:04 UTC, Paul Backus 
wrote:

[...]



I'm not going to sit here and spend have my time fixing shit 
that should have never broke in the first place.


Thanks, you've made a great decision for me, I'm not longer 
using D for anything. The only reason I used it was for it's 
binary support and meta programming... no longer. Screw 
performance, non one else really cares and one doesn't 
necessarily need meta programming.


Thanks, see you in another life!


yes i think i lurked around long enough, bye D.

Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)

[lurker via Digitalmars-d]

after the beta i tried it the final again - just to be fair.

1.) install d, install visual d.
2.) trying to to look at options under visual d without a project 
crashes VS2017 - latest

service pack.
3.) VS2017 - displays a problem on startup
4.) creating the dummy project - compile for x64. error something 
is missing.

5.) deinstall everything and wait for another year

this crap does not even work out of the box - what else is not 
tested in D?


i guess you don't intend to draw crowds to D and just keep 
talking on how to this and that a little better in the compiler 
pet project.


is D that dead that the releases are not tested or do you want to 
keep all windows users out?

Re: Dicebot on leaving D: It is anarchy driven development in all its glory.

[lurker via Digitalmars-d]

On Sunday, 26 August 2018 at 19:28:30 UTC, Radu wrote:

On Sunday, 26 August 2018 at 16:09:35 UTC, lurker wrote:

[...]


Yeah right... I'm sure this is what everyone experienced.

This thread has become the trollers trolling playground.


no, i used to use d1 a lot and then d2 changed everything with it 
promise. but it turned into skript like monster, that doesn't 
work very well with tons of features. d2 is unreliable, doesn't 
install correct, dll problem .
no company i ever worked at, used linux. they all use vs with 
windows. they want to make money and not go for the experiments 
of some compiler freaks.
it is important that you can have a quality experience on windows 
with vs, be able to use dll's and have a stable compiler with 
predictable use; if possible be able not to use the gc, but the 
gc wouldn't even be hanger.


well, you are correct, i have a different opinion and experience 
with d2 - so i must be a troll.
anyway, radu, i wish you good luck on a larger commercial program 
on windows with d2.


over and out.

Re: Dicebot on leaving D: It is anarchy driven development in all its glory.

[lurker via Digitalmars-d]

On Sunday, 26 August 2018 at 16:25:31 UTC, rikki cattermole wrote:

On 27/08/2018 4:09 AM, lurker wrote:

On Sunday, 26 August 2018 at 14:17:33 UTC, Chris wrote:

On Sunday, 26 August 2018 at 14:00:56 UTC, nkm1 wrote:


So please report any issues you're having. Because they are not 
regular user experience.


i did - and lost interest. right now i'd rather use a modern 
BASIC, because the install works and the compiler too.

Re: Dicebot on leaving D: It is anarchy driven development in all its glory.

[lurker via Digitalmars-d]

On Sunday, 26 August 2018 at 14:17:33 UTC, Chris wrote:

On Sunday, 26 August 2018 at 14:00:56 UTC, nkm1 wrote:

[...]


What did I expect? Better: What do I expect now. I've been 
using D for years now. I think it's time for D to offer users 
the same stability as other languages do. Simple as.


lurking around this board for a long time and gave up on d2 along 
time ago. it is to scripty. i can not convince anybody at work to 
use it even for small things under windows. some tried it and 
they say it is to buggy, misses windows essentials and there 
seems to be no chance of betterment via management or the 
compiler enthusiasts that rather implement any fancy fart instead 
of getting the compiler stable, bug free and usable.
it seems like this is a language experiment, unusable for serious 
development.
i just downloaded current beta 2 and visual D. installs ok, no 
detection of visual studio or any of the associated paths. visual 
D installed ok, but a click on menu options killed visual studio.

i uninstalled successfully - hallelujah.
so i lurk around for an other year an see if D experiment is 
still around and/or usable.

Re: D beyond the specs

[lurker via Digitalmars-d]

On Friday, 16 March 2018 at 11:44:59 UTC, Chris wrote:

[...]


easy code readability, few keywords, well defined and predictable 
(ex. ebnf)
well D is all - but that. i can't get anyone in our company to 
use it even for little stuff.

Re: proposed @noreturn attribute

[Lurker via Digitalmars-d]

On Friday, 14 July 2017 at 15:39:01 UTC, Guillaume Boucher wrote:

Example 1: Polymorphism

class Bird { void fly() { ... } };
class Penguin : Bird { override void fly() @pragma(noreturn) { 
assert(0); }  };

class EvolvedPenguin : Penguin { override void fly() { ... } };



No matter how you look at it, this code should simply not be 
allowed:


Bird bird = ...;
bird.fly(); // is this return or noreturn?

Penguin penguin = ...;
penguin.fly(); // is this return or noreturn?

In both cases, compiler cannot draw any conclusions about 
return/noreturn and thus I believe such code should not be 
allowed.


And if this is disallowed, a Bottom type would fit again.

Re: proposed @noreturn attribute

[Lurker via Digitalmars-d]

On Saturday, 8 July 2017 at 20:27:11 UTC, H. S. Teoh wrote:
Also, a @noreturn attribute would allow overriding a non-void 
class method with a @noreturn one (e.g. the derived class is a 
sentinel object that forces an exception / termination upon 
calling that method), whereas you can't do that with a None 
return type because the signature would not match the base 
class's.



T


The reverse is also true, and more disastrous!

Re: Proposal 2: Exceptions and @nogc

[Lurker via Digitalmars-d]

Everything looks good except this one line:

On Sunday, 9 April 2017 at 03:26:14 UTC, Walter Bright wrote:

throw new E(string);



I don't like it for 2 reasons:

a) E e = new E(string); throw e;

   Should be *exactly* the same as

   throw new E(string).

   I think it's obvious why.


b) Using 'new' in @nogc code feels plain wrong.


I think a library method of explicitly creating a ref-counted 
throwable would be better. One can then do


E e = refCountedThrowable!(E)(string);
throw e;

or, interchangeably,

throw refCountedThrowable!(E)(string);

and

throw new E(string);

would be illegal because new cannot be called from within a @nogc 
method.


(haven't ever used @nogc so I'm probably wrong)

Re: CTFE Status 2

[Lurker via Digitalmars-d]

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
Hi Guys, due to the old CTFE status thread getting to page 30, 
I am now starting a new one.


...
--
I hope this thread is informative and will continue to be that 
way.


Cheers,
Stefan (aka UplinkCoder)


Thanks Stefan for your work, and for documenting it. Very 
exciting to read the progress! I wish more people were as devoted 
as you are! Keep up the good work!

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

[Lurker via Digitalmars-d]

On Tuesday, 14 February 2017 at 16:25:17 UTC, Andrei Alexandrescu 
wrote:

Range remove
(SwapStrategy s = SwapStrategy.stable, Range, Offset...)
(Range range, Offset offset)
if (s != SwapStrategy.stable
&& isBidirectionalRange!Range
&& hasLvalueElements!Range
&& hasLength!Range
&& Offset.length >= 1);



Range
remove (SwapStrategy s = SwapStrategy.stable, Range, Offset...)
(Range range, Offset offset)
if CanRemove!(s, range, offset);

The function name is on the first line. I think 10 seconds 
would be an exaggeration of an admittedly real issue.




Thought so, too, but then I *did* spend 10 seconds trying to find 
it myself!



Tuple!(InputRange1, InputRange2)
swapRanges(InputRange1, InputRange2)(InputRange1 r1, 
InputRange2 r2)

if (isInputRange!(InputRange1) && isInputRange!(InputRange2)
&& hasSwappableElements!(InputRange1)
&& hasSwappableElements!(InputRange2)
&& is(ElementType!(InputRange1) == 
ElementType!(InputRange2)));




Tuple!(InputRange1, InputRange2)
swapRanges(InputRange1, InputRange2)(InputRange1 r1, InputRange2 
r2)

if CanSwapRanges!(InputRange1, InputRange2);

Re: A betterC modular standard library?

[lurker via Digitalmars-d]

On Monday, 19 December 2016 at 05:59:07 UTC, Ilya Yaroshenko 
wrote:
On Monday, 19 December 2016 at 01:52:21 UTC, Andrei 
Alexandrescu wrote:

On 12/18/16 7:31 PM, Seb wrote:

tl:dr: Phobos is very bloated.


How does the D standard library compare in size with some 
other languages (C++, Rust, Go, Java, Python)?


C++ and Rust are the best from this list in terms of low level 
programming. They have smaller libraries comparing with D.


Go, Java, Python --- If I need a language like them I will you 
them, not D.


Go - awesome GC, commercially supported, easy to write your own 
libs

Java - awesome GC, commercially supported, Scala(!!!)
Python - awesome scripting, commercially supported

D - ??? awesome what ? What do we have better then Scala?

Performance? NO.
BRandomAccessRanges makes our performance less then C/C++.

Clean and clever API in standard library? NO.
We are placing our Range API whenever possible including RNGs. 
We have not a language standard for I/O. Half of Phobos is 
outdated to language standards.


Best generics? NO.
Scala is more powerful.

--
What do we have awesome? Where D is the best?
--
D is awesome for low-level system libraries in betterC mode.
(and small text processing routines)
This will make D great in other fields.
--


Let's do something about it!


I've said this several times, and it bears repeating. We want 
to make D entirely pay-as-you go, and offer full support to 
anyone working on it. The best "something" anyone can do about 
it is do good engineering work in the D mainline.


National D Foundation Party.

That will automatically benefit all users of the D language, 
instead of balkanizing the community.


...

Granted, the lure of the clean slate is strong, and more care 
is needed to mind backwards compatibility, but that's where 
the real impact is.



Andrei


How Mir projects breaks backward compatibility ?

How proposed direction breaks backward compatibility?

Lets use other prefix for the new libraries. Mir uses `mir.` 
And allow Phobos to be a sandbox for C++ as it is now.


Ilya



Thats why I asked for moderation in forums.

Re: Checkedint ready for one more round of reviews

[Lurker via Digitalmars-d]

On Wednesday, 19 October 2016 at 17:09:35 UTC, Andrei 
Alexandrescu wrote:
Just made one more pass through it addressing concerns and 
adding a new policy (Throw). Reviews welcome. Let's get this 
through Scylla and Charybdis!


This module provides a few predefined hooks (below) that add 
useful behavior to Checked:


Missing Throw.

Throw	Force all integral errors to fail by printing an error 
message to stderr and then abort the program. Abort is the 
default second argument for Checked.


Seems to be copy-pasted from Abort.

Re: So what's the deal with DFLAGS?

[Lurker via Digitalmars-d]

On Friday, 14 October 2016 at 00:47:34 UTC, Andrei Alexandrescu 
wrote:
Should we do something about 
https://issues.dlang.org/show_bug.cgi?id=1660? -- Andrei


Srsly, the bug is over 8 years old, any only one person 
complained. It's not even a bug but a feature request.


Close it as won't fix and move on.

Re: Can you shrink it further?

[Lurker via Digitalmars-d]

On Tuesday, 11 October 2016 at 03:00:45 UTC, Stefan Koch wrote:
On Tuesday, 11 October 2016 at 02:48:22 UTC, Andrei 
Alexandrescu wrote:
That looks good. I'm just worried about the jump forward - 
ideally the case c < 127 would simply entail a quick return. I 
tried a fix, but it didn't do what I wanted in ldc. We 
shouldn't assert(0) if wrong - just skip one byte. Also, are 
we right to not worry about 5- and 6-byte sequences? The docs 
keep on threatening with it, and then immediately mention 
those are not valid.


[ ... ]

Andrei



If you want to skip a byte it's easy to do as well.

void popFront3(ref char[] s) @trusted pure nothrow {
   immutable c = s[0];
   uint char_length = 1;
   if (c < 127)
   {
   Lend :
 s = s.ptr[char_length .. s.length];
   } else {
 if ((c & b01100_) == 0b1000_)
 {
   //just skip one in case this is not the beginning of a 
code-point char

   goto Lend;
 }
 if (c < 192)
 {
   char_length = 2;
   goto Lend;
 }
 if (c < 240)
 {
   char_length = 3;
   goto Lend;
 }
 if (c < 248)
 {
   char_length = 4;
   goto Lend;
 }
   }
 }


Pardon me asking, but why all these gotos instead of else ifs:

  if (c < 192)
  {
char_length = 2;
  }
  else if (c < 240)
  {
char_length = 3;
  } else if (...) {
  }

Does it have any effect on generated code (I don't think it 
should)?

Re: iPhone vs Android

[Lurker via Digitalmars-d]

On Tuesday, 13 September 2016 at 22:19:54 UTC, Jonathan M Davis 
wrote:
So, I really think that we need to find a way to make it so 
that exceptions aren't GC allocated normally anymore - or at 
least have a way to reasonably and easily not be GC allocated - 
but the problem is @nogc, not the actual memory management or 
its cost.


- Jonathan M Davis


Introduce RefCountedException?

Also that the pattern almost always is "throw new" and *very* 
rarely it is "Exception e = new ...; throw e;". I think we might 
be able to take advantage of that (e.g. "throw new E" could be a 
special case of "new" that allocates on some sort of "Exception" 
heap that is manually managed, or recognize RefCountedException).

Re: Image of D code on Norwegian IT news site

[Lurker via Digitalmars-d]

On Thursday, 1 September 2016 at 18:45:14 UTC, deadalnix wrote:

On Wednesday, 31 August 2016 at 18:50:58 UTC, simendsjo wrote:
An article about how outsourcing reduces the need for 
Norwegian developers. No links to D other than the image on 
top though. I wonder what they searched for to find this image.


http://www.digi.no/artikler/rader-norske-it-folk-til-a-droppe-programmering/279380


I assume Norwegian jobs are taken away by these annoying 
Romanians :)


Shots fired!

Re: dub test

[Lurker via Digitalmars-d]

On Wednesday, 24 August 2016 at 13:52:43 UTC, Andrei Alexandrescu 
wrote:

// This will always be true
assert(a >= 1 && a <= 5);
assert(a >= 0.0 && a <= 10.0);


Pretty sure you have a bug here :)

Re: Entity Component Architecture

[Lurker via Digitalmars-d]

On Friday, 26 August 2016 at 19:55:30 UTC, vladdeSV wrote:
What I can conclude so far is my approach uses a lot of 
processing power. I did a test where I generated 1 entities 
and it drained my CPU to 50%.


All feedback is appreciated. Thank you for your input :)


hasComponent()/getComponent() should be O(1) and preferrably 
CTFEable.


You could turn Entity into a template, or store a bitmask of 
applied Components etc.

Re: User defined statements for D like seed have?

[lurker via Digitalmars-d]

http://seed7.sourceforge.net/index.htm

seed7 is also a compiler! and i use it, after comming from D, 
with great pleasure.






On Wednesday, 7 March 2007 at 22:02:00 UTC, dennis luehring wrote:

example how a for statement is declared
http://seed7.sourceforge.net/examples/declstat.htm

ok i know that seed is an interpreter language but maybe there 
is a way walter can allow something like this for his buildin 
statements


or even better the case statement

http://seed7.sourceforge.net/manual/stats.htm#case-statement

as a statement-template wich can produce (with the help of the 
awaited static foreach) a nice objectfactory from a tuple or 
something like this


ciao denni

Re: Escaping the Tyranny of the GC: std.rcstring, first blood

[Googler Lurker via Digitalmars-d]

On Sunday, 21 September 2014 at 23:28:31 UTC, Paulo Pinto wrote:

Am 22.09.2014 01:06, schrieb Ola Fosheim Grostad:
On Sunday, 21 September 2014 at 22:58:59 UTC, Paulo Pinto 
wrote:

Since when Go is a competitor in the webspace?


Since people who create high throughput servers started using 
it?




Which people? A few Silicon Valley startups, besides Google?


Go fizzled inside google but granted has traction outside of
google. Paulo stop feeding the troll for Petes sake.

Re: GDC2, LDC2 Status Updates?

[lurker]

dsimcha Wrote:

> I've been curious for a while how close GDC2 and LDC2 are to being ready 
> for production use.  Are the test suite results posted publicly for 
> either of these?  Other than that, is there anything else other than 
> building and testing for myself that would give me a good idea of where 
> these libraries stand?

The typical reply is "they're already fully production ready, it just depends 
on what you need". Seriously though, people have different kind of requirements 
for production ready products. These kind of questions just start yet another 
public debate of the basic definitions of terms.

Re: std.parallelism: VOTE IN THIS THREAD

[lurker]

Bruno Medeiros Wrote:

> On 19/04/2011 14:47, Russel Winder wrote:
> > On Tue, 2011-04-19 at 06:13 -0500, Caligo wrote:
> > [ . . . ]
> >> I would like to make a comment if that's okay.  If a person is not an
> >> expert on parallelism, library development, or we can't verify his or
> >> her background and such, I don't see why their vote should count.  I'm
> >> not voting because I'm just an ordinary D user, and I have no
> >> expertise in parallelism.  And since this a public vote, if would be
> >> great if people who are voting did not hide behind an alias, such as
> >> bearophile.
> >
> > I think there is an very interesting and important issue here.  There
> > are really four (or more/less) roles of people who might vote:
> >
> > Has detailed knowledge of implementation and usage.
> > Has some knowledge of implementation and/or usage.
> > Perhaps just using the API.
> > No actual interest.
> >
> > And then there are:
> >
> > Sock puppet aka shill
> > Troll
> >
> > but let's ignore them.
> >
> > Although the general belief is "one person, one vote", some decisions
> > are best influenced by considering the weighting to a vote provided by
> > annotating with role.
> >
> > Two cases perhaps highlight this:
> >
> > If a person using the library but having no knowledge of the
> > implementation finds a problematic API issue then this should count as
> > much as any view of people more knowledgeable about the internals.
> >
> > If a person without knowledge of the theory and practice votes yes where
> > the domain experts are able to argue there is a blocking problem, then
> > the person leading the vote should have the option of cancelling and
> > re-entering review even if there was a clear majority vote for.
> >
> > I think the issue here is not to be bound too rigidly by votes and
> > statistics, this is not after all politics, but instead to ensure that
> > everyone has the right sort of say about these things and that the
> > majority of people always feel the right decisions are getting made.
> >
> > Consider the system not being one of the review leader managing the
> > votes, but of the review leader having a single golden vote which then
> > has to be justified by argumentation.
> >
> >> P.S.
> >> I can't wait for std.parallelism to become part of Phobos.
> >
> > Me too.
> >
> 
> I generally agree with this perspective, being aware of this issue, and 
> not making the voting completely democratic (that's why I'm not voting 
> on this one). On the other hand, one would also hope that those with D's 
> best interest in mind will also be mindful of this, and not vote if they 
> feel they have insuficient knowledge to evaluate the proposal. In other 
> words, one would hope the community would self-regulate to avoid this 
> problem, and no formal additional rules should be needed. Let's see.
> 
> In any case it seems this won't matter for this proposal, everyone is 
> voting yes :) . But it's worthwhile to keep in mind for the future.

Yes, everyone is voting yes. And half of the voters haven't ever used 
parallelism or know anything about its library level design issues. This voting 
process seemed like a joke. I know this kind of voting is popular in other 
projects, but D community's infrastructure isn't ready for this. It just shows 
how UNagile and clumsy the design process is and merely a meat puppet theatre 
for hiding a dictatorship with uninformed "democracy". You could just add stuff 
until someone starts complaining and begin hardcore technical discussion when 
real problems arise.

Cheers,
sock puppet #2347

Re: i like cakes

[random lurker]

FeepingCreature Wrote:

> On 28.03.2011 03:45, Gary Whatmore wrote:
> > Hello again
> > 
> > I've stayed quiet for a long time because people started accusing me of 
> > trolling. But now, I REALLY HATE THIS IDIOT IN REDDIT  HE IS DRIVING ME 
> > CRAZY. ASSHOLE ASSWIPE SHITHOLE LUNATIC. I HATE HIM. BASHING D JUST BECAUSE 
> > HE'S SOME MENTALLY ILL PSYCHOPATE WANTING TO KILL ANDREI AND WALTER :-( THE 
> > BEST WE CAN DO IS FIND I LIKE CAKES AND DOWNVOTE ALL HIS VOTES. GO AWAY 
> > TROLL! :-(
> > 
> >  - G.W.
> 
> Are you the idiot with the sockpuppets? Good job giving all of us a bad name.

Gary Whatmore's message looks like a troll post to me. Could even be iLiekCaeks 
himself.

Re: "Code Sandwiches"

[lurker]

Nick Sabalausky Wrote:

> I've never had a USB drive or an SD card die on me. And I've been using the 
> cheap no-name ones from MicroCenter. Maybe you're just using *really* bad 
> ones or being rough on them? Or spend time near strong em fields?

You might forget them in the wrong pocket or your dog might bite the usb 
connector into pieces. I also don't like the unmount feature. You sometimes 
forget to sync data and boom the whole file system is corrupt.

Re: Is DMD 2.052 32-bit?

[lurker]

Jonathan M Davis Wrote:

> On Wednesday 09 March 2011 17:56:13 Walter Bright wrote:
> > On 3/9/2011 4:30 PM, Jonathan M Davis wrote:
> > > Much as I'd love to have a 64-bit binary of dmd, I don't think that the
> > > gain is even vaguely worth the risk at this point.
> > 
> > What is the gain? The only thing I can think of is some 64 bit OS
> > distributions are hostile to 32 bit binaries.
> 
> Well, the fact that you then have a binary native to your system is obviously 
> a 
> gain (and is likely the one which people will cite most often), and that 
> _does_ 
> count for quite a lot. However, regardless of that, it's actually pretty easy 
> to 
> get dmd to run out of memory when compiling if you do much in the way of CTFE 
> or 
> template stuff. Granted, fixing some of the worst memory-related bugs in dmd 
> will 
> go a _long_ way towards fixing that, but even if they are, you're 
> theoretically 
> eventually supposed to be able to do pretty much anything at compile time 
> which 
> you can do at runtime in SafeD. And using enough memory that you require the 
> 64-
> bit address space would be one of the things that you can do in SafeD when 
> compiling for 64-bit. As long as the compiler is only 32-bit, you can't do 
> that 
> at compile time even though you can do it at runtime (though the current 
> limitations of CTFE do reduce the problem in that you can't do a lot of stuff 
> at 
> compile time period).
> 
> In any case, the fact that dmd runs out of memory fairly easily makes having 
> a 
> 64-bit version which could use all of my machine's memory really attractive. 
> And 
> honestly, having an actual, 64-bit binary to run on a 64-bit system is 
> something 
> that people generally want, and it _is_ definitely a problem to get a 32-bit 
> binary into the 64-bit release of a Liunx distro.
> 
> Truth be told, I would have thought that it would be a given that there would 
> be 
> a 64-bit version of dmd when going to support 64-bit compilation and was 
> quite 
> surprised when that was not your intention.

I think porting DMD to 64 bits would be a pragmatic solution to this. Computers 
are getting more memory faster than Walter is able to fix possible leaks in 
DMD. There's awful lots of template and CTFE code using more than 2 or 3 GB of 
RAM. I can't even imagine how one could develop some modern application if this 
was a hard limit. Luckily there are GDC and LDC, which allow enterprise users 
to take full advantage of the 24-64 GB available.

Some simple use case would be Facebook's infrastructure. Assume Andrei wanted 
to rewrite it all in D. Probably more than 100M LOC. Would need hundreds of 
gigabytes of RAM to compile. It would also take days to compile, and maybe 50% 
less on a 64 bit system.

Re: Is DMD 2.052 32-bit?

[lurker]

Jonathan M Davis Wrote:

> Now, assuming that all of that is taken care, if you're using a 32-bit binary 
> on 
> a 64-bit system, you're still going to be restricted on how much that program 
> can use. It doesn't use the native word size of the machine to do what it 
> does, 
> and in many cases, running a 32-bit program on a 64-bit machine is slower 
> than 
> running a 64-bit version of that program on that machine (though that's going 
> to 
> vary from program to program, since there are  obviously quite a few factors 
> which affect efficiency).

The efficiency claim is true. 64-bit architures have much more registers. This 
can effectively double the code's performance in most cases. Loads and stores 
can also use full 64 bits of bandwidth instead of 32. Thus again twice as much 
speed. In general if you worry about larger binary size, use UPX. Other than 
that, 64 bit code outperforms the 32 bit. We want to keep the fastest compiler 
title, right?

Re: "Code Sandwiches"

[lurker]

Walter Bright Wrote:

> On 3/9/2011 10:18 PM, Nick Sabalausky wrote:
> > They're text. With minor formatting. That alone makes html better. Html is
> > lousy for a lot of things, but formatted text is the one thing it's always
> > been perfectly good at. And frankly I think I'd *rather* go with pretty much
> > any word processing format if the only other option was pdf.
> 
> I used to use HTML for presentations. Frankly, it was terrible. The text was 
> rendered badly, especially when blown up on a screen. I could never get it to 
> look right. I couldn't email the presentation to anyone without sending a wad 
> of 
> other files along with it.
> 
> I switched to pdf presentations, and they worked great and looked great. The 
> pdf 
> viewers would render text that looked great blown up. The pdf was all in one 
> file, meaning I could email it to someone and they could look at it directly 
> from their mail program. I would bring backups on a thumb drive so in case my 
> laptop was busted/stolen by the TSA, I could run my presentation on anyone's 
> computer.
> 
> I do not understand why HTML engines do such an ugly job rendering text, 
> while 
> PDF's on the same machine do a great job. This is true on Windows as well as 
> Ubuntu.

This can't be true! Walter defending inferior semi-standard formats. PDF 
doesn't even have as nice transition effects as powerpoint or new jQuery using 
presentations stored in the cloud services. Your thumb drives break anyway once 
a year so I'm in favor of a subscription model for the cloud. Stardard HTML + 
CSS + JavaScript or Flash works for everyone. There's also Silverlight coming 
soon.

Re: How mature is std.socket?

[lurker]

Yes, 2.51:

Digital Mars D Compiler v2.051
Copyright (c) 1999-2010 by Digital Mars written by Walter Bright
Documentation: http://www.digitalmars.com/d/2.0/index.html
Usage:
...

Re: How mature is std.socket?

[lurker]

Are you talking about listener.d? I managed to compile it with the
latest DMD:

http://pastie.org/1565017

Re: How mature is std.socket?

[lurker]

Also, I wouldn't mind a small example of a server using std.socket.

Thanks

How mature is std.socket?

[lurker]

Given that large parts of Phobos are still in flux or planned for
replacement I'd like to ask, how mature is std.socket?

I'm thinking of writing a small server app and would like to know if
there are serious problems awaiting the uninitiated?

Thanks

Re: is it possible to learn D(2)?

[lurker]

Andrei Alexandrescu Wrote:

> On 12/18/10 3:44 PM, Jeff Nowakowski wrote:
> > On 12/18/2010 03:16 PM, Don wrote:
> >> Jeff Nowakowski wrote:
> >>> D2 has *never* been officially released (like D1 was), though its
> >>> release was supposed to coincide with the release of Andrei's book.
> >>
> >> Where did you get that idea? I've never heard it before.
> >> (Genuine question, I'd like to know where that impression came from).
> >
> > Which idea are you questioning? That D2 hasn't been "released", or that
> > the two were supposed to come out together? The answer to both would be
> > the newsgroup.
> >
> > There was plenty of talk about them coming out together, and then time
> > went by, and Andrei's book was relatively quietly released (unless I
> > missed some big announcement; my memory was of posts trickling in of
> > people who had pre-ordered), and no mention was made of D2 being
> > released any more along with the book.
> >
> > I can dig up posts if you like, but I'd rather not unless any of this is
> > in dispute.
> 
> I don't think it's worth investigating this, but at any rate my thinking 
> has been that finalizing TDPL would finalize the specification of D2. Of 
> course, ideally the compiler would follow the specification as closely 
> as possible, but with the number of extant issues it has always been 
> pretty clear that conformance will be trailing.
> 
> The book hasn't been released quietly at all; I've sent numerous updates 
> to this group (just search for TDPL in the title) and my website has 
> made the event as prominent as it could. As it was clearly highly 
> anticipated in this group, laying it any thicker would have been 
> inappropriate.
> 
> >>> Walter and Andrei haven't been very honest in their presentations on
> >>> the state of the language.
> >>
> >> I think the initial estimate of how long things would take was wildly
> >> optimistic. I am certain that there's been no intention to be dishonest,
> >> at any stage.
> >
> > Andrei gives other people a lot of shit over only showing the positive
> > in their presentations. Both Andrei and Walter have misrepresented the
> > open source compiler issues on their slides (and Walter had no excuse
> > after Andrei was called for it on the newsgroup).
> >
> > I saw Andrei's Google presentation and he talked a lot about D2 features
> > and gave away a lot of books, but never once said that D2 was still
> > being implemented and that serious bugs remained.
> 
> A fair point. Well I didn't give away "a lot" of books, I gave three, 
> and specifically for the three most embarrassing questions. (My budget 
> of giveaway books is fairly limited.)

Does this mean that Facebook is not paying you that well, after all? I could 
donate like $82 to you to give away three more books. No need to mention my 
name, after all I'm just helping the poor.

Re: Why Ruby?

[lurker]

Nick Sabalausky Wrote:

> "Jacob Carlborg"  wrote in message 
> news:ie8f5f$o6...@digitalmars.com...
> >
> > Probably not, but, for example, Scala allows very compact delegate 
> > literals:
> >
> > Array(1, 2, 3, 4, 5).select(_ > 3).collect(_ * _)
> >
> > Or more verbose:
> >
> > Array(1, 2, 3, 4, 5).select((x) => x > 3).collect((x, y) => x * y)
> >
> > I'm not 100% sure I that the syntax is correct.
> >
> 
> I'd be surprised if the first one is correct, because that "collect(_ * _)" 
> would seem highly limited (how would you use the same value twice, or use 
> just the second value, or use them in reverse order?).
> 
> The second one reminds me of C#'s lambdas and seems like an excellent 
> solution to the question of what to do with all the noise of the extra curly 
> braces, "return" keyword and trailing semicolon. And given that 1. The => 
> isn't currently a valid D token anyway, and 2. The (x) and (x,y) are already 
> being used perfectly fine by the existing delegate literal syntax, I can't 
> imagine there would be any ambiguity with it in D.
> 
> I'd be absolutely in favor of adding that to D. In fact, I'd love to see it 
> happen. Just require that the part after "=>" is an expression, accept that 
> the more complex delegates that need statements use the existing syntax 
> (which should be fine since it's only the single-expression-and-nothing-else 
> delegates that are seen as verbose in D), and call it a day.

=> would make D look like Perl or PHP or Ruby. Statements are more general than 
expressions, the D's solution is more general. How much the short new syntax 
matters if you need two syntaxes for it?! Would mean 2 function syntaxes, 2 
delegate syntaxes. Two things was already complex for users.

Re: Why Ruby?

[lurker]

Nick Sabalausky Wrote:

> "piotrek"  wrote in message 
> news:ie8fu9$ej...@digitalmars.com...
> > On Mon, 13 Dec 2010 09:49:50 -0600, Andrei Alexandrescu wrote:
> >> By the way, I couldn't stop cringing at the distasteful, male-centric
> >> sexual jokes that the talk is peppered with. Wonder if there was any
> >> woman in the audience, and how she might have felt. And this is not a
> >> ghetto rant - it's the keynote of a major Ruby conference! (And I'm
> >> definitely not a prude.) Am I alone in thinking that this is not what
> >> our metier should evolve into?
> >>
> >>
> >> Andrei
> >
> > You're definitely not. No matter how strong pressure is, I stand and
> > fight against common acceptance for female humiliation. It's so sad
> > to me how many think they're real men while treating women as a things
> > they can freely abuse.
> >
> 
> Didja hear the one about the blonde who couldn't find her pencil?

I have a bad sense of humor, but what is this if I'm trolling?

Re: Slides from my ACCU Silicon Valley talk

[lurker]

Nick Sabalausky Wrote:

> "snk_kid"  wrote in message 
> news:ie8gst$tt...@digitalmars.com...
> > None of those usernames are mine except this one (snk_kid). You need to 
> > stop making assumptions and nobody really cares about a comment voting 
> > system. You come off as a child making such an unprofessional post in a 
> > public mailing list of a programming language. Is this what the D 
> > community is about? I've never seen anything like it before, its pathetic.
> >
> 
> lurker was just trolling. Like Andrew's sign indicated, best not to feed 
> them.

I see, now defending D is considered trolling. Something tells me this Nick is 
actually snc_kid. 

Re: Slides from my ACCU Silicon Valley talk

[lurker]

Why don't you retard, I mean eternium, I mean iLikeCakes, I mean snk_kid, I 
mean WeAreAllTreeBear, I mean bearophile's alter ego, go someplace else. 
Waisting time here is really not worth it. They provide psychiatric treatment 
in hospitals. I can't prove this conspiracy easily, but I also voted down your 
stupid remarks there. I hope this teaches you a lesson.

retard Wrote:

> Tue, 14 Dec 2010 02:56:45 +0100, Andrej Mitrovic wrote:
> 
> > Why do /you/ take it personally?
> 
> You've misunderstood. I only wish the discussion was a bit more technical 
> and had less to do with opinions and hype. The reason is, a more 
> technical approach might solve technical problems in more efficient way. 
> But my goal is not to belittle social issues wrt language adoption. 
> Surely I understand reddit isn't lambda-the-ultimate.org and I'm glad 
> that the Go trolls didn't find the thread (yet). I just find this 
> behavior incomprehensible. 
> 
> My personal stance on this matter is that I believe a more consistent and 
> flexible mechanism for operators would fit D. I'm also a bit more of a 
> fan of C++0x concepts than those contraints shown in the slides. I 
> haven't really thought how it all would work out, but if the atmosphere 
> was more ambitious to this direction, I could participate more. But it 
> seems my vision conflicts badly with what D2 has become.
> 
> > 
> > On 12/14/10, retard  wrote:
> >> Mon, 13 Dec 2010 14:44:36 -0500, snk_kid wrote:
> >>
> >>> Gary Whatmore Wrote:
> >>>
>  Simen kjaeraas Wrote:
> 
>  > Walter Bright  wrote:
>  >
>  > > Andrei Alexandrescu wrote:
>  > >> Compared to the talk at Google, I changed one of the "cool
>  > >> things" from threading to operator overloading. Didn't manage to
>  > >> talk about that - there were a million questions - although I
>  > >> think it's a great topic.
>  > >>  http://erdani.com/tdpl/2010-12-08-ACCU.pdf
>  > >
>  > >
>  > > Anyone care to do the honors and post this to reddit programming?
>  >
>  > Done.
>  >
>  > http://www.reddit.com/r/programming/comments/eklq0/
> >> andrei_alexandrescus_talk_at_accu_silicon_valley/
> 
>  Guys, I made several sockpuppet reddit accounts to mod down the two
>  guys >criticising this thread. I recommend everyone to help us
>  improve D's publicity by >ignoring these trolls and voting them down.
>  It has worked before, too -- reddit >seems to fold the subthreads
>  that get too many negative votes. This makes it >look much better
>  than it is.
> 
>   - G.W.
> >>>
> >>> That's absolutely pathetic, you're actually doing the community a
> >>> disservice.
> >>
> >> I really don't know what to say. Take a look at
> >>
> >> 0 points: http://www.reddit.com/r/programming/comments/eklq0/
> >> andrei_alexandrescus_talk_at_accu_silicon_valley/c18swbi
> >>
> >> or
> >>
> >> -1 points: http://www.reddit.com/r/programming/comments/eklq0/
> >> andrei_alexandrescus_talk_at_accu_silicon_valley/c18sz8n
> >>
> >> These say nothing against D. Why does one take them personally? They
> >> are both also highly informative. As far as I can tell, these two
> >> comments go much deeper in operator semantics theory than the combined
> >> effort of 68 other threads by Walter, Andrei et al. For example the
> >> precedence of operators can get problematic when using several
> >> libraries from various vendors.
> >>
> >> Then you have:
> >>
> >> http://www.reddit.com/r/programming/comments/eklq0/
> >> andrei_alexandrescus_talk_at_accu_silicon_valley/c18t1d5
> >>
> >> "I really like D (2.0) and I wish it would take off."
> >>
> >> 7 points? WTF? What is the value of this reply? It's a purely
> >> subjective opinion and doesn't necessarily even beg for further
> >> discussion.
> >>
> 

Re: const a storage class or a type modifier?

[lurker]

Andrej Mitrovic Wrote:

> I think scope needs to be documented better in the docs. I didn't even
> know it could be used in the parameter list, or what it does for that
> matter.

One of D's strong points is that you never can know what amazing things it can 
do. Bearophile always complains that D doesn't do 'Foo' or 'Bar', but these 
undocumented features since year 200x always bring a smile to my lips. You can 
say 'haha' in the voice of that simpsons wiggum son character.

Re: blog: Overlooked Essentials for Optimizing Code (Software

[lurker]

ruben niemann Wrote:

> Diego Cano Lagneaux Wrote:
> 
> > Well, I think a simple look at the real world is enough to agree that you  
> > need several years of experience and good skills. Moreover, my personal  
> > experience is that it's easier to get a job (and therefore the much needed  
> > working experience) when you have a 3-year degree than a 5-year one, at  
> > least in Spain: I've been told at many job interviews that I was  
> > 'overqualified' (I didn't care about that, just wanted to work, but they  
> > did)
> 
> Same happened to me. I've MSc in computer engineering from a technical 
> university. I began my PhD studies (pattern recognition and computer vision), 
> but put those on hold after the first year because it seemed there isn't much 
> non-academic work on that field and because of other more urgent issues. Four 
> years after getting my MSc I'm still writing user interface html / css / 
> javascript / php in a small enterprise. Hoping to see D or some strongly 
> typed language in use soon. I'm one of the techies running the 
> infrastructure, I should have studied marketing / management if I wanted to 
> go up in the organization and earn more.

It's usually your own fault if you don't get promotions. My career started with 
WAP/XHTML/CSS, J2EE, Tapestry, Struts, then Stripes, Spring, Hibernate, jQuery, 
and few others. Due to my lack of small talk social skills, I was frist moved 
from client interface and trendy things to the backend coding and testing, 
later began doing sysadmin work at the same company. My working area is in the 
basement floor near a tightly locked and cooled hall full of servers. It's 
pretty cold here, I rarely see people (too lazy to climb upstairs to fetch a 
cup of coffee so I brought my own espresso coffee maker here) and when I do, 
they're angry because some  doesn't work again.

Re: why a part of D community do not want go to D2 ?

[lurker #5]

As a long time lurker I witnessed the last, rather infamous event when this 
topic
was brought up.
The way I see it the situation has only deteriorated further since then.
There are still resources spent on managing the "political" situation, to avoid
license infringement, supporting two libraries, duplicating code because of
license issues, not to mention the time spent on just discussing the situation.
Since the developers of the "alternative" standard library obviously have 
ulterior
motives, the only solution is to cut them out of the D ecosystem. This can be
easily achieved if Walter stopped showing this compassionate attitude toward 
them,
and started to officially "not recommend" the use of that library, in any public
forum where the issue is brought up. After a year of this their high attitude
would probably sink to the level where is belongs.
This would not undo the damage they had already done, but at least it would
neutralize any threat they represent to D2.

Re: [D typesystem] What is the type of null?

[lurker]

el muchacho Wrote:
> 
> I don't know if it has already been cited here, but this is a good read :
> Much Ado About Nothing: Putting Java’s Null in its Place
> http://www.ccs.neu.edu/scheme/pubs/dissertation-cobbe.pdf

I only saw words Haskell and Java there. Was enough to make me vomit and made 
my brain refuse to read more. We don't need Java bloat or Haskell academics in 
practical systems programming. There's no way to avoid null.

Re: duck!

[lurker]

Andrei Alexandrescu Wrote:

> I was talking to Walter about Kenji's adaptTo. We both think it's a very 
> powerful enabler, but adaptTo is a bland name. After discussing a few 
> marketing strategies, I proposed "duck". It's short, simple, and evokes 
> "duck typing".
> 
> class C
> {
>  int draw(){ return 10; }
> }
> interface Drawable
> {
>  long draw();
> }
> ...
> auto c = new C;
> auto d = duck!Drawable(c);

Object c = new C;
auto d = duck!Drawable(c); // awes

does this work? After all, c is a C:

Object c = new C;
auto d = duck!Drawable(cast(C)c);

One fears this feature has little real world use. But it's a great way to add 
additional bloat to the puny little Phobos...

It's amusing as always that the syntax is being discussed before we even know 
how this works. How does the int -> long coercion work there? Any possibility 
to get a written spec for this?

Re: Andrei's Google Talk

[lurker]

Juanjo Alvarez Wrote:

> On Thu, 23 Sep 2010 09:53:33 +0200, Don  wrote:
> > No, but you have to include the license WITH the executable (in the 
> > 'documentation and other materials'). Which is fine if in fact 
> there are 
> > 'documentation and other materials'. But it would seem to prohibit 
> > distribution of a bare executable.
> 
> You can include it in the about box, in the --help switch, etc. Many 
> programs do it that way and I never heard of any problem with that.

A valid corner case example was given here: a hello world application. A 
minimal hello world application is "Hello world!" + the bytes used to make the 
syscall. The license text would bloat the executable horribly. Thus, BSD isn't 
suitable for *all* commercial application development. QED

Re: The Wrong Stuff

[lurker]

retard Wrote:

> Sun, 26 Sep 2010 09:26:28 -0400, Michel Fortin wrote:
> 
> > On 2010-09-26 03:56:32 -0400, Don  said:
> > 
> >> I was just referring to the "without having to add new keywords" bit.
> >> And a fairly general comment to the whole thread (not just this post).
> >> I meant that __keywords are available, and the argument that @ provides
> >> a namespace for keywords is completely wrong, and utterly dreadful. I'm
> >> a bit disturbed that people are even thinking in that way.
> > 
> > People (including me) are thinking that way because there is no sane
> > semantic definition of what the @ syntax stands for. I'll grant you one
> > thing: @attributes are only used to affect declarations in one way or
> > another, so as long as this stands they're more limited in purpose than
> > keywords in general. But beyond that, what makes @ different from
> > another namespace for keywords?
> > 
> > 
> >> See also the August 28 post by Herb Sutter: http://herbsutter.com/
> >> 
> >> "My biggest (but not only) beef with C++0x [[attributes]] is that the
> >> standard itself was abusing attributes as disguised [[keywords]].
> >> Attributes are acceptable as pure annotations, but they should have no
> >> semantic effect on the program.
> >> [snip]
> >> it’s a clear example of adding language keywords dressed in attributes’
> >> clothing, and not something I want to be responsible for forcing three
> >> million C++ developers to live with until the end of time."
> > 
> > Unfortunately, one attribute with the @ syntax in D -- and I'd say the
> > flagship one as it was the first and most discussed -- is not a pure
> > annotation as it has a noticeable effect on semantics. I'm talking about
> > @property which, if it ever get implemented, changes your function so it
> > simulates a field. In Herb's terms, @property is clearly a keyword in
> > disguise.
> > 
> > And then you realize many keywords fit that same definition of an
> > attribute (deprecated, pure, nothrow...) and you're left with a very
> > fuzzy concept of what the @ syntax is for. We have an important keyword
> > disguised as an @attribute (@property) and attributes disguised as
> > keywords for historical reason (deprecated, pure, nothrow...). Whatever
> > the @ syntax was supposed to stand for, it's pretty messed up right now.
> > 
> > There's also confusion about the term "attribute" itself. Try reading
> > that page and come with a sane definition of what is an attribute in D.
> > 
> 
> This just makes me wonder, why is it so *** hard to get things right? I 
> remember when D didn't have the @stuff syntax at all. I wished it worked 
> like annotations in Java or in C#. If I made my own 3rd party lint/
> document_generator/unit_test_tool/whatever, and I'd just want a way to 
> decorate some syntax tree nodes. How can it be so hard to do this? Can 
> you use your own @annotations now? Probably not. There's only the 
> @property syntax, nothing else. The __traits keyword was also supposed to 
> change to 'traits' or something a bit more sane. Nothing really happened. 
> Why am I using this language?

There is absolutely no need to use D. In fact some (most?) of us wish that you 
wouldn't.

This answer isn't for you because you implicitly seem to disagree with 
everything, but here it goes: Designing new keywords is a complicated task. 
Walter follows a so called parser oriented thinking - what's easy to implement 
in the parser (the low hanging fruit), seems to be the best solution. If you 
need other kind of changes to the language, you need to carefully take into 
consideration (Herb Sutter like C++ thinking) all kinds of aspects such as 
legacy concerns (C compatibility), namespace issues (__keywords and @keywords 
nicely create new namespaces and don't conflict with user symbols like 
variables). I can't even possibly imagine why would anyone (except you) want to 
use their own keywords. It sounds like a new treacherous way to invite 
dangerous macros to the language. The reservation of the word macro without 
giving an implementation is a conscious decision to disable all kinds of 
over-expressive macros in forthcoming versions of the language. Providing 
customized @!
 keywords for 3rd party tools seems like mocking the damn good state of the art 
meta-programming system D has. If I could design D, I'd use @ in front of every 
keyword to avoid namespace collisions with user symbols.

Re: The Wrong Stuff

[lurker]

Andrei Alexandrescu Wrote:

> On 9/23/10 22:59 CDT, Walter Bright wrote:
> > Jonathan M Davis wrote:
> >> I don't really mind it how it is, but I've known plenty of programmers
> >> who hated the fallthrough behavior in other languages. So, it would
> >> likely be a good change to make.
> >
> > I'm probably alone in this, but I've always liked the C behavior and
> > never had a problem with it. It's probably from my asm days, as it works
> > just like labeled asm statements do.
> 
> Well admitting you're alone in this is the first step to recovery :o).
> 
> Andrei

He's not alone with his view. The automatic implicit porting of C code is an 
important feature - D should work even more like C than it does now. The syntax 
could also make use of a revamp, we have 'pure' and 'const' and so forth, in C 
those are __attribute__((pure)) and similar kind of conventions. The C approach 
saves keywords for actual code.

Re: A summary of D's design principles

[lurker]

Justin Johansson Wrote:

> On 19/09/2010 11:49 PM, Lutger wrote:
> > Justin Johansson wrote:
> >
> >> On 19/09/2010 2:59 AM, Lutger wrote:
> >>> To me some of the most distinguishing aspects of D are:
> >>>
> >>> - scale to complex as well as small programs: unlike C# and Java but 
> >>> perhaps
> >>> like python
> >>>
> >>> - focus on early binding: this quote from David Griers is fitting: "Never 
> >>> put
> >>> off until run time what you can do at compile time." But also related is 
> >>> the
> >>> tendency to choose for a rich set of features, binding at 'language design
> >>> time'
> >>>
> >>> - support a diversity of programming styles (like C++, python) and 
> >>> attempt to
> >>> integrate them
> >>>
> >>> - support for features that help, and avoid designs that complicate
> >>> maintenance of large programs
> >>>
> >>> - take advantage of existing C knowledge and codebase
> >>>
> >>> - enable the programmer to make his own tradeoff between performance and
> >>> other quality criteria: this is true of many languages, but in D there is 
> >>> a
> >>> much wider space to choose from.
> >>
> >> I think the salient point that all miss is that D does not
> >> expand beyond the classical OO paradigm in any meaningful way.
> >
> > I don't understand this statement, there are quite a few things in D that
> > support a different style of programming than OOP, such as:
> > - closures for higher-order programming
> > - pointers, systems programming features
> > - templates
> > - pure, transitive const and immutable
> >
> > Do you think this is not meaningful? Or do you mean that what is actually 
> > needed
> > is a better OOP system than what D offers? What do you have in mind?
> 
> Some of these features you mention are very worthwhile but I mean that
> that D does not offer any better OOP system amongst its contemporary
> rivals.
> 
> To be well read on the subject of OOP models I can recommend this link
> to a well-articulated paper by Bertrand Meyer:
> 
> http://se.ethz.ch/~meyer/publications/computer/taxonomy.pdf

tl;dr

Anyway, D supports many paradigms, read the slides written by Walter in some 
conference. They are the truth. D supports imperative, procedural, functinal, 
metal, meta, constrain, dsl programming, among others. That should be enough.

Andrei A. interview

[lurker]

http://www.reddit.com/r/programming/comments/d58qq/interview_with_andrei_alexandrescu_part_3_d/

The author explains how he used bribery to spread non-political D internally 
inside Facebook, among others =) Great read, good advertisement for us, 
finally, in major media!

Re: [OT] NG needs more simultaneous connections?

[lurker]

Nick Sabalausky Wrote:

> I've been having trouble connection to the NG more and more often in the 
> last couple months. Maybe buzz from TDPL is generating enough new traffic 
> that the current max simultaneous connections setting has become inadequate? 

Now is your chance to build a D2/Phobos using NNTP server that has a fast fiber 
based socket server and provides an AJAX/XHTML/jQuery interface for us web 
users.

Re: Current RDMD, please?

[lurker]

Walter Bright Wrote:

> Jacob Carlborg wrote:
> > Please build the Mac version on Mac OS X 10.5 if possible otherwise it 
> > will only run on Mac OS X 10.6. This should really be fixed in possible.
> 
> 10.6 is over a year old, why not upgrade?

It costs money - money doesn't grow on trees?

Re: Andrei's Google Talk

[lurker]

Johannes Pfau Wrote:

> On 16.08.2010 22:36, lurker wrote:
> > 
> > This is unbelievable douchebaggery. The default ddoc IS good enough for 
> > most of us. There is simply no need for more complex tools. I think ddoc 
> > hits the sweet spot here by providing semi-professional looking html 
> > documents. Like someone said earlier, you can always spent a week worth of 
> > time creating a better tool for document generation.
> > 
> > Doxygen STILL doesn't support D. What does this tell? It tells that C++ is 
> > crappy for software development. The millions of C++ users haven't been 
> > able to write a docgen support for D. It's just not possible. OTOH a 
> > qualified compiler veteran such as Walter wrote a better tool in less than 
> > a week, blindfolded.
> 
> What's the point of this post?
> I never wanted to replace ddoc in any way - the syntax is the best
> documentation syntax that I've seen, the WYSIWYG ideology is great and
> it's great that ddoc can output to different formats. If it sounded like
> I was flaming or something, I did not want to. (I agree, the last point
> about <,> is quite hypothetical)

Whatever. I feel insulted. :-(

> 
> But there are little problems with ddoc - I mentioned a few, some more
> are already known and some of these might even exist in doxygen as well.
> (I don't know doxygen and I always thought it's generated documentation
> looks ugly. I only know the msdn / ndoc / qooxdoo.org api documentation
> which IMHO beat doxygen) Sure most of these issues are often not
> important. But if it's possible why not fix these? Why is spending one
> week (of my time) to enhance ddoc (and fix the known bugs, I want to
> provide a fix for the known problem with stray parenthesis in the next
> few days) a bad thing?

Fixing problems is good, but when creating documentation the main focus is on 
communicating ideas. All kinds of fancy colors just distract people. I like 
default Phobos docs. It's hard to find something as simple from other language 
communities. The C++ documentation sucks so much that I mostly read dead tree 
books. And I think simple macros are better than tons of semicolon rules.

> 
> BTW: what do you consider to be "default ddoc"? I agree that the phobos
> documentation is fine, but there is no default ".ddoc" file shipped with
> dmd and the documentation generated without a special .ddoc file is not
> that great.

I meant that one or candydoc.

Re: Andrei's Google Talk

[lurker]

Johannes Pfau Wrote:

> On 16.08.2010 04:53, Walter Bright wrote:
> > BCS wrote:
> >>> This seems excessive.
> >>>
> >> Unless you are setting up a new output format, you will never see
> >> them. In that light, it doesn't seem excessive to me.
> > 
> > Adding features because one can isn't good enough. One should only add
> > features if they fill a real need.

> bla blah blah bla
{snip}

> 
> -- 
> Johannes Pfau

This is unbelievable douchebaggery. The default ddoc IS good enough for most of 
us. There is simply no need for more complex tools. I think ddoc hits the sweet 
spot here by providing semi-professional looking html documents. Like someone 
said earlier, you can always spent a week worth of time creating a better tool 
for document generation.

Doxygen STILL doesn't support D. What does this tell? It tells that C++ is 
crappy for software development. The millions of C++ users haven't been able to 
write a docgen support for D. It's just not possible. OTOH a qualified compiler 
veteran such as Walter wrote a better tool in less than a week, blindfolded.

Re: Andrei's Google Talk

[lurker]

Walter Bright Wrote:

> dsimcha wrote:
> > == Quote from Adam Ruppe (destructiona...@gmail.com)'s article
> >> To me, the biggest appeal of ddoc is that it doesn't require markup to
> >> give good enough results. It's almost mindless to use.
> > 
> > Not only that, because it doesn't require markup, the docs look good as 
> > plain text
> > comments, not just when processed into HTML.
> 
> That wasn't by accident :-). One of the explicit major goals of Ddoc was to 
> not 
> require any markup unless you are getting into more advanced use of it. Some 
> of 
> the design was compromised to make that work, but I think the results are 
> worth it.

Unlike doxygen, Ddoc almost accepts plain english. It's not hard to see how 
much better designed Ddoc is *for D code*. A generic document generator can 
never support unit tests, contracts and so forth. I disagree with our 
''retard'' completely.

Queue

[lurker]

Is there a Queue in Phobos? I can only see a SList on the online documentation.

Any plans to add other containers?

Thanks.

Re: Andrei's Google Talk

[gcc-lurker]

Walter Bright Wrote:

> Leandro Lucarella wrote:
> > Walter Bright, el  5 de agosto a las 13:34 me escribiste:
> >> mwarning wrote:
> >>> On Thu, 05 Aug 2010 03:23:25 +, BCS wrote:
> >>>
>  For a number of IP/legal reasons, Walter CAN'T work on LLVM or LDC.
> >>> can you please elaborate a bit?
> >>> I remember that statement has appeared before,
> >>> but I can't remember the reason that was given.
> >> Because when I've had the roomful of lawyers do their due diligence
> >> on me, saying "I never looked at the source code" is an effective
> >> defense against any claims of possible infringement. When I say
> >> that, they click their briefcases shut, say "we're done here", and
> >> leave.
> > 
> > That seems a little stupid, there are billions of open source projects,
> > and I never hear anyone giving that excuse not to contribute.
> 
> 
> Have you ever been specifically grilled by lawyers if you stole code from 
> gcc? I 
> have. When people are going to invest a lot of money in your stuff, it better 
> be 
> clean.

I thought the FSS owned GCC. It seems the smelly Stallman is using his evil 
powers and unaware henchmen to force the freedom down our throats. That's why 
we should use unrestrictive commercial friendly licenses only such as the 
Phobos/Boost alliance and BSD. Say no to (L)GPL!

Re: Documentation generation

[Lurker]

Walter Bright Wrote:

> bearophile wrote:
> > Removing that HTML ddoc parsing & HTML generation from DMD allows such code
> > to evolve faster and to be debugged more efficiently. Today some people are
> > using
> 
> There are very good reasons why ddoc is part of dmd.
> 
> 1. Being a defined part of D means it's ALWAYS there. That means there won't 
> be 
> D compilers without ddoc. That means that people can rely on it being there, 
> and 
> use it with confidence.
> 
> 2. Please do not underestimate the power of something reliably being there. 
> In 
> my experience, it makes it FAR more likely that people will actually use it, 
> and 
> there's the big win. If it's a separate utility, I guarantee you that usage 
> of 
> ddoc will drop probably by 90%.

That's just silly. People using 15 different good document generators is much 
better than one s**y one with s**y templates you need to dig from old newsgroup 
posts.

> 
> 3. A separate ddoc utility means that, inevitably, dmd and ddoc will get out 
> of 
> sync with each other. People will update dmd and not ddoc, and vice versa. 
> There 
> is quite enough grief with people mixing one version of dmd with the wrong 
> version of phobos and then being mystified by the results. I can't tell you 
> how 
> many times I've helped someone who INSISTED they were using the correct 
> libphobos.a and there were no others on their machine, only to eventually 
> sheepishly discover another old libphobos.a on their path that was being used.

His idea was probably to separate the tools and still provide them both as part 
of the standard distribution. It would be your duty to keep both up to date.

> 
> 4. Making it a separate utility means others will invent "improved" ddocs, 
> with 
> the resulting balkanization and non-portability of documentation comments. 
> See 
> C++ for the affect this has.

D already has several document generators because ddoc is way too primitive. 
Luckily the main competition (Tango) died because of an organized FUD attack.

> 
> 5. The documentation of Phobos took a HUGE leap forward with the integration 
> of 
> ddoc.

The output is still a huge joke compared to tools like doxygen and javadoc. No 
offense. And those are rather basic document generation tools -- better ones 
exist.

> 
> 6. Similar advantages can be found with the integration of unittesting in D, 
> and 
> the integration of the preprocessor with C/C++ (I'm old enough to remember 
> when 
> that was a separate program).

The integrated unit test is a joke. Spend 30 minutes with Java 6 someday and 
try JUnit. Or maybe few hours. The more you use, the more you learn. If you 
open your eyes, you might actually see how crippled your vision of unit testing 
is. The integrated unittest stuff brings almost zero value when doing serious 
software development.

> 
> 7. Contrary to what you state, making ddoc a separate utility will make it 
> far 
> harder to maintain, not easier.

One of the main reasons why 3rd party tool support sucks is that YOU have zero 
ability communicating technical details to the community. We can see it in 
documentation. Almost none exists. People make lots of questions here and 
instead of answering you always focus on bikeshedding.

> Just outputting JSON files is not enough, as 
> ddoc is also able to pretty-print the declarations and do color syntax 
> highlighting of coding examples. If you look at the dmd source code changes, 
> you'll find that ddoc tracks changes in D's grammar and syntax with rarely 
> any 
> changes at all in the ddoc code.

That's not a surprise. If a docgen tool and a compiler frontend coming from a 
single vendor didn't share any code, I wouldn't call it software engineering. 
It would be a horrible toy project written by an amateur.

Re: Axiomatic purity of D

[lurker]

Justin Johansson Wrote:

> To what degree do the author and advocates of the D(2) Programming
> Language believe that it is axiomatically pure and to what degree
> to the naysayers believe that it is conversely impure.  Further,
> does axiomatic purity in a PL really matter?
> 
> Thanks in advance for all opinions offered.

What *is* axiomatic purity? A quick google books search returned titles like:

"Jesus remembered"
"American physics in transition: a history of conceptual change in"
"Feminism-art-theory: an anthology, 1968-2000"
"Feminism and tradition in aesthetics"
"Constructive interventions: paradigms, process and practice of .."
"Agriculture and rural connections in the Pacific, 1500-1900"
"Possessed by the past: the heritage crusade and the spoils of history"

Documentation on D's vtable

[lurker]

Where's the vtable layout documented? I couldn't find it in the documentation.

Bonus points: How would it look like in C?

Thanks

[OT] The Clay Programming Language

[Lurker]

Interesting generics

http://www.reddit.com/r/programming/comments/ctmxx/the_clay_programming_language/

Re: Status of std.xml (D2/Phobos)

[lurker]

I'm very interested.

Tango's XML code was very good and damn fast. Maybe license issues can be worked
out for that part at least?

Data-binding infrastructure.

[lurker]

Do you think Phobos could benefit by adding data-binding interfaces? The
purpose is to provide the infrastructure necessary so that other libraries
(GUI Toolkits, Validation, ORMs, etc) can inter-operate seamlessly.

In .NET there's a whole set of interfaces for this purpose. They don't have a
great design but the fact that they are standard makes possible to create an
object that can be bound everywhere and performs validation everywhere
(everywhere been, windows client, web application or web service).

You can see all interfaces related to data-binding here:
http://msdn.microsoft.com/en-us/library/41e17s4b.aspx

But the more used are these three:

INotifyPropertyChanged
Provides an event to notify listeners that a property has changed.

IDataErrorInfo
Provides methods that allow validating and display corresponding GUI elements
to the user.

IBindingList
Provides notification when a collection has changed (elements added/removed,
clear, update, ...)

Thanks

bind() vs curry()

[lurker]

What's the difference between std.bind.bind and std.funtional.curry? They seem
to perform the same function (though bind() seams more flexible).

It is really a need for both functions in phobos?

Thanks

Re: need clarification: will typedef, C struct initialization, etc.

[lurker]

Lionello Lunesu Wrote:

> On 1-6-2010 5:38, Andrei Alexandrescu wrote:
> > On 05/31/2010 03:54 PM, bearophile wrote:
> >> Andrei Alexandrescu:
> >>> typedef is gone.
> >>
> >> *mewls* I have shown here some examples of typedef usage, and I'll
> >> keep posting few more in future. I'd like to pull it back from the
> >> grave and keep it :-)
> > 
> > It's wasted time. typedef is gone.
> > 
> > Andrei
> 
> :((
> 
> I also miss typedef. I thought D had a great opportunity to fix it.
> 
> Take something like the Windows headers. It mostly consists of typedefs
> for handles and whatnot. Without typedef you'd have to use alias and
> type safety is out of the windows.
> 
> So what would be the way to translate those Windows headers? Create a
> unique struct for each old typedef? With alias this, and a ctor? Well,
> if that's the way to do it now, why not make typedef a shortcut for
> exactly that!?
> 
> IIRC typedef is gone because you and Walter could not agree whether it
> had to be a subtype or a supertype of the typedef'ed type. For me it's
> rather simple: I want to introduce a new type in such a way that it
> helps me prevent mistakes, ie. passing one handle when the function
> wants another, even though both are based on void*, or whatever.
> 
> Bring typedef back!

You're apparently missing something. The D 2.0+ has and will be designed by 
real group of experts who have "garnered a solid reputation as a leading 
innovator in programming languages and methods", i.e. Walther and Android. They 
have huge experience designing the leading programming languages such as 
Haskell, F#, Spec#, Java7, C#4, Erlang, Discipline, Python3, XML, Go etc. 

The decade of community inspired D has already ended. There's too much momentum 
behind the current design decisions to change that now. The future spec will be 
"casual and conversational, but never at the expense of focus and precision".

You're only wasting your time if you wish D to change. It won't. D is focusing 
on commercial multicore real world applications now. That's happens by using 
Phobos & D2. Your previous bugs are magically gone. We need stability, we don't 
need new features. Most importantly, we don't need no experimental features - 
especially if your proposal comes from a competing language with a simpler 
syntax and more rigorously presented semantics.

Re: One document about Go

[Lurker]

== Quote from bearophile (bearophileh...@lycos.com)'s article
> Lurker:
> Combine the 2 things into one struct and return by value. Multi-value
return makes for hard to comprehend code. So, IMO, it's hardly syntactic
sugar: it's syntactic grafitti.

"You are very wrong, multiple return values are good, if they have a good
enough syntax."

Maybe. Or maybe just your personal opinion/preference. Your first example
looked ugly to me, but I'll see what you did further here and "decide" for
myself if I'd go that far with the "standard C syntax". It does seem like a
complete rethinking of the whole function call syntax and behavior and the
multiple return concept is just one of many if someone was going to start
with a clean slate. Another person may argue that only error codes should be
returned from functions and everything else gets passed as arguments: no
return values, basically then. Since I'm thinking aloud, I will say that I
think the issue in isolation probably can't be effectively dealt with. At
least I would approach it from a higher level to see where the suggestion
fits-in in the grand scheme of things.

"Regarding this C/C++/D/Java/C#/etc are worse and Python and Go are better.
Multiple return values make code simpler to write, simpler to read and
remove the need for silly and logically ridiculous features like "out"
arguments (an input value that is a return? This is making things go
backwards)."

Or so it would seem "backwards" if you decide to view what's in-between the
parens to a called function as "in" args. Which of course they are not, by
design. In C, from where much of existing syntax is derived, "reference
args" are not hard to grasp.

"D language isn't even able to tell if an "out" argument has being used
before it is assigned inside the function (as C# compiler is able to,
because in C# using uninitialized variables is an error) This is awful and
surely worse than multiple return values."

The closest I have come to "in" or "out" keywords has been reading of
MS "managed code" documentation, so I can't see the value in that nor
multiple return values (yet?). I'll probably learn more by lurking in this
thread, so don't waste too much of your time responding to me if I'm
not "getting it".

> import std.stdio: writeln;
> import std.conv: to;
> int foo(int x, out string s) {
> writeln(s);
> int result = x * x;
> s = to!string(result);
> return result;
> }
> void main () {
> string s;
> writeln(s);
> int r = foo(10, s);
> writeln(r);
> }

> A possible syntax for D multiple return values:
> import std.stdio: writeln;
> import std.conv: to;
> (int, string) foo(int x) {
> int result = x * x;
> return (result, to!string(result));
> }
> void main () {
> (int r, string s) = foo(10);
> writeln(s);
> writeln(r);
> }

Looks too foreign, and like it has too much ramification for parsing (not
that I'd know though). This kind of thing seems like something to work out
at language design time and not years after language introduction.

> The second is simpler to understand code and less bug-prone than the first.

That's a weak case at best. While D's "in" and "out" modifiers are surely to
help the compiler in some way mostly, I don't have any issue with the old
way of doing it. It seems more stylistic than anything else.

> An alternative syntax:
> import std.stdio: writeln;
> import std.conv: to;
> [int, string] foo(int x) {
> int result = x * x;
> return [result, to!string(result)];
> }
> void main () {
> [int r, string s] = foo(10);
> writeln(s);
> writeln(r);
> }

I'm not a big fan of overloading parens and brackets yet another way. I
think conceptually, multiple return values may be another straw the tips the
scale toward D becoming unacceptably cryptic (it'a already very cryptic)
rather than useable, especially to those who have never programmed before.
Again though, this all sounds like first thoughts on a new programming
language rather than an existing one.

> 
> Walter Bright:
> > C got it right and it doesn't need fixing.
> I have never programmed in Go, but keep in mind that Go designers are
expert language designers and programmers. They aren't stupid people.
> Anyway, this is not so important. Named arguments and multiple return
values are quite more important (for D3).
> Bye,
> bearophile

Re: One document about Go

[Lurker]

== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> Lurker wrote:

> > When will D support that? Removing unnecessary semis really pretties up
the
> > code.
> This idea reappears every few years, and even gets folded into a language
now
> and then. It started with Pascal, and most recently has appeared in
Javascript.
> The idea basically sux because of the maintenance issue. What maintenance
issue?
> The one where you decide to add a new line of code before the }. You
inevitably
> forget to go back and append the ; to the previous line. Even if you do
happen
> to remember, now your diff visualizer shows 2 lines changed rather than 1.

While I've not coded in a language without semis, I don't think that adding
the semi on a multi-statement line is something easy to forget to do. Did I
grok your example correctly?

> C got it right and it doesn't need fixing.
> (There are other good reasons for the ; I outlined in my blog
> http://www.drdobbs.com/blog/archives/2010/05/improving_compi.html )

I think that when people suggest removing semis, they mean that the compiler
will put them in automagically, in place of an end-of-line character. So on
your blog, where you suggest that semis are important as synching tokens,
it's really the same thing, because you either work with the EOLs or the
compiler converts them to semis on statement lines. Maybe it opens a can of
worms, but maybe semis proliferate to new languages (obviously Go jettisoned
the semis) just because someone picked the "wrong" way to do it with C(?)
and maybe you didn't step back an eval that issue when you created D so long
ago and/or just wanted backwards compatibility with C (?) instead of
a "drastic" departure from it (?).

So, we have a semi-new language (no pun intended), D that embraces semis,
and we have a new language Go that rejects them. The thing is though, C-
compatibility was not a goal of Go but some level of C-likeness was an
important goal for D (right?). Therefore, I think I'd have to weight Go's
decision more, at least for now unless they decide it was a bad decision and
go back and change to semis. And I do like what the the
unnecessary "missing" semis do for code readability.

.02 (Just aloud off the top of my head).

Re: One document about Go

[Lurker]

== Quote from bearophile (bearophileh...@lycos.com)'s article

> In Go you can omit semicolons at the end of lines, so I presume it's not a
terrible thing for C-like languages:
> package main
> import " fmt " // formatted I/O.
> func main() {
> fmt.Printf ("Hello Hello\n")
> }

When will D support that? Removing unnecessary semis really pretties up the
code.

> 
> In Go you can omit some () for example in "if":
> if !*omitNewline {
> s += Newline
> }
> Generally I don't like to remove the parentheses of function calls (as
done in Ruby), but in this case of the 'if' syntax I think removing them
helps remove some useless visual noise from the code.

I disagree.

> 
> The multiple return values is the Go feature I'd like most for D3 (beside
named arguments):
> func f(int i) (int, string) {
> return (i+1) ("supergenial")
> }
> x, y := f(3);

Combine the 2 things into one struct and return by value. Multi-value return
makes for hard to comprehend code. So, IMO, it's hardly syntactic sugar:
it's syntactic grafitti.

> 
> Page 15-26 shows that there is polymorphism in Go too. Go designers are
trying to invent/adopt something simpler than C++-style templates.
> 


"Compile-time polymorhism": you were thinking "generics/templates"? When
seeing or using the term 'polymorphism' without additional modifiers, I tend
to think of "inclusion polymorphism".

Re: Link time optimization in D

[Lurker]

Walter Bright wrote:

"Essentially, link time optimization is a hack to get around the language
problem C/C++ have with their separate compilation model."

I know what you meant, but to be correct: C/C++ have INDEPENDENT
compilation, not SEPARATE compilation; Ada has SEPARATE compilation, for
example.

Re: Spellechecker - is this really fun?

[lurker]

Eldar Insafutdinov Wrote:

> bearophile Wrote:
> 
> > Be gentle, he is working for free for an open source language you too can 
> > use. He's not a bug-fixing robot, I think that being a mammal he needs some 
> > fun once in a while :-)
> 
> And I appreciate that. Even more, we all love the good stuff that D offers 
> you. But it's wrong to say that because it is open source, it has to be fun. 
> Successful open source projects have very strict management, just like in the 
> commercial software development. Python or llvm are good examples of that. 
> Just because the project is opensource it doens't mean that developers have 
> less responsibility. We are all trying to make D successful, a book is about 
> to come out. It is not a toy project, people rely on it. The main page says 
> "Its focus is on combining the power and high performance of C and C++ with 
> the programmer productivity of modern languages like Ruby and Python." I 
> can't see the its productivity if I am stuck with a compiler bug. And I am 
> developing a non-commercial open source project too. What if it was 
> commercial? What would I tell my boss? "There's a compiler bug, and I have no 
> idea when it will be fixed". It's been reported for a month, yet there's no 
> comment!
  from compiler developers on it. Bearing in mind that some important bugs stay 
in bugzilla for years I can assume the same for this bug. Would my boss like 
this uncertainty? Nobody wants to loose money.
> 
> I am not trying to be an asshole here. All of this comes from actually using 
> D. Also I am not begging for fixing that particular bug. I am not in the 
> position of dictating D's development. But a good example for you: I've 
> noticed in the LLVM bugzilla, that Chris Lattner, the leader of the project, 
> comments almost immediately on bugs. I don't see similair things happening in 
> D, even considering that LLVM is used much wider and it's more difficult to 
> control everything for one person.

I think your post hits the nail directly on the head. People expect commitment 
and quality these days. Even open source developers expect quality. The 
competition is huge on compiler market. You have serious competitors like gcc, 
llvm/clang, ghc, icc, java's jit etc. These have superior performance and dmd 
has serious problems that make for instance expression templates dead slow in 
high performance computing. The standard library version of xml parser also 
sucks, Tango has world class implementation.

It's sad to say this, but d2/phobos cannot be used in high performance 
application development during the next 5 to 10 years. It's also bad for 
graphical end user applications because the garbage collector is bad and 
performance wise it cannot win c++ & Qt. So what's left? Open source hobby 
projects.

If you're a commercial user, you must be able to buy support. At this pace, 
even if you shoved tons of dollars to the core developer (yes, there's only one 
- a huge risk for any 3rd party), nothing will change because D seems to be a 
hobby project. I don't know why W is writing code and documentation so slowly. 
I don't know why he doesn't hire more developers (open source developers are 
free!). I can only imagine that he doesn't want anyone to participate, because 
it's his language and it would be shameful if some random community member 
could achieve similar results. There are also intellectual property taint 
issues as we saw with Tango vs Phobos.

Re: sad

[another lurker]

In a manner I was trolling. But it is truth in it. I liked Tango but for long 
time
suspected there is too much personal issues in Tango leaders. Today I know Tango
team wants to have famous not D to have success. Don't know how to express sorry
for poor English. Tango want force people use Tango. Tango is poison.

== Quote from Piotrek (star...@tlen.pl)'s article
> W dniu 30.04.2010 19:42, Steven Schveighoffer pisze:
> > On Fri, 30 Apr 2010 12:16:01 -0400, Arth Lloyd Flores
> >  wrote:
> >
> >> where did you get this news?
> >>
> >> On Sat, May 1, 2010 at 12:08 AM, another lurker  wrote:
> >>
> >>> Tango is dead effective today
> >
> > It is not dead. another lurker was just saying it is dead to him (he
> > will not use it/has deleted it off of his hard drive).
> >
> > -Steve
> Hi
> I've got impression that "another lurker" was trolling. Tango will never
> be dead - for D1 it the only option. So until D1 is used it's alive.
> Different issue is that license chosen for Tango isn't the best one. I'm
> all the way with Walter that license for standard library should be 100%
> legal correct.
> Cheers
> Piotrek

Re: Masahiro Nakagawa and SHOO invited to join Phobos developers

[another lurker]

== Quote from dolive (doliv...@sinal.com)'s article
> Andrei Alexandrescu �:
> > On 04/30/2010 08:55 AM, Moritz Warning wrote:
> > > On Fri, 30 Apr 2010 09:07:06 -0400, Steven Schveighoffer wrote:
> > >
> > >> On Fri, 30 Apr 2010 09:02:32 -0400, Moritz Warning
> > >>   wrote:
> > >>
> > >>> have you thought about just asking the authors of the Tango code in
> > >>> question?
> > >>> I would imagine they would say that they only see a minor resemblance
> > >>> in the api and asking wouldn't even be necessary from their point of
> > >>> view.
> > >>>
> > >> One of the major authors of the Tango time module, John Chapman, cannot
> > >> be located so until he is and agrees the proposed Phobos time module
> > >> cannot be accepted."
> > >>
> > >> -Steve
> > >
> > > Well, then let's point this out (we need to contact JC, that's the
> > > problem at heart).
> > > All the blaming doesn't help anyone.
> >
> > Moritz, I think there is a misunderstanding somewhere.
> >
> > Following SHOO's request to add his date/time to Phobos, Walter received
> > a phone call at home from a Tango representative. The representative
> > stated that the Tango team (of which five people worked on the date/time
> > code) finds that code infringing upon their license, which would make
> > Phobos infringing if it accepted said code.
> >
> >
> > Andrei
> Prohibit tango use dmd1

Yes. They shown their true face today. I deleted all Tango code on my disk and I
will never use it. It is poison.

sad

[another lurker]

Tango is dead effective today

DBC TM

[Lurker]

"Design by Contract is a registered trademark[1] of Interactive Software 
Engineering, Inc. in the United States"

http://en.wikipedia.org/wiki/Design_by_contract

Does Digital Mars has permission for ISE to use the DBC trademark? This is not 
an attack to the D language but I was just curious if Walter had spoken with 
someone at ISE about it.