Re: Possible workaround for static linking of C and D obj files on Win32

[Xiemargl]

Did you try the Open Watcom Linker?
It support OMF, COFF, AR, ELF, but no x64.

Re: Bus error w/combined writeln(int) and uniform

[Lars T. Kyllingstad]

On Sun, 30 Jan 2011 18:43:22 +0100, Magnus Lie Hetland wrote:

> Tried to see if I could find this in the issue tracker; sorry if I
> missed it. (Maybe it manifests with something other than a bus error on
> other platforms?)
> 
> Anyway, when I run the following program in OS X (using dmd 2.051), it
> first prints out 1, and then I get a bus error:
> 
> import std.random, std.stdio;
> void main() {
>  writeln(1);
>  auto y = uniform(0.0, 1.0);
> }
> 
> Writing a string instead, for example, removes the problem (as does many
> other minor changes; I've tried to eliminate as much as possible from my
> original program while retaining the bug).
> 
> Is this already known, or should I submit it?
> 
> Thanks,
> 
> - M

It works fine on Linux, which means the bug is likely OSX specific.  I 
only know of one "mysterious OSX segfault" bug currently in Bugzilla, but 
I'm not sure if it's related:

  http://d.puremagic.com/issues/show_bug.cgi?id=4854

-Lars

Re: Variants array and IDK

[Nick Sabalausky]

"g g"  wrote in message news:ii5mtb$12qv$1...@digitalmars.com...
> IDK where to put this.
>
> first thing:
> Could it be a way to collapse Variants in std.variant?, like
> Variant x = Variant(1)
> Variant y = Variant([x,x,x,x])
> //y could be simplified to Variant(int[]) instead of 
> Variant(Variant(int)[])
> //now it is not implemented (as far i know)
>

The problem with that is that x is only an int at runtime. It's the same 
problem as this:

Variant x = Variant(1);
int z = x;  // ERROR: x might not be an int.

You have to do it like this:

Variant x = Variant(1);
if(x.convertsTo!int())
{
int z = x.coerce!int();
}
else
   // Do something else

Or you skip the "if(x.convertsTo!int())" part if you expect that x should 
always be an int. If it ever isn't an int then coerce will throw an 
exception.

So if you want y to be Variant(int[]), you need to do:

Variant x = Variant(1);
if(x.convertsTo!int())
{
auto xInt = x.coerce!int();
Variant y = Variant([xInt,xInt,xInt,xInt]);
}
else
   // Do something else

Re: std.unittests [updated] for review

[Jens Mueller]

Andrei Alexandrescu wrote:
> On 01/30/2011 06:13 AM, Jens Mueller wrote:
> >Masahiro Nakagawa wrote:
> >>
> >>I vote Andrei's suggestion, std.exception is better than new std.unittests.
> >>I think testing module should provide more features(e.g. Mock, Stub...).
> >>Your helpers help assert writing style but not help testing.
> >>In addition, std.exception already defined similar functions.
> >
> >I do not like putting it in std.exception. Maybe the name std.unittest
> >is also not good. I would propose std.assert if assert wasn't a keyword.
> >When I use std.exception I want to handle situations that are part of
> >the spec (i.e. exceptions) whereas Jonathan's module helps me writing
> >asserts (that's most of the time unittests).
> >Basically it helps me verifying behavior according to a spec. I want to
> >keep the dichotomy of errors and exceptions. Putting both things in one
> >module is rather strange to me. What are the arguments for putting it in
> >std.exception? I find the size a rather weak argument. I thought about
> >providing an assertDeath ones std.process is redone.
> >And even though enforce and assert are mirroring each other they are
> >used in different contexts. I would _not_ expect helpers for writing
> >assertions (Assert_Error_) in a module named std.exception.
> >
> >Jens
> 
> assertThrows and its converse are a good fit for std.exception. Then
> we're left with a couple of concepts that don't deserve their own
> module and are difficult to fit elsewhere. I reckon that in a
> perfect world there would be a better match, but I don't cringe at
> the thought of std.exception holding them.

I going to get used to it. I'll guess I just don't want to loose the
concept of errors vs. exceptions.

Jens

Re: (Was: On 80 columns should (not) be enough for everyone)

[Don]

Tomek Sowiński wrote:

Andrej Mitrovic napisał:


If you really want to set up a column limit that *everyone* has to abide to, 
then make a poll to see what everyone can agree on.


Actually that's a splendid idea. Let's take it easy. Regardless of that silly 
beef I'm really curious what distribution will emerge.

What is your preferred *maximum* length for a line of D code? (please reply 
with a number only)


100 (8 levels of 4-space indent, + 65 characters).
Second preference: 110.

"scope" and "delete" are being removed, but not type-safe variadic templates?

[%u]

Hi,

I just realized something: If the delete keyword is being removed because it's
dangerous, and if the scope storage class is being removed because of the same
dangling reference problem, how come

int[] global_var;
void foo(int[] args...) { global_var = args; }

isn't considered to be just as dangerous, and therefore also being removed?
(Or perhaps this is a bug, and we should always add the scope modifier so that
it prevents reference escaping?)

Thanks! :)

Re: On 80 columns should (not) be enough for everyone

[Max Samukha]

On 01/30/2011 07:17 PM, Andrej Mitrovic wrote:

The unittest topic is about to get derailed so I want to continue this silly 
discussion here.

Wheres Nick? I want to see the CRT vs LCD discussion heated up again with 
Andrei claiming that LCDs are so Godlike but yet claims 80 columns is enough 
for everyone.

80 colums is an artifact of the old age. Just like the preprocessor is an 
artifact of the C language. And many other old things are artifacts. There's no 
reason to keep these artifacts around anymore.

A couple of things, Andrei:
1. 80 colums is way too restrictive. 80 columns wasn't determined by some 
scientific method to be a good size for code, it's a product of limitations of 
the older generation hardware. Who will run a brand new language like D in a 
freakin' Terminal?

Have you ever heard of the expression "limitations boost creativity"? That can be 
considered a good thing, if creativity is what you're after. In code, it's not. You're looking for 
clarity in code. 80 column limitations are good for C obfuscation contests and nothing else. 80 
columns means people are going to *work around* the limit, by using hacks and workarounds to make 
everything fit in place. Do you really believe that programmers are going to spend any time at all 
thinking: *"oh this line doesn't fit on 80 columns. I should now spend some time thinking 
about how to improve and rewrite the design of my code. 80 columns really is the golden 
ration"*?

If you want to see more files on the screen, get multiple screens. Is Facebook 
running out of money, can't they afford a few monitors for the C++ guru? Yes, I 
know you're not allowed to comment on that one. :)

2. A widescreen aspect ratio causes less eye strain. Wider code means the same. 
It doesn't have to stretch all the way to be effective, but 80 columns is too 
limiting. Do a Google search and read what people have go say about that.

3. Less columns means more rows. And generally coders *hate* it when they can't 
see a function that fits on a single screen. They hate having to scroll up and 
down. This common syntax form is a proof of that:
void main() {
 void foo() {
  while (true) {
  if (done) {
  }
  }
  }
}

I find that unpleasant to read. Not impossible, but unpleasant. I can live with 
it though, but if you limit code to 80 limits that's going to become a mess to 
read.

3. It's 2010. Does your GNU/emacs still not support wrapping lines by word 
boundaries? Scite had this since the '90s, and that's not even an advanced 
editor. Vim supports word wrapping as well. Heck, I'm pretty sure you can 
customize it to wrap on whatever boundary you want to (although I'm only 
speculating, but pretty much everything in Vim is customizable). You can even 
customize how your cursor reacts if it's on an 'artificial' new line, one that 
has been wrapped.

Isn't technology amazing?

4. Just how many files do you want to edit at a single time on the screen? 
We're not really multitasking beings, you know. Try using one of your hands and 
do forward circles, as if it were a wheel. With the other one do backward 
circles. And now use your foot to draw a circle on the floor. You're end up 
looking like a clown in seconds, and a bad one at that.

Again, people who want to have documentation, and code, and IRC chats in 
display buy more computer screens. Why should your code have to suffer if you 
really want to do multiple things all at once?

Bottom line:

If you really want to set up a column limit that *everyone* has to abide to, 
then make a poll to see what everyone can agree on. I don't see why everyone 
has to cater to your rules only, regardless of what your professional 
experience might be. You're a big contributor to Phobos, but you're not the 
only one. I tend to believe that D is (or should be) a community effort, so 
please don't hijack D away from the community by forcing your own rules down to 
everyone else.


I think there is no need to establish a fixed limit. "Avoid long lines" 
recommendation in the style guide would be enough.

Re: Smartphones and D

[retard]

Sun, 30 Jan 2011 19:36:44 +0100, Daniel Gibson wrote:

> Am 30.01.2011 13:29, schrieb Michel Fortin:
>> On 2011-01-30 03:05:59 -0500, Gary Whatmore  said:
>>
>>> D's main focus currently is 32-bit x86 servers and desktop
>>> applications. This is where the big market has traditionally been. Not
>>> everyone has 64-bit hardware and I have my doubts about the size of
>>> the smartphone markets.
>>
>> I think the important point here is ARM, not smartphones.
>>
>> ARM processors will soon start to enter other markets, mainly the
>> server and laptop markets,
> 
> I'm not sure about these markets, because ARM is stuck to 32bit, 64bit
> ARM seems to be (almost?) impossible as far as I know.

It will take years before the 64-bit address space starts to make sense 
in portable systems.

While workstations for developers have bigger and completely different 
requirements, in general the most demanding applications for ordinary 
sixpack-joe are hd-video transcoding (which actually isn't memory 
intensive), image manipulation (this year's basic $100 models already 
sport a sensor of 14 megapixels => 45 MB per image layer), and 
surprisingly web browsing.

The ARM equipment support this by providing powerful co-processors and 
having a tiny (Thumb) instruction set. It's really hard to see where they 
would need more than 4 GB of RAM.. even according to Moore's law it will 
take at least 6 years for the top of the line products to use this much 
memory.

Re: Bus error w/combined writeln(int) and uniform

[Magnus Lie Hetland]

On 2011-01-31 10:18:49 +0100, Lars T. Kyllingstad said:


It works fine on Linux, which means the bug is likely OSX specific.  I
only know of one "mysterious OSX segfault" bug currently in Bugzilla, but
I'm not sure if it's related:

  http://d.puremagic.com/issues/show_bug.cgi?id=4854


Thanks for the tip. I have no idea if they're related either; it seems 
I did get a segfault (and bus error) under other circumstances as well. 
I guess maybe I'll add a comment to the bug.


--
Magnus Lie Hetland
http://hetland.org

Re: Smartphones and D

[dennis luehring]

While workstations for developers have bigger and completely different
requirements, in general the most demanding applications for ordinary
sixpack-joe are hd-video transcoding (which actually isn't memory
intensive), image manipulation (this year's basic $100 models already
sport a sensor of 14 megapixels =>  45 MB per image layer), and
surprisingly web browsing.

The ARM equipment support this by providing powerful co-processors and
having a tiny (Thumb) instruction set. It's really hard to see where they
would need more than 4 GB of RAM.. even according to Moore's law it will
take at least 6 years for the top of the line products to use this much
memory.


but they work on 64bit:
http://www.computerworld.com/s/article/9197298/Arm_readies_processing_cores_for_64_bit_computing

Re: Smartphones and D

[retard]

Mon, 31 Jan 2011 12:04:11 +0100, dennis luehring wrote:

>> While workstations for developers have bigger and completely different
>> requirements, in general the most demanding applications for ordinary
>> sixpack-joe are hd-video transcoding (which actually isn't memory
>> intensive), image manipulation (this year's basic $100 models already
>> sport a sensor of 14 megapixels =>  45 MB per image layer), and
>> surprisingly web browsing.
>>
>> The ARM equipment support this by providing powerful co-processors and
>> having a tiny (Thumb) instruction set. It's really hard to see where
>> they would need more than 4 GB of RAM.. even according to Moore's law
>> it will take at least 6 years for the top of the line products to use
>> this much memory.
> 
> but they work on 64bit:
> http://www.computerworld.com/s/article/9197298/
Arm_readies_processing_cores_for_64_bit_computing

What this means is that the same add/sub/mul/div calculator program which 
previously needed 2000 bytes of RAM on my grandfather's PDA soon uses 500 
GB.

Re: On 80 columns should (not) be enough for everyone

[Daniel Gibson]

Am 31.01.2011 00:17, schrieb Stewart Gordon:

On 30/01/2011 17:17, Andrej Mitrovic wrote:


80 colums is an artifact of the old age. Just like the
preprocessor is an artifact of the C language. And many other old
things are artifacts. There's no reason to keep these artifacts
around anymore.


Other than, as you begin to say, the difficulty in deciding on where to
move the line to.


A couple of things, Andrei:
1. 80 colums is way too restrictive. 80 columns wasn't determined
by some scientific method to be a good size for code, it's a
product of limitations of the older generation hardware. Who will
run a brand new language like D in a freakin' Terminal?


For all I know, people probably still do run the D compiler in the
terminal app on Unix-like systems.



1. The D-Compiler doesn't care if the code fits in your terminal
2. You can have bigger terminals than 80x25 - just resize your 
xterm/rxvt/gnome-terminal/putty/whatever

Re: Smartphones and D

[Daniel Gibson]

Am 31.01.2011 11:52, schrieb retard:

Sun, 30 Jan 2011 19:36:44 +0100, Daniel Gibson wrote:


Am 30.01.2011 13:29, schrieb Michel Fortin:

On 2011-01-30 03:05:59 -0500, Gary Whatmore  said:


D's main focus currently is 32-bit x86 servers and desktop
applications. This is where the big market has traditionally been. Not
everyone has 64-bit hardware and I have my doubts about the size of
the smartphone markets.


I think the important point here is ARM, not smartphones.

ARM processors will soon start to enter other markets, mainly the
server and laptop markets,


I'm not sure about these markets, because ARM is stuck to 32bit, 64bit
ARM seems to be (almost?) impossible as far as I know.


It will take years before the 64-bit address space starts to make sense
in portable systems.



Again: "ARM processors will soon start to enter other markets, mainly 
the *server* and laptop markets,"
So while you /may/ be true about laptops, servers definitely can use 
more than 4GB of RAM.

