date:20110202


On 2/2/11 11:06 PM, Jeff Nowakowski wrote:

On 02/02/2011 10:59 AM, Andrei Alexandrescu wrote:


(Absolute) font size does not belong to the page designer, instead to
the user. Just press dedicated key binding (often ctrl-), or whatever
command to set it appropriately.


I'm not sure about that. Facebook's site is professionally designed and
I think they use fixed font sizes all over the place.


There are tons of "professionally designed" big name sites all over the
web that use fixed-font sizes that either look terribly small or
terribly large, comparatively. Don't you experience this yourself?

The whole idea is just wrong. People browse the web in all kinds of
default font sizes, screen resolutions, and preferred browser width.
Your web page should flow naturally to whatever the user has.


Someone mentioned in this thread that leaving all font sizes to default 
causes the text to be too small.


The rhetoric is convincing but I'm afraid it can't be properly 
translated into reality.



Andrei

Re: new documentation format for std.algorithm

2011-02-02 Thread David Nadlinger


On 2/3/11 6:06 AM, Jeff Nowakowski wrote:

The whole idea is just wrong. People browse the web in all kinds of
default font sizes, […]


Yet I'd guess that 99% of all people on the web have never touched their 
browsers default font size/style controls…


David

Re: Uniform call syntax for implicit this.

On Wednesday 02 February 2011 20:48:15 %u wrote:
> When implemented, will uniform call syntax work for the "this"
> object even if not specified?
> 
> For example, will foo() get called in the following example?
> 
> void foo(A a, int b) {}
> 
> class A {
> void test() {
> this.foo(10);
> foo(10);
> }
> }

I would think so, since I don't think that the this pointer/reference is 
treated 
in any special way. The only special thing about it as far as I know is that 
it's filled in for you in cases where you use member variables or call member 
functions without it. However, as UFCS has yet to be implemented, I'm not sure 
that we can be quite sure of how it's going to work. There are going to be a 
number of related features - such as alias this, opDispatch, and cases where 
there's a member function and a free function with the same name - which are 
going to have to be able to interact unambiguously, and I don't think that all 
of that has been entirely sorted out yet.

- Jonathan M Davis

Re: new documentation format for std.algorithm

2011-02-02 Thread Walter Bright


Jérôme M. Berger wrote:

Andrei Alexandrescu wrote:

I'm not sure about that. Facebook's site is professionally designed and
I think they use fixed font sizes all over the place.


"Professionally designed" does not mean that they did the job right!


Apple's SDK documentation on their web site is literally painful for me to read. 
The light grey on white coupled with small font is awful. For a company focussed 
on design, I don't understand this.

Re: new documentation format for std.algorithm

2011-02-02 Thread Jeff Nowakowski


On 02/02/2011 10:59 AM, Andrei Alexandrescu wrote:


(Absolute) font size does not belong to the page designer, instead to
the user. Just press dedicated key binding (often ctrl-), or whatever
command to set it appropriately.


I'm not sure about that. Facebook's site is professionally designed and
I think they use fixed font sizes all over the place.


There are tons of "professionally designed" big name sites all over the 
web that use fixed-font sizes that either look terribly small or 
terribly large, comparatively. Don't you experience this yourself?


The whole idea is just wrong. People browse the web in all kinds of 
default font sizes, screen resolutions, and preferred browser width. 
Your web page should flow naturally to whatever the user has.

Re: Calling method by name.

2011-02-02 Thread Robert Jacques


On Wed, 02 Feb 2011 12:55:37 -0500, %u  wrote:


I know is possible to create an object from its name. It's possible to
call a method from that object if the name is only known at runtime?

Would something like the following be possible?

string classname, methodname;
// Ask the user for class and method.
auto obj = Object.factory(classname);
invoke(methodname, obj, param1, param2);

Thanks


I've been working on an update to std.variant, which includes a  
compile-time reflection to runtime-reflection system. (See  
https://jshare.johnshopkins.edu/rjacque2/public_html/) From the docs:


Manually registers a class with Variant's runtime-reflection system. Note  
that Variant automatically registers any types it is exposed. Note how in  
the example below, only Student is manually registered; Grade is  
automatically registered by Variant via compile-time reflection of Student.


module example;
class Grade   { real  mark;  }
class Student { Grade grade; }
void main(string[] args) {
Variant.__register!Student;
Variant grade = Object.factory("example.Grade");
grade.mark(96.6);
assert(grade.mark == 96.6);
}

And dynamic method/field calls are handled via the __reflect(string name,  
Variant[]  args...) method like so:


grade.__reflect("mark",Variant(96.6));
assert(grade.__reflect("mark") == 96.6);

Uniform call syntax for implicit this.

2011-02-02 Thread %u

When implemented, will uniform call syntax work for the "this"
object even if not specified?

For example, will foo() get called in the following example?

void foo(A a, int b) {}

class A {
void test() {
this.foo(10);
foo(10);
}
}


Thanks

Re: new documentation format for std.algorithm

2011-02-02 Thread Adam D. Ruppe

spir wrote:
> Is there an easy way to avoid duplicates in cheat sheet (2 readln, 3 writeln)?

Yes, easily, done now. http://arsdnet.net/d-web-site/std_stdio.html

> * The pointer to readln points ~ 3 lines below readln's doc's headline.

Fixed via hackish. The real cause here is ddoc for some reason
outputs the  anchors all over the place, almost at random,
and with repeated names... it's partially useful, but could be
a lot more.

My program runs through all of them, removing the ones that look
useless and renaming the others, so direct links work correctly,
even to things like enums with repeated names.

(for example:
http://arsdnet.net/d-web-site/std_stdio.html#File.readln
vs
http://arsdnet.net/d-web-site/std_stdio.html#readln

works there. But on the real site:

http://d-programming-language.org/phobos/std_stdio.html#readln

It just goes to the first reference of the name, which, in this
case, is wrong - it goes to the struct member instead of the
global that was asked for.)

The ideal situation is probably to fix up the ddoc macros so it
outputs the right thing in the first place. Maybe I'll find the
cause when I look at std.ddoc later in the week.

Re: Wrong link in Const FAQ

You're probably looking for this:
http://www.drdobbs.com/blog/archives/2008/03/invariant_strin.html;jsessionid=W4D43VWK24ALLQE1GHPSKH4ATMY32JVN?print=true

Unfortunately Dr Dobb's admins decided it'd be a good idea to just
kill all the links in existence. There's plenty of dead links pointing
to that website.

Here's a list of some other Walter's posts:
http://www.drdobbs.com/blog/bioPages/author/WalterBright/index.jhtml;jsessionid=W4D43VWK24ALLQE1GHPSKH4ATMY32JVN

Re: Should we have an Unimplemented Attribute?

Yeah, I had a hunch it would be overkill. Well that's why I'm asking,
not proposing. :p

Re: new documentation format for std.algorithm

On Wednesday, February 02, 2011 18:27:34 spir wrote:
> On 02/03/2011 02:24 AM, Jonathan M Davis wrote:
> > The hyphenating looks horrible and is hard to
> > read. I see no reason to make the category column worry about space so
> > much. I would expect the functions column to be able to handle the width
> > adjustment for various screen sizes.
> > 
> > Screenshot:http://is.gd/J51l9r
> 
> Nothing like that by me; screenshot:
> http://spir.wdfiles.com/local--files/variety/Screenshot-1.png
> 
> Actually, all looks rather nice now, imo, with latest settings.
> The second table (in firefox, light on dark colors):
> http://spir.wdfiles.com/local--files/variety/Screenshot-2.png

Evidently, Gecko handles the hyphenated stuff better than KHTML or Webkit.

- Jonathan M Davis

Re: new documentation format for std.algorithm


On 02/03/2011 03:20 AM, Adam Ruppe wrote:

I downloaded your new style to my site too and ran the automatic
table generator over std.stdio so we can see how it looks with
some different content.

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

I actually like that quite a bit! I don't have the hyphenation
script, so that won't work, but the rest is there.


I think such evolutation becoming standard for stdlib doc is a big gain. Just 
this cheat sheet table with a few words on /purpose/ of each feature helps much 
in (re)discovering a module.


Two notes:
* Is there an easy way to avoid duplicates in cheat sheet (2 readln, 3 writeln)?
* The pointer to readln points ~ 3 lines below readln's doc's headline.

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

Re: Should slice[]=slice be disallowed?

2011-02-02 Thread Ali Çehreli


bearophile wrote:

Ali Çehreli:

(This must have been discussed before, but I couldn't come up with a way 
to search in the archives.)


I have some unfinished ideas here, please add your comments :-)
http://d.puremagic.com/issues/show_bug.cgi?id=3971

Bye,
bearophile


Thanks bearophile! I was thinking about you when I was typing my message. ;)

Ali

Re: new documentation format for std.algorithm


On 02/03/2011 02:24 AM, Jonathan M Davis wrote:

The hyphenating looks horrible and is hard to
read. I see no reason to make the category column worry about space so much. I
would expect the functions column to be able to handle the width adjustment for
various screen sizes.

Screenshot:http://is.gd/J51l9r


Nothing like that by me; screenshot:
http://spir.wdfiles.com/local--files/variety/Screenshot-1.png

Actually, all looks rather nice now, imo, with latest settings.
The second table (in firefox, light on dark colors):
http://spir.wdfiles.com/local--files/variety/Screenshot-2.png

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

Re: Should we have an Unimplemented Attribute?

On Wednesday, February 02, 2011 17:48:05 Simen kjaeraas wrote:
> Jonathan M Davis  wrote:
> > On Wednesday, February 02, 2011 16:16:00 Andrej Mitrovic wrote:
> >> On 2/3/11, Jonathan M Davis  wrote:
> >> > Usually the thing to do would be to either comment them out or put an
> >> > assert(0)
> >> 
> >> Can't do that with classes and struct.
> > 
> > ??? You can comment out classes and structs just fine. You can also
> > comment out
> > member functions of classes and structs just fine. You can put assert(0)
> > in
> > member functions of classes and structs just fine. In this case, it
> > sounds like a
> > particular member function should have been commented out but wasn't.
> > 
> > - Jonathan M Davis
> 
> I think he means that any use of an @unimplemented class should give a
> warning/error/other message.

Well ,that makes some sense, but a struct or class is pretty useless without 
its 
methods, so it would quickly become obvious that it wasn't fully implemented 
when you used it if the methods had assert(0) in their bodies (especially if a 
propery message went with it). However, code that isn't ready yet really should 
just be commented. I think that it's happened in the past that stuff in Phobos 
or 
druntime has been left in there unfinished but undocumented on the theory that 
because it was undocumented, it wasn't an issue. And I don't think that that's 
necessarily a good practice. The fact that auto functions haven't showed up the 
docs causing people to look through the source hasn't helped any either.

