Re: newsgroup web viewer
On Wed, Nov 16, 2011 at 08:27:55PM -0800, bcs wrote: > >I really do not understand why people keep writing replacements for > >newsreaders that miss fundamentally useful aspects of it. > > Because they have never used a proper new reader? This is like asking why car manufacturers keep writing replacements for horse drawn buggies that miss fundamentally useful aspects of it. like whips.
Re: newsgroup web viewer
On 11/16/2011 08:46 PM, Kagamin wrote: bcs Wrote: On 11/16/2011 10:14 AM, Walter Bright wrote: I really do not understand why people keep writing replacements for newsreaders that miss fundamentally useful aspects of it. Because they have never used a proper new reader? What do you do if you don't have access to your proper newsreader, but have access to internet? Well you should be able to find feature list and screen shots from the available options. Anyone who is going to make an effort to write a NNTP client should really try out the existing one first. For that matter, most anyone who has the resources to write a new client will have the resources to run an old one.
Re: newsgroup web viewer
I did some bug fixing tonight and changed some features. http://arsdnet.net/d-web-site/nntp/thread-index?newsgroup=digitalmars.D * The links are all working now. You can view individual posts. * It uses cookies to remember your preferences. Name, email, preferred view mode, etc. * Added collapsed views of the full thread. The code seems slow today. But: http://arsdnet.net/d-web-site/nntp/get-thread?newsgroup=digitalmars.D&messageId=%3Cmailman.959.1321474737.24802.digitalmars-d%40puremagic.com%3E&ordering=ByParent and there's an expand link to pull it all up, or you can click the individual posts. Read vs unread is done with browser history if you click individual posts. I'm going to try using this to do all my posts for a while.
Re: newsgroup web viewer
bcs wrote: > Add that to the multi post view with it pointing to an anchor on the > same page and you might have a point. Added bonus: instant caching. meh, I don't want to clutter the multiple post page with all kinds of links. If you want the details, you can click through to the post.
Re: newsgroup web viewer
bcs Wrote: > On 11/16/2011 10:14 AM, Walter Bright wrote: > > > > I really do not understand why people keep writing replacements for > > newsreaders that miss fundamentally useful aspects of it. > > Because they have never used a proper new reader? What do you do if you don't have access to your proper newsreader, but have access to internet?
Re: newsgroup web viewer
On 11/16/2011 07:53 AM, Adam Ruppe wrote: But looking at a tree thread is almost impossible once it gets to more than about ten posts without computer assistance, and even then, it's so fractured that people repeat themselves a lot. I find I have that tendency no matter what the format. If, in a thread, there are more than about 20 post I haven't read, I tend to just not read anything that isn't in response to something I posted. Linear, hierarchical. Doesn't matter much. At least with hierarchical I sometimes read the siblings of my posts. I think it's a defensive time management tactic. I've seen threads here that literally grew content faster than I cold read it (assuming I wanted to think about it at all).
Re: newsgroup web viewer
On 11/16/2011 10:14 AM, Walter Bright wrote: I really do not understand why people keep writing replacements for newsreaders that miss fundamentally useful aspects of it. Because they have never used a proper new reader?
Re: newsgroup web viewer
On 11/16/2011 07:23 PM, Adam D. Ruppe wrote: Jesse Phillips Wrote: How is that easy in a linear, err chronological, view? The parent isn't the one directly above. Hit a View Parent link. http://arsdnet.net/d-web-site/nntp/get-message?newsgroup=digitalmars.D&messageId=%3Cj9v9k7%241lji%241%40digitalmars.com%3E digitalmars.D Thread: newsgroup web viewer by Adam D. Ruppe In reply to: Re: newsgroup web viewer by Walter Bright Add that to the multi post view with it pointing to an anchor on the same page and you might have a point. Added bonus: instant caching.
Re: newsgroup web viewer
On 11/16/2011 08:04 AM, Adam Ruppe wrote: bcs Wrote: Cut the tab size by about 60% and that's usable. OK OTOH it will still end up with a column size of -10 pt about the time threads get interesting. Another fundamentally broken aspect of tree views. Not inherently. That is a fundamentally broken aspect of placing the messages bodies in-line with a tree views. And if anyone keeps more than about 3 layers of quoting you need to be Tolstoy to be more than half the content. Well, the way I see it, if you're quoting more than two lines at a time, you're probably over-quoting. Exactly. Remember, in both linear and tree views, getting back to the parent post is very easy, How? I don't see any back links? and if someone is reading the reply, it is likely that he read the parent already anyway. Only true for me about 40-50% of the time: "So-n-so responded to this sub tree so there might be something interesting in it, so I will start reading there." I hit the N key or look for the bold titles. How is that N key implemented? boldEach(find!"a.timestamp> b"(sort!"a.timestamp< b.timestamp") (messages)); or something like that. I don't really know, but I assume thunder-bird stores a bit somewhere for each post indicating what I've opened. Anything based on time stamp would be useless as I very rarely read thread in time order.
Re: newsgroup web viewer
Jesse Phillips Wrote: > How is that easy in a linear, err chronological, view? The parent isn't > the one directly above. Hit a View Parent link. http://arsdnet.net/d-web-site/nntp/get-message?newsgroup=digitalmars.D&messageId=%3Cj9v9k7%241lji%241%40digitalmars.com%3E digitalmars.D Thread: newsgroup web viewer by Adam D. Ruppe In reply to: Re: newsgroup web viewer by Walter Bright
Re: newsgroup web viewer
On Wed, 16 Nov 2011 11:04:15 -0500, Adam Ruppe wrote: > Remember, in both linear and tree views, getting back to the parent post > is very easy, How is that easy in a linear, err chronological, view? The parent isn't the one directly above.
Re: newsgroup web viewer
Vladimir Panteleev Wrote: > What do you mean by that? If you want to use any of my code, feel free, and if I like your program better, I'm willing to abandon mine.
Re: Why not extend array operations to full Fortran90 power ?
On Wed, 16 Nov 2011 14:08:33 -0500, Joachim Wuttke wrote: Compare (1) Y[] = X[]*X[]; (2) Y[] = sin( X[] ); With gdc 4.4.6, (1) compiles and executes as I expected, whereas (2) is not allowed (fails at compile time). Why? The semantics of (2) is unambiguous, and it works perfectly well in Fortran90. Allowing (2) would make D really attractive for formula-heavy mathematical work. - Joachim Lack of developer man-hours. This has actually been discussed before and is on Don's bubble list, IIRC, but there are a lot of other bug to fix before it.
Re: newsgroup web viewer
On Wed, 16 Nov 2011 17:33:56 +0200, Adam Ruppe wrote: Vladimir Panteleev Wrote: Hmm... Now what do I do with the half-written thing I started writing two days ago (for news and newsgroups)? We could always combine the best parts of both of them! I have planned for something different in many aspects, including style, user interface design, functionality and internal design decisions. I think I'll continue working on my project. I only hope I'll complete it before it is made irrelevant. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: newsgroup web viewer
On Wed, 16 Nov 2011 17:33:56 +0200, Adam Ruppe wrote: Vladimir Panteleev Wrote: Hmm... Now what do I do with the half-written thing I started writing two days ago (for news and newsgroups)? We could always combine the best parts of both of them! What do you mean by that? -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Why not extend array operations to full Fortran90 power ?
On 11/16/2011 4:48 PM, Simen Kjærås wrote:
On Wed, 16 Nov 2011 22:31:31 +0100, Xinok wrote:
On 11/16/2011 2:08 PM, Joachim Wuttke wrote:
Compare
(1) Y[] = X[]*X[];
(2) Y[] = sin( X[] );
With gdc 4.4.6,
(1) compiles and executes as I expected, whereas
(2) is not allowed (fails at compile time).
Why?
The semantics of (2) is unambiguous,
and it works perfectly well in Fortran90.
Allowing (2) would make D really attractive
for formula-heavy mathematical work.
- Joachim
I think vector operations are designed to avoid turning them into
loops. In (2), this would require several calls to sin().
Really? How would you do Y[] = X[] * X[] without a loop?
That's not what I meant by it. Perhaps an example is in order:
void main(){
int rand(){
rndGen.popFront();
return rndGen.front;
}
int[5] a;
int[5] b = [1000, 2000, 3000, 4000, 5000];
a[] = b[] + (rand() % 1000);
writeln(a);
}
This is the result:
[1299, 2299, 3299, 4299, 5299]
It adds the same random value to each element, meaning it only calls
rand() once. D doesn't treat vector operations like loops.
Re: Why not extend array operations to full Fortran90 power ?
On 11/16/2011 10:48 PM, Simen Kjærås wrote: On Wed, 16 Nov 2011 22:31:31 +0100, Xinok wrote: On 11/16/2011 2:08 PM, Joachim Wuttke wrote: Compare (1) Y[] = X[]*X[]; (2) Y[] = sin( X[] ); With gdc 4.4.6, (1) compiles and executes as I expected, whereas (2) is not allowed (fails at compile time). Why? The semantics of (2) is unambiguous, and it works perfectly well in Fortran90. Allowing (2) would make D really attractive for formula-heavy mathematical work. - Joachim I think vector operations are designed to avoid turning them into loops. In (2), this would require several calls to sin(). Really? How would you do Y[] = X[] * X[] without a loop? In the special case that the type of X and Y is eg. float[4], use SIMD :o). Joachim's example points out an performance limitation of the current array vector operations: if we have Y[] = sin( X[] ); Then there is currently no way to implement an overload for sin such that it can benefit from RVO. It should be able to write the sinuses directly to Y, but it cannot. That is merely syntax though. copy(map!sin(X), Y); // good enough for me.
Re: newsgroup web viewer
Le 16/11/2011 23:25, Adam D. Ruppe a écrit : > Somedude Wrote: >> PS: bug when one clicks on a thread title, though > > Yeah, I know. When I wrote this originally, it was last year and my > web.d module was pretty different than it is now. ... > I'm probably going to fix this by Friday. Cool. :) Dude
Re: reddit discussion on article by bearophile
On 11/16/11 11:42 AM, Kagamin wrote: Andrei Alexandrescu Wrote: Heh heh... took me a few seconds to figure out what you meant. It actually DOES compile because `yellow` and `blue` are in enum previously defined with their respective values 1<<0 and 1<<1, he tried to construct a value-to-string map. This is actually a pretty awesome fail. Andrei
Re: newsgroup web viewer
Somedude Wrote: > Some forums, like http://forum.hardware.fr, allow you to go back to the > post you are responding to by clicking on the poster's name, and it also > displays the number of responses to your own post. I like that idea. Something I've been going for here is to keep the listing uncluttered. I don't like how on things like phpbb, there's all kinds of useless stuff on every screen. It's especially painful to browse it in something like lynx. So, for this, I want to have just one link per post on the main listing - the author's name - that goes to details. Then, on the individual posts, you have additional links to reply, navigate, etc. Since the reply form is on the individual post, it maintains all the thread headers for the traditional newsgroup viewers, without the user having to realize it.
Re: Translation of C struct to D
If I try to cast with register_chrdev(0, (char*)DEVICE_NAME, &fops); the following error appears: C style cast illegal, use cast(char*)DEVICE_NAME Or use DEVICE_NAME.ptr
Re: newsgroup web viewer
Somedude Wrote: > PS: bug when one clicks on a thread title, though Yeah, I know. When I wrote this originally, it was last year and my web.d module was pretty different than it is now. I got it to compile again to make changes, but haven't completely converted it to the new code. You can still get to individual posts if you manually change it from get-message to get-message-page in the url. (old web.d did that automatically. New web.d doesn't since it proved to be buggy in more complex sites. I haven't gotten around to fixing it since I started using a different method anyway.) I'm probably going to fix this by Friday.
Re: newsgroup web viewer
Le 16/11/2011 03:51, Adam D. Ruppe a écrit : > Is there a lot of interest in this kind of thing among the community? I've waited for this for such a long time... Thx :) PS: bug when one clicks on a thread title, though
Re: newsgroup web viewer
Le 16/11/2011 05:47, bcs a écrit : > On 11/15/2011 07:18 PM, Adam D. Ruppe wrote: >> Trass3r Wrote: >>> http://www.digitalmars.com/webnews/newsgroups.php is nicer and works >>> fine >>> for me the few times I need a web viewer. >> >> Oh, I keep forgetting this one exists! >> >> Can we get this linked from the main newsgroups page at least? >> >>> A threaded view is a must have :) >> >> Change the ordering to ByParent in the url, though I haven't adjusted >> the stylesheet >> to include proper spacing for that. > > Either that's not working, it's not what I want or the stylesheet thing > is getting in the way. > >> >> It puzzles me how people actually like that view though! I hate threaded >> views with a passion. > > Do you actually enjoy having to guess what something is in reply to? Or > how about the fun you can have trying to locate replies to a given post? > Or what about when one branch of a thread goes off on a interesting > tangent and another dives down a rabbit hole you couldn't care less about? > > Unless you plan on reading *everything* (and when things get > interesting, that is just flat impossible, even if you don't have a > job), the most important information is virtually invisible in anything > but a threaded view. Some forums, like http://forum.hardware.fr, allow you to go back to the post you are responding to by clicking on the poster's name, and it also displays the number of responses to your own post. And you get all the responses in a new tab if you click on that number. Very practical.
Re: reddit discussion on article by bearophile
Le 16/11/2011 17:57, Andrei Alexandrescu a écrit : > http://www.reddit.com/r/programming/comments/me6a5/some_examples_of_strong_static_typing_in_d/ > > > Andrei Someone brought up a problem I had thought about a few days ago. I quote (emphasis by me): > However, I am not much of a fan of D. I prefer c++ more because it doesn't even try and memory manage, whereas in D it is optional. *I do not like this because you end up using libraries which use the GC* and I think that ruins a sort of elegance you get from select right kind of smart pointer for as specific usage. Given that D boasts that you can choose to *not* use the GC, shouldn't Phobos strive to resort to manual memory management ? I supposed this has already been discussed, but just in case I missed the discussion, could someone give a link to it ?
Re: Why not extend array operations to full Fortran90 power ?
On Wed, 16 Nov 2011 22:31:31 +0100, Xinok wrote: On 11/16/2011 2:08 PM, Joachim Wuttke wrote: Compare (1) Y[] = X[]*X[]; (2) Y[] = sin( X[] ); With gdc 4.4.6, (1) compiles and executes as I expected, whereas (2) is not allowed (fails at compile time). Why? The semantics of (2) is unambiguous, and it works perfectly well in Fortran90. Allowing (2) would make D really attractive for formula-heavy mathematical work. - Joachim I think vector operations are designed to avoid turning them into loops. In (2), this would require several calls to sin(). Really? How would you do Y[] = X[] * X[] without a loop?
Re: Translation of C struct to D
Am 2011-11-16 00:53, schrieb Iain Buclaw: Rather than using toStringz, you should be able to get by with declaring the register_chrdev function as follows. extern(C) int register_chrdev (uint major, in char *name, file_operations *fops) This yields the following compiler error: Error: cannot implicitly convert expression (DEVICE_NAME) of type char[] to char* If I try to cast with register_chrdev(0, (char*)DEVICE_NAME, &fops); the following error appears: C style cast illegal, use cast(char*)DEVICE_NAME Best regards Michael
Re: Why not extend array operations to full Fortran90 power ?
On 11/16/2011 2:08 PM, Joachim Wuttke wrote: Compare (1) Y[] = X[]*X[]; (2) Y[] = sin( X[] ); With gdc 4.4.6, (1) compiles and executes as I expected, whereas (2) is not allowed (fails at compile time). Why? The semantics of (2) is unambiguous, and it works perfectly well in Fortran90. Allowing (2) would make D really attractive for formula-heavy mathematical work. - Joachim I think vector operations are designed to avoid turning them into loops. In (2), this would require several calls to sin().
Re: Why not extend array operations to full Fortran90 power ?
On 11/16/2011 08:08 PM, Joachim Wuttke wrote: Compare (1) Y[] = X[]*X[]; (2) Y[] = sin( X[] ); With gdc 4.4.6, (1) compiles and executes as I expected, whereas (2) is not allowed (fails at compile time). Why? The semantics of (2) is unambiguous, and it works perfectly well in Fortran90. Allowing (2) would make D really attractive for formula-heavy mathematical work. - Joachim I like it, but there is a problem: (2) is already valid code if you have these two overloads: float sin(float x); float[] sin(float[] x); So with your rule it would be ambiguous.
Re: Why not extend array operations to full Fortran90 power ?
Joachim Wuttke Wrote: > Compare > >(1) Y[] = X[]*X[]; >(2) Y[] = sin( X[] ); > > With gdc 4.4.6, >(1) compiles and executes as I expected, whereas >(2) is not allowed (fails at compile time). > Why? > > The semantics of (2) is unambiguous, > and it works perfectly well in Fortran90. > Allowing (2) would make D really attractive > for formula-heavy mathematical work. > > - Joachim Hmm... well, yeah http://d.puremagic.com/issues/show_bug.cgi?id=3395
Why not extend array operations to full Fortran90 power ?
Compare (1) Y[] = X[]*X[]; (2) Y[] = sin( X[] ); With gdc 4.4.6, (1) compiles and executes as I expected, whereas (2) is not allowed (fails at compile time). Why? The semantics of (2) is unambiguous, and it works perfectly well in Fortran90. Allowing (2) would make D really attractive for formula-heavy mathematical work. - Joachim
Re: reddit discussion on article by bearophile
Andrei Alexandrescu Wrote: > Heh heh... took me a few seconds to figure out what you meant. It actually DOES compile because `yellow` and `blue` are in enum previously defined with their respective values 1<<0 and 1<<1, he tried to construct a value-to-string map.
Re: Curl wrapper review
Jonas Drewsen wrote:
>Hi,
>
>After all the comments from last review I've refactored the curl
>wrapper and it is ready for a new review.
>
>David Nadlinger was handling the last review so I guess it would make
>sense if he run this one as well if he wants to.
>
>Code:
>https://github.com/jcd/phobos/blob/curl-wrapper/etc/curl.d
>
>Docs:
>http://freeze.steamwinter.com/D/web/phobos/etc_curl.html
>
>Regards,
>Jonas
Looks great so far!
Some minor nitpicks:
* Examples: "new Http()" is used 4 times in the examples, but as Http is
a struct, I see no reason to create it using new?
* Move
--
// Get using an line range and proxy settings
auto client = new Http();
client.proxy = "1.2.3.4";
foreach (line; byLine("d-p-l.org", client))
writeln(line);
--
from the first to the second example. (The sentence "For more control
than the high level functions provide, use the low level API:" sounds
like everything shown up to that point was the high level api, so that
one example should be moved below that sentence)
* smtp.perform; --> smtp.perform();
* Please set default timeouts for the simple API. Nothing is more
annoying than a application locking up because of internet loss..
* Speaking of timeouts, I'd like a special TimeoutException, as it's
easy to recover from these errors.
* At least the high-level API should really be @safe (or @trusted).
Adding those qualifiers to the low level API would also be good, but
that can always be done after merging into phobos.
* Some functions could be nothrow? @property StatusLine statusLine()
for example, maybe some more.
--
Johannes Pfau
Re: newsgroup web viewer
Adam Ruppe Wrote: > Kagamin Wrote: > > well, most people here seem to use nntp clients, so their requests (like > > threaded view) can be safely ignored :) they have it in their clients. > > Indeed. Hell, I probably won't use it very often, since I have > my precious mutt mail client! > > But, regardless, I wrote that already and just need to tweak > it now, so not a big hassle. Well, lol, if you need a joblist, this is my view: 1. corrupted messages 2. non-working links 3. sync with nntp server 4. order threads by last post time (like forums) (done?) // here we will have reading 5. (didn't test posting yet, goes here) 6. paging 7. accounts and server-side cookies
Re: Array slice assign syntax
On 11/16/2011 04:24 AM, bearophile wrote:
The Bugzilla issues that I really care about is a not an useless long list,
it's about fifteen items long, and this post is about one of them.
I think current array slice assign syntax is a bit messy, and I think this
should be addressed.
Kenji Hara has recently written a very nice program (that here I have modified
a bit for clarity) that shows the current array assign situation:
import std.stdio, std.typetuple;
void main() {
writeln("Rhs is an array, is it compilable?");
writeln("a\t/ b\t\ta=b\ta[]=b\ta=b[]\ta[]=b[]");
foreach (i, Lhs; TypeTuple!(int[3], int[]))
foreach (j, Rhs; TypeTuple!(int[3], int[])) {
writef("%s\t/ %s ", Lhs.stringof, Rhs.stringof);
Lhs a = [0,0,0];
Rhs b = [1,2,3];
writef("\t%s", __traits(compiles, { a = b; }));
writef("\t%s", __traits(compiles, { a[] = b; }));
writef("\t%s", __traits(compiles, { a = b[]; }));
writef("\t%s", __traits(compiles, { a[] = b[]; }));
writeln();
}
writeln("\nRhs is a element, is it compilable?");
writeln("a\t\t\ta=N\ta[]=N\ta[0..2]=N");
foreach (Lhs; TypeTuple!(int[3], int[])) {
writef("%s\t\t", Lhs.stringof);
Lhs a = [0,0,0];
writef("\t%s", __traits(compiles, { a = 9; }));
writef("\t%s", __traits(compiles, { a[] = 9; }));
writef("\t%s", __traits(compiles, { a[0..2] = 9; }));
writeln();
}
}
Currently (DMD 2.057head, despite I think Walter has not updated DMD version
number yet) it prints:
Rhs is an array, is it compilable?
a / b a=b a[]=b a=b[] a[]=b[]
int[3u] / int[3u] truetruetruetrue
int[3u] / int[] truetruetruetrue
int[] / int[3u] truetruetruetrue
int[] / int[] truetruetruetrue
Rhs is a element, is it compilable?
a a=N a[]=N a[0..2]=N
int[3u] truetruetrue
int[] false truetrue
This also means this is currently accepted:
void main() {
int[3] a;
a = 1;
assert(a == [1, 1, 1]);
}
While this is not accepted:
void main() {
int[] b = new int[3];
b = 1;
assert(b == [1, 1, 1]); //Error: cannot implicitly convert expression (1)
of type int to int[]
}
I'd like D to require a[]=1 in that first case too.
I'd like the [] to be required every time an O(n) vector operation is done, for:
- constancy with all other vector operations among two arrays, that require [];
- and to avoid unwanted (and not easy to spot in the code) O(n) operations;
- bugs and confusion in D newbies that don't have memorized all current special
cases.
On the other hand Don says that [] is only required for lvalues.
I think this boils to a new table like this:
Rhs is an array, is it compilable?
a / b a=b a[]=b a=b[] a[]=b[]
int[3u] / int[3u] FALSE trueFALSE true
int[3u] / int[] FALSE trueFALSE true
int[] / int[3u] FALSE trueFALSE true
int[] / int[] truetruetruetrue
Rhs is a element, is it compilable?
a a=N a[]=N a[0..2]=N
int[3u] FALSE truetrue
int[] false truetrue
Now if there's a [] on the left, then it's an O(n) vector operation (like a
copy), otherwise it's O(1).
That also means:
void main() {
int[] a = new int[3];
int[] b = new int[3];
a = b; // OK, copies just array fat reference
}
void main() {
int[3] a, b;
a = b; // Not OK, hidden vector op
}
I am not sure this new table is fully correct, but it's a start. Fixes of
mistakes are welcomes.
---
This is an alternative proposal.
On the other hand this vector op syntax doesn't currently compile:
void main() {
int[3] a, b;
a[] += b;
}
So if array assign is seen as a normal vector op, then the [] is needed on the
right too:
Rhs is an array, is it compilable?
a / b a=b a[]=b a=b[] a[]=b[]
int[3u] / int[3u] FALSE FALSE FALSE true
int[3u] / int[] FALSE FALSE FALSE true
int[] / int[3u] FALSE FALSE FALSE true
int[] / int[] trueFALSE FALSE true
Rhs is a element, is it compilable?
a a=N a[]=N a[0..2]=N
int[3u] FALSE truetrue
int[] false truetrue
Where the two cases with dynamic arrays are syntax errors to keep more symmetry:
void main() {
int[] a = new int[3];
int[] b = new int[3];
a[] = b; // error
a = b[]; // error
}
---
Lot of time ago I have opened bug issue 3971 on this topic, but that Bugzilla
thread contains various mistakes and some parts of it are obsolete.
Bye,
bearophile
First thing:
Re: Website message overhaul
Am 16.11.2011 02:24, schrieb Jude Young: I see one camp that is against using multi-paradigm on the basis that it sounds buzz-wordy, and another camp for using because it does actually mean something specific. I'm not against calling D "multi paradigm", I'm just against the style of the "Modern convenience. Multi-paradigm power. Native efficiency." sentences. It *sounds* buzzwordy, regardless of the words. Even "Rusty bars. Heavy chains. Merciless guards." sounds like a cheap commercial ;) OTOH "D is a modern, powerful multi-paradigm programming language that combines the efficiency of native code with the convenience of modern languages like C#" contains all those buzzwords but doesn't sound as bad. Cheers, - Daniel
Re: reddit discussion on article by bearophile
On 11/16/11 10:34 AM, Kagamin wrote:
Andrei Alexandrescu Wrote:
http://www.reddit.com/r/programming/comments/me6a5/some_examples_of_strong_static_typing_in_d/
Andrei
Those are examples of shitty C coding... if I wanted something akin to what he
wrote I'd do this
#define ENTRY(name, val) { (1<
Heh heh... took me a few seconds to figure out what you meant.
Andrei
Re: reddit discussion on article by bearophile
Andrei Alexandrescu Wrote:
> http://www.reddit.com/r/programming/comments/me6a5/some_examples_of_strong_static_typing_in_d/
>
> Andrei
Those are examples of shitty C coding... if I wanted something akin to what he
wrote I'd do this
#define ENTRY(name, val) { (1<
Re: newsgroup web viewer
On 11/16/2011 7:33 AM, Adam Ruppe wrote: Vladimir Panteleev Wrote: Hmm... Now what do I do with the half-written thing I started writing two days ago (for news and newsgroups)? We could always combine the best parts of both of them! I've thought many times about nothing more than a CGI based news reader that works just like an NNTP news reader, in fact, have it use the NNTP database. Yeah, I know we have that miserable php one.
Re: newsgroup web viewer
On 11/16/2011 5:17 AM, Mafi wrote: Am 16.11.2011 07:48, schrieb Walter Bright: I agree with you, which is why the D site has never used typical forum software. I've not seen one that preserved the tree like structure of conversations. They mash them all flat and spread them out over endless pages. What about mwforum (http://www.mwforum.org/)? It uses a tree-structure and jumps for you to the newest post. It works great and is fast even though it uses Perl CGI. Not bad, but no way to mark a posting as 'read', so no way to tell what you haven't read yet. I really do not understand why people keep writing replacements for newsreaders that miss fundamentally useful aspects of it.
Re: newsgroup web viewer
On 11/16/2011 7:27 AM, Adam Ruppe wrote: You have that same reply to list, parent link, etc. people want, and the browser history keeps track of where you've been. A reddit-like view would be acceptable as long as it had a button to mark a posting as 'read'. Read ones would be in a different color, or maybe faded. Even better would an ability to collapse/expand it so you could see the unread ones easily.
Re: newsgroup web viewer
On 11/16/2011 7:39 AM, Adam Ruppe wrote: Walter Bright Wrote: It's trivial with a news reader, because unread messages are in boldface. Which is possible because the messages are sorted linearly in the computer! When you do a newnews command in NNTP, you tell it a time, not a thread. Then it grabs everything since that time, and you know they are new. Hmmm that's an idea though. If it plopped down a "last checked" time cookie or url param, it could bold the new things on the web too. That's not quite it. I do not read the newsgroup articles in a chronological order, so "unread" articles are most definitely not just the new articles since the last time I looked at the thread.
reddit discussion on article by bearophile
http://www.reddit.com/r/programming/comments/me6a5/some_examples_of_strong_static_typing_in_d/ Andrei
Re: Array slice assign syntax
On Wed, 16 Nov 2011 03:24:25 -, bearophile wrote: +1 vote toward looking into this more. I like the idea of a more consistent syntax, and the [] requirement for vector operations vs single/simple assignment. Lot of time ago I have opened bug issue 3971 on this topic, but that Bugzilla thread contains various mistakes and some parts of it are obsolete. So.. create a new BZ, put the content of your message here in it, and mark the old one a duplicate of the new one .. or mark the old one invalid, and simply create a new one with this content. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Array slice assign syntax
On Wed, 16 Nov 2011 04:24:25 +0100, bearophile wrote: [Good stuff] Votes++
Re: newsgroup web viewer
Walter Bright Wrote: > If that sin isn't enough, the other problem is there is no way to mark a post > as > "read". Every linear view web forum software I've ever seen handles this automatically. I don't really love the implementation of most of them, but they usually do a good enough job anyway. > That's the main thing that sux about Reddit. Try reading a topic for a while, > then come back a few hours later and wonder what's new. Aye. Reddit is one reason why I don't like tree views!
Re: newsgroup web viewer
bcs Wrote: > Cut the tab size by about 60% and that's usable. OK > OTOH it will still end > up with a column size of -10 pt about the time threads get interesting. Another fundamentally broken aspect of tree views. > And if anyone keeps more than about 3 layers of quoting you need to be > Tolstoy to be more than half the content. Well, the way I see it, if you're quoting more than two lines at a time, you're probably over-quoting. Remember, in both linear and tree views, getting back to the parent post is very easy, and if someone is reading the reply, it is likely that he read the parent already anyway. > I hit the N key or look for the bold titles. How is that N key implemented? boldEach(find!"a.timestamp > b"(sort!"a.timestamp < b.timestamp") (messages)); or something like that.
Re: newsgroup web viewer
Jonathan M Davis Wrote: > Knowing the parent post of a particular post can be critical to understanding > that post - especially when the parent post isn't quoted in the reply. Yeah, that's one of the few times I hit the o-t keys in my mail reader to sort by thread. Keep in mind that this information is always available! I just don't like using it by default. > Particularly with longer threads, I don't know how you could ever hope to > follow them without having a properly threaded tree structure to the posts. I've never had trouble following linear threads, even with hundreds of posts. But looking at a tree thread is almost impossible once it gets to more than about ten posts without computer assistance, and even then, it's so fractured that people repeat themselves a lot. > Even gmail - which has threading of a > sort - is completely inadequate to dealing with complex threads. Gmail sucks on so many levels. Their interface is almost unusable.
Re: newsgroup web viewer
Peter Alexander Wrote: > Would this encourage vandalism? If people know they can get a post on > the front page of the D website just by posting to D.announce then I > think we could see some trouble. Meh, I say we cross that bridge when we come to it. Right now, the D newsgroups have a pretty good record; most the people who post here are honest and well enough on topic. Until that changes, I wouldn't worry about it.
Re: newsgroup web viewer
Walter Bright Wrote: > It's trivial with a news reader, because unread messages are in boldface. Which is possible because the messages are sorted linearly in the computer! When you do a newnews command in NNTP, you tell it a time, not a thread. Then it grabs everything since that time, and you know they are new. Hmmm that's an idea though. If it plopped down a "last checked" time cookie or url param, it could bold the new things on the web too.
Re: newsgroup web viewer
Vladimir Panteleev Wrote: > Hmm... Now what do I do with the half-written thing I started writing two > days ago (for news and newsgroups)? We could always combine the best parts of both of them!
Re: newsgroup web viewer
Nick Sabalausky Wrote: > a:link vs a:visited That was my original plan, but I like having multiple posts on one page too, and you can't link them up that way. Or can you? Maybe with script, I can watch the scroll position and change the anchor as each post scrolls into view. The anchor could be used as a link target. But if you view posts individually: http://arsdnet.net/d-web-site/nntp/get-message-page?newsgroup=digitalmars.D&messageId=%3Cop.v4yfbjy4tuzx1w%40cybershadow.mshome.net%3E&original You have that same reply to list, parent link, etc. people want, and the browser history keeps track of where you've been.
Re: newsgroup web viewer
Kagamin Wrote: > well, most people here seem to use nntp clients, so their requests (like > threaded view) can be safely ignored :) they have it in their clients. Indeed. Hell, I probably won't use it very often, since I have my precious mutt mail client! But, regardless, I wrote that already and just need to tweak it now, so not a big hassle.
Re: newsgroup web viewer
"Adam D. Ruppe" wrote in message news:j9vg6h$28tl$1...@digitalmars.com... > bcs Wrote: >> Either that's not working, it's not what I want or the stylesheet thing >> is getting in the way. > > Stylesheet... did a quick adjustment, try now: > > http://arsdnet.net/d-web-site/nntp/get-thread?newsgroup=digitalmars.D&messageId=%3Cj9ps5n%2430nq%241%40digitalmars.com%3E&ordering=ByParent > That's better, but it's still difficult to use. I think mail-archive.com has the ideal design for a tree view: http://www.mail-archive.com/digitalmars-d-learn@puremagic.com/ Granted, they desperately need to fix the problem where all replies are shown with only one level of indenting (it works fine when you're viewing a message, though), and they lack the ability to post. But other than that, I think it would be good to mimic their design as much as possible. Another great example is lists.puremagic.com: http://lists.puremagic.com/pipermail/dmd-beta/2011-October/thread.html All that needs is some nicer styling (or *some* styling!), an actual partial-tree-view when viewing a message (like mail-archive.com, instead of just "Previous"/"Next") and, again, the ability to post. Whenever I'm not using my real email/NG client, I use one of those two - mail-archive.com and lists.puremagic.com. The only major thing either of them actually needs is the ability to post. With that added in, I'd be perfectly happy with them.
Re: newsgroup web viewer
"bcs" wrote in message news:j9vhqd$2cc6$1...@digitalmars.com... > On 11/15/2011 09:03 PM, Adam D. Ruppe wrote: >> bcs Wrote: >> >>> Or >>> how about the fun you can have trying to locate replies to a given post? >> >> On the other hand, finding new posts is virtually impossible with a tree >> view, because it's mixed in at random. >> > > Nope, finding them is trivial. I hit the N key or look for the bold > titles. Admittedly, a bit harder to do in a web interface than a "real" > client. > a:link vs a:visited
Re: newsgroup web viewer
Am 16.11.2011 07:48, schrieb Walter Bright: I agree with you, which is why the D site has never used typical forum software. I've not seen one that preserved the tree like structure of conversations. They mash them all flat and spread them out over endless pages. What about mwforum (http://www.mwforum.org/)? It uses a tree-structure and jumps for you to the newest post. It works great and is fast even though it uses Perl CGI. Mafi
Re: newsgroup web viewer
Adam D. Ruppe Wrote: > On the other hand, finding new posts is virtually impossible with a tree > view, because it's mixed in at random. well, most people here seem to use nntp clients, so their requests (like threaded view) can be safely ignored :) they have it in their clients.
Re: newsgroup web viewer
I suggest to focus on correctness rather than features.
Re: Array slice assign syntax
a = b for two static arrays of the same type and size is ok for me, especially when the size is small. I get your point though and like a strict syntax, too. The notion of a vector operation always using [] seems natural.
Re: newsgroup web viewer
On Wed, 16 Nov 2011 04:51:25 +0200, Adam D. Ruppe wrote: I've complained about the godawful web viewers for the newsgroup before, and wrote a little program to do a better job. Hmm... Now what do I do with the half-written thing I started writing two days ago (for news and newsgroups)? -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Curl wrapper review
Den 16-11-2011 00:08, Bernard Helyer skrev:
I'll just post my thoughts here while they're fresh. It looks good. The
documentation is what I'd expect from a Phobos module, as is the naming
convention.
auto _basicFtp(T)(const(char)[] url, const(void)[] sendData, Ftp client)
You're right. Should be private
If you don't want people using it, shouldn't it be marked private instead
of using the underscore for obscurity?
private struct Pool(DATA)
{
private:
You've marked private things as 'private foo;' everywhere else in the
module, what's with the switch in styles for this struct? Also, as the
whole struct is module private I'm not sure of the utility of marking
members private. I guess it's a form of documentation.
Regarding the switch in I just think that I'd been doing lots of c++
coding that day. Anyway I think it is ok to use that style for small
classes/structs that can fit on a single screen even though I haven't
done that consistently either in this module. I'll change it to match
the rest of the module.
Regarding the second question: I just think it is good style to mark up
the private parts. And if someone copy/pastes it as a public struct
it'll work as intended.
But really, I'm grasping at straws. Even if the above were to remain, I
would love to see this in Phobos yesterday. :)
-Bernard.
Thanks for the comments.
/Jonas
Re: Continuous Merging For GDC and LDC?
On Wednesday, November 16, 2011 10:28:37 Alex Rønne Petersen wrote: > One thing that confuses me a bit is why GDC and LDC need downstream > copies of druntime/phobos. Couldn't patches that fix the libraries for > certain archs/OSs be sent upstream, in order to reduce merging work and > always provide the latest release to users? Now that so many version > identifiers are standardized across DMD, GDC, LDC, and SDC, I think it'd > be beneficial to do this. druntime is expected to have differing versions per compiler. Both Sean Kelly and Iain Buclaw would argue that - they have in the past. However, I would certainly hope that that would _not_ be the case with Phobos. It's supposed to be at a higher level and thus should generally be able to avoid such issues. - Jonathan M Davis
Re: Curl wrapper review
That's ok. Anyone else up for handling the review? /Jonas Den 16-11-2011 00:36, David Nadlinger skrev: Hi Jonas, great to see that the code is ready for a second round – the sooner we get something like this into Phobos, the better. However, currently I can barely manage to spare some time for D related projects, and there are other things I'd really like to finish soon (tracking yet another exception-related problem that breaks part of my GSoC code on Linux x86_64, updating LDC to DMD 2.056/LLVM 3.0 and officially completing its move to GitHub), so it would be great if somebody else could handle the review. David On 11/15/11 9:21 PM, Jonas Drewsen wrote: Hi, After all the comments from last review I've refactored the curl wrapper and it is ready for a new review. David Nadlinger was handling the last review so I guess it would make sense if he run this one as well if he wants to. Code: https://github.com/jcd/phobos/blob/curl-wrapper/etc/curl.d Docs: http://freeze.steamwinter.com/D/web/phobos/etc_curl.html Regards, Jonas
Re: Continuous Merging For GDC and LDC?
On 16-11-2011 00:40, Iain Buclaw wrote: On 15 November 2011 23:21, dsimcha wrote: How does the merging process for new Phobos/druntime/DMD front ends work w.r.t. GDC and LDC? To what extent is it automated? If it's mostly automated except when things go wrong (or could be made so), we should set up a server somewhere (maybe on one of the DMD tester boxes that's underworked, if there is one) that automatically merges every commit to druntime/phobos/dmd and tests it. It seems to take agonizingly long after every DMD release for LDC and GDC to get caught up, which makes sense only if the merges are being done by hand or changes are made to low-level stuff (certain parts of druntime, the glue layer of the compiler, etc.). Furthermore, such continuous merging might encourage DMD/Phobos/druntime devs to do things in a more LDC/GDC-friendly way and would make trunk revisions of Phobos/druntime/dmd in between releases available to GDC/LDC users. API changes in the D frontend could break builds. New features in D that require backend support could break builds. The only positive to continuous merging is that they will be caught early and dealt with. Other than that, I tend to use merges as a time to start merging in some experimental features I've got in the flux. In this current merge I've been working out support for named value return support in gdc, and weeding out some bugs present in the current in/out contract inheritance. One thing that confuses me a bit is why GDC and LDC need downstream copies of druntime/phobos. Couldn't patches that fix the libraries for certain archs/OSs be sent upstream, in order to reduce merging work and always provide the latest release to users? Now that so many version identifiers are standardized across DMD, GDC, LDC, and SDC, I think it'd be beneficial to do this. - Alex
Re: Website message overhaul
On 11/16/2011 12:34 AM, Jonathan M Davis wrote: On Wednesday, November 16, 2011 00:23:09 Walter Bright wrote: That's like saying Python supports static typing, it just never checks it! While I don't know scala, I think that there's a _big_ difference between a language that supports a style of programming which is functional except for its lack immutability and saying that a dynamically typed language supports static typing. Here's an analogy maybe that is more palatable. Let's say a language says it supports "memory safe" programming. But it never checks it. Would you say, then, that C "supports" memory safe programming, because if you're super careful and never make any mistakes, it is memory safe? I'd be a laughingstock if I made such a claim. I would say that C doesn't prevent you from writing memory safe programs, but not that it supported it. There is no support in C for it.
Re: Website message overhaul
On Wednesday, November 16, 2011 00:23:09 Walter Bright wrote: > On 11/15/2011 10:55 PM, Peter Alexander wrote: > > Scala does support function purity (you can write pure functions) and > > immutable data (you can create data that you don't write to), it just > > doesn't statically check either of those things :-) > > That's like saying Python supports static typing, it just never checks it! While I don't know scala, I think that there's a _big_ difference between a language that supports a style of programming which is functional except for its lack immutability and saying that a dynamically typed language supports static typing. Immutability is an important part of functional programming, but you can program functionally without having any immutability. But you seem to much more inclined to consider something pointless or useless if the compiler doesn't enforce it than most programmers are (e.g. const in C++). I'd argue that stuff like auto result = map!foo(filter!bar(range)); is most definitely functional even if there's no immutability involved at all. - Jonathan M Davis
Re: newsgroup web viewer
On 11/15/2011 11:37 PM, Andrei Alexandrescu wrote: That's why I like using twitter, as in the current draft. I fear we may find ourselves reinventing twitter by a great roundabout method.
Re: Website message overhaul
On 11/15/2011 10:55 PM, Peter Alexander wrote: Scala does support function purity (you can write pure functions) and immutable data (you can create data that you don't write to), it just doesn't statically check either of those things :-) That's like saying Python supports static typing, it just never checks it! As you say, you know few people that share your opinion, so is that an opinion we want to put forward on the front page? I don't think we should write "Scala is not a functional programming language" on the front page, or make any comments about other languages.
Re: Array slice assign syntax
This makes perfect sense to me as a new-comer, and having not had much
experience writing this sort of code, this is exactly how I would have
assumed it is now.
I would have been in for a confusing surprise had I tried to do any of this
stuff.
On 16 November 2011 05:24, bearophile wrote:
> The Bugzilla issues that I really care about is a not an useless long
> list, it's about fifteen items long, and this post is about one of them.
>
> I think current array slice assign syntax is a bit messy, and I think this
> should be addressed.
>
> Kenji Hara has recently written a very nice program (that here I have
> modified a bit for clarity) that shows the current array assign situation:
>
>
> import std.stdio, std.typetuple;
>
> void main() {
>writeln("Rhs is an array, is it compilable?");
>writeln("a\t/ b\t\ta=b\ta[]=b\ta=b[]\ta[]=b[]");
>
>foreach (i, Lhs; TypeTuple!(int[3], int[]))
>foreach (j, Rhs; TypeTuple!(int[3], int[])) {
>writef("%s\t/ %s ", Lhs.stringof, Rhs.stringof);
>Lhs a = [0,0,0];
>Rhs b = [1,2,3];
>writef("\t%s", __traits(compiles, { a = b; }));
>writef("\t%s", __traits(compiles, { a[] = b; }));
>writef("\t%s", __traits(compiles, { a = b[]; }));
>writef("\t%s", __traits(compiles, { a[] = b[]; }));
>writeln();
>}
>
>
>writeln("\nRhs is a element, is it compilable?");
>writeln("a\t\t\ta=N\ta[]=N\ta[0..2]=N");
>
>foreach (Lhs; TypeTuple!(int[3], int[])) {
>writef("%s\t\t", Lhs.stringof);
>Lhs a = [0,0,0];
>writef("\t%s", __traits(compiles, { a = 9; }));
>writef("\t%s", __traits(compiles, { a[] = 9; }));
>writef("\t%s", __traits(compiles, { a[0..2] = 9; }));
>writeln();
>}
> }
>
>
>
> Currently (DMD 2.057head, despite I think Walter has not updated DMD
> version number yet) it prints:
>
>
> Rhs is an array, is it compilable?
> a / b a=b a[]=b a=b[] a[]=b[]
> int[3u] / int[3u] truetruetruetrue
> int[3u] / int[] truetruetruetrue
> int[] / int[3u] truetruetruetrue
> int[] / int[] truetruetruetrue
>
> Rhs is a element, is it compilable?
> a a=N a[]=N a[0..2]=N
> int[3u] truetruetrue
> int[] false truetrue
>
>
>
> This also means this is currently accepted:
>
> void main() {
>int[3] a;
>a = 1;
>assert(a == [1, 1, 1]);
> }
>
>
> While this is not accepted:
>
> void main() {
>int[] b = new int[3];
>b = 1;
>assert(b == [1, 1, 1]); //Error: cannot implicitly convert expression
> (1) of type int to int[]
> }
>
>
>
> I'd like D to require a[]=1 in that first case too.
>
> I'd like the [] to be required every time an O(n) vector operation is
> done, for:
> - constancy with all other vector operations among two arrays, that
> require [];
> - and to avoid unwanted (and not easy to spot in the code) O(n) operations;
> - bugs and confusion in D newbies that don't have memorized all current
> special cases.
>
> On the other hand Don says that [] is only required for lvalues.
>
> I think this boils to a new table like this:
>
>
> Rhs is an array, is it compilable?
> a / b a=b a[]=b a=b[] a[]=b[]
> int[3u] / int[3u] FALSE trueFALSE true
> int[3u] / int[] FALSE trueFALSE true
> int[] / int[3u] FALSE trueFALSE true
> int[] / int[] truetruetruetrue
>
> Rhs is a element, is it compilable?
> a a=N a[]=N a[0..2]=N
> int[3u] FALSE truetrue
> int[] false truetrue
>
>
> Now if there's a [] on the left, then it's an O(n) vector operation (like
> a copy), otherwise it's O(1).
>
> That also means:
>
> void main() {
>int[] a = new int[3];
>int[] b = new int[3];
>a = b; // OK, copies just array fat reference
> }
>
> void main() {
>int[3] a, b;
>a = b; // Not OK, hidden vector op
> }
>
>
> I am not sure this new table is fully correct, but it's a start. Fixes of
> mistakes are welcomes.
>
> ---
>
> This is an alternative proposal.
>
> On the other hand this vector op syntax doesn't currently compile:
>
> void main() {
>int[3] a, b;
>a[] += b;
> }
>
>
> So if array assign is seen as a normal vector op, then the [] is needed on
> the right too:
>
>
> Rhs is an array, is it compilable?
> a / b a=b a[]=b a=b[] a[]=b[]
> int[3u] / int[3u] FALSE FALSE FALSE true
> int[3u] / int[] FALSE FALSE FALSE true
> int[] / int[3u] FALSE FALSE FALSE true
> int[] / int[] trueFALSE FALSE true
>
> Rhs is a element, is it compilable?
> a a=N a[]=N a[0..2]=N
> int[3u] FALSE truetrue
> int[]