Re: Smartphones and D

[Daniel Gibson]

Am 31.01.2011 12:04, schrieb dennis luehring:

While workstations for developers have bigger and completely different
requirements, in general the most demanding applications for ordinary
sixpack-joe are hd-video transcoding (which actually isn't memory
intensive), image manipulation (this year's basic $100 models already
sport a sensor of 14 megapixels => 45 MB per image layer), and
surprisingly web browsing.

The ARM equipment support this by providing powerful co-processors and
having a tiny (Thumb) instruction set. It's really hard to see where they
would need more than 4 GB of RAM.. even according to Moore's law it will
take at least 6 years for the top of the line products to use this much
memory.


but they work on 64bit:
http://www.computerworld.com/s/article/9197298/Arm_readies_processing_cores_for_64_bit_computing




Hmm I didn't know about that. I thought I read some months ago that 
porting ARM to 64bit is almost impossible.


As a side note, a comment on the article:
"However, it's easy to imagine a service such as Amazon's EC2 offering 
virtualized Linux instances without the user being aware that it's an 
ARM setup, and these could be cheaper than equivalent x86 instances 
(perhaps even making for a "budget EC2" service)."
This is BS, because the user is *directly* using EC2 VMs (can use his 
own binaries etc), so he *will* care if it runs x86 or ARM. And I don't 
think anyone would want to emulate x86 on ARM...


Cheers,
- Daniel

Re: On 80 columns should (not) be enough for everyone

[Nick Sabalausky]

"Daniel Gibson"  wrote in message 
news:ii67i0$1vf2$2...@digitalmars.com...
> Am 31.01.2011 00:17, schrieb Stewart Gordon:
>>
>> For all I know, people probably still do run the D compiler in the
>> terminal app on Unix-like systems.
>>
>
> 1. The D-Compiler doesn't care if the code fits in your terminal
> 2. You can have bigger terminals than 80x25 - just resize your 
> xterm/rxvt/gnome-terminal/putty/whatever

Not if you're in text-mode. Which could happen if your X11 gets fucked. 
Which has happened to me [randomly] on more than one occasion. Of course, if 
that does happen, then editing D code probably wouldn't be your biggest 
priority, so I'm not really making much of a point here...

Re: (Was: On 80 columns should (not) be enough for everyone)

[Michel Fortin]

On 2011-01-31 02:18:26 -0500, foobar  said:

Phobos is a very good product that I for one will never use. Just 
looking at the one huge page for algorithms is enough to discourage 
many people.


But is Phobos the problem or is the one-page-per-module documentation 
the problem?


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: "Internal error: backend\cod1.c 1895" when trying to build DMD/Druntime/Phobos from source

[Vladimir Panteleev]

On Mon, 31 Jan 2011 06:13:54 +0200, Walter Bright  
 wrote:



Vladimir Panteleev wrote:
Compiling the source from the .zip still yields a broken dmd.exe. My  
version and the one from the .zip seem to differ in many small ways.  
The first difference is that in main(), the .zip version calls a  
function to get the address of errno, while my .exe accesses a variable  
directly.


Check your dmc's errno.h. It should call a function.


It's declared as follows:

#if defined(_MT) || defined(_DLL) || __cplusplus
extern int * __CLIB _errno(void);
#define errno (*_errno())
#else
extern int __cdecl errno;
#endif

So, which of _MT or _DLL or __cplusplus should be defined on my machine  
but aren't?


--
Best regards,
 Vladimirmailto:vladi...@thecybershadow.net

Re: Smartphones and D

[Jacob Carlborg]

On 2011-01-30 18:53, Daniel Gibson wrote:

Am 30.01.2011 09:30, schrieb Gary Whatmore:

Jonathan M Davis Wrote:


On Sunday 30 January 2011 00:05:59 Gary Whatmore wrote:

jim_g Wrote:

What I tried to say is, in my opinion, a language with only a half
or a
quarter of D's improvements over C++ would be more successful on
smartphone/tablet platforms than yet another x86 oriented language, no
matter how good. The killer feature is to be in the right place and
the
right time.


That's clearly not true. D is a revolutionary new language. It's
supposed
to replace most of the mainstream language including C/C++, C#,
Objective
C, and Java. The scripting capabilities also make D a good
competitor for
the notorious Python, leading to several orders of magnitude better
performance than slow VM languages give. We have a Python fan
(bearphile)
in this mailing list who has several times shown how D outperforms
Python
(which probably is the fastest scripting language).

D's main focus currently is 32-bit x86 servers and desktop
applications.
This is where the big market has traditionally been. Not everyone has
64-bit hardware and I have my doubts about the size of the smartphone
markets. The modern iterators, streams, and XML processing in Phobos 2
help in these a lot. D is also fully open source which means it's a
perfect replacement for open source frameworks (Qt).


I do think that it would be a definite boon to be able to create D
programs for
smart phones, but the overall focus of D development has been on the
language
itself and the standard libraries, not on making it work on additional
platforms. That's a backend issue. It will likely be addressed at
some point,
but it's not a priority. There's just too much else to do.

Not to mention, until some of the D GUI toolkits - such as QtD - are
more
mature, I'm not sure how feasible it would be to create smart phone
applications
anyway. GUI development is not one of D's strong suits at this point.
It's being
addressed, but it takes time.


Another point worth noting is that these phones are really limited. It
doesn't make sense to run a garbage collected D in them. Mine has
96x65 pixels according to Wikipedia. It likely has few kilobytes of
RAM. A simple hello world wouldn't fit in the ram. Would be much
better to replace Qt for desktop users with a GUI written in D.

- G.W.


Then it's not a smartphone, at least not a modern one.
jim_g was talking about Android phones and iphones, which are pretty
powerful and handle garbage collected languages just fine (android uses
java..)


Objective-C on iOS doesn't use the GC. But I think Mono does.

--
/Jacob Carlborg

Re: Bus error w/combined writeln(int) and uniform

[Jacob Carlborg]

On 2011-01-31 12:04, Magnus Lie Hetland wrote:

On 2011-01-31 10:18:49 +0100, Lars T. Kyllingstad said:


It works fine on Linux, which means the bug is likely OSX specific. I
only know of one "mysterious OSX segfault" bug currently in Bugzilla, but
I'm not sure if it's related:

http://d.puremagic.com/issues/show_bug.cgi?id=4854


Thanks for the tip. I have no idea if they're related either; it seems I
did get a segfault (and bus error) under other circumstances as well. I
guess maybe I'll add a comment to the bug.


To begin with, are you using Mac OS X 10.5 or 10.6? If you're using 10.6 
we can rule out that bug.


--
/Jacob Carlborg

Re: Bus error w/combined writeln(int) and uniform

[Jacob Carlborg]

On 2011-01-31 10:18, Lars T. Kyllingstad wrote:

On Sun, 30 Jan 2011 18:43:22 +0100, Magnus Lie Hetland wrote:


Tried to see if I could find this in the issue tracker; sorry if I
missed it. (Maybe it manifests with something other than a bus error on
other platforms?)

Anyway, when I run the following program in OS X (using dmd 2.051), it
first prints out 1, and then I get a bus error:

import std.random, std.stdio;
void main() {
  writeln(1);
  auto y = uniform(0.0, 1.0);
}

Writing a string instead, for example, removes the problem (as does many
other minor changes; I've tried to eliminate as much as possible from my
original program while retaining the bug).

Is this already known, or should I submit it?

Thanks,

- M


It works fine on Linux, which means the bug is likely OSX specific.  I
only know of one "mysterious OSX segfault" bug currently in Bugzilla, but
I'm not sure if it's related:

   http://d.puremagic.com/issues/show_bug.cgi?id=4854

-Lars


Can it be this problem: http://d.puremagic.com/issues/show_bug.cgi?id=4854 ?

--
/Jacob Carlborg

Re: Smartphones and D

[dennis luehring]

Am 31.01.2011 12:15, schrieb retard:

Mon, 31 Jan 2011 12:04:11 +0100, dennis luehring wrote:


 While workstations for developers have bigger and completely different
 requirements, in general the most demanding applications for ordinary
 sixpack-joe are hd-video transcoding (which actually isn't memory
 intensive), image manipulation (this year's basic $100 models already
 sport a sensor of 14 megapixels =>   45 MB per image layer), and
 surprisingly web browsing.

 The ARM equipment support this by providing powerful co-processors and
 having a tiny (Thumb) instruction set. It's really hard to see where
 they would need more than 4 GB of RAM.. even according to Moore's law
 it will take at least 6 years for the top of the line products to use
 this much memory.


 but they work on 64bit:
 http://www.computerworld.com/s/article/9197298/

Arm_readies_processing_cores_for_64_bit_computing

What this means is that the same add/sub/mul/div calculator program which
previously needed 2000 bytes of RAM on my grandfather's PDA soon uses 500
GB.


there are so many different ARM Architectures out there that i don't 
thing that someone will put an comming 64bit variant into an PDA... no 
one needs to be afraid here

Re: d-programming-language.org

[Ary Manzana]

On 1/30/11 5:03 AM, Andrei Alexandrescu wrote:

I've had some style updates from David Gileadi rotting in a zip file in
my inbox for a good while. It took me the better part of today to
manually merge his stale files with the ones in the repository, which
have in the meantime undergone many changes.

The result is in http://d-programming-language.org. It has (or at least
should have) no new content, only style changes. I added a simple site
index, see http://d-programming-language.org/siteindex.html. It's not
linked from anywhere but gives a good entry point for all pages on the
site.


It looks great!!

The only think I don't like is the background image. I mean, I like the 
background, it just doesn't have to be an image. Each time I go to 
another page it shows me a white page and then loads everything. It 
would be much better to use the lastest css gradient feature ( 
http://robertnyman.com/2010/02/15/css-gradients-for-all-web-browsers-without-using-images/ 
). Of course this won't work in IE, but just put a brown background 
color for IE or put a background image just for IE.

Re: Is D still alive?

[Steven Schveighoffer]

On Fri, 28 Jan 2011 20:16:54 -0500, Walter Bright  
 wrote:



Steven Schveighoffer wrote:

I can't buy "enterprise" support,


Of course you can!


No really, I can't afford it ;)

But seriously, I find it hard to believe that you can buy enterprise  
support for D if it means that you do the work.  There's only one you.  So  
at some point, you might be spread too thin between adding new features,  
posting to this newsgroup, and supporting all enterprise customers.


Any estimate you can give on how many such customers you have?

-Steve

Re: Is D still alive?

[Steven Schveighoffer]

On Fri, 28 Jan 2011 16:25:49 -0500, retard  wrote:


Fri, 28 Jan 2011 10:14:04 -0500, Steven Schveighoffer wrote:

I think as D matures
and hopefully gets more enterprise support, these problems will be
history.


This is the classic chicken or the egg problem. I'm not trying to be
unnecessarily mean. Enterprise support is something you desperately need.
Consider dsource, wiki4d, d's bugzilla etc. It's amazing how much 3rd
party money and effort affects the development. Luckily many things are
also free nowadays such as github.


I'd say the last 1-2 years have been extremely productive compared to the  
previous years combined.  I feel like the growth has been better than  
linear.


I'm not saying enterprise support is waiting in the wings for D to be  
"fully mature", and it might take someone developing a for-sale compiler  
to get to that point.  But even without that kind of support, I expect  
that usable stability in dmd will come about sooner rather than later.



The statements I made are not a property of D, they are a property of
the lack of backing/maturity.  I'm sure when Haskell was at the same
maturity stage as D, and if it had no financial backing/support
contracts, it would be just as much of a gamble.


But Haskell developers have uninterruptedly received funding during the
years.


If I understand you correctly, that's not what I'm talking about.  I'm  
talking about a company who *uses* haskell being able to go to a  
haskell-supplier company and say "I want you guys to guarantee you will  
fix any bugs we encounter."  If that's what you mean, then I stand  
corrected, but then that makes Haskell not a good comparison here...



You seem to think that D is inherently flawed because of D, but it's
simply too young for some tasks.  It's rapidly getting older, and I
think in a year or two it will be mature enough for most projects.


I've heard this before. I've also heard the 64-bit port and many other
things are done in a year/month or two. The fact is, you're overly
optimistic and these are all bullshit. When I come back here in a year or
two, I have full justification to laugh at your stupid claims.


Open-source development takes time, and is hard to predict, because  
typically it comes from free time, which isn't guaranteed.  Because it's  
hard to predict doesn't mean a) "it's all bullshit", b) it doesn't make  
progress, and c) it will never succeed.


In two years if you come back here and laugh at me, I will again shake my  
head in pity that you care so much about such things.  I gave me best  
estimate, and maybe I'm off.  We aren't on trial here, or having lives  
depend on us.  You need to find a more constructive outlet for your  
pessimism.  Well, it would be nice if it was simply on another newsgroup.


-Steve

Re: Variants array and IDK

[Robert Jacques]

On Mon, 31 Jan 2011 02:04:11 -0500, g g  wrote:


IDK where to put this.

first thing:
Could it be a way to collapse Variants in std.variant?, like
Variant x = Variant(1)
Variant y = Variant([x,x,x,x])
//y could be simplified to Variant(int[]) instead of  
Variant(Variant(int)[])

//now it is not implemented (as far i know)