Really, code that isn't ready yet should be commented out unless there's a 
really good reason to leave it in there unfinished, in which case it should 
almost certainly be using assert(0) so that it blows up when you try and use it.

- Jonathan M Davis

Re: new documentation format for std.algorithm

Andrei wrote:
> I made one more pass and made the following changes:

I downloaded your new style to my site too and ran the automatic
table generator over std.stdio so we can see how it looks with
some different content.

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

I actually like that quite a bit! I don't have the hyphenation
script, so that won't work, but the rest is there.


As a side note, I want to do a huge battery of changes to
std.ddoc so it puts out nicer semantic html. I'll try it on my
private copy first. If all goes well, it won't change the appearance
at all and will let my helper programs (and others like them, if
any exist) do a much better job.

The current ddoc macros used there really undersell its
capabilities IMO.

Re: new documentation format for std.algorithm

On Wednesday, February 02, 2011 17:37:27 Andrei Alexandrescu wrote:
> On 2/2/11 7:24 PM, Jonathan M Davis wrote:
> > On Wednesday, February 02, 2011 11:12:07 Andrei Alexandrescu wrote:
> >> On 2/2/11 2:45 AM, Andrei Alexandrescu wrote:
> >>> Following ideas and advice from this newsgroup, I have a draft at
> >>> 
> >>> http://d-programming-language.org/cutting-edge/phobos/std_algorithm.htm
> >>> l
> >>> 
> >>> There are two tables, one with just the names and the other with names
> >>> and a brief description. Let me know of any feedback. Thanks!
> >>> 
> >>> 
> >>> Andrei
> >> 
> >> I made one more pass and made the following changes:
> >> 
> >> * Added thin horizontal rules (you might have seen this already)
> >> 
> >> * Added "Comparison" category
> >> 
> >> * Reduced columns to two in the cheat sheet table and used leading rows
> >> for distinguishing categories
> >> 
> >> * Added hyphenation, which should make justice to the justified style
> >> (watch it at work in a narrow window!)
> >> 
> >> Let me know how it looks!
> > 
> > Aside from the category column, it looks great. However, the hyphenated
> > category column looks horrible. The only one that manages to put its
> > whole name on one line is Sorting. All of the others get split up onto 2
> > or 3 lines and become almost illegible. There's _tons_ of room for the
> > Functions column in comparison. Unless you really think that there are
> > going to be screens that are so small that they can't even fit all of
> > the function names in there by listing them in a single line vertically
> > (i.e. so small that there isn't enough space to horizontally place the
> > longest function name), I would strongly suggest having the category
> > column take up one line for each name rather than trying to hyphenate
> > it. At most, split up Set Operations onto two lines, with Set on one
> > line and Operations on the second. The hyphenating looks horrible and is
> > hard to read. I see no reason to make the category column worry about
> > space so much. I would expect the functions column to be able to handle
> > the width adjustment for various screen sizes.
> > 
> > Screenshot: http://is.gd/J51l9r
> > 
> > - Jonathan M Davis
> 
> Wow, Konqueror has a pretty bad layout engine wrt soft hyphenation.
> Hyphenating has a high penalty and should only occur when otherwise
> things would be really ugly.
> 
> I'll setup the table such that the first column is not hyphenated.

Chrome looks pretty much the same (though for some reason it shows almost none 
of the hyphens). Of course, they are cousins, since Konqueror uses KHTML and 
Chrome uses Webkit, which was forked from KHTML. Regardless, even if Konqueror 
were considered unimportant (which, fortunately, was not your reaction), the 
fact that Chrome has the problem would make it so that it was still something 
that needed to be addressed (since Chrome certainly doesn't have a small user 
base).

- Jonathan M Davis

Re: Should we have an Unimplemented Attribute?

2011-02-02 Thread Simen kjaeraas

Jonathan M Davis  wrote:

On Wednesday, February 02, 2011 16:16:00 Andrej Mitrovic wrote:

On 2/3/11, Jonathan M Davis  wrote:
> Usually the thing to do would be to either comment them out or put an
> assert(0)

Can't do that with classes and struct.

??? You can comment out classes and structs just fine. You can also  
comment out
member functions of classes and structs just fine. You can put assert(0)  
in
member functions of classes and structs just fine. In this case, it  
sounds like a

particular member function should have been commented out but wasn't.

- Jonathan M Davis

I think he means that any use of an @unimplemented class should give a
warning/error/other message.

--
Simen

Re: D vs Go on reddit


On 02/02/2011 10:37 PM, bearophile wrote:

If a person looks at the history of computer languages, she sees thousands of 
languages. Many of them were lot of work to be created, and most of them have 
failed, over and over again. This has happened even to languages better than 
many other languages present at their time, and when you see this you get sad.


Like in any other domain in our civilisation, the (hum) "success" (in social 
sense: fame, power, money) of a programming language has exactly nothing to do 
with its quality.
Actually, I rather think the opposite: that deep reasons allowing the creation 
of a Good Thing play against its social success (could hardly explain this 
clearly); and conversely. I would for instance blindly bet 1000€ (or $, or £) 
that in, say, 18 months, Go will have reached a higher level of success D will 
ever reach. Nothing to do with quality.
I also bet Go not only will never be a good language, compared to other modern 
ones in the same field, but will quickly become a big mess, and worse and 
worse; while loads of people will sing for its fame (and more and more of them, 
more and more loudly).


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

Re: new documentation format for std.algorithm


On 2/2/11 7:24 PM, Jonathan M Davis wrote:

On Wednesday, February 02, 2011 11:12:07 Andrei Alexandrescu wrote:

On 2/2/11 2:45 AM, Andrei Alexandrescu wrote:

Following ideas and advice from this newsgroup, I have a draft at

http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html

There are two tables, one with just the names and the other with names
and a brief description. Let me know of any feedback. Thanks!


Andrei


I made one more pass and made the following changes:

* Added thin horizontal rules (you might have seen this already)

* Added "Comparison" category

* Reduced columns to two in the cheat sheet table and used leading rows
for distinguishing categories

* Added hyphenation, which should make justice to the justified style
(watch it at work in a narrow window!)

Let me know how it looks!


Aside from the category column, it looks great. However, the hyphenated category
column looks horrible. The only one that manages to put its whole name on one
line is Sorting. All of the others get split up onto 2 or 3 lines and become
almost illegible. There's _tons_ of room for the Functions column in comparison.
Unless you really think that there are going to be screens that are so small
that they can't even fit all of the function names in there by listing them in a
single line vertically (i.e. so small that there isn't enough space to
horizontally place the longest function name), I would strongly suggest having
the category column take up one line for each name rather than trying to
hyphenate it. At most, split up Set Operations onto two lines, with Set on one
line and Operations on the second. The hyphenating looks horrible and is hard to
read. I see no reason to make the category column worry about space so much. I
would expect the functions column to be able to handle the width adjustment for
various screen sizes.

Screenshot: http://is.gd/J51l9r

- Jonathan M Davis


Wow, Konqueror has a pretty bad layout engine wrt soft hyphenation. 
Hyphenating has a high penalty and should only occur when otherwise 
things would be really ugly.


I'll setup the table such that the first column is not hyphenated.

Andrei

Re: D vs Go on reddit

On 02/03/2011 12:31 AM, bearophile wrote:

Walter:

http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0

I have one comment about one thing said by bnolsen:

Simplicity + Orthogonality == win.<

I would like people who state such phrases to all spend 3 months (only)
programming exclusively in Oberon. From some point of view, it may probably be
considered the best language ever. Twice as expressive as Modula with half of
its features. It brings one the full power of imperative, structured,
object-oriented paradigms in a language /completely/ described in 13 (!) pages
of plain text.
It is a wonderful incarnation of the core any modern language should possess,
and how to do it properly. Language designers of the mainstream paradigm could
just start with Oberon as a clean, pure, safe, pedestal and just build on it.
For a full set of reasons, probably, Oberon has not had any success. Among them
(?) the obsession of those guys at ETH Zürich at /not/ considering practicality
as beeing of any worth, I guess ;-) This transforms programming in Oberon --a
potentially enthusiasmic experience at first sight-- into a battle of every
instant against irritating corners, annoying lacks, and against oneself to not
explode one's screen out of frustration.

What I want most is the language features to be implemented in a clean way,
with a clear semantics, with very few bad interactions with other language
features and very few pitfalls, and with a good clean syntax. If this is done
well enough, then I am able to learn and use hundreds of features too (and lots
of keywords).

Oberon is all what you ask for in the first sentence. On the other hand, just
/listing/ features D provides and Oberon does not would require pages.
Actually, its feature set is radically minuscule (and even more when compared
to its expressive power, I guess); this does not ensure cleanness, consistency
and orthogonality, indeed; but it may be impossible to achieve those qualities
as soon as features grow in number and, primarily, in diversity. I guess, in
fact, it is extremely difficult even for super simple toy languages. Successes
(from this point of view) like Oberon are rarissim as far as I know. (*)

Denis

(*) Even Pascal & Modula did not reach this point; precisely, Oberon abandoned
some of their features like enums and subrange types.

--
_
vita es estrany
spir.wikidot.com

Re: new documentation format for std.algorithm

On Wednesday, February 02, 2011 11:12:07 Andrei Alexandrescu wrote:
> On 2/2/11 2:45 AM, Andrei Alexandrescu wrote:
> > Following ideas and advice from this newsgroup, I have a draft at
> > 
> > http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html
> > 
> > There are two tables, one with just the names and the other with names
> > and a brief description. Let me know of any feedback. Thanks!
> > 
> > 
> > Andrei
> 
> I made one more pass and made the following changes:
> 
> * Added thin horizontal rules (you might have seen this already)
> 
> * Added "Comparison" category
> 
> * Reduced columns to two in the cheat sheet table and used leading rows
> for distinguishing categories
> 
> * Added hyphenation, which should make justice to the justified style
> (watch it at work in a narrow window!)
> 
> Let me know how it looks!