Also if want to know if using Variant  internally for a scripting  
language is recommendable ( or acceptable)
I am facing the problem? writing my weird language (  
https://github.com/zkp0s/Dw fell free to comment on it __not finished__)


Excuse me if I wrote in the wrong newsgroup. I didn't know where to put  
it, .learn .D or .annouce ( Dw)


Thanks for reading
.


One of Variant's design goals is to be used for interfacing/implementing  
scripting languages. So, yes, I'd say it's both recommended and  
acceptable. In fact, I'd encourage you to post to the newsgroup or  
bugzilla any rough edges you run into with variant. I've been working on  
an update to it which fixes all current bugzilla issues and implements a  
runtime-reflection system.  
(https://jshare.johnshopkins.edu/rjacque2/public_html/variant.mht,  
https://jshare.johnshopkins.edu/rjacque2/public_html/variant.d)

Re: Decision on container design

[Steven Schveighoffer]

On Fri, 28 Jan 2011 18:32:28 -0500, Michel Fortin  
 wrote:


On 2011-01-28 17:09:08 -0500, Andrei Alexandrescu  
 said:



On 1/28/11 3:05 PM, Michel Fortin wrote:

Not my preferred choices (especially #1), but having containers in
Phobos will certainly be an improvement over not having them. So go  
ahead!
 Well if you brought forth some strong argument I'm all ears. What I  
see for now is that struct containers are just difficult to implement  
and need to have carefully explained semantics, whereas a lot of people  
know how classes behave from day one.


We already argument this over and over in the past. First, I totally  
acknowledge that C++ style containers have a problem: they make it  
easier to copy the content than pass it by reference. On the other side  
of the spectrum, I think that class semantics makes it too easy to have  
null dereferences, it's easy to get lost when you have a container of  
containers.


I have some experience with containers having class-style semantics: in  
Objective-C, I ended up creating a set of macro-like functions which I  
use to initialize containers whenever I use them in case they are null.  
And I had to do more of these utility functions to handle a particular  
data structure of mine which is a dictionary of arrays of objects. In  
C++, I'd have declared this as a "map< string, vector< Object > >" and  
be done with it; no need for special care initializing each vector, so  
much easier than in Objective-C.


I see value in this idiom, and I have ideas on how to solve this with  
class-based containers.  Essentially, I think we need a way to construct a  
"container of containers" where the owner container is the one who has  
class semantics, and the sub-containers only provide access through the  
owner.  I haven't fleshed out how this will work, but it solves another  
really important problem that dcollections currently has --  
over-allocation.


The issue is, if you have a nested container (say a map of strings to  
linked-lists), the map container pre-allocates a page of elements, to ease  
stress on the GC.  But so does each linked list!  However, since the lists  
all are part of the map, they could potentially share the same allocator.   
If you have few elements in each list, this could significantly reduce the  
over-allocation of memory.


-Steve

Re: Decision on container design

[Steven Schveighoffer]

On Sat, 29 Jan 2011 12:09:00 -0500, Simon Buerger  wrote:


On 28.01.2011 19:31, Andrei Alexandrescu wrote:

1. Containers will be classes.

2. Most of the methods in existing containers will be final. It's up
to the container to make a method final or not.

3. Containers and their ranges decide whether they give away
references to their objects. Sealing is a great idea but it makes
everybody's life too complicated. I'll defer sealing to future
improvements in the language and/or the reflection subsystem.

4. Containers will assume that objects are cheap to copy so they won't
worry about moving primitives.


Not perfectly what I would like, but a reasonable choice, and most  
important to actually have a mature container-lib. But there are other  
choices remaining: what containers will be there and what will they be  
called? My suggestion is


* Set, MulitSet, Map, MultiMap (hash-table based)
* OrderedSet, OrderedMultiSet, OrderedMap, OrderedMultiMap (tree-based)
* Sequence (like stl-Deque. the name is just more intuitive. Funny  
enough, the stl-deque implemenation has nothing to do with a "doubly  
linked list")
* Array (like stl-vector. I think "vector" is a kinda strange name, but  
that may be only my impression)

* List (linked list)

* Stack/Queue/PriorityQueue should be done on top of an other class,  
with a "impl"-template-param, like the stl-ones


Things to note:
* container should be named with respect to their use, not the  
implementation. "HashSet" is a bad name, because the user shouldnt care  
about the implemenation.


* unordered sets are used more often than ordered. So it should be  
"Set/OrderedSet", and not "UnorderedSet/Set" (also, the first one is two  
characters less typing *g*)


* opEqual should work between different types of Sets (or Maps, or  
sequences). Nothing wrong with comparing an ordered to an unordered one,  
or a list to an array.


http://www.dsource.org/projects/dcollections

-Steve

Audio time-compression (Was: On 80 columns should (not) be enough for everyone)

[Ulrik Mikaelsson]

2011/1/30 Walter Bright :
> People who use screen readers often crank up the playback rate to 2x. The
> software adjusts the pitch so it doesn't sound like the Chipmunks.
>
> I've often wondered why DVRs don't do this (I've sent the suggestion to
> Tivo, they ignored me). I'd like the option to play the news (or other talk
> shows) at a faster rate, with pitch adjustment. I've found I can watch Tivo
> at 3x with the closed captioning on, and can almost keep up. The problem
> with DVRs at any fast forward speed is they turn the sound off! G.
>
> A golden opportunity missed.
>
> I'd also love it if youtube etc. did this. It's so boring looking at youtube
> presentations because they talk so slow. I'd love a double speed youtube
> viewing option.
>
> Remember I posted this in case some troll tries to patent it.
I KNEW I wasn't alone at this. My S.O. usually just rolls her eyes
when I do this. (Tip: VLC does it for at least double-speed)

I think the reason I.E. YouTube and Tivo don't do it is that AFAIU, it
is fairly CPU-consuming (FFT back and forth?) In the TiVo-case, my
guess is nobody paid for the hardware, and in the YouTube-case I doubt
neither Flash nor JavaScript will enable the performance required.
Perhaps it can be done browser-dependently with HTML5.

Now, what we need is the audio-equivalent of this:
http://www.youtube.com/watch?v=6NcIJXTlugc

Re: Smartphones and D

[Andrew Wiley]

On Mon, Jan 31, 2011 at 5:51 AM, Daniel Gibson wrote:

> Am 31.01.2011 11:52, schrieb retard:
>
>  Sun, 30 Jan 2011 19:36:44 +0100, Daniel Gibson wrote:
>>
>>  Am 30.01.2011 13:29, schrieb Michel Fortin:
>>>
 On 2011-01-30 03:05:59 -0500, Gary Whatmore  said:

  D's main focus currently is 32-bit x86 servers and desktop
> applications. This is where the big market has traditionally been. Not
> everyone has 64-bit hardware and I have my doubts about the size of
> the smartphone markets.
>

 I think the important point here is ARM, not smartphones.

 ARM processors will soon start to enter other markets, mainly the
 server and laptop markets,

>>>
>>> I'm not sure about these markets, because ARM is stuck to 32bit, 64bit
>>> ARM seems to be (almost?) impossible as far as I know.
>>>
>>
>> It will take years before the 64-bit address space starts to make sense
>> in portable systems.
>>
>>
> Again: "ARM processors will soon start to enter other markets, mainly the
> *server* and laptop markets,"
> So while you /may/ be true about laptops, servers definitely can use more
> than 4GB of RAM.
>

They already have address extension technologies in place to allow up to 1TB
of RAM with certain CPUs. It's not 64 bit, but it does fix the memory
problem.

Re: (Was: On 80 columns should (not) be enough for everyone)

[Andrei Alexandrescu]

On 01/31/2011 01:18 AM, foobar wrote:

Andrei Alexandrescu Wrote:


== Quote from Walter Bright (newshou...@digitalmars.com)'s article

foobar wrote:

ATM, Phobos ranks extremely poorly in this regard. Far worse than C++ which
is by far one of worst ever. both Java and C# are surprisingly high on this
list and are behind various "new-age" scripting languages such as python and
Ruby and languages that were designed to be readable by humans such as
Smalltalk.

I think you've mixed up libraries with languages. Please rephrase so we know
what you're referring to and give specifics.


Seconded. Also there is this one presupposition that reflects poorly on 
foobar's argument: that choosing foobar's
preferred convention inherently makes the code more accessible. In fact, a 
stronger argument could be made to
the contrary as we're talking about a maximum and 80<  120.

Andrei from the ER


That's just incorrect since I didn't even specify my style convention.
As I said multiple times before, Phobos is design with Andrei in mind: meaning 
that if you are Andrei-like (or if you _are_ indeed Andrei) it would be easy to 
read and use. Otherwise it confusing as hell and hard to navigate.


But that goes for anyone, including your code. Code written in foobar's 
style is designed with foobar in mind: meaning that if you are 
foobar-like (or if you _are_ indeed foobar) it would be easy to read and 
use. Otherwise it is confusing as hell and hard to navigate.


I can only assume you'd have a hard time writing code that does not have 
foobar's signature. Same here.


Besides, it seems to have worked for me; at work I'm not considered one 
of the more obfuscated coders. Also, I wrote a little library Loki which 
is regarded as very small and readable for what it does. Its 
functionality has been shadowed by the much larger and comprehensive 
Boost, but Loki's code has always been the simplest and cleanest 
although it implements rather advanced concepts. Do you have any 
publicly available samples of your work that we might look at?



In addition, you now want to force artificial limits that don't make
any sense.

You completely miss the most important principle - it doesn't matter
how good and efficient your product is if no one's using it. Phobos
is a very good product that I for one will never use. Just looking at
the one huge page for algorithms is enough to discourage many
people.


From what I've seen, everyone who advocates D2 mentions std.algorithm 
as one of its main strengths, and never as a liability. I have 
difficulty reconciling that signal with one opinion relayed anonymously.



Andrei

Re: On 80 columns should (not) be enough for everyone

[Andrei Alexandrescu]

On 01/31/2011 01:48 AM, foobar wrote:

Stewart Gordon Wrote:


Therein lies the problem - in this day and age, everyone's screen is
different, and everyone's needs are different.  Even if we can get
people to agree on a limit of 100 in this day and age, it might not suit
the programmers of the future.  After all, OUAT people managed with the
32 columns of the ZX Spectrum.

Stewart.


That's why I'm opposed to *any*  artificial limit as proposed by Andrei.


Opposition rendered anonymously from an armchair quarterback has little 
credibility. If you join Phobos on technical merit, we will all be very 
glad to do our best to accommodate your needs.


Andrei

Re: Is D still alive?

[Simen kjaeraas]

Steven Schveighoffer  wrote:

On Fri, 28 Jan 2011 20:16:54 -0500, Walter Bright  
 wrote:



Steven Schveighoffer wrote:

I can't buy "enterprise" support,


Of course you can!


No really, I can't afford it ;)

But seriously, I find it hard to believe that you can buy enterprise  
support for D if it means that you do the work.  There's only one you.   
So at some point, you might be spread too thin between adding new  
features, posting to this newsgroup, and supporting all enterprise  
customers.


Even if that is the case, Walter is free to hire others to do the
enterprise work for him.


--
Simen

Re: Decision on container design

[Simon Buerger]

On 31.01.2011 17:53, Steven Schveighoffer wrote:

http://www.dsource.org/projects/dcollections

-Steve


Well, seems not bad on a quick look. But source is updated 2 years 
ago, so I doubt it would compile with current dmd. Anyway, the topic 
here is the std-behaviour of the std-lib. But sure, always nice to 
have custom alternatives.


Krox

Re: On 80 columns should (not) be enough for everyone

[Ulrik Mikaelsson]

FWIW: Here's my two cents; (Non-Phobos participant, so feel free to
click delete now)

I'm not sure whether text-books and program-code are really comparable
in this respect. When reading books I hardly put much attention to
each particular word, while in computer-code, each token is very
significant. The "flow" of reading is simply different. If it weren't,
we would hardly use hard line-breaks at all, just concatenate
statements like we concatenate sentences in text, and use  to format code. Especially, we would not use monospaced
fonts and care about "columns".

I would rather like to hear whether any mathematicians ever insert
hard-breaks into their equations just "to not get them too wide".

Personally, I've been a long time on the fence regarding strict
line-length, and my current position is:
 90 columns is the rule of thumb. 80 columns is often hard to fit
using readable names, but 90 columns generally works. When the code
exceeds 90 columns, I try to look for:
 * local variable names that can be shortened without breaking their
descriptiveness.
 * sub-expressions in the line, which can be reasonably be extracted
into separe pre-computed variable. (Which also increases readability
of the code by itself.)
 * unnecessary nested depth in the function, and try to either
refactor parts out to separate functions, or refactor the function to
be more pass-based rather then nested.

One special-case which often cause problems, is function-calls,
especially "method"-calls. Roughly lines like: (note 3-level leading
indent)
otherObj1.doSomethingSensible(otherObj2.internalVariable,
this.config, this.context);

At this point, I can see two obvious alternatives;
otherObj1.doSomethingSensible(otherObj2.internalVariable,
this.config,
  this.context);
vs.
otherObj1.doSomethingSensible(otherObj2.internalVariable,
  this.config,
  this.context);

Both have advantages and problems. In the first alternative, you might
miss the second argument if reading too fast, and in the second
alternative, the vertical space can be quickly wasted, especially if
the line get's just slightly too long due to many small arguments.
(I.E. debug-output of many short-named local variables.) In these
cases, I usually just leave it to overflow. That will
 * hint to the reader that it's still just one single function-call
 * arguments won't be missed
 * not waste unnecessary vertical space
 * it's up to the code-viewer to determine whether a line-wrap is
actually needed, which it might even indicate using a wrap-marker in
the margin (not possible with a manual line-break).

For other common long-line sources like enums, array literals etc, I
usually block-format and insert line-breaks as usual to not exceed 90
columns wide.

My guess is, if I worked enough with long mathematical expression, I
would use roughly the same guidelines.

/ Ulrik

(*doh* that was probably more than 2 cents worth.)

2011/1/30 Andrei Alexandrescu :
> On 01/30/2011 12:27 PM, Walter Bright wrote:
>>
>> Andrej Mitrovic wrote:
>>>
>>> 80 columns
>>> wasn't determined by some scientific method to be a good size for
>>> code, it's
>>> a product of limitations of the older generation hardware.
>>
>> 80 columns came from how many characters would fit on a standard size
>> 8.5*11 sheet of paper. Even punch cards followed this precedent.
>>
>> That paper size has stood the test of time as being a comfortable size
>> for reading. Reading longer lines is fatiguing, as when one's eyes
>> "carriage return" they tend to go awry.
>>
>> You can see this yourself if you resize and reflow a text web site to be
>> significantly wider than 80 columns. It gets harder to read.
>
> Also: pick a random book or newspaper and count the characters in a line.
> They range between 60 and 80, counting for about 10 words per line. This has
> been the case ever writing systems have been invented. It is a fallacy to
> assume that 80 has anything to do with the first monitors. In fact, it's the
> opposite - the monitors were conceived following a universal human constant.
>
> One funny thing is that at my employer (where each and every employee has a
> 30" 2560x1600 monitor) everything is under constant debate, starting with
> which email server and ending with choosing UserId versus UserID. Nobody and
> not once has debated the 80 column rule.
>
> Phobosians have voted with their fingers. Long lines in Phobos are rare and
> the result of lack of enforcement, not a stylistic choice. Jonathan simply
> didn't know about that, and has graciously agreed to align to that
> convention (thanks!).
>
>
> Andrei
>

Re: (Was: On 80 columns should (not) be enough for everyone)

[foobar]

Michel Fortin Wrote:

> On 2011-01-31 02:18:26 -0500, foobar  said:
> 
> > Phobos is a very good product that I for one will never use. Just 
> > looking at the one huge page for algorithms is enough to discourage 
> > many people.
> 
> But is Phobos the problem or is the one-page-per-module documentation 
> the problem?
> 
> -- 
> Michel Fortin
> michel.for...@michelf.com
> http://michelf.com/
> 

Phobos' organization is the problem. If you read the C++ standard you'll see 
that their description of the stdlib describes  as a library. Hence, 
c++'s design is a single file per library. Phobos does exactly the same mistake.

D has a far superior module system that doesn't require this moronic design. 
Please let's use it. 

I have a hard time believing that having a separate doc page per function is a 
better solution than to properly organize the code. 

Re: Decision on container design

[David Nadlinger]

On 1/31/11 6:48 PM, Simon Buerger wrote:

Well, seems not bad on a quick look. But source is updated 2 years ago,…


http://www.dsource.org/projects/dcollections/browser/branches/d2 – four 
months are not quite as long as two years. Oh, and Steve is the very 
author of dcollections. ;)


David

Re: On 80 columns should (not) be enough for everyone

[Andrei Alexandrescu]

On 1/31/11 11:54 AM, Ulrik Mikaelsson wrote:

FWIW: Here's my two cents; (Non-Phobos participant, so feel free to
click delete now)

I'm not sure whether text-books and program-code are really comparable
in this respect. When reading books I hardly put much attention to
each particular word, while in computer-code, each token is very
significant. The "flow" of reading is simply different. If it weren't,
we would hardly use hard line-breaks at all, just concatenate
statements like we concatenate sentences in text, and use  to format code. Especially, we would not use monospaced
fonts and care about "columns".


Well the fact of the matter is that style used in books is very 
influential. People do copy book samples into code and continue working 
in the same style from them. I've been asked for (and released) the 
source code of all snippets in TDPL.



I would rather like to hear whether any mathematicians ever insert
hard-breaks into their equations just "to not get them too wide".


I'm not sure I can qualify as a mathematician but my research is very 
math-heavy. In my thesis 
(http://erdani.com/research/dissertation_color.pdf) I frequently 
inserted line breaks even when not technically necessary, check e.g. eq. 
2.16 on page 12.



Personally, I've been a long time on the fence regarding strict
line-length, and my current position is:
  90 columns is the rule of thumb. 80 columns is often hard to fit
using readable names, but 90 columns generally works.


Seems reasonable. Since both Jonathan and Don prefer longer lines, I'm 
now more inclined to increase and/or soften the recommended limit for 
Phobos.



Andrei

Re: Decision on container design

[Steven Schveighoffer]

On Mon, 31 Jan 2011 12:48:06 -0500, Simon Buerger  wrote:


On 31.01.2011 17:53, Steven Schveighoffer wrote:

http://www.dsource.org/projects/dcollections

-Steve


Well, seems not bad on a quick look. But source is updated 2 years ago,  
so I doubt it would compile with current dmd. Anyway, the topic here is  
the std-behaviour of the std-lib. But sure, always nice to have custom  
alternatives.


latest meaningful change was 4 months ago:  
http://www.dsource.org/projects/dcollections/changeset/102


It should compile on the latest DMD (if not, file a ticket).  BTW, it  
changes very little mostly because I haven't had many complaints about it  
(maybe not a good sign?) and I haven't had much opportunity to use it, as  
my day job does not allow using D unfortunately.


It was proposed as a possibility for the std lib, but Andrei and I  
couldn't come to an agreement on what the collections should look like.   
Ironically, his latest decision moves std.container closer to dcollections  
in design.


However, it should be relatively compatible with phobos' container lib (in  
fact RedBlackTree is a direct port of dcollections' version).


-Steve

Re: Is D still alive?

[Ulrik Mikaelsson]

2011/1/28 retard :
> I've heard this before. I've also heard the 64-bit port and many other
> things are done in a year/month or two. The fact is, you're overly
> optimistic and these are all bullshit. When I come back here in a year or
> two, I have full justification to laugh at your stupid claims.
>
64-bit port for D (at least v1) IS available. I use LDC to build and
run on 64-bit, but I'm sure GDC will work as well.

The LDC-port for D2 may be untested though, and I do not know about
GDC, but personally, I think it's a mistake to recommend D2 "for new
projects". Given the importance of compilers, runtime and
base-libraries, and the kind of bug-reports I hear frustration around,
it seems D2 should still be considered beta, but for people who want
working development now, recommend D1. In all it's inferiority, it IS
more stable.

My guess is much frustration in the D community stems from slightly
pre-maturely trying to push D2, before neither D1 nor D2 was ready.
I've chosen to only work with D1/Tango from start, and I simply don't
recognize the frustration many are feeling. I'm only concerned over
that there ARE quite a few developers that seems to have been turned
off by instability, and the Phobos/Tango-problem.

Well, well. I'm generally a happy D-developer, and I only hope D3
won't be started until D2 is rock-stable, and fully utilized. :)

Re: (Was: On 80 columns should (not) be enough for everyone)

[Ulrik Mikaelsson]

90 as a rule of thumb with some exceptions.

Re: Is D not-for-profit or not?!

[Steven Schveighoffer]

On Sun, 30 Jan 2011 11:55:28 -0500, Andrei Alexandrescu  
 wrote:



Steve is in New York City.


If you mean me, I'm in the Boston area (not exactly in Boston), and I  
bring a thousand curses on you for suggesting I'm from NYC ;)   
Unfortunately, all of us must turn our envious eyes on Green Bay and  
Pittsburgh this week...


-Steve

Re: (Was: On 80 columns should (not) be enough for everyone)

[foobar]

Andrei Alexandrescu Wrote:

> On 01/31/2011 01:18 AM, foobar wrote:
> > Andrei Alexandrescu Wrote:
> >
> >> == Quote from Walter Bright (newshou...@digitalmars.com)'s article
> >>> foobar wrote:
>  ATM, Phobos ranks extremely poorly in this regard. Far worse than C++ 
>  which
>  is by far one of worst ever. both Java and C# are surprisingly high on 
>  this
>  list and are behind various "new-age" scripting languages such as python 
>  and
>  Ruby and languages that were designed to be readable by humans such as
>  Smalltalk.
> >>> I think you've mixed up libraries with languages. Please rephrase so we 
> >>> know
> >>> what you're referring to and give specifics.
> >>
> >> Seconded. Also there is this one presupposition that reflects poorly on 
> >> foobar's argument: that choosing foobar's
> >> preferred convention inherently makes the code more accessible. In fact, a 
> >> stronger argument could be made to
> >> the contrary as we're talking about a maximum and 80<  120.
> >>
> >> Andrei from the ER
> >
> > That's just incorrect since I didn't even specify my style convention.
> > As I said multiple times before, Phobos is design with Andrei in mind: 
> > meaning that if you are Andrei-like (or if you _are_ indeed Andrei) it 
> > would be easy to read and use. Otherwise it confusing as hell and hard to 
> > navigate.
> 
> But that goes for anyone, including your code. Code written in foobar's 
> style is designed with foobar in mind: meaning that if you are 
> foobar-like (or if you _are_ indeed foobar) it would be easy to read and 
> use. Otherwise it is confusing as hell and hard to navigate.
> 
> I can only assume you'd have a hard time writing code that does not have 
> foobar's signature. Same here.
> 
> Besides, it seems to have worked for me; at work I'm not considered one 
> of the more obfuscated coders. Also, I wrote a little library Loki which 
> is regarded as very small and readable for what it does. Its 
> functionality has been shadowed by the much larger and comprehensive 
> Boost, but Loki's code has always been the simplest and cleanest 
> although it implements rather advanced concepts. Do you have any 
> publicly available samples of your work that we might look at?
> 
> > In addition, you now want to force artificial limits that don't make
> > any sense.
> >
> > You completely miss the most important principle - it doesn't matter
> > how good and efficient your product is if no one's using it. Phobos
> > is a very good product that I for one will never use. Just looking at
> > the one huge page for algorithms is enough to discourage many
> > people.
> 
>  From what I've seen, everyone who advocates D2 mentions std.algorithm 
> as one of its main strengths, and never as a liability. I have 
> difficulty reconciling that signal with one opinion relayed anonymously.
> 
> 
> Andrei

Everything is relative. Loki is a c++ library and I'm sure it's one of the best 
c++ libs. This is relative to a horribly unfriendly language which is used by a 
certain type of people. 
I'm OTOH comparing to a different set of languages, their libs and their users. 

Also, I never said that Phobos is poor from an implementation point of view, on 
the contrary, I too think that especially the new phobos modules (Algorithms) 
and concepts (Range) are very good and efficient. 

My reoccurring complain is about _usability_ of this awesome code base. 
The code is poorly organized in few huge files, functions are poorly named, 
etc. 

I keep taking about the API while you keep talking about its implementation.
 D needs to cater for different kinds of people, not just American born C++ 
guru programmers, but a diverse community of programmers with different 
programming backgrounds (that includes web developers that only learned 
scripting languages), different nationalities (They don't need to have native 
level English capabilities including understanding of American culture and 
insider jokes), different OS users (not just *nix geeks), etc.

Re: Decision on container design

[Simon Buerger]

Okay, my fault. Didnt realize you were the author, and the project is 
still active. The "2 years" came from here: 
http://www.dsource.org/projects/dcollections/browser/trunk/dcollections. 
I thought, that "trunk" was the most recent version. Added a bookmark, 
and will definitely take a closer look later. Thx for mentioning.



On 31.01.2011 19:09, Steven Schveighoffer wrote:

On Mon, 31 Jan 2011 12:48:06 -0500, Simon Buerger  wrote:


On 31.01.2011 17:53, Steven Schveighoffer wrote:

http://www.dsource.org/projects/dcollections

-Steve


Well, seems not bad on a quick look. But source is updated 2 years
ago, so I doubt it would compile with current dmd. Anyway, the topic
here is the std-behaviour of the std-lib. But sure, always nice to
have custom alternatives.


latest meaningful change was 4 months ago:
http://www.dsource.org/projects/dcollections/changeset/102

It should compile on the latest DMD (if not, file a ticket). BTW, it
changes very little mostly because I haven't had many complaints about
it (maybe not a good sign?) and I haven't had much opportunity to use
it, as my day job does not allow using D unfortunately.

It was proposed as a possibility for the std lib, but Andrei and I
couldn't come to an agreement on what the collections should look
like. Ironically, his latest decision moves std.container closer to
dcollections in design.

However, it should be relatively compatible with phobos' container lib
(in fact RedBlackTree is a direct port of dcollections' version).

-Steve

Re: On 80 columns should (not) be enough for everyone

[bearophile]

Andrei:

> Seems reasonable. Since both Jonathan and Don prefer longer lines, I'm 
> now more inclined to increase and/or soften the recommended limit for 
> Phobos.

I think 110 columns are a little too many. I have suggested 90-95 chars max 
(but less than 80 on average) after seeing both the problems caused by too much 
short lines (to keep lines below 70-80 chars I have seen programmers use 2 
spaces to indent or use very short variable names. This is worse than 95 chars 
long lines), and seeing lines with 120+ chars that cause troubles to older 
programmer that can't use a too much small font because of their older eyes.

Bye,
bearophile

Re: d-programming-language.org

[Adam Ruppe]

Ary Manzana
> The only think I don't like is the background image. I mean, I like
> the background, it just doesn't have to be an image. Each time I go to
> another page it shows me a white page and then loads everything.

That's not the image's fault. The image is cached and background
loaded, so the main page never has to wait on it.

The problem is a meta refresh on some of the pages. Meta refresh is
evil evil evil and sucks massively. I wish nobody used it. It's
completely useless too. And it delays the page load, giving the
white we see here.

The right way to do that is with an http redirect, or just pointing
the links to the files themselves. (symlink them on the server
perhaps if you want both names to work, but I'd just change the
link targets in the side to pick one name or the other.)


Kill all meta refreshes with fire!

Partial template application

[bearophile]

Functional languages often have built-in partial function application:
http://en.wikipedia.org/wiki/Currying#Contrast_with_partial_function_application

D doesn't have this feature built-in despite it can't break C compatibility, 
maybe because it's a lot of work to implement, maybe because it is seen as 
bug-prone, or maybe just because Walter was/is not interested in it.

So in D you do it using std.functional.curry (I think this is a partial 
application more than a currying, so I am not sure this is the best name):

int fun(int a, int b) { return a + b; }
alias curry!(fun, 5) fun5;
assert(fun5(6) == 11);


Few hours ago in D.learn Simen Kjaeraas has shown a small D2 program that uses 
nested templates to allow template partial application:


import std.typecons, std.functional, std.array;

template optArg(alias pred) {
template optArg(alias fn) {
auto optArg(Range)(Range r) {
   alias binaryFun!pred predicate;
   alias unaryFun!fn func;

   auto result = tuple(r.front, func(r.front));
   foreach (e; r) {
  auto tmp = func(e);
  if (predicate(e, result[1]))
 result = tuple(e, tmp);
   }
   return result;
}
}
}
void main() {
alias optArg!"a < b" minArg;
alias minArg!"a" foo;
assert(foo([5, 2, 1, 3]) == tuple(1, 1));
}


I'd like a new template feature in D, automatic partial template application. 
It allows to simplify that code like this (untested):

import std.typecons, std.functional, std.array;

auto optArg(alias pred, alias fn, Range)(Range r) {
alias binaryFun!pred predicate;
alias unaryFun!fn func;

auto result = tuple(r.front, func(r.front));
foreach (e; r) {
auto tmp = func(e);
if (predicate(e, result[1]))
result = tuple(e, tmp);
}
}

void main() {
alias optArg!"a < b" minArg;
alias minArg!"a" foo;
assert(foo([5, 2, 1, 3]) == tuple(1, 1));
}


If (as usual) you don't want to implement this as a new D feature, I presume 
something like a PartialTemplate/StaticCurry/StaticPartialApplication is 
writeable in the standard library:

import std.typecons, std.functional, std.array;

auto optArg(alias pred, alias fn, Range)(Range r) {
alias binaryFun!pred predicate;
alias unaryFun!fn func;

auto result = tuple(r.front, func(r.front));
foreach (e; r) {
auto tmp = func(e);
if (predicate(e, result[1]))
result = tuple(e, tmp);
}
}

void main() {
alias PartialTemplate!(optArg, "a < b") minArg;
alias PartialTemplate!(minArg, "a") foo;
assert(foo([5, 2, 1, 3]) == tuple(1, 1));
}

Bye,
bearophile

Re: On 80 columns should (not) be enough for everyone

[Ulrik Mikaelsson]

2011/1/31 Andrei Alexandrescu :
> On 1/31/11 11:54 AM, Ulrik Mikaelsson wrote:
>> I'm not sure whether text-books and program-code are really comparable
>> in this respect. When reading books I hardly put much attention to
>> each particular word, while in computer-code, each token is very
>> significant. The "flow" of reading is simply different. If it weren't,
>> we would hardly use hard line-breaks at all, just concatenate
>> statements like we concatenate sentences in text, and use> processor>  to format code. Especially, we would not use monospaced
>> fonts and care about "columns".
>
> Well the fact of the matter is that style used in books is very influential.
> People do copy book samples into code and continue working in the same style
> from them. I've been asked for (and released) the source code of all
> snippets in TDPL.

Sorry, maybe I was unclear, I wasn't referring to code-snippets in a
book. I meant the kind of text-books I understood Walter refer to,
that made the basis for 80x25. Think fiction, not programming books. I
absolutely agree there are good UI-design reasons to limit
column-width in these. Commonly such text is also "text-align:
justify", and even broken up into multiple-column layouts to reduce
horizontal scan, but precisely those two things make me skeptical
about just HOW relevant it actually is for computer-code.

>> I would rather like to hear whether any mathematicians ever insert
>> hard-breaks into their equations just "to not get them too wide".
>
> I'm not sure I can qualify as a mathematician but my research is very
> math-heavy. In my thesis (http://erdani.com/research/dissertation_color.pdf)
> I frequently inserted line breaks even when not technically necessary, check
> e.g. eq. 2.16 on page 12.

Thank you, interesting for the topic (although I didn't understand a
thing of the actual math :). I note however that given the very terse
variable-names (as is common in math), the lines don't actually grow
very long. However, where you HAVE chosen to insert line-breaks, is at
equality-operators which I would say is roughly a statement in
programming-language terms. ("A = B" is a statement, while "A+B" is
not.)

Interestingly enough, this is roughly the rule-of thumb I use. Try
hard to keep statements below 90 characters, but don't resort to
manual line-breaks if it's not possible.

>> Personally, I've been a long time on the fence regarding strict
>> line-length, and my current position is:
>>  90 columns is the rule of thumb. 80 columns is often hard to fit
>> using readable names, but 90 columns generally works.
>
> Seems reasonable. Since both Jonathan and Don prefer longer lines, I'm now
> more inclined to increase and/or soften the recommended limit for Phobos.
Actually, writing and reading about it got me thinking. I think the
real value of the 80/90/120/whatever-rule is not really the actual
line-length itself. If that was the case, editors with
auto-indentation could quite easily have additional rules for
automatic code-wraps. The actual value of having the rule is to alert
the coder that something _might_ be sub-optimally expressed. Perhaps D
should have something similar to pylint? Sure, much of the need for
pylint goes away in a statically typed language, but it's also quite
good in diagnosing design by code-complexity measurements. OTOH things
like symbols-per-file, arguments-per-function,
operations-per-function, etc. could be good indicators to quickly spot
hairy code. One could also check for naming-conventions and probably
other cleanliness-aspects as well.

Re: d-programming-language.org

[Steven Schveighoffer]

On Sun, 30 Jan 2011 03:03:08 -0500, Andrei Alexandrescu  
 wrote:


I've had some style updates from David Gileadi rotting in a zip file in  
my inbox for a good while. It took me the better part of today to  
manually merge his stale files with the ones in the repository, which  
have in the meantime undergone many changes.


BTW, in perusing the site, I noticed the language reference does not  
contain a navigation menu.  I can only get to the lexical page, not any  
other pages of the language reference.


-Steve

Re: review for unittests

[Steven Schveighoffer]

On Sun, 30 Jan 2011 17:54:20 -0500, Nick Sabalausky  wrote:


"bearophile"  wrote in message
news:ii3nsc$kob$1...@digitalmars.com...

Andrei:


Yes, once you go beyond 80 columns.


I suggest to relax that limit a little, I think 90-95 columns are
acceptable still. Too much short lines have their disadvantages too. If
your screen allows only 80 columns, I suggest you to buy one larger one
that allows up to 90.



Or just increase your resolution ;)


Wait, is this really Nick Sabalausky suggesting you should be able to  
handle something that has advanced in technology in the last 20 years? ;)


-Steve

Re: (Was: On 80 columns should (not) be enough for everyone)

[foobar]

Walter Bright Wrote:

> foobar wrote:
> > Java (the language itself) is mediocre at best but the Java standard
> > libraries are excellent with comprehensive usable documentation to boot.
> > 
> > Phobes is half a notch above c++ stdlib which is the worst ever from a
> > usability and readability perspective. Are we still using G-d files? really?
> 
> Please take a module or function in the phobos documentation, and rewrite it 
> to 
> how you think it should be done and post it, as an example of how to do it 
> right. We welcome such help.

My complaint is not about the implementation itself as it is about it's API. 
Java is an excellent example of many very usable APIs, meaning that it very 
easy to both read Java code and understand what the functions do and write code 
that's just as readable *without* RTFM. 

When I learned C++ in university, my notoriously demanding professor said that 
code should be self documenting and that comments are meant to compensate for 
poorly written code. 

Re: Partial template application

[Simen kjaeraas]

bearophile  wrote:

If (as usual) you don't want to implement this as a new D feature, I  
presume something like a  
PartialTemplate/StaticCurry/StaticPartialApplication is writeable in the  
standard library:


import std.typecons, std.functional, std.array;

auto optArg(alias pred, alias fn, Range)(Range r) {
alias binaryFun!pred predicate;
alias unaryFun!fn func;

auto result = tuple(r.front, func(r.front));
foreach (e; r) {
auto tmp = func(e);
if (predicate(e, result[1]))
result = tuple(e, tmp);
}
}

void main() {
alias PartialTemplate!(optArg, "a < b") minArg;
alias PartialTemplate!(minArg, "a") foo;
assert(foo([5, 2, 1, 3]) == tuple(1, 1));
}


dranges has something like this:
http://svn.dsource.org/projects/dranges/trunk/dranges/docs/templates.html
see CurryTemplate

--
Simen

Re: Is D still alive?

[Trass3r]

I've chosen to only work with D1/Tango from start, and I simply don't
recognize the frustration many are feeling. I'm only concerned over
that there ARE quite a few developers that seems to have been turned
off by instability, and the Phobos/Tango-problem.


Well, if nobody acted as a guinea pig, no issues would be uncovered ;)
And though I already encountered several blocker bugs myself I got the  
feeling that the situation has become way better.
Of course if, for some reason, you absolutely need x64 or have a hard  
deadline for your project then D1 is probably the better way to go.

Re: (Was: On 80 columns should (not) be enough for everyone)

[Steven Schveighoffer]

On Sun, 30 Jan 2011 14:47:26 -0500, Walter Bright  
 wrote:



Tomek Sowiński wrote:
What is your preferred *maximum* length for a line of D code? (please  
reply with a number only)


6.022e+23


It's amazing that D does so much, and to top it off, it's only ONE LINE OF  
CODE!


-Steve

Re: d-programming-language.org

[David Gileadi]

On 1/31/11 11:50 AM, Steven Schveighoffer wrote:

BTW, in perusing the site, I noticed the language reference does not
contain a navigation menu. I can only get to the lexical page, not any
other pages of the language reference.


Andrei e-mailed me about this.  It's due to some Ddoc macros that got 
lost on some pages, including the lexical page.  I'll take a look at 
fixing it soon; right now I'm a bit swamped.

Re: Partial template application

[Andrej Mitrovic]

Isn't it possible to unify functions which work on compile-time and
run-time arguments?

What I mean is, if curry detects that you're currying a compile-time
argument against a template, then it should do what your
PartialTemplate/StaticCurry would do.

It seems odd having to create 'static' counterparts to functions in
Phobos. So far I only know of staticIndexOf and staticMap. But adding
more would seem like duplicating the effort and creating a sort of
std.staticAlgorithm

Re: (Was: On 80 columns should (not) be enough for everyone)

[Steven Schveighoffer]

On Sun, 30 Jan 2011 13:55:53 -0500, Tomek Sowiński  wrote:


Andrej Mitrovic napisał:

If you really want to set up a column limit that *everyone* has to  
abide to, then make a poll to see what everyone can agree on.


Actually that's a splendid idea. Let's take it easy. Regardless of that  
silly beef I'm really curious what distribution will emerge.


What is your preferred *maximum* length for a line of D code? (please  
reply with a number only)


80

-Steve

Re: On 80 columns should (not) be enough for everyone

[Russel Winder]

On Mon, 2011-01-31 at 13:41 -0500, bearophile wrote:
[ . . . ]
> I think 110 columns are a little too many. I have suggested 90-95
> chars max (but less than 80 on average) after seeing both the problems
> caused by too much short lines (to keep lines below 70-80 chars I have
> seen programmers use 2 spaces to indent or use very short variable
> names. This is worse than 95 chars long lines), and seeing lines with
> 120+ chars that cause troubles to older programmer that can't use a
> too much small font because of their older eyes.

What say we cut the agist crap.

Just because anyone over 50 (like me) has worsening eyesight doesn't
mean they can't work quite happily with 110 character lines using 8pt
fonts.  I like 110 character lines in smaller fonts, and I like 2 space
indents.  And proportional fonts -- Ocean Sans MT rules -- why all this
monospace font obsession (*).

At the end of the day source code consistency is the only really
important thing.  Anyone amending a file or adding a file to a codebase
must do it in the style of the current code so as to avoid spoiling
consistency, and creating specious changes in version control.  Just
because I object to a coding style doesn't mean I can't use it if I am
amending someone else code.

Whoever is the project leader for a project defines a style and then
everyone works with it -- even if that style is some crappy 80 column
stupidity ;-)


(*)  Flame wars should be directed to /dev/null -- or if you insist on
using Windows, whatever the equivalent is. :-)
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: (Was: On 80 columns should (not) be enough for everyone)

[Steven Schveighoffer]

On Mon, 31 Jan 2011 12:09:01 -0500, Andrei Alexandrescu  
 wrote:



On 01/31/2011 01:18 AM, foobar wrote:



You completely miss the most important principle - it doesn't matter
how good and efficient your product is if no one's using it. Phobos
is a very good product that I for one will never use. Just looking at
the one huge page for algorithms is enough to discourage many
people.


 From what I've seen, everyone who advocates D2 mentions std.algorithm  
as one of its main strengths, and never as a liability. I have  
difficulty reconciling that signal with one opinion relayed anonymously.


I think the main problem is with ddoc.  This, from std.algorithm is a  
f**king mess IMO:


Jump to: BoyerMooreFinder EditOp Group NWayUnion OpenRight SetDifference  
SetIntersection SetSymmetricDifference SetUnion SortOutput Splitter  
SwapStrategy Uniq Until balancedParens boyerMooreFinder bringToFront  
canFind completeSort copy count endsWith equal fill filter find  
findAdjacent findAmong group indexOf initializeAll insert isPartitioned  
isSorted largestPartialIntersection largestPartialIntersectionWeighted  
levenshteinDistance levenshteinDistanceAndPath makeIndex map max min  
minCount minPos mismatch move moveAll moveSome nWayUnion no none  
partialSort partition reduce remove reverse schwartzSort semistable  
setDifference setIntersection setSymmetricDifference setUnion skipOver  
sort splitter stable startsWith substitute swap swapRanges topN topNCopy  
uninitializedFill uniq unstable until yes