Aside from the category column, it looks great. However, the hyphenated 
category 
column looks horrible. The only one that manages to put its whole name on one 
line is Sorting. All of the others get split up onto 2 or 3 lines and become 
almost illegible. There's _tons_ of room for the Functions column in 
comparison. 
Unless you really think that there are going to be screens that are so small 
that they can't even fit all of the function names in there by listing them in 
a 
single line vertically (i.e. so small that there isn't enough space to 
horizontally place the longest function name), I would strongly suggest having 
the category column take up one line for each name rather than trying to 
hyphenate it. At most, split up Set Operations onto two lines, with Set on one 
line and Operations on the second. The hyphenating looks horrible and is hard 
to 
read. I see no reason to make the category column worry about space so much. I 
would expect the functions column to be able to handle the width adjustment for 
various screen sizes.

Screenshot: http://is.gd/J51l9r

- Jonathan M Davis

Re: Should we have an Unimplemented Attribute?

On Wednesday, February 02, 2011 16:16:00 Andrej Mitrovic wrote:
> On 2/3/11, Jonathan M Davis  wrote:
> > Usually the thing to do would be to either comment them out or put an
> > assert(0)
> 
> Can't do that with classes and struct.

??? You can comment out classes and structs just fine. You can also comment out 
member functions of classes and structs just fine. You can put assert(0) in 
member functions of classes and structs just fine. In this case, it sounds like 
a 
particular member function should have been commented out but wasn't.

- Jonathan M Davis

Re: Should we have an Unimplemented Attribute?

Well, then I suggest they be used in Phobos when a function isn't
implemented. Pretty please!

Re: Should we have an Unimplemented Attribute?

Oh, I meant Druntime. :p

Re: std.xml should just go


On 2/2/11 6:28 PM, Brad Roberts wrote:

On 2/2/2011 3:33 PM, Andrei Alexandrescu wrote:

For a while we've espoused the strategy of keeping std.xml in Phobos until 
something better comes along.

But recently we've started to rethink that.

Pretty much everyone who tries std.xml ends up disappointed. Anyone who wants 
to bash D has std.xml as an easy pick.
Anyone who looks at speed comparisons sees std.xml there like a sore thumb. 
Finally, the mere existence of a package, no
matter how inadequate, stifles the initiative of others working on it.

This all makes std.xml a net liability. It's not better than nothing; it's 
worse than nothing.

Should we nuke it?


Andrei


How sure are you about the assertion?  I haven't used it nor am likely to, but 
I also have trouble ruling out the
potential that there's users for which it works and they just aren't talking 
about it here.  This forum is, like it or
not, a minority of the user base.  Certainly the vocal people are the minority.


It has certain bugs 
(http://d.puremagic.com/issues/buglist.cgi?quicksearch=xml) that seem to 
occur in quite common XML code (though I'm no expert) yet nobody is 
discussing them or voting for them.



I'm not against replacement, but I'd be concerned about removal before a 
replacement is available.


My problem is that the mere presence is reducing the likelihood of a 
replacement coming about, in addition to the other liabilities.



Andrei

Re: std.xml should just go

2011-02-02 Thread Bernard Helyer

On Wed, 02 Feb 2011 16:28:27 -0800, Brad Roberts wrote:

> I haven't used it nor am likely to,
> but I also have trouble ruling out the potential that there's users for
> which it works and they just aren't talking about it here.

I do not believe that it's possible that anyone has used std.xml 
successfully for something substantial. :D

Re: std.xml should just go

2011-02-02 Thread Simen kjaeraas


Andrei Alexandrescu  wrote:


Should we nuke it?


Nuke it. Old versions of Phobos are available to those who need it, and
those should be very few.

--
Simen

Re: Should we have an Unimplemented Attribute?

2011-02-02 Thread Iain Buclaw

== Quote from Andrej Mitrovic (andrej.mitrov...@gmail.com)'s article
> On 2/3/11, Jonathan M Davis  wrote:
> >
> > Usually the thing to do would be to either comment them out or put an
> > assert(0)
> Can't do that with classes and struct.
> >  Regardless, I question the wisdom in adding something into the
> > language which _encourages_ you to leave in unfinished code.
> >
> My use case was protection for the user from using unfinished code by
> accident and as a reminder on how much work you're left to do as a
> library writer. But you might have a fair point here.

>From a library maintainer's POV, it may be wise to use an internal throw 
>function.

>From a developers POV, there's nothing that assert(! unimplementated) or
assert(false) can't do as a way to lay mines around checkpoints that you're
uncertain how to set off. :)

Both do not require any special language feature to function.

Regards

Re: std.xml should just go

2011-02-02 Thread Brad Roberts

On 2/2/2011 3:33 PM, Andrei Alexandrescu wrote:
> For a while we've espoused the strategy of keeping std.xml in Phobos until 
> something better comes along.
> 
> But recently we've started to rethink that.
> 
> Pretty much everyone who tries std.xml ends up disappointed. Anyone who wants 
> to bash D has std.xml as an easy pick.
> Anyone who looks at speed comparisons sees std.xml there like a sore thumb. 
> Finally, the mere existence of a package, no
> matter how inadequate, stifles the initiative of others working on it.
> 
> This all makes std.xml a net liability. It's not better than nothing; it's 
> worse than nothing.
> 
> Should we nuke it?
> 
> 
> Andrei

How sure are you about the assertion?  I haven't used it nor am likely to, but 
I also have trouble ruling out the
potential that there's users for which it works and they just aren't talking 
about it here.  This forum is, like it or
not, a minority of the user base.  Certainly the vocal people are the minority.

I'm not against replacement, but I'd be concerned about removal before a 
replacement is available.

Later,
Brad

Re: Should we have an Unimplemented Attribute?

On 2/3/11, Jonathan M Davis  wrote:
>
> Usually the thing to do would be to either comment them out or put an
> assert(0)

Can't do that with classes and struct.

>  Regardless, I question the wisdom in adding something into the
> language which _encourages_ you to leave in unfinished code.
>

My use case was protection for the user from using unfinished code by
accident and as a reminder on how much work you're left to do as a
library writer. But you might have a fair point here.

Re: Should slice[]=slice be disallowed?

Ali Ãehreli:

> (This must have been discussed before, but I couldn't come up with a way 
> to search in the archives.)

I have some unfinished ideas here, please add your comments :-)
http://d.puremagic.com/issues/show_bug.cgi?id=3971

Bye,
bearophile

Re: std.xml should just go

Andrei:

> Should we nuke it?

Yep. And do the same in similar situations.

Bye,
bearophile

Re: Should slice[]=slice be disallowed?

2011-02-02 Thread Ali Çehreli


Ali Çehreli wrote:
> (This must have been discussed before, but I couldn't come up with a way
> to search in the archives.)
>
> There is a hidden danger with two uses of slices:
>
> double[] slice1 = [ 1, 1, 1];
> double[] slice2 = [ 2, 2, 2];
> double[] slice3 = [ 3, 3, 3];
>
> slice2 = slice1;  // (1)
> slice3[] = slice1;// (2)
>
> The last two lines mean very different things:
>
>   (1) start sharing elements with slice1
>
>   (2) copy slice1's elements
>
> If either gets used by accident, the difference may not be noticed until
> the elements are modified in the future.
>
> Could we limit the syntax to reduce the chances of such a risk? e.g.
> "When two slices are involved, both sides must use the array-wise
> syntax".