(in voice of comic-book guy) Worst navigation bar ever.

-Steve

Re: d-programming-language.org

[Andrei Alexandrescu]

On 1/31/11 12:50 PM, Steven Schveighoffer wrote:

On Sun, 30 Jan 2011 03:03:08 -0500, Andrei Alexandrescu
 wrote:


I've had some style updates from David Gileadi rotting in a zip file
in my inbox for a good while. It took me the better part of today to
manually merge his stale files with the ones in the repository, which
have in the meantime undergone many changes.


BTW, in perusing the site, I noticed the language reference does not
contain a navigation menu. I can only get to the lexical page, not any
other pages of the language reference.

-Steve


Thanks, David and me are looking into that.

Andrei

Re: (Was: On 80 columns should (not) be enough for everyone)

[Andrei Alexandrescu]

On 1/31/11 1:07 PM, Steven Schveighoffer wrote:

On Mon, 31 Jan 2011 12:09:01 -0500, Andrei Alexandrescu
 wrote:


On 01/31/2011 01:18 AM, foobar wrote:



You completely miss the most important principle - it doesn't matter
how good and efficient your product is if no one's using it. Phobos
is a very good product that I for one will never use. Just looking at
the one huge page for algorithms is enough to discourage many
people.


From what I've seen, everyone who advocates D2 mentions std.algorithm
as one of its main strengths, and never as a liability. I have
difficulty reconciling that signal with one opinion relayed anonymously.


I think the main problem is with ddoc. This, from std.algorithm is a
f**king mess IMO:

Jump to: BoyerMooreFinder EditOp Group NWayUnion OpenRight SetDifference
SetIntersection SetSymmetricDifference SetUnion SortOutput Splitter
SwapStrategy Uniq Until balancedParens boyerMooreFinder bringToFront
canFind completeSort copy count endsWith equal fill filter find
findAdjacent findAmong group indexOf initializeAll insert isPartitioned
isSorted largestPartialIntersection largestPartialIntersectionWeighted
levenshteinDistance levenshteinDistanceAndPath makeIndex map max min
minCount minPos mismatch move moveAll moveSome nWayUnion no none
partialSort partition reduce remove reverse schwartzSort semistable
setDifference setIntersection setSymmetricDifference setUnion skipOver
sort splitter stable startsWith substitute swap swapRanges topN topNCopy
uninitializedFill uniq unstable until yes

(in voice of comic-book guy) Worst navigation bar ever.

-Steve


Let's fix it! I'm thinking along the lines of finding some broad groups, 
e.g.


Searching

find until mismatch startsWith ...

Sorting

sort partialSort partition ...

Set operations

setUnion setDifference ...

...?

We'd eliminate the unstructured "jump to" section and we create the 
grouping by hand (sigh).



Andrei

Re: "scope" and "delete" are being removed, but not type-safe variadic templates?

[spir]

On 01/31/2011 11:10 AM, %u wrote:

Hi,

I just realized something: If the delete keyword is being removed because it's
dangerous, and if the scope storage class is being removed because of the same
dangling reference problem, how come

 int[] global_var;
 void foo(int[] args...) { global_var = args; }

isn't considered to be just as dangerous, and therefore also being removed?
(Or perhaps this is a bug, and we should always add the scope modifier so that
it prevents reference escaping?)

Thanks! :)


IIRC, I had a bug because of this, precisely (except for obj.member instead of 
global_var).


Denis
--
_
vita es estrany
spir.wikidot.com

Re: (Was: On 80 columns should (not) be enough for everyone)

[Adam Ruppe]

Steven Schveighoffer wrote:
> I think the main problem is with ddoc.  This, from std.algorithm is a
> f**king mess IMO:

Note that that is generated through some short javascript in the
html header.

I remember writing a brief change to that to make it look a lot
better (organized into a simple grid) but it seems to be lost now.

I'd be willing to redo it though. Need to make a github account
to get commit power back, but if there's agreement on changes, I'll
make them.

Re: std.unittests [updated] for review

[spir]

On 01/30/2011 01:13 PM, Jens Mueller wrote:

I do not like putting it in std.exception. Maybe the name std.unittest
is also not good. I would propose std.assert if assert wasn't a keyword.
[...]

 I would_not_  expect helpers for writing

assertions (Assert_Error_) in a module named std.exception.


Same for me. Find it strange. Would never search assertion helper funcs inside 
std.exception. Why not std.assertion? std.unittests would be fine if there were 
some more stuff in there, I mean not only assertions. Else, the obvious name 
imo is std.assertion.


Denis
--
_
vita es estrany
spir.wikidot.com

Re: std.unittests [updated] for review

[spir]

On 01/30/2011 02:13 PM, Jens Mueller wrote:

The only argument against putting in its own module is it's size. That
seems to be your main point. I think putting something in new module
should mainly be concerned with separating stuff logically. Later on it
should be easy to add a new module that imports std.exception and let's
say std.assertion.
But all you say is valid. I just fear that fixing names later will be
costly. Having two modules allows us to handle this better. Just because
std.exception is already kind of messy doesn't justify putting in
there.


I feel the same.

Denis
--
_
vita es estrany
spir.wikidot.com

Re: (Was: On 80 columns should (not) be enough for everyone)

[Walter Bright]

foobar wrote:

Walter Bright Wrote:


foobar wrote:
Java (the language itself) is mediocre at best but the Java standard 
libraries are excellent with comprehensive usable documentation to boot.


Phobes is half a notch above c++ stdlib which is the worst ever from a 
usability and readability perspective. Are we still using G-d files?

really?

Please take a module or function in the phobos documentation, and rewrite
it to how you think it should be done and post it, as an example of how to
do it right. We welcome such help.


My complaint is not about the implementation itself as it is about it's API.
 Java is an excellent example of many very usable APIs, meaning that it very
easy to both read Java code and understand what the functions do and write
code that's just as readable *without* RTFM.



Please take a Phobos module or a function, and rewrite its API to demonstrate 
your point.

Re: (Was: On 80 columns should (not) be enough for everyone)

[Adam Ruppe]

Andrei Alexandrescu wrote:
> We'd eliminate the unstructured "jump to" section and we create the
> grouping by hand (sigh).

Maybe we can get the best of both worlds: how about a "Group:" or
"Tags:" section in the ddoc that a program could automatically
pull out to make the listing?

I think we can do that without modifying the compiler. Scanning
the text in javascript or whatever for that section would be simple
enough.

Re: Is D still alive?

[Steven Schveighoffer]

On Mon, 31 Jan 2011 12:26:56 -0500, Simen kjaeraas  
 wrote:



Steven Schveighoffer  wrote:

On Fri, 28 Jan 2011 20:16:54 -0500, Walter Bright  
 wrote:



Steven Schveighoffer wrote:

I can't buy "enterprise" support,


Of course you can!


No really, I can't afford it ;)

But seriously, I find it hard to believe that you can buy enterprise  
support for D if it means that you do the work.  There's only one you.   
So at some point, you might be spread too thin between adding new  
features, posting to this newsgroup, and supporting all enterprise  
customers.


Even if that is the case, Walter is free to hire others to do the
enterprise work for him.


Again, there's only one Walter.  Throwing warm bodies at a problem doesn't  
always solve it ;)


I for one would have a hard time being a full-time enterprise support  
developer for compiler software.


That being said, he does work at a compiler company, so I suppose he  
probably has better access to compiler-savvy folks...


-Steve

Re: Is D still alive?

[Jesse Phillips]

Trass3r Wrote:

> > I've chosen to only work with D1/Tango from start, and I simply don't
> > recognize the frustration many are feeling. I'm only concerned over
> > that there ARE quite a few developers that seems to have been turned
> > off by instability, and the Phobos/Tango-problem.
> 
> Well, if nobody acted as a guinea pig, no issues would be uncovered ;)
> And though I already encountered several blocker bugs myself I got the  
> feeling that the situation has become way better.
> Of course if, for some reason, you absolutely need x64 or have a hard  
> deadline for your project then D1 is probably the better way to go.

Andrei put for the question once of, "How many issues would users run across if 
they stuck to those features that are also available in v1.0?"

I think the answer would be more then sticking with a D1 compiler, but not 
nearly the number people do hit, which is also diminishing rapidly.

I do not think there is an issue with using D2 in a new project, but if you 
have to ask you probably should go with D1. I say this because someone who is 
aware of the issues present in the language is able to decide if their desired 
project would be hindered by the bug. There are definitely some projects, with 
constraints which would not make D a very good choice.

For example D would make a great language on an embedded device, but currently 
the first one to take it on will have a massive overhead to make it work.

Re: Decision on container design

[Steven Schveighoffer]

On Mon, 31 Jan 2011 13:36:57 -0500, Simon Buerger  wrote:

Okay, my fault. Didnt realize you were the author, and the project is  
still active. The "2 years" came from here:  
http://www.dsource.org/projects/dcollections/browser/trunk/dcollections.  
I thought, that "trunk" was the most recent version. Added a bookmark,  
and will definitely take a closer look later. Thx for mentioning.


Sorry about that, I have had at least 3 people be confused at why trunk  
wasn't the D2 version.  I really need to swap those (make the 1.x version  
the branch).  Unfortunately, it will screw up the D1 documentation, since  
it's auto-generated.  But that should probably be moot since the D1  
version isn't changing...


-Steve

Re: (Was: On 80 columns should (not) be enough for everyone)

[Jonathan M Davis]

On Monday, January 31, 2011 11:13:40 Andrei Alexandrescu wrote:
> On 1/31/11 1:07 PM, Steven Schveighoffer wrote:
> > On Mon, 31 Jan 2011 12:09:01 -0500, Andrei Alexandrescu
> > 
> >  wrote:
> >> On 01/31/2011 01:18 AM, foobar wrote:
> >>> You completely miss the most important principle - it doesn't matter
> >>> how good and efficient your product is if no one's using it. Phobos
> >>> is a very good product that I for one will never use. Just looking at
> >>> the one huge page for algorithms is enough to discourage many
> >>> people.
> >> 
> >> From what I've seen, everyone who advocates D2 mentions std.algorithm
> >> as one of its main strengths, and never as a liability. I have
> >> difficulty reconciling that signal with one opinion relayed anonymously.
> > 
> > I think the main problem is with ddoc. This, from std.algorithm is a
> > f**king mess IMO:
> > 
> > Jump to: BoyerMooreFinder EditOp Group NWayUnion OpenRight SetDifference
> > SetIntersection SetSymmetricDifference SetUnion SortOutput Splitter
> > SwapStrategy Uniq Until balancedParens boyerMooreFinder bringToFront
> > canFind completeSort copy count endsWith equal fill filter find
> > findAdjacent findAmong group indexOf initializeAll insert isPartitioned
> > isSorted largestPartialIntersection largestPartialIntersectionWeighted
> > levenshteinDistance levenshteinDistanceAndPath makeIndex map max min
> > minCount minPos mismatch move moveAll moveSome nWayUnion no none
> > partialSort partition reduce remove reverse schwartzSort semistable
> > setDifference setIntersection setSymmetricDifference setUnion skipOver
> > sort splitter stable startsWith substitute swap swapRanges topN topNCopy
> > uninitializedFill uniq unstable until yes
> > 
> > (in voice of comic-book guy) Worst navigation bar ever.
> > 
> > -Steve
> 
> Let's fix it! I'm thinking along the lines of finding some broad groups,
> e.g.
> 
> Searching
> 
> find until mismatch startsWith ...
> 
> Sorting
> 
> sort partialSort partition ...
> 
> Set operations
> 
> setUnion setDifference ...
> 
> ...?
> 
> We'd eliminate the unstructured "jump to" section and we create the
> grouping by hand (sigh).

At minimum, it needs to be smarter about user-defined types. The functions for 
a 
class or struct should not be grouped with free functions. They should be 
grouped with the type that they're in. _That_, at least, should be automatable, 
but it wouldn't help any with std.algorithm, since it's full of free functions 
(though it would be a big improvement for std.datetime). Unfortunately, you 
can't really automate the sorting based on usage. Best case, you could create 
tags on functions that said which grouping they went in, and perhaps that would 
be well worth doing, but you still have to worry about tagging them. So, on 
some 
level, the grouping is going to have to be done by hand.

- Jonathan M Davis

Re: On 80 columns should (not) be enough for everyone

[JMRyan]

Walter Bright  wrote in
news:ii4an2$1npj$1...@digitalmars.com: 

> 80 columns came from how many characters would fit on a standard size
> 8.5*11 sheet of paper. Even punch cards followed this precedent.

This suggests (without exactly stating) one of my personal reasons for a
strict line length limit:  sometimes programmers like to print their
code.   Maybe I'm showing my age, but I find dead trees best for code
review.  One *can* use a smaller font (hard on the eyes) or print in
landscape (yuck--and even that is not enough for some code).

PS.  I knew about the punch card precident and have even used key punch
machines myself, but I didn't know that punch card length was based on
earlier precident.  Given the absurd length of line printer output of
the day, that surprises me.

Max length of a LOC: poll results (Was: On 80 columns...)

[Tomek Sowiński]

Tomek Sowiński napisał:

> Actually that's a splendid idea. Let's take it easy. Regardless of that silly 
> beef I'm really curious what distribution will emerge.
> 
> What is your preferred *maximum* length for a line of D code? (please reply 
> with a number only)
 
Alright, I'm wrapping up this toy study. Two things before the numbers come:

 - A few respondents gave 2 numbers, one "reasonable", the other "if I really 
have to". I took the latter (larger) number as I was after maximum length, 
something usable as a setting for a repository hook.
 - 2 respondents said "no limit". I excluded them from computations, albeit 
it's a valid answer. 1 respondent answered "1 mole" which I also excluded as a 
22-order-of-magnitude outlier.

> lengths = c(80, 80, 110, 120, 80, 80, 100, 100, 120, 110, 90)
> summary(lengths)
   Min. 1st Qu.  MedianMean 3rd Qu.Max. 
  80.00   80.00  100.00   97.27  110.00  120.00 
>
> sd(lengths)  # standard deviation
[1] 16.18080
>
> quantile(lengths, c(.1, .25, .5, .75, .9))
10% 25% 50% 75% 90% 
 80  80 100 110 120 
>
> library(moments)
> skewness(lengths)  # take with a grain of salt, little data
[1] 0.1645005
>
> length(lengths) # count
[1] 11

-- 
Tomek

Re: Audio time-compression (Was: On 80 columns should (not) be enough for everyone)

[Walter Bright]

Ulrik Mikaelsson wrote:

2011/1/30 Walter Bright :

People who use screen readers often crank up the playback rate to 2x. The
software adjusts the pitch so it doesn't sound like the Chipmunks.

I've often wondered why DVRs don't do this (I've sent the suggestion to
Tivo, they ignored me). I'd like the option to play the news (or other talk
shows) at a faster rate, with pitch adjustment. I've found I can watch Tivo
at 3x with the closed captioning on, and can almost keep up. The problem
with DVRs at any fast forward speed is they turn the sound off! G.

A golden opportunity missed.

I'd also love it if youtube etc. did this. It's so boring looking at youtube
presentations because they talk so slow. I'd love a double speed youtube
viewing option.

Remember I posted this in case some troll tries to patent it.

I KNEW I wasn't alone at this. My S.O. usually just rolls her eyes
when I do this. (Tip: VLC does it for at least double-speed)

I think the reason I.E. YouTube and Tivo don't do it is that AFAIU, it
is fairly CPU-consuming (FFT back and forth?) In the TiVo-case, my
guess is nobody paid for the hardware, and in the YouTube-case I doubt
neither Flash nor JavaScript will enable the performance required.
Perhaps it can be done browser-dependently with HTML5.


I think the problem is it either never occurred to Tivo or Youtube, or they 
don't care about it. When I shut off my Tivo service, I told them that such a 
feature would entice me to keep it. But I seriously doubt they transmitted my 
idea to the right people.




Now, what we need is the audio-equivalent of this:
http://www.youtube.com/watch?v=6NcIJXTlugc


That is an impressive algorithm!

Re: "scope" and "delete" are being removed, but not type-safe variadic templates?

[Steven Schveighoffer]

On Mon, 31 Jan 2011 14:15:18 -0500, spir  wrote:


On 01/31/2011 11:10 AM, %u wrote:

Hi,

I just realized something: If the delete keyword is being removed  
because it's
dangerous, and if the scope storage class is being removed because of  
the same

dangling reference problem, how come

 int[] global_var;
 void foo(int[] args...) { global_var = args; }

isn't considered to be just as dangerous, and therefore also being  
removed?
(Or perhaps this is a bug, and we should always add the scope modifier  
so that

it prevents reference escaping?)

Thanks! :)


IIRC, I had a bug because of this, precisely (except for obj.member  
instead of global_var).


Yes, I remember that one.

I would say we can't really get rid of it or change the way it works (it's  
just way too awesome to remove).  All we could possibly do ATM is make it  
un-@safe.


Same goes for referencing a stack-allocated fixed-size array:

void foo(int[] args) { global_var = args;}

void bar()
{
int[5] blah;
foo2(blah[]);
}

-Steve

Re: (Was: On 80 columns should (not) be enough for everyone)

[Steven Schveighoffer]

On Mon, 31 Jan 2011 14:17:50 -0500, Adam Ruppe   
wrote:



Steven Schveighoffer wrote:

I think the main problem is with ddoc.  This, from std.algorithm is a
f**king mess IMO:


Note that that is generated through some short javascript in the
html header.

I remember writing a brief change to that to make it look a lot
better (organized into a simple grid) but it seems to be lost now.

I'd be willing to redo it though. Need to make a github account
to get commit power back, but if there's agreement on changes, I'll
make them.


I'm all for it (voice with no authority).

I typically ignore that Jump To bar and use the browser's find.

I really think ddoc needs to be revamped to do more in this area, along  
with cross-linking.  I really like dil's output (see tangos' docs).


-Steve

Re: (Was: On 80 columns should (not) be enough for everyone)

[Andrei Alexandrescu]

On 1/31/11 1:22 PM, Adam Ruppe wrote:

Andrei Alexandrescu wrote:

We'd eliminate the unstructured "jump to" section and we create the
grouping by hand (sigh).


Maybe we can get the best of both worlds: how about a "Group:" or
"Tags:" section in the ddoc that a program could automatically
pull out to make the listing?

I think we can do that without modifying the compiler. Scanning
the text in javascript or whatever for that section would be simple
enough.


Great idea!

Andrei

Re: (Was: On 80 columns should (not) be enough for everyone)

[Michel Fortin]

On 2011-01-31 14:13:40 -0500, Andrei Alexandrescu 
 said:



Let's fix it! I'm thinking along the lines of finding some broad groups, e.g.

Searching

find until mismatch startsWith ...

Sorting

sort partialSort partition ...

Set operations

setUnion setDifference ...

...?

We'd eliminate the unstructured "jump to" section and we create the 
grouping by hand (sigh).


Please do. Grouping by task is very useful when you're searching for a 
particular function.


That said, it'd help if Ddoc could help too... For documenting 
Objective-C files I have made my own documentation generator (written 
in D!) which gives you this kind of output:



For generating the above page, all I have to do in my header file is to 
specify which documentation group each function belongs to and the rest 
is done automatically. Here's the corresponding header file; notice I 
only have to write a @group directive when the group changes, not for 
each function:





--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Is D still alive?

[Ulrik Mikaelsson]

2011/1/31 Jesse Phillips :
> I do not think there is an issue with using D2 in a new project, but if you 
> have to ask you probably should go with D1. I say this because someone who is 
> aware of the issues present in the language is able to decide if their 
> desired project would be hindered by the bug.
I completely agree with this, but that important "if" is not conveyed
by the recommendation "D version 2 which is recommended for new
projects." :) I think it's not as much a problem of actual problems,
as a problem of wrong expectations.

Anyhow, D1 is a great language. D2 looks to be an ever better language
and from what I hear rapidly stabilizing. The only reason I brought
this up (after days of questioning if it's even worth mentioning), is
hoping to avoid the same problems when D3 arrives.

Re: (Was: On 80 columns should (not) be enough for everyone)

[so]

Java is an excellent example of many very usable APIs, meaning that it  
very easy to both read Java code and understand what the functions do  
and write code that's just as readable *without* RTFM.


This one i don't understand. (seems i fail to understand many things  
nowadays!).
I have read the C++ standard library manuals many times, but still i find  
myself going back and reading it again occasionally.

Probably like my memory, STL also doesn't have the best of qualities.
But i have to ask, why would you target those that don't RTFM? It seems to  
me every language mainly targeting this kind of audience.

Re: Max length of a LOC: poll results (Was: On 80 columns...)

[Tomek Sowiński]

Tomek Sowiński napisał:

> Alright, I'm wrapping up this toy study. Two things before the numbers come:
> 
>  - A few respondents gave 2 numbers, one "reasonable", the other "if I really 
> have to". I took the latter (larger) number as I was after maximum length, 
> something usable as a setting for a repository hook.
>  - 2 respondents said "no limit". I excluded them from computations, albeit 
> it's a valid answer. 1 respondent answered "1 mole" which I also excluded as 
> a 22-order-of-magnitude outlier.

Steven came in late with his datapoint, so once again:

> lengths = c(80, 80, 110, 120, 80, 80, 100, 100, 120, 110, 90, 80)
> 
> summary(lengths)
   Min. 1st Qu.  MedianMean 3rd Qu.Max. 
  80.00   80.00   95.00   95.83  110.00  120.00 
> 
> sd(lengths)  # standard deviation
[1] 16.21354
> 
> quantile(lengths, c(.1, .25, .5, .75, .9))
10% 25% 50% 75% 90% 
 80  80  95 110 119 
> 
> skewness(lengths)  # take with a grain of salt, little data
[1] 0.3121957
> 
> length(lengths) # count
[1] 12

-- 
Tomek

Re: Audio time-compression (Was: On 80 columns should (not) be enough for everyone)

[Ulrik Mikaelsson]

2011/1/31 Walter Bright :
>> I think the reason I.E. YouTube and Tivo don't do it is that AFAIU, it
>> is fairly CPU-consuming (FFT back and forth?) In the TiVo-case, my
>> guess is nobody paid for the hardware, and in the YouTube-case I doubt
>> neither Flash nor JavaScript will enable the performance required.
>> Perhaps it can be done browser-dependently with HTML5.
>
> I think the problem is it either never occurred to Tivo or Youtube, or they
> don't care about it. When I shut off my Tivo service, I told them that such
> a feature would entice me to keep it. But I seriously doubt they transmitted
> my idea to the right people.

Perhaps, although I develop for STB:s at work, and I know how
amazingly price-pressed the hardware is. Seriously, it's designed to
show live HD, but the developers manual for one manufacturer, there's
a performance-warning about animated GIF:s (not kidding).

My guess is, the only FFT the box can manage is the one hard-coded in
the video-chip, which can't easily be exploited for other means.

Of course, I don't know what HW the Tivo is using, perhaps they're just lazy. :)

Re: Is D still alive?

[retard]

Mon, 31 Jan 2011 11:43:37 -0500, Steven Schveighoffer wrote:

> On Fri, 28 Jan 2011 20:16:54 -0500, Walter Bright
>  wrote:
> 
>> Steven Schveighoffer wrote:
>>> I can't buy "enterprise" support,
>>
>> Of course you can!
> 
> No really, I can't afford it ;)
> 
> But seriously, I find it hard to believe that you can buy enterprise
> support for D if it means that you do the work.  There's only one you. 
> So at some point, you might be spread too thin between adding new
> features, posting to this newsgroup, and supporting all enterprise
> customers.
> 
> Any estimate you can give on how many such customers you have?

The fact that the final specification and design rationale of D is 
undocumented and in Walter's head means that no other person can sell 
that kind of deep enterprise support because it's not clear how the 
language should work. The rest of us can only guess. It also means that 
the more Walter spends time on enterprise support, the less he has time 
to work on D. The best for D might be to not buy any support at all. All 
the conferences and events are just distracting D's development.

I think the same applies to Phobos 2.. only Andrei knows the design well 
enough and knows how it's going to change in the future. No matter how 
much time one spends studying D or the ecosystem or how D is used in the 
enterprise world, one simply can't obtain any reasonable level of 
knowledge to become a "certified" authority in this community.

About the enterprise support... I haven't seen any material from Walter 
targeting professional D developers, only advertisements for people who 
have never used D. Maybe the hardcore stuff isn't publicly available.

The commercial language consultancy support I've seen is that consultants 
with 20+ years of enterprise "C++ experience" teach young developers with 
only ~1-5 years of enterprise experience with the platform. Typically 
even the fresh juniors have some experience with the platform (via 
university training) and the in-house seniors with 3+ years of experience 
help them to get more familiar with the platform used in the company. 
It's also very rare to only focus on the language, usually the frameworks 
and toolchain are the major culprits. YMMV of course and the world is 
full of all kinds of bullshit consultancy.

Re: Is D still alive?

[Jonathan M Davis]

On Monday, January 31, 2011 11:31:29 Jesse Phillips wrote:
> Trass3r Wrote:
> > > I've chosen to only work with D1/Tango from start, and I simply don't
> > > recognize the frustration many are feeling. I'm only concerned over
> > > that there ARE quite a few developers that seems to have been turned
> > > off by instability, and the Phobos/Tango-problem.
> > 
> > Well, if nobody acted as a guinea pig, no issues would be uncovered ;)
> > And though I already encountered several blocker bugs myself I got the
> > feeling that the situation has become way better.
> > Of course if, for some reason, you absolutely need x64 or have a hard
> > deadline for your project then D1 is probably the better way to go.
> 
> Andrei put for the question once of, "How many issues would users run
> across if they stuck to those features that are also available in v1.0?"
> 
> I think the answer would be more then sticking with a D1 compiler, but not
> nearly the number people do hit, which is also diminishing rapidly.
> 
> I do not think there is an issue with using D2 in a new project, but if you
> have to ask you probably should go with D1. I say this because someone who
> is aware of the issues present in the language is able to decide if their
> desired project would be hindered by the bug. There are definitely some
> projects, with constraints which would not make D a very good choice.
> 
> For example D would make a great language on an embedded device, but
> currently the first one to take it on will have a massive overhead to make
> it work.

Personally, I find that it's issues such as not being able to link C or C++ 
code 
compiled by Microsoft's compiler with code compiled by dmd which would stop be 
me from being able to use D in projects at work. The stability of the compiler 
is an issue, but the linker issue totally kills it before the stability issue 
would even come up. Pretty much everything I work on at work has to run on both 
Linux and Windows (and soon Mac OS X), and we use Microsoft's compiler here, so 
D could would _have_ to be able to link with code compiled by Microsoft's 
compiler. The issue of D1 or D2 is completely irrelevant.

Now, if you could use a compiler other than dmd (maybe gdc would work - I don't 
know), then maybe then it would become a possibility, and then you have the 
question of D1 or D2, but if the linking issue isn't solved one way or another, 
then it doesn't matter.

I'm sure that the situation is not as grim at all companies, but it definitely 
is 
where I work.

- Jonathan M Davis

Re: On 80 columns should (not) be enough for everyone

[spir]

On 01/30/2011 07:27 PM, Walter Bright wrote:

Andrej Mitrovic wrote:

80 columns
wasn't determined by some scientific method to be a good size for code, it's
a product of limitations of the older generation hardware.


80 columns came from how many characters would fit on a standard size 8.5*11
sheet of paper. Even punch cards followed this precedent.

That paper size has stood the test of time as being a comfortable size for
reading. Reading longer lines is fatiguing, as when one's eyes "carriage
return" they tend to go awry.

You can see this yourself if you resize and reflow a text web site to be
significantly wider than 80 columns. It gets harder to read.


Code is no newspaper article. And newspaper articles are rarely multi-indented.

Denis
--
_
vita es estrany
spir.wikidot.com

Re: On 80 columns should (not) be enough for everyone

[bearophile]

Russel Winder:

> What say we cut the agist crap.

There are also armies of programmers with myopia :-)

Bye,
bearophile

Re: Max length of a LOC: poll results (Was: On 80 columns...)

[Walter Bright]

Tomek Sowiński wrote:

1 respondent answered "1 mole" which I also excluded as a 22-order-of-magnitude
outlier.


What kind of a jerk is that respondent?

Re: On 80 columns should (not) be enough for everyone

[Walter Bright]

JMRyan wrote:

Walter Bright  wrote in
news:ii4an2$1npj$1...@digitalmars.com: 


80 columns came from how many characters would fit on a standard size
8.5*11 sheet of paper. Even punch cards followed this precedent.


This suggests (without exactly stating) one of my personal reasons for a
strict line length limit:  sometimes programmers like to print their
code.   Maybe I'm showing my age, but I find dead trees best for code
review.  One *can* use a smaller font (hard on the eyes) or print in
landscape (yuck--and even that is not enough for some code).

PS.  I knew about the punch card precident and have even used key punch
machines myself, but I didn't know that punch card length was based on
earlier precident.  Given the absurd length of line printer output of
the day, that surprises me.


Looking it up shows that the history is a bit more complicated than I said:

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

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

Re: On 80 columns should (not) be enough for everyone

[spir]

On 01/31/2011 06:54 PM, Ulrik Mikaelsson wrote:

I share most of Ulrik mentions.


I'm not sure whether text-books and program-code are really comparable
in this respect.


Even if they were (which is imo absurd to state), what would count is not 
column number, but content length -- which is different in the case of code due 
to indentation. Thus, to get 80-char max line length, we'd have to allow up to, 
say, column #100 ;-)


Denis
--
_
vita es estrany
spir.wikidot.com

Re: (Was: On 80 columns should (not) be enough for everyone)

[spir]

On 01/30/2011 07:55 PM, Tomek Sowiński wrote:

Andrej Mitrovic napisał:


If you really want to set up a column limit that *everyone* has to abide to, 
then make a poll to see what everyone can agree on.