Oy! :( I meant the above only in the array-wise semantics. Both of these 
should be valid with their different meanings:


slice2 = slice1;
slice3[] = slice1[];

This is still ok:

slice2 = slice1[];   // a slice to "all of" slice1

This should be illegal:

slice3[] = slice1;

Should it be?

Ali

Re: std.xml should just go

On Wednesday, February 02, 2011 15:33:42 Andrei Alexandrescu wrote:
> For a while we've espoused the strategy of keeping std.xml in Phobos
> until something better comes along.
> 
> But recently we've started to rethink that.
> 
> Pretty much everyone who tries std.xml ends up disappointed. Anyone who
> wants to bash D has std.xml as an easy pick. Anyone who looks at speed
> comparisons sees std.xml there like a sore thumb. Finally, the mere
> existence of a package, no matter how inadequate, stifles the initiative
> of others working on it.
> 
> This all makes std.xml a net liability. It's not better than nothing;
> it's worse than nothing.
> 
> Should we nuke it?

I'm fine with that, but then again, I've never used it. Still, I see some 
benefit 
in deprecating and/or removing modules that we know that we want to replace. At 
_minimum_, we should really start adding module comments to such modules that 
say that the module is going to be replaced at a later date, so you shouldn't 
expect it to be usable in your code in the long term unless you copy the source.

- Jonathan M Davis

Re: Should we have an Unimplemented Attribute?

On Wednesday, February 02, 2011 14:59:53 Andrej Mitrovic wrote:
> We know what a Deprecated Attribute is for:
> http://www.digitalmars.com/d/2.0/attribute.html#deprecated.
> 
> You can use a compiler switch to enable using these:
> -d
> allow deprecated features
> 
> But what about structs/classes/functions/etc which are partially
> implemented, but still unusable? Marking them with deprecated doesn't
> make sense, as this will likely confuse both the user and the library
> writers. Would it be overkill to introduce a new attribute?
> 
> The idea came after I've spent some good time trying to get druntime's
> getMembers function to work in my code, only to find out from this NG
> that it's not properly implemented.
> 
> Discuss?

Usually the thing to do would be to either comment them out or put an assert(0) 
in the code. Regardless, I question the wisdom in adding something into the 
language which _encourages_ you to leave in unfinished code.

If getMembers is not properly implemented, then it really shouldn't be left 
uncommented and/or without an assert(0) in it.

- Jonathan M Davis

Re: std.xml should just go

2011-02-02 Thread Bernard Helyer

On Wed, 02 Feb 2011 17:33:42 -0600, Andrei Alexandrescu wrote:
> 
> Should we nuke it?

>From orbit; it's the only way to be sure.

Remove it with utter prejudice, before someone else makes the mistake of 
trying to use it.

Should slice[]=slice be disallowed?

2011-02-02 Thread Ali Çehreli

(This must have been discussed before, but I couldn't come up with a way 
to search in the archives.)


There is a hidden danger with two uses of slices:

double[] slice1 = [ 1, 1, 1];
double[] slice2 = [ 2, 2, 2];
double[] slice3 = [ 3, 3, 3];

slice2 = slice1;  // (1)
slice3[] = slice1;// (2)

The last two lines mean very different things:

  (1) start sharing elements with slice1

  (2) copy slice1's elements

If either gets used by accident, the difference may not be noticed until 
the elements are modified in the future.


Could we limit the syntax to reduce the chances of such a risk? e.g. 
"When two slices are involved, both sides must use the array-wise 
syntax". Then the second line had to be written as:


slice3[] = slice1[];

Ali

Re: new documentation format for std.algorithm


On 2/2/11 5:20 PM, David Nadlinger wrote:

On 2/2/11 11:34 PM, David Nadlinger wrote:

Setting font size, line height and element dimensions in pixels is the
only option if you want an at least somewhat consistent user
experience […]


Okay, I guess that should rather be »the most reasonable option if you
want an at least somewhat consistent user experience…«.

I know well that standards-minded web developers used to strongly
advocate using relative sizes not too long ago, but in my perception,
things have changed since that.

Anyway, regardless of what's used as a base for font size, you'll
probably always need to modify the zoom level on some sites out there.
For example, Andrei's copy of the cutting-edge Phobos docs appears way
to big with standard Chromium font size settings on my screen, but if I
turned it down globally in browser preferences, Wikipedia would now be
too small – they use 0.8em font size for body copy…

David


It is also my perception that many of today's sites choose their own 
fonts and font sizes. Do we have a person with experience who could tell 
us what to do about font sizes?


Andrei

Re: Should we have an Unimplemented Attribute?

2011-02-02 Thread Piotr Szturmaj


Andrej Mitrovic wrote:

We know what a Deprecated Attribute is for:
http://www.digitalmars.com/d/2.0/attribute.html#deprecated.

You can use a compiler switch to enable using these:
-d
 allow deprecated features

But what about structs/classes/functions/etc which are partially
implemented, but still unusable? Marking them with deprecated doesn't
make sense, as this will likely confuse both the user and the library
writers. Would it be overkill to introduce a new attribute?

The idea came after I've spent some good time trying to get druntime's
getMembers function to work in my code, only to find out from this NG
that it's not properly implemented.

Discuss?


In C# there is NotImplementedException for that.

public class A
{
public int foo()
{
throw new NotImplementedException();
}
}

I see people ask for new attributes. Why not add user defined attributes 
into language? C# has custom attributes and Java has custom annotations.


Custom attributes could be just classes (as in C#):

class GuidAttribute : Attribute
{
string guid;

this(string guid)
{
this.guid = guid;
}
}

used like this (COM interfaces):

@Guid("48eecd81-35d7-4d4e-9ab8-479a38713053")
interface MyInterface
{
byte foo();
ulong bar();
}

or used for ORM:

@DBTable("users")
struct UserRow
{
@NotNull string username;
@NotNull string password
ubyte age;
}

There would be also need for some method to enumerate those attributes 
at compile time/run time. We already have that possibility for 
predefined attributes.

Re: std.xml should just go

Am 03.02.2011 00:33, schrieb Andrei Alexandrescu:
> For a while we've espoused the strategy of keeping std.xml in Phobos until
> something better comes along.
> 
> But recently we've started to rethink that.
> 
> Pretty much everyone who tries std.xml ends up disappointed. Anyone who wants 
> to
> bash D has std.xml as an easy pick. Anyone who looks at speed comparisons sees
> std.xml there like a sore thumb. Finally, the mere existence of a package, no
> matter how inadequate, stifles the initiative of others working on it.
> 
> This all makes std.xml a net liability. It's not better than nothing; it's 
> worse
> than nothing.
> 
> Should we nuke it?
> 
> 
> Andrei

You could explicitly deprecate it.

Or just nuke it, if someone still wants to use it (or is already using it) he
can copy the source-file to his project.

Cheers,
- Daniel

std.xml should just go

For a while we've espoused the strategy of keeping std.xml in Phobos 
until something better comes along.


But recently we've started to rethink that.

Pretty much everyone who tries std.xml ends up disappointed. Anyone who 
wants to bash D has std.xml as an easy pick. Anyone who looks at speed 
comparisons sees std.xml there like a sore thumb. Finally, the mere 
existence of a package, no matter how inadequate, stifles the initiative 
of others working on it.


This all makes std.xml a net liability. It's not better than nothing; 
it's worse than nothing.


Should we nuke it?


Andrei

Re: D vs Go on reddit

Walter:

> http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0

I have one comment about one thing said by bnolsen:

>Simplicity + Orthogonality == win.<

What I want most is the language features to be implemented in a clean way, 
with a clear semantics, with very few bad interactions with other language 
features and very few pitfalls, and with a good clean syntax. If this is done 
well enough, then I am able to learn and use hundreds of features too (and lots 
of keywords).

So the main problem I have with C++ is not its number of features (D seems to 
have a comparable number of them), but how brittle they are, how many corner 
cases they have, how many traps they have when you combine them with other 
language features. This is not just a lack of orthogonality.

Bye,
bearophile

Re: new documentation format for std.algorithm

2011-02-02 Thread David Nadlinger


On 2/2/11 11:34 PM, David Nadlinger wrote:

Setting font size, line height and element dimensions in pixels is the
only option if you want an at least somewhat consistent user experience […]


Okay, I guess that should rather be »the most reasonable option if you 
want an at least somewhat consistent user experience…«.


I know well that standards-minded web developers used to strongly 
advocate using relative sizes not too long ago, but in my perception, 
things have changed since that.


Anyway, regardless of what's used as a base for font size, you'll 
probably always need to modify the zoom level on some sites out there. 
For example, Andrei's copy of the cutting-edge Phobos docs appears way 
to big with standard Chromium font size settings on my screen, but if I 
turned it down globally in browser preferences, Wikipedia would now be 
too small – they use 0.8em font size for body copy…


David

Should we have an Unimplemented Attribute?

We know what a Deprecated Attribute is for:
http://www.digitalmars.com/d/2.0/attribute.html#deprecated.

You can use a compiler switch to enable using these:
-d
allow deprecated features

But what about structs/classes/functions/etc which are partially
implemented, but still unusable? Marking them with deprecated doesn't
make sense, as this will likely confuse both the user and the library
writers. Would it be overkill to introduce a new attribute?

The idea came after I've spent some good time trying to get druntime's
getMembers function to work in my code, only to find out from this NG
that it's not properly implemented.

Discuss?

Re: new documentation format for std.algorithm

2011-02-02 Thread David Nadlinger


On 2/2/11 10:03 PM, spir wrote:

On 02/02/2011 09:40 PM, "Jérôme M. Berger" wrote:

Andrei Alexandrescu wrote:


I'm not sure about that. Facebook's site is professionally designed and
I think they use fixed font sizes all over the place.


"Professionally designed" does not mean that they did the job right!

Jerome


Sure, setting absolute sizes and such was what web-designers used to do
before the first html/CSS tutorial was published?


No, it's what designers do if they are actual designers. Having text 
size entirely determined by the user is a noble idea for a web page 
consisting entirely of freely reflowable text, but as a matter of fact, 
there is much more to a web page today, and much more to what people 
expect from website design.


Setting font size, line height and element dimensions in pixels is the 
only option if you want an at least somewhat consistent user experience 
across multiple devices (and their default values). If an user dislikes 
the designer's choices, they might always use the zoom controls on their 
browser to adjust the site to their liking (and browsers have gotten 
pretty good at resizing nowadays).


David

Re: Calling method by name.

On 2/2/11, Stanislav Blinov  wrote:
> AFAIK, D2's TypeInfo and friends do have an interface for runtime
> reflection (methods offTi() and getMembers()), though a quick glance
> shows they're not implemented, i.e. return null all the time.
>

Talk about posting this after I've spent 20 minutes trying to figure
out why getMembers doesn't work!

Re: new documentation format for std.algorithm

2011-02-02 Thread Nick Sabalausky

"Andrei Alexandrescu"  wrote in message 
news:iibvgn$13bt$1...@digitalmars.com...
> On 2/2/11 9:08 AM, Adam Ruppe wrote:
>>
>> a) I really like a fixed width for the links, so it forms a neat
>> grid. My eyes just see a blob of links when it's a list...
>
> That would really hurt e.g. set operations.
>

I have the same problem. Maybe if it was just fixed-width *per* section?

Re: new documentation format for std.algorithm

2011-02-02 Thread Nick Sabalausky

"Andrei Alexandrescu"  wrote in message 
news:iibuu1$123i$1...@digitalmars.com...
> On 2/2/11 6:06 AM, Nick Sabalausky wrote:
>> "Denis Koroskin"<2kor...@gmail.com>  wrote in message
>> news:op.vp9wmrreo7cclz@korden-pc...
>>> On Wed, 02 Feb 2011 14:06:11 +0300, Magnus Lie Hetland
>>>   wrote:
>>>
 I think perhaps some adjustments could be made to the layout, to make 
 it
 more suitable to narrow(ish) browser windows (c.f., the discussio about
 80 columns -- without starting a huge thread like that again ;)

 For one thing, in narrow(ish) columns, ragged-right might be 
 preferable.
 Then again, it may be that the way it looks on my end isn't what's
 intended:

http://www.idi.ntnu.no/~mlh/images/std-alg-docs.png

>>>
>>> Left menu, Category and Function Name tables do take up about 800 pixels
>>> in width, leaving very little space for Description on small resolution
>>> displays, mostly because of the large font size used and identifiers as
>>> long as "largestPartialIntersectionWeighted".
>>>
>>> While there is little we can do with identifier names, I believe font 
>>> size
>>> could be reduced by about 30% without sacrificing readability. At least 
>>> in
>>> Opera the page looks well even at 70% scale.
>>
>> Actually, I think a smaller font improves the readability on that page. 
>> Left
>> as it is, I would always hit "decrease font" two or three times in my
>> browser before reading. (And that's even not counting the layout problems
>> the current font size causes.)
>
> OK, for now I removed everything fixing the font size from the css. Take a 
> look.
>

Not quite ideal IMHO, but definitely a *lot* better. I'd be happy with it.


>> I also agree with what others said about needing a better visual boundary
>> between the different descriptions.
>
> I'll look into this. I saw arguments against alternating colors. Also, 
> horizontal lines throughout would be ugly. More ideas would be welcome.
>

I think it would work ok if each description were at least 3 lines on 
average, but yea, with them mostly being one or two lines (esp. one line) it 
does get noisy.

I'd try adding extra spacing before and after the line, and *if* the line 
still looks noisy I'd try ripping out the line and just go with the extra 
spacing.

It's not actually all that bad as it is, though. I could certainly live with 
it and get used to it. Big improvement over just not having the line like 
before.


>> Only other thing I could bring up is that I'm really not as much a fan of
>> justified text as Andrei. But I can live with it fine, of course, just as
>> I've been doing (and I don't want to start a "left-aligned" vs 
>> "justified"
>> bikeshed war).
>
> Yah, it sometimes does look a bit forced. I'd need to add hyphenation to 
> make justified text look good.
>