Actually that's a splendid idea. Let's take it easy. Regardless of that silly 
beef I'm really curious what distribution will emerge.

What is your preferred *maximum* length for a line of D code? (please reply 
with a number only)


99

Denis
--
_
vita es estrany
spir.wikidot.com

Re: (Was: On 80 columns should (not) be enough for everyone)

[spir]

On 01/30/2011 10:18 PM, foobar wrote:

Right, so does that mean it should be made_less_  readable by a diverse 
community of people?
I have no issue with any style Andrei or others use when they code for 
themselves, be it 10 characters per row or 1000.
I do place a MUCH higher weight on making the stdlib readable and accessible 
for a large range of diverse people with different cultures, languages, 
traditions, eye-sight, screen sizes, and preferred beer flavors.


There is only one true beer flavor.


ATM, Phobos ranks extremely poorly in this regard.


Sure. How can we ensure Phobos contributors drink Pilsner Urquell? 
http://en.wikipedia.org/wiki/Pilsner_Urquell


Denis
--
_
vita es estrany
spir.wikidot.com

Re: Partial template application

[bearophile]

Andrej Mitrovic:

> What I mean is, if curry detects that you're currying a compile-time
> argument against a template, then it should do what your
> PartialTemplate/StaticCurry would do.

This is currently not possible, a static curry needs compile-time arguments, so 
they need to specified as template arguments (with the bang !), while the 
normal curry is supposed to work with run-time values too.

Walter has tried to unify the two, using a syntax like:
void foo(int x, static int y, int z) {}
That's equivalent to:
void foo(int y)(int x, int z) {}

But the legend says he has found unspecified implementation difficulties, so 
the idea was abandoned. One purpose of D design is to avoid excessive compiler 
complexity.

---

Simen kjaeraas:

> dranges has something like this:
> http://svn.dsource.org/projects/dranges/trunk/dranges/docs/templates.html
> see CurryTemplate

Thank you for the link. This looks like a true currying, instead of a partial 
application like std.functional.curry.
I suggest to add CurryTemplate to Phobos2 while we wait forever for templates 
to be curried on default :-)

Bye,
bearophile

Re: Is D still alive?

[retard]

Mon, 31 Jan 2011 11:53:34 -0800, Jonathan M Davis wrote:

> On Monday, January 31, 2011 11:31:29 Jesse Phillips wrote:
>> Trass3r Wrote:
>> > > I've chosen to only work with D1/Tango from start, and I simply
>> > > don't recognize the frustration many are feeling. I'm only
>> > > concerned over that there ARE quite a few developers that seems to
>> > > have been turned off by instability, and the Phobos/Tango-problem.
>> > 
>> > Well, if nobody acted as a guinea pig, no issues would be uncovered
>> > ;) And though I already encountered several blocker bugs myself I got
>> > the feeling that the situation has become way better. Of course if,
>> > for some reason, you absolutely need x64 or have a hard deadline for
>> > your project then D1 is probably the better way to go.
>> 
>> Andrei put for the question once of, "How many issues would users run
>> across if they stuck to those features that are also available in
>> v1.0?"
>> 
>> I think the answer would be more then sticking with a D1 compiler, but
>> not nearly the number people do hit, which is also diminishing rapidly.
>> 
>> I do not think there is an issue with using D2 in a new project, but if
>> you have to ask you probably should go with D1. I say this because
>> someone who is aware of the issues present in the language is able to
>> decide if their desired project would be hindered by the bug. There are
>> definitely some projects, with constraints which would not make D a
>> very good choice.
>> 
>> For example D would make a great language on an embedded device, but
>> currently the first one to take it on will have a massive overhead to
>> make it work.
> 
> Personally, I find that it's issues such as not being able to link C or
> C++ code compiled by Microsoft's compiler with code compiled by dmd
> which would stop be me from being able to use D in projects at work. The
> stability of the compiler is an issue, but the linker issue totally
> kills it before the stability issue would even come up. Pretty much
> everything I work on at work has to run on both Linux and Windows (and
> soon Mac OS X), and we use Microsoft's compiler here, so D could would
> _have_ to be able to link with code compiled by Microsoft's compiler.
> The issue of D1 or D2 is completely irrelevant.

I don't do Windows development, but not being able to use popular third 
party development tools because of object file format issues sounds like 
a huge problem. I did a quick look at the digitalmars site. The 
limitation is only mentioned once in the FAQ section. A competent 
programmer might also discover that by reading the optlink page.

Also no mention of the quality of D2 toolchain. "1.030 stable", "1.066 
latest", and mysterious "2.051". I would assume it's stable. But like 
Ulrik said "the kind of bug-reports I hear frustration around, it seems 
D2 should still be considered beta"

Re: (Was: On 80 columns should (not) be enough for everyone)

[spir]

On 01/31/2011 07:38 PM, foobar wrote:

I keep taking about the API while you keep talking about its implementation.
  D needs to cater for different kinds of people, not just American born C++ 
guru programmers, but a diverse community of programmers with different 
programming backgrounds (that includes web developers that only learned 
scripting languages), different nationalities (They don't need to have native 
level English capabilities including understanding of American culture and 
insider jokes), different OS users (not just *nix geeks), etc.


+++

(insider jokes are excluding jokes)

(I'm unsure about tolerating Heineken drinkers, though)

Denis
--
_
vita es estrany
spir.wikidot.com

Re: (Was: On 80 columns should (not) be enough for everyone)

[spir]

On 01/30/2011 09:32 PM, "Jérôme M. Berger" wrote:

foobar wrote:

Tomek Sowiński Wrote:


Andrej Mitrovic napisał:


If you really want to set up a column limit that *everyone* has to abide to, 
then make a poll to see what everyone can agree on.

Actually that's a splendid idea. Let's take it easy. Regardless of that silly 
beef I'm really curious what distribution will emerge.

What is your preferred *maximum* length for a line of D code? (please reply 
with a number only)

--
Tomek



I think that putting an artificial limit is incredibly stupid. Haven't anyone here 
learned the "No magic numbers" rule?!?!

Walter correctly pointed out that it's harder to read long rows, however, 
unlike printed text and ancient terminals, current display technology is much 
more dynamic.
Font size, zoom level, screen form-factor, window size, resolution, etc means 
that each person can configure his own individual optimal view.

As the OP said, use word wrap and adjust your editor window width/font 
size/zoom level/etc to your liking.
If your editor does not support this "new" feature, go get a new editor and 
don't bother other people with different preferences.
Stop forcing this moronic "one size fits all" attitude on everyone.


Do you know of any editor that can word wrap *while respecting
indentation*? Any editor I know will wrap to the first column, which
renders indentation pointless in the presence of long lines...

Jerome


Yop, geany :-) http://en.wikipedia.org/wiki/Geany

Denis
--
_
vita es estrany
spir.wikidot.com

Re: (Was: On 80 columns should (not) be enough for everyone)

[foobar]

Andrei Alexandrescu Wrote:

> On 1/31/11 1:07 PM, Steven Schveighoffer wrote:
> > On Mon, 31 Jan 2011 12:09:01 -0500, Andrei Alexandrescu
> >  wrote:
> >
> >> On 01/31/2011 01:18 AM, foobar wrote:
> >
> >>> You completely miss the most important principle - it doesn't matter
> >>> how good and efficient your product is if no one's using it. Phobos
> >>> is a very good product that I for one will never use. Just looking at
> >>> the one huge page for algorithms is enough to discourage many
> >>> people.
> >>
> >> From what I've seen, everyone who advocates D2 mentions std.algorithm
> >> as one of its main strengths, and never as a liability. I have
> >> difficulty reconciling that signal with one opinion relayed anonymously.
> >
> > I think the main problem is with ddoc. This, from std.algorithm is a
> > f**king mess IMO:
> >
> > Jump to: BoyerMooreFinder EditOp Group NWayUnion OpenRight SetDifference
> > SetIntersection SetSymmetricDifference SetUnion SortOutput Splitter
> > SwapStrategy Uniq Until balancedParens boyerMooreFinder bringToFront
> > canFind completeSort copy count endsWith equal fill filter find
> > findAdjacent findAmong group indexOf initializeAll insert isPartitioned
> > isSorted largestPartialIntersection largestPartialIntersectionWeighted
> > levenshteinDistance levenshteinDistanceAndPath makeIndex map max min
> > minCount minPos mismatch move moveAll moveSome nWayUnion no none
> > partialSort partition reduce remove reverse schwartzSort semistable
> > setDifference setIntersection setSymmetricDifference setUnion skipOver
> > sort splitter stable startsWith substitute swap swapRanges topN topNCopy
> > uninitializedFill uniq unstable until yes
> >
> > (in voice of comic-book guy) Worst navigation bar ever.
> >
> > -Steve
> 
> Let's fix it! I'm thinking along the lines of finding some broad groups, 
> e.g.
> 
> Searching
> 
> find until mismatch startsWith ...
> 
> Sorting
> 
> sort partialSort partition ...
> 
> Set operations
> 
> setUnion setDifference ...
> 
> ...?

Excellent!

> 
> We'd eliminate the unstructured "jump to" section and we create the 
> grouping by hand (sigh).
> 

You just got my hopes up in the previous paragraph. :(

How about converting algorithm.d into a package and make those "groups" modules 
in this package? 
I'm sure this can be done with the help of some aliases for backwards 
compatibility

> 
> Andrei

Re: (Was: On 80 columns should (not) be enough for everyone)

[Adam Ruppe]

Steven Schveighoffer wrote:
> I'm all for it (voice with no authority).

Here it is with the brief css change to put it in a grid:

http://arsdnet.net/d-web-site/std_algorithm.html

It's a very small change that, to me, makes a huge difference.

> I really think ddoc needs to be revamped to do more in this area,
> along with cross-linking.

Agreed. Though, if we can't change the compiler, we could do this
with a macro too.

Use ($func std.file.read) to read a file.

And the $func macro can simply link it to the right place, or to
something like my own dpldocs.info/std.file.read to redirect/search
for the referenced item.

Say... I wonder... there's already a class "d_psymbol" in the
html, I could do this in the script too, or maybe with a simple
tweak to the existing macro.

I did it in script on that same link. I'm not in love with it,
but it proves the concept is easy enough with what we already
have.

Re: (Was: On 80 columns should (not) be enough for everyone)

[Adam Ruppe]

> Say... I wonder... there's already a class "d_psymbol" in the

No, I'm wrong. That's only the currently referenced symbol. No
point linking back to itself!

Gotta go back to the drawing board for good cross referencing.

Re: Partial template application

[Andrej Mitrovic]

On 1/31/11, bearophile  wrote:
> Walter has tried to unify the two, using a syntax like:
> void foo(int x, static int y, int z) {}
> That's equivalent to:
> void foo(int y)(int x, int z) {}
>
> But the legend says he has found unspecified implementation difficulties, so
> the idea was abandoned. One purpose of D design is to avoid excessive
> compiler complexity.
>

Well I do think there should be a difference between compile time and
runtime arguments, so I'd keep the current syntax rather than mix the
two. Perhaps D3 could have a form of static expressions:

import std.typecons, std.functional, std.array;
auto optArg(alias pred, alias fn, Range)(Range r) {
// same as before
}

void main() {
   alias static optArg!"a < b" minArg;
   alias static minArg!"a" foo;
   assert(foo([5, 2, 1, 3]) == tuple(1, 1));
}

and then we could have:

import std.stdio, std.typetuple, std.algorithm, std.traits, std.range;
void main()
{
int[] arr1 = [ 1, 2, 3, 4 ];
int[] arr2 = [ 5, 6 ];
auto squares = map!("a * a")(chain(arr1, arr2));

//~ alias staticMap!(Unqual, int, const int, immutable int) T;
alias static map!(Unqual, int, const int, immutable int) T;
}

I'm not sure how that would work, I'm just throwing ideas in the air. :)

Re: Is D still alive?

[Andrei Alexandrescu]

On 1/31/11 1:52 PM, retard wrote:

I think the same applies to Phobos 2.. only Andrei knows the design well
enough and knows how it's going to change in the future. No matter how
much time one spends studying D or the ecosystem or how D is used in the
enterprise world, one simply can't obtain any reasonable level of
knowledge to become a "certified" authority in this community.


People on the Phobos roster all have contributed to it, not to mention 
the many contributed patches via bugzilla and ideas aired in this group. 
Also, I have a track record of bringing ideas for future Phobos 
additions for discussion up here before acting on them. In the words of 
collection companies: "What else can we do?"


I think I'll do something terrible: I'll killfile r...@tard.com.invalid. 
This is a rare occurrence - my current filter has only four entries that 
probably are not valid anymore. I have always saluted your visible 
efforts at being civil, and I have appreciation for them; obviously you 
are quite unhappy about the state of the language, and given that it's 
difficult to not let emotions take the driver's seat. At the same time, 
however, all too often there's this schadenfreude in your posts that 
reduces the credibility and the value of the actual content 
considerably. Between hunting for bits of content and trying to 
distinguish whether they are genuine or the reverse engineering of a 
presupposition - the toll on my time is too high. Feel free to email me 
or to change your ID if you want to share something. Thanks.



Andrei

Re: On 80 columns should (not) be enough for everyone

[spir]

On 01/30/2011 10:29 PM, Nick Sabalausky wrote:

void main()
{
 void foo()
 {
while(true)
if(done)
{
}
 }
}

I'm a big fan of "stacking" flow-control statements like that whenever the
outer statements don't have anything else in their body.

Like this (stupid example):

// Draw funny design (and yes, this could be optimized better)
if(shouldRefresh)
foreach(int x; 0..width)
foreach(int y; 0..height)
if(x ^ y<  width*height / 2)
 buffer[x + y*width] = palette[(x+y) % $];

Instead of something more like:

// Draw funny design (and yes, this could be optimized better)
if(shouldRefresh)
{
 foreach(int x; 0..width)
 {
 foreach(int y; 0..height)
 {
 if(x ^ y<  width*height / 2)
 buffer[x + y*width] = palette[(x+y) % $];
 }
 }
}



Nice idea :-) Really makes sense, imo.

Denis
--
_
vita es estrany
spir.wikidot.com