I'm not sure how much that would work in this case, since each "paragraph" 
is fairly short and there doesn't seem to be much that would be 
hyphenatable.

As it is, I'm getting a lot of rather huge space characters:
http://www.semitwist.com/download/phobosAlgoScreenshot.png

FWIW, doing one "decrease font" click in FF2 (I have no idea how much that 
decreases it by) fixes the ultra-large spaces, and puts the font size at 
what I would consider ideal (although there's probably a number of people 
who would find that too small.)

Re: Calling method by name.

2011-02-02 Thread Stanislav Blinov


On 02/02/2011 11:11 PM, Robert Clipsham wrote:

On 02/02/11 20:00, Jacob Carlborg wrote:

On 2011-02-02 20:42, Robert Clipsham wrote:

On 02/02/11 17:55, %u wrote:

I know is possible to create an object from its name. It's possible to
call a method from that object if the name is only known at runtime?

Would something like the following be possible?

string classname, methodname;
// Ask the user for class and method.
auto obj = Object.factory(classname);
invoke(methodname, obj, param1, param2);

Thanks


As far as I'm aware there is no way to do this in any of the standard
libraries. This said, it is possible (at least to some extent), to do
some runtime reflection by parsing symbols out of the object file and
demangling them - this is what I'm using, but it's not as extensive as
what you're requesting, it's very use specific (mainly missing calling
methods with any number of parameters). It should be possible with some
work though.


Another possibility would be to using __traits with some allMembers,
collecting all the names and a delegate in a hash and store it in the
object.


If it's possible to do this, you should, it's what I'd be using if I had
access to it, unfortunately, there's no such love for D1.



AFAIK, D2's TypeInfo and friends do have an interface for runtime 
reflection (methods offTi() and getMembers()), though a quick glance 
shows they're not implemented, i.e. return null all the time.

Re: D vs Go on reddit

Walter:

> http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0

If a person looks at the history of computer languages, she sees thousands of
languages. Many of them were lot of work to be created, and most of them have
failed, over and over again. This has happened even to languages better than
many other languages present at their time, and when you see this you get sad.

And then there are language extensions / modifications. Researchers and
students have created hundreds of extensions to the C and Java languages, but
most of those extensions are forgotten, lot of wasted work.

Few of the failed languages, like Algol, have given part of their ideas to
successive languages that have succeed.

Some languages aren't meant to become widespread, they are just research toys.
Despite they usually die quickly, later some of their ideas find their place in
more widespread languages like Java, Haskell, OCaML, Scala, etc, so sometimes
that work is not wasted.

Designing a new language is a bet, the success probability is quite low. Even
if the language is good and it's backed by a strong firm, the probability of
failure is very real.

Software is an important part of our planetary civilization, and even small
improvements in creating it are able to influence society. So despite all,
designing a good new language is a lot of fun and it's very hard, and even if
it's a low probability bet, it's worth doing it.

Language designers usually create more than one language in their life, and
sometimes they design many languages. So even if the success probability is
low, trying again and again sometimes gives them a positive result :-) A good
language designer is more important than the design of a single language.

Bye,
bearophile

Re: D vs Go on reddit

2011-02-02 Thread Nick Sabalausky

"Walter Bright"  wrote in message 
news:iicfaa$23j7$1...@digitalmars.com...
> http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0

Wow, dumbass Google fanboys are just pouring out of the woodworks.

Re: new documentation format for std.algorithm


On 02/02/2011 09:40 PM, "Jérôme M. Berger" wrote:

Andrei Alexandrescu wrote:


I'm not sure about that. Facebook's site is professionally designed and
I think they use fixed font sizes all over the place.


"Professionally designed" does not mean that they did the job right!

Jerome


Sure, setting absolute sizes and such was what web-designers used to do before 
the first html/CSS tutorial was published?


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

Re: new documentation format for std.algorithm

2011-02-02 Thread Jérôme M. Berger

Andrei Alexandrescu wrote:
> Following ideas and advice from this newsgroup, I have a draft at
> 
> http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html
> 
> There are two tables, one with just the names and the other with names
> and a brief description. Let me know of any feedback. Thanks!
> 
Somewhat unrelated: there is a typo in the summary for "canFind":
the snippet calls "find" instead of "canFind".

Jerome
-- 
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr



signature.asc
Description: OpenPGP digital signature

Re: new documentation format for std.algorithm

2011-02-02 Thread Jérôme M. Berger

Andrei Alexandrescu wrote:
> 
> I'm not sure about that. Facebook's site is professionally designed and
> I think they use fixed font sizes all over the place.
> 
"Professionally designed" does not mean that they did the job right!

Jerome
-- 
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr



signature.asc
Description: OpenPGP digital signature

D vs Go on reddit

2011-02-02 Thread Walter Bright


http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0

Re: new documentation format for std.algorithm


On 2/2/11 2:15 PM, Magnus Lie Hetland wrote:

On 2011-02-02 16:40:15 +0100, Andrei Alexandrescu said:


On 2/2/11 5:06 AM, Magnus Lie Hetland wrote:

I think perhaps some adjustments could be made to the layout, to make it
more suitable to narrow(ish) browser windows (c.f., the discussio about
80 columns -- without starting a huge thread like that again ;)


Yah, the irony! :o)


:D


For one thing, in narrow(ish) columns, ragged-right might be preferable.
Then again, it may be that the way it looks on my end isn't what's
intended:

http://www.idi.ntnu.no/~mlh/images/std-alg-docs.png


This is a problem indeed.


The current version looks quite a bit better. However, it seems like the
hyphenation has gone a bit haywire. Just look at the categories,
function names etc. now...

http://www.idi.ntnu.no/~mlh/images/std-alg-docs.png

It does seem like slightly smaller text would help in general, but there
are so many ideas/opinions flying around -- I'll just leave it up to you ;)



The png seems to refer to an older version with three columns. No?

Andrei

Re: new documentation format for std.algorithm


On 2/2/11 2:16 PM, Magnus Lie Hetland wrote:

On 2011-02-02 16:01:29 +0100, Andrej Mitrovic said:


Yay! Glad to see this being incorporated in the website.

Btw, about the fonts:
I think this is a bug with the cutting-edge site only. The fonts
appear bigger, but they'll end up being smaller on the dmars website.
See:

http://i.imgur.com/7nfzz.jpg


Ahah!

Then I guess squashing that bug would be useful, before fretting any
more about horizontal real-estate :)



I fixed it by removing any absolute font sizes from std.ddoc.

Andrei

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

2011-02-02 Thread Jérôme M. Berger

Andrej Mitrovic wrote:
> Bleh. I tried to use Git to update some of the doc files, but getting
> the thing to work will be a miracle.
> 
> git can't find the public keys unless I use msysgit. Great. How
> exactly do I cd to D:\ ?
> 
> So I try git-gui. Seems to work fine, I clone the forked repo and make
> a few changes. I try to commit, it says I have to update first. So I
> do that. *Error: crash crash crash*. I try to close the thing, it just
> keeps crashing. CTRL+ALT+DEL time..
> 
> Okay, I try another GUI package, GitExtensions. I make new
> public/private keys and add it to github, I'm about to clone but then
> I get this "fatal: The remote end hung up unexpectedly".
> 
> I don't know what to say..

Why do you think I keep arguing against Git every chance I get?

Jerome
-- 
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr



signature.asc
Description: OpenPGP digital signature

Re: new documentation format for std.algorithm

2011-02-02 Thread Magnus Lie Hetland


On 2011-02-02 16:01:29 +0100, Andrej Mitrovic said:


Yay! Glad to see this being incorporated in the website.

Btw, about the fonts:
I think this is a bug with the cutting-edge site only. The fonts
appear bigger, but they'll end up being smaller on the dmars website.
See:

http://i.imgur.com/7nfzz.jpg


Ahah!

Then I guess squashing that bug would be useful, before fretting any 
more about horizontal real-estate :)


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

Re: new documentation format for std.algorithm

2011-02-02 Thread Magnus Lie Hetland


On 2011-02-02 16:40:15 +0100, Andrei Alexandrescu said:


On 2/2/11 5:06 AM, Magnus Lie Hetland wrote:

I think perhaps some adjustments could be made to the layout, to make it
more suitable to narrow(ish) browser windows (c.f., the discussio about
80 columns -- without starting a huge thread like that again ;)


Yah, the irony! :o)


:D


For one thing, in narrow(ish) columns, ragged-right might be preferable.
Then again, it may be that the way it looks on my end isn't what's
intended:

http://www.idi.ntnu.no/~mlh/images/std-alg-docs.png


This is a problem indeed.


The current version looks quite a bit better. However, it seems like 
the hyphenation has gone a bit haywire. Just look at the categories, 
function names etc. now...


 http://www.idi.ntnu.no/~mlh/images/std-alg-docs.png

It does seem like slightly smaller text would help in general, but 
there are so many ideas/opinions flying around -- I'll just leave it up 
to you ;)


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

Re: C# Interop

2011-02-02 Thread Richard Webb

>> I assume that you do quite a lot of initialization for TLS

I'm not directly, but Juno has a number of static class constructors that 
allocate
static members, and Outlook creates lots of threads (for example, i see the 
static
constructor of the module juno.com.core get called 20+ times on startup).
The Juno lib predates the TLS changes in D2 so i guess that some of these static
variables don't need to be thread local, but i haven't had chance to 
investigate that.


>>Are you using callbacks into the C++ DLL from the module ctors

The D dll just exports a couple of 'C' functions that the C++ dll calls. There 
are
no calls in the other direction.


>> that might work better if the C++ part also uses thread local storage

The C++ dll uses ATL for it's COM stuff, and i'm not sure what that does with 
TLS
in the background.

I'll try your suggested change tommorow.

Thanks,
Richard Webb

Re: Calling method by name.

2011-02-02 Thread Robert Clipsham


On 02/02/11 20:00, Jacob Carlborg wrote:

On 2011-02-02 20:42, Robert Clipsham wrote:

On 02/02/11 17:55, %u wrote:

I know is possible to create an object from its name. It's possible to
call a method from that object if the name is only known at runtime?

Would something like the following be possible?

string classname, methodname;
// Ask the user for class and method.
auto obj = Object.factory(classname);
invoke(methodname, obj, param1, param2);

Thanks


As far as I'm aware there is no way to do this in any of the standard
libraries. This said, it is possible (at least to some extent), to do
some runtime reflection by parsing symbols out of the object file and
demangling them - this is what I'm using, but it's not as extensive as
what you're requesting, it's very use specific (mainly missing calling
methods with any number of parameters). It should be possible with some
work though.


Another possibility would be to using __traits with some allMembers,
collecting all the names and a delegate in a hash and store it in the
object.


If it's possible to do this, you should, it's what I'd be using if I had 
access to it, unfortunately, there's no such love for D1.


--
Robert
http://octarineparrot.com/

Re: new documentation format for std.algorithm


On 2/2/11 1:41 PM, Denis Koroskin wrote:

On Wed, 02 Feb 2011 19:00:20 +0300, Andrei Alexandrescu
 wrote:


On 2/2/11 7:07 AM, spir wrote:

On 02/02/2011 09:45 AM, Andrei Alexandrescu wrote:

Following ideas and advice from this newsgroup, I have a draft at

http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html


There are two tables, one with just the names and the other with names
and a
brief description. Let me know of any feedback. Thanks!


Andrei


To avoid the descriptive table taking to much width, as evoked, remove
the category column by:
* Putting category names as "inter-lines" (dunno how to code that in
html, but there's certainly a way to do it).
* Making one table per category (simpler and nicer?).

Denis


Probably one table per category would make for too many tables. How
about the separating rows in
http://d-programming-language.org/cutting-edge/phobos/std_container.html?

Andrei


FWIW, in Opera there is also a huge gap (about 1000 pixels in height)
between the table and its summary
(http://habreffect.ru/files/940/18dbd8cbb/bug.png). It is most like
Opera specific, but I'm not sure.

That gap is coming from lots of empty paragraphs () in between
table rows:

 ...... 

I think it won't hurt to remove those as unnecessary.


Yah, that needs fixing. Unfortunately it makes a mess of the source as 
the empty line in between rows made it easy for me to follow and easy 
for emacs to wrap rows properly (at 80 columns, heh).


Andrei

Re: randomSample with unknown length

2011-02-02 Thread Magnus Lie Hetland


On 2011-02-02 16:32:25 +0100, Andrei Alexandrescu said:

randomSample is designed to subsample a large stream in constant space 
and without needing to scan the entire stream in order to output the 
first element.


Sure. I was just thinking that you could have a version for the cases 
where there was no end in sight :)


I used in in my dissertation where e.g. I had to select 100K samples 
from a stream of many millions.


Cool.

Having a reservoir sample available would be nice. I'd be thrilled if 
you coded up a reservoirSample(r, n) function for addition to 
std.random.


Seems Simen beat me to it :)

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

Re: new documentation format for std.algorithm

2011-02-02 Thread Jacob Carlborg


On 2011-02-02 09:45, Andrei Alexandrescu wrote:

Following ideas and advice from this newsgroup, I have a draft at

http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html

There are two tables, one with just the names and the other with names
and a brief description. Let me know of any feedback. Thanks!


Andrei


I think the font looks kind of weird, at least on Mac OS X. The font for 
the "intro text" looks fine.


In the description column, I think the text that is the actual function 
call should have a different style from the rest of the text. Probably 
some other color or something like that.


--
/Jacob Carlborg

Re: Calling method by name.

2011-02-02 Thread Jacob Carlborg


On 2011-02-02 20:42, Robert Clipsham wrote:

On 02/02/11 17:55, %u wrote:

I know is possible to create an object from its name. It's possible to
call a method from that object if the name is only known at runtime?

Would something like the following be possible?

string classname, methodname;
// Ask the user for class and method.
auto obj = Object.factory(classname);
invoke(methodname, obj, param1, param2);

Thanks


As far as I'm aware there is no way to do this in any of the standard
libraries. This said, it is possible (at least to some extent), to do
some runtime reflection by parsing symbols out of the object file and
demangling them - this is what I'm using, but it's not as extensive as
what you're requesting, it's very use specific (mainly missing calling
methods with any number of parameters). It should be possible with some
work though.


Another possibility would be to using __traits with some allMembers, 
collecting all the names and a delegate in a hash and store it in the 
object.


--
/Jacob Carlborg

Re: new documentation format for std.algorithm


On 02/02/2011 08:41 PM, Denis Koroskin wrote:

On Wed, 02 Feb 2011 19:00:20 +0300, Andrei Alexandrescu
 wrote:


On 2/2/11 7:07 AM, spir wrote:

On 02/02/2011 09:45 AM, Andrei Alexandrescu wrote:

Following ideas and advice from this newsgroup, I have a draft at

http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html

There are two tables, one with just the names and the other with names
and a
brief description. Let me know of any feedback. Thanks!


Andrei


To avoid the descriptive table taking to much width, as evoked, remove
the category column by:
* Putting category names as "inter-lines" (dunno how to code that in
html, but there's certainly a way to do it).
* Making one table per category (simpler and nicer?).

Denis


Probably one table per category would make for too many tables. How about the
separating rows in
http://d-programming-language.org/cutting-edge/phobos/std_container.html?

Andrei


FWIW, in Opera there is also a huge gap (about 1000 pixels in height) between
the table and its summary (http://habreffect.ru/files/940/18dbd8cbb/bug.png).
It is most like Opera specific, but I'm not sure.

That gap is coming from lots of empty paragraphs () in between table 
rows:

 ...... 

I think it won't hurt to remove those as unnecessary.


They don't appear in firefox rendering by me. (But are well in source.)

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

Re: new documentation format for std.algorithm


On 02/02/2011 08:12 PM, Andrei Alexandrescu wrote:

On 2/2/11 2:45 AM, Andrei Alexandrescu wrote:

Following ideas and advice from this newsgroup, I have a draft at

http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html

There are two tables, one with just the names and the other with names
and a brief description. Let me know of any feedback. Thanks!


Andrei


I made one more pass and made the following changes:

* Added thin horizontal rules (you might have seen this already)

* Added "Comparison" category

* Reduced columns to two in the cheat sheet table and used leading rows for
distinguishing categories

* Added hyphenation, which should make justice to the justified style (watch it
at work in a narrow window!)

Let me know how it looks!


Looks very good by me (even with my custom colors, but also watched with 
original ones).


A single detail: You should not use hyphenation in the top (simple) table, else 
it will cut function names, like mismatch in:

...findSplitAfter  findSplitBefore  indexOf  minCount  minPos  mis-
match  skipOver  startsWith  until...

Thank you for this work, Andrei.

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

Re: new documentation format for std.algorithm

2011-02-02 Thread Denis Koroskin

On Wed, 02 Feb 2011 19:00:20 +0300, Andrei Alexandrescu  
 wrote:



On 2/2/11 7:07 AM, spir wrote:

On 02/02/2011 09:45 AM, Andrei Alexandrescu wrote:

Following ideas and advice from this newsgroup, I have a draft at

http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html

There are two tables, one with just the names and the other with names
and a
brief description. Let me know of any feedback. Thanks!


Andrei


To avoid the descriptive table taking to much width, as evoked, remove
the category column by:
* Putting category names as "inter-lines" (dunno how to code that in
html, but there's certainly a way to do it).
* Making one table per category (simpler and nicer?).

Denis


Probably one table per category would make for too many tables. How  
about the separating rows in  
http://d-programming-language.org/cutting-edge/phobos/std_container.html?


Andrei


FWIW, in Opera there is also a huge gap (about 1000 pixels in height)  
between the table and its summary  
(http://habreffect.ru/files/940/18dbd8cbb/bug.png). It is most like Opera  
specific, but I'm not sure.


That gap is coming from lots of empty paragraphs () in between  
table rows:


 ...... 

I think it won't hurt to remove those as unnecessary.

Re: Calling method by name.

2011-02-02 Thread Robert Clipsham


On 02/02/11 17:55, %u wrote:

I know is possible to create an object from its name. It's possible to
call a method from that object if the name is only known at runtime?

Would something like the following be possible?

string classname, methodname;
// Ask the user for class and method.
auto obj = Object.factory(classname);
invoke(methodname, obj, param1, param2);

Thanks


As far as I'm aware there is no way to do this in any of the standard 
libraries. This said, it is possible (at least to some extent), to do 
some runtime reflection by parsing symbols out of the object file and 
demangling them - this is what I'm using, but it's not as extensive as 
what you're requesting, it's very use specific (mainly missing calling 
methods with any number of parameters). It should be possible with some 
work though.


--
Robert
http://octarineparrot.com/

Re: new documentation format for std.algorithm

2011-02-02 Thread Simen kjaeraas

On Wed, 02 Feb 2011 20:12:07 +0100, Andrei Alexandrescu  
 wrote:



On 2/2/11 2:45 AM, Andrei Alexandrescu wrote:

Following ideas and advice from this newsgroup, I have a draft at

http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html

There are two tables, one with just the names and the other with names
and a brief description. Let me know of any feedback. Thanks!


Andrei


I made one more pass and made the following changes:

* Added thin horizontal rules (you might have seen this already)

* Added "Comparison" category

* Reduced columns to two in the cheat sheet table and used leading rows  
for distinguishing categories


* Added hyphenation, which should make justice to the justified style  
(watch it at work in a narrow window!)


Let me know how it looks!


Much better! I vote this for official style.

--
Simen

Re: new documentation format for std.algorithm

2011-02-02 Thread Denis Koroskin

On Wed, 02 Feb 2011 19:00:20 +0300, Andrei Alexandrescu  
 wrote:



On 2/2/11 7:07 AM, spir wrote:

On 02/02/2011 09:45 AM, Andrei Alexandrescu wrote:

Following ideas and advice from this newsgroup, I have a draft at

http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html

There are two tables, one with just the names and the other with names
and a
brief description. Let me know of any feedback. Thanks!


Andrei


To avoid the descriptive table taking to much width, as evoked, remove
the category column by:
* Putting category names as "inter-lines" (dunno how to code that in
html, but there's certainly a way to do it).
* Making one table per category (simpler and nicer?).

Denis


Probably one table per category would make for too many tables. How  
about the separating rows in  
http://d-programming-language.org/cutting-edge/phobos/std_container.html?


Andrei


It looks great! One thing I don't like is that complexity sometimes gets  
split into 2 lines with huge spaces before and after asterisk (tested in  
Opera and Chrome):


nr*   log
nc

Either increased column width or  could probably help.

Re: new documentation format for std.algorithm

On 2/2/11, Andrei Alexandrescu  wrote:
> * Added hyphenation, which should make justice to the justified style
> (watch it at work in a narrow window!)

It even copies text properly when there's a hyphen. Nice.

Re: new documentation format for std.algorithm

> Same principle may even be the default for
> most modules, don't you think?

Indeed. It also lets us automatically generate stuff off
the existing files.

Here's my first go at automated tables:

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

I only tagged the map function in the std.algorithm source.

http://arsdnet.net/d-web-site/algorithm.d

(Using the ($TAG) macro described in a last post)


The program to do the automation is here:
http://arsdnet.net/d-web-site/improveddoc.d

It needs my dom module, here:
http://arsdnet.net/d-web-site/arsd/dom.d

If you want the Phobos html to work, you need to fix std.ddoc.

BIGOH = Ο($(D $0))

Is the new line. (The old one had terribly butchered html and
broke even my dom's tag soup fixer...)

Re: new documentation format for std.algorithm


On 2/2/11 2:45 AM, Andrei Alexandrescu wrote:

Following ideas and advice from this newsgroup, I have a draft at

http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html

There are two tables, one with just the names and the other with names
and a brief description. Let me know of any feedback. Thanks!


Andrei


I made one more pass and made the following changes:

* Added thin horizontal rules (you might have seen this already)

* Added "Comparison" category

* Reduced columns to two in the cheat sheet table and used leading rows 
for distinguishing categories


* Added hyphenation, which should make justice to the justified style 
(watch it at work in a narrow window!)


Let me know how it looks!


Andrei

Re: new documentation format for std.algorithm

On Wednesday, February 02, 2011 00:45:59 Andrei Alexandrescu wrote:
> Following ideas and advice from this newsgroup, I have a draft at
> 
> http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html
> 
> There are two tables, one with just the names and the other with names
> and a brief description. Let me know of any feedback. Thanks!

Definitely an improvement and looks good overall, but I really don't think that 
you should try to center the function names. It looks bad and makes them harer 
to read IMHO. If you're going to justify them at all, I'd suggest left justify.

- Jonathan M Davis

Re: C# Interop

2011-02-02 Thread Rainer Schuetze



Richard Webb wrote:

Also, DLLs can be used in multi-threading environments.


On a related note, i'm having a bit of a problem with a D dll at the moment.

I have an Outlook COM Addin that is written in D2 using the Juno library and 
that
is running ok, but i'm now trying to use a D dll from a COM addin written in C++
and i'm getting a crash inside dll_process_attach.

The only thing i get in the call stack is gcx.mark, but it appears that the 
crash
is due to the GC running midway through the thread setup code. Disabling the GC
during the thread_moduleTlsCtor() calls avoids the crash, but that might just be
covering the problem up.


If there is a garbage collection going on, I assume that you do quite a 
lot of initialization for TLS. Are you using callbacks into the C++ DLL 
from the module ctors? This might be dangerous...


You might want to try this version of impersonate thread(), that might 
work better if the C++ part also uses thread local storage:


// execute function on the TLS for the given thread
static void impersonate_thread( uint id, void function() fn )
{
if( id == GetCurrentThreadId() )
{
fn();
return;
}

// temporarily set current TLS array pointer to the array 
pointer of the referenced thread

void** curteb = getTEB();
void** teb= getTEB( id );
assert( teb && curteb );

void** curtlsarray = cast(void**) curteb[11];
void** tlsarray= cast(void**) teb[11];
if( !curtlsarray || !tlsarray )
return;

curteb[11] = tlsarray;
fn();
curteb[11] = curtlsarray;
}

Especially loading more DLLs from the TLS init code will still be 
troublesome...


Rainer

Re: Having fun making tutorials


On 02/02/2011 07:12 PM, Andrej Mitrovic wrote:

If someone makes a mistake when writing a tutorial, there's always
someone more knowledgeable that can correct the errors


... instead of criticizing the original author ;-)


That's the
great thing about wiki's.


Yop!

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

Re: new documentation format for std.algorithm


On 02/02/2011 05:05 PM, Daniel Gibson wrote:

I don't understand why cmp, equal, isSorted, ... are in the "Mutations" 
category.


what about an 'information' category? I use that word to categorise type 
functionality when there are numerous methods, seems to work fine. Typically 
'==', cmp, contains, count, indexOf... fall into this category.


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

Re: new documentation format for std.algorithm


On 02/02/2011 05:44 PM, Adam Ruppe wrote:

I also moved the brief description from the table to the first
line of the ddoc. The ddoc spec already describes the first paragraph
as being a summary, with the following paragraphs as a separate
description, so we're
just leveraging that existing definition.


I think that's just the-right-thing. Same principle may even be the default for 
most modules, don't you think? Thus allowing to generate summary tables of 
module functionality close to the top of generated html pages. This would also 
encourage authors writing sensible (first-line) summaries, properly telling the 
/purpose/ of each feature.


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

Re: new documentation format for std.algorithm


On 02/02/2011 05:00 PM, Andrei Alexandrescu wrote:

On 2/2/11 7:07 AM, spir wrote:

On 02/02/2011 09:45 AM, Andrei Alexandrescu wrote:

Following ideas and advice from this newsgroup, I have a draft at

http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html

There are two tables, one with just the names and the other with names
and a
brief description. Let me know of any feedback. Thanks!


Andrei


To avoid the descriptive table taking to much width, as evoked, remove
the category column by:
* Putting category names as "inter-lines" (dunno how to code that in
html, but there's certainly a way to do it).
* Making one table per category (simpler and nicer?).

Denis


Probably one table per category would make for too many tables. How about the
separating rows in
http://d-programming-language.org/cutting-edge/phobos/std_container.html?


Just what was needed, I guess.

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

Re: new documentation format for std.algorithm


On 02/02/2011 04:58 PM, Andrei Alexandrescu wrote:

On 2/2/11 6:47 AM, spir wrote:

On 02/02/2011 11:08 AM, bearophile wrote:

BlazingWhitester:


It looks realy nice!


I agree, it's a clear improvement.



But brief description table could use some spacing between
descriptions. It's a lilttle hard to read.


Instead of that I suggest to give an alternating white - light cyan
background to every adjacent group in the first table and every row in
the second table. Like in this page:
http://www.digitalmars.com/webnews/newsgroups.php?renew=1
Replacing with or.
In attach (I hope) a modified version for show.


Should /not/ be done (*): a web-designer should no more impose
(background) colors to users, than font sizes or any other rendering
style element. And certainly not white backgrounds, please (make my eyes
cry). The site's design is supposed to just-work without any custom
style; proposed style is a 'plus'.

Denis

(*) Works not by me, anyway: I cannot stand white background, highly
painful after 1/4 hour. To avoid this, I set my own background color in
firefox (as well as other elements like fonts & sizes). Thus, your trick
is invisible by people like me.


I guess this makes the alternating backgrounds tenuous. For now I added some
subtle horizontal lines, let me know how that works.

http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html


Does the job. For a question of taste I don't like that at all, but indeed 
others may disagree. (I prefere slight vertical spacing.)


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

Re: new documentation format for std.algorithm


On 02/02/2011 04:55 PM, Andrei Alexandrescu wrote:

I also agree with what others said about needing a better visual boundary
between the different descriptions.


I'll look into this. I saw arguments against alternating colors. Also,
horizontal lines throughout would be ugly.


Agreed.


 More ideas would be welcome.


Wouldn't 0.1 or 0.2 em vertical spacing do the job?

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

Re: Having fun making tutorials

On 2/2/11, Jesse Phillips  wrote:
> This is great. I suggest writing a tutorial on anything that you are
> learning, even if you are using a tutorial to learn it.

Yeah. A contributor doesn't have to be very experienced to write
anything, and more people should know that!

If someone makes a mistake when writing a tutorial, there's always
someone more knowledgeable that can correct the errors. That's the
great thing about wiki's.

The not-so-great part is that wikis tend to get abandoned or severely
outdated. But again, the reason for that is lack of contributors.

Calling method by name.

2011-02-02 Thread %u

I know is possible to create an object from its name. It's possible to
call a method from that object if the name is only known at runtime?

Would something like the following be possible?

string classname, methodname;
// Ask the user for class and method.
auto obj = Object.factory(classname);
invoke(methodname, obj, param1, param2);

Thanks

Re: C# Interop

2011-02-02 Thread Richard Webb

>> Also, DLLs can be used in multi-threading environments.

On a related note, i'm having a bit of a problem with a D dll at the moment.

I have an Outlook COM Addin that is written in D2 using the Juno library and 
that
is running ok, but i'm now trying to use a D dll from a COM addin written in C++
and i'm getting a crash inside dll_process_attach.

The only thing i get in the call stack is gcx.mark, but it appears that the 
crash
is due to the GC running midway through the thread setup code. Disabling the GC
during the thread_moduleTlsCtor() calls avoids the crash, but that might just be
covering the problem up.

This is with the latest druntime/phobos code from a couple of days ago plus your
patch from #5382, running on Windows 2008.

Any ideas?

Re: Having fun making tutorials

2011-02-02 Thread Jesse Phillips

This is great. I suggest writing a tutorial on anything that you are learning, 
even if you are using a tutorial to learn it. If you don't really have a place 
to get started you can look through existing stuff on Wiki4D or questions on 
StackOverflow for some ideas.

A lot of the existing stuff on Wiki4D is greatly outdated, but it is much more 
fun to write something new in your own style, so if there is something that 
interests you feel free to replace it.

Andrej Mitrovic Wrote:

> I've just uploaded this page:
> http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/CompilingLinkingD
> 
> It's a small guide on using DMD and Optlink, and the usual confusion with 
> linker errors when using the import switch. Still it's too Windows specific 
> and it doesn't discuss DLLs. I think they're special enough to warrant a new 
> page, and I might be writing about them soon. I'm no expert though.
> 
> A few days ago I've also written a small guide on how a typical D template 
> works from the ground up (in this case unaryFun):
> http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/D2Templates
> 
> I'm trying not to duplicate the effort and re-explain everything that TDPL 
> already explains perfectly. What other areas are newbies typically struggling 
> with when it comes to D?
> 
> Actually, I could use a good tutorial or two for myself! :)

Wrong link in Const FAQ

2011-02-02 Thread Klaim - Joël Lamotte

Hi,

I was reading the FAQ about const (
http://d-programming-language.org/const-faq.html), and got a
Doctor Dobb's website
"Sorry, the requested page is not found."
message on the link for the explaination about immutable strings.

I hope the article is still around.


Joël Lamotte.

Re: new documentation format for std.algorithm

Andrei Alexandrescu wrote:
> For now it's manual; I had to write the actual text which was the bulk
> anyway. Long term we'll need to look at generating the table by adding
> category tags to each function/class etc.

Right. I now think the best way to do it is something like this:

Macros:
WIKI = Phobos/StdAlgorithm
TAG = $1

/**
map!"2 * a"([1, 2, 3]) lazily returns a range with the numbers 2, 4, 6.

Implements the homonym function (also known as $(D transform)) present

[... snip all unmodified existing content ...]
See_also:
$(TAG Iteration)

 */

Then, the function tags are grouped in a pretty logical place,
and have enough decoration in the HTML that we can easily parse
them out before or after.

The helper program would search all links with the tag class and
figure out what function they belong to. With that, it generates
the categorization tables.

Alternatively, it could use a "Tags:" instead of "See_also:".

I also moved the brief description from the table to the first
line of the ddoc. The ddoc spec already describes the first paragraph
as being a summary, with the following paragraphs as a separate
description , so we're
just leveraging that existing definition.

Now, when the table is generated, it can go through and pull
the first paragraph out of each ddoc section and put it in the
summary table.

Alternatively, we add a new section, say, "Briefly":

/**
Implements the homonym function (also known as $(D transform)) present
[... snip all unmodified existing content ...]

Briefly:
map!"2 * a"([1, 2, 3]) lazily returns a range with the numbers 2, 4, 6.

See_also:
$(TAG Iteration)

 */

And the helper program pulls that out for the table. The
result might look something like this:

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

(I only played with map() there and dmd -D'd it, so nothing fancy).

> Not getting this.

What I mean there is the above "Briefly:" section.

> That would really hurt e.g. set operations.

Yeah. Oh well.

Re: new documentation format for std.algorithm


On 2/2/11 10:05 AM, Daniel Gibson wrote:

Am 02.02.2011 09:45, schrieb Andrei Alexandrescu:

Following ideas and advice from this newsgroup, I have a draft at

http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html

There are two tables, one with just the names and the other with names
and a brief description. Let me know of any feedback. Thanks!


Andrei


I like it. It's much easier to find the right function.

I don't understand why cmp, equal, isSorted, ... are in the "Mutations"
category.
It makes sense for bringToFront, initializeAll, swap etc, though.
Maybe a "Analyzation" category would make sense for the former?

Cheers,
- Daniel


That's a mistake; I must have been tired because my plan was to put cmp, 
equal, isSorted under their own category called "comparison". In fact I 
could swear I did that, but I can't find that text. I might have cut it 
and forgot to paste... :o)


Will fix a bit later.


Andrei

Re: new documentation format for std.algorithm


Am 02.02.2011 17:22, schrieb Daniel Gibson:

Am 02.02.2011 17:20, schrieb Andrei Alexandrescu:

On 2/2/11 10:05 AM, Daniel Gibson wrote:

Am 02.02.2011 09:45, schrieb Andrei Alexandrescu:

Following ideas and advice from this newsgroup, I have a draft at

http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html


There are two tables, one with just the names and the other with names
and a brief description. Let me know of any feedback. Thanks!


Andrei


I like it. It's much easier to find the right function.

I don't understand why cmp, equal, isSorted, ... are in the "Mutations"
category.
It makes sense for bringToFront, initializeAll, swap etc, though.
Maybe a "Analyzation" category would make sense for the former?

Cheers,
- Daniel


That's a mistake; I must have been tired because my plan was to put cmp,
equal, isSorted under their own category called "comparison". In fact I
could swear I did that, but I can't find that text. I might have cut it
and forgot to paste... :o)

Will fix a bit later.


Andrei



Ok :)

What about min, max and such?


ok, there seems to be no "and such", but I just realized that min and 
max are missing in the upper table.

Re: new documentation format for std.algorithm


Am 02.02.2011 17:20, schrieb Andrei Alexandrescu:

On 2/2/11 10:05 AM, Daniel Gibson wrote:

Am 02.02.2011 09:45, schrieb Andrei Alexandrescu:

Following ideas and advice from this newsgroup, I have a draft at

http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html

There are two tables, one with just the names and the other with names
and a brief description. Let me know of any feedback. Thanks!


Andrei


I like it. It's much easier to find the right function.

I don't understand why cmp, equal, isSorted, ... are in the "Mutations"
category.
It makes sense for bringToFront, initializeAll, swap etc, though.
Maybe a "Analyzation" category would make sense for the former?

Cheers,
- Daniel


That's a mistake; I must have been tired because my plan was to put cmp,
equal, isSorted under their own category called "comparison". In fact I
could swear I did that, but I can't find that text. I might have cut it
and forgot to paste... :o)

Will fix a bit later.


Andrei



Ok :)

What about min, max and such?

Re: new documentation format for std.algorithm


On 2/2/11 9:08 AM, Adam Ruppe wrote:

Andrei Alexandrescu Wrote:

There are two tables, one with just the names and the other with
names and a brief description. Let me know of any feedback.
Thanks!


Did you decide on a manually maintained table or is it auto
generated?  I do really think adding a Tags: section, or perhaps just
putting groups under the See_Also: section is a good way to do the
grouping.


For now it's manual; I had to write the actual text which was the bulk 
anyway. Long term we'll need to look at generating the table by adding 
category tags to each function/class etc.



The mini examples might be good as a new section too, one that can be
hidden in the big docs, but available to the jump table.


Not getting this.


Also a few notes:

a) I really like a fixed width for the links, so it forms a neat
grid. My eyes just see a blob of links when it's a list...


That would really hurt e.g. set operations.


b) The  anchors in the page are repeated in a lot of
cases, meaning the links may go to the wrong place. I suggest
tweaking ddoc to make them fully qualified (at least inside the
module, for example, "#OpenRight.yes" instead of "#yes").


Yah, how did you pull that trick in your generated jump table?


c) I think I agree with the others that the Category header eats a
bit too much horizontal space, but it isn't a big deal to me.


I'll probably change that.


I'm working on my own little tweaks to the system concurrently. I
like your version a lot more than mine right now, but still think we
can do a little better... if I have time today in between my other
work, I'll see about adding my ideas here to my version so you can
see them in practice.


Awesome!


Andrei

Re: new documentation format for std.algorithm


Am 02.02.2011 09:45, schrieb Andrei Alexandrescu:

Following ideas and advice from this newsgroup, I have a draft at

http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html

There are two tables, one with just the names and the other with names
and a brief description. Let me know of any feedback. Thanks!


Andrei


I like it. It's much easier to find the right function.

I don't understand why cmp, equal, isSorted, ... are in the "Mutations" 
category.

It makes sense for bringToFront, initializeAll, swap etc, though.
Maybe a "Analyzation" category would make sense for the former?

Cheers,
- Daniel

Re: new documentation format for std.algorithm


On 2/2/11 10:06 AM, Adam Ruppe wrote:

Andrei Alexandrescu:

Hmmm, this wrong jumping is a problem. I'll look into it. Offhand I
don't know how to distinguish in the generated doc between an enum value
and a function, but Adam did it. Adam?


My method is to track the level of nesting. The more  tags above
you in the tag tree, the further down you are.

The generated html puts everything in a  html tag. It goes:


Functionname  and prototype
Information about it


For enums (and probably structs/class methods too, but I haven't
confirmed yet), the sub-members are in that dd, like so:


 Enum Name
 Enum description

Member #1 name
Member #1 description

  




So, if you keep track of how many's are above you in the
tree, you know what your parent is - are you a top level function
or a member of another object?

If you're a member of another object, you go up the tree a couple
levels (get past your, then past the enclosing) and
find the  that is the last sibling to your grandparent.

That holds the name of the enum.

Here's my javascript implementation:

function getParentTerm(e) {
while(e) {
if(e.tagName == "DD")
return e;
e = e.parentNode;
}

// we have the definition, gotta get the term right above it

if(e == null)
return null; // has no parent

var r;
var arr = e.parentNode.childNodes;
for(var p = 0; p<  arr.length; p++) {
var a = arr[p];
if(a.tagName == "DT")
r = a; // store the last term we saw...
if(a == e) // if we're back to ourselves...
return r; // ... the last term is the answer
}
//assert(0);
}



Since the actual function names are underlined, you can get
a full name by searching the returned term for a  tag and
pulling it out. While parent !is null, name = parent.name ~ "." ~
name, done.

If you found the child a[name] elements and replaced the name
attribute with the result from above, the links would all work too.


I have an almost working D implementation too, but the HTML isn't
well formed xml so my library butchers it a bit on output. That needs
to be fixed before ditching the javascript. Then, I figure, we can
add the helper program in between dmd itself and the live site.


Anyway, I know what's wrong and how to fix it, but haven't written
the last pieces of code to actually do it yet... after that, we
just have some presentation issues to finalize and we're set.


Got it, thanks. Perhaps indeed a ddoc change would make this easier.

Andrei

Re: new documentation format for std.algorithm

Andrei Alexandrescu:
> Hmmm, this wrong jumping is a problem. I'll look into it. Offhand I
> don't know how to distinguish in the generated doc between an enum value
> and a function, but Adam did it. Adam?

My method is to track the level of nesting. The more  tags above
you in the tag tree, the further down you are.

The generated html puts everything in a  html tag. It goes:


   Function name and prototype
   Information about it


For enums (and probably structs/class methods too, but I haven't
confirmed yet), the sub-members are in that dd, like so:


Enum Name
Enum description
   
   Member #1 name
   Member #1 description
   
 




So, if you keep track of how many 's are above you in the
tree, you know what your parent is - are you a top level function
or a member of another object?

If you're a member of another object, you go up the tree a couple
levels (get past your , then past the enclosing ) and
find the  that is the last sibling to your grandparent.

That holds the name of the enum.

Here's my javascript implementation:

function getParentTerm(e) {
while(e) {
if(e.tagName == "DD")
return e;
e = e.parentNode;
}

// we have the definition, gotta get the term right above it

if(e == null)
return null; // has no parent

var r;
var arr = e.parentNode.childNodes;
for(var p = 0; p < arr.length; p++) {
var a = arr[p];
if(a.tagName == "DT")
r = a; // store the last term we saw...
if(a == e) // if we're back to ourselves...
return r; // ... the last term is the answer
}
//assert(0);
}



Since the actual function names are underlined, you can get
a full name by searching the returned term for a  tag and
pulling it out. While parent !is null, name = parent.name ~ "." ~
name, done.

If you found the child a[name] elements and replaced the name
attribute with the result from above, the links would all work too.


I have an almost working D implementation too, but the HTML isn't
well formed xml so my library butchers it a bit on output. That needs
to be fixed before ditching the javascript. Then, I figure, we can
add the helper program in between dmd itself and the live site.


Anyway, I know what's wrong and how to fix it, but haven't written
the last pieces of code to actually do it yet... after that, we
just have some presentation issues to finalize and we're set.

Re: new documentation format for std.algorithm