Re: What would you do... -> Extending std.concurrency
On Thu, Dec 8, 2011 at 7:12 PM, Sean Kelly wrote:
> On Dec 8, 2011, at 4:13 PM, Andrew Wiley wrote:
>>
>> This is somewhat of a threadjack, but I was looking at making a
>> lighter actor-like abstraction for message passing, and possibly
>> making it compatible with std.concurrency, and I saw this:
>> "The general idea is that every messageable entity is represented by a
>> common handle type (called a Cid in this implementation), which allows
>> messages to be sent to in-process threads, on-host processes, and
>> foreign-host processes using the same interface."
>>
>> As far as I can tell, Cid does not appear outside the documentation at
>> the top of std.concurrency, and Tid is a direct linkage to
>> std.concurrency's private mailbox implementation, so I was wondering
>> what the best way to extend message-passing functionality to another
>> type would be.
>
> Originally I'd thought that Tid would be process-local and we'd have a
> different type for external stuff, but that sacrifices a lot of the power of
> the actor model. However, I think everything can be handled by the one Tid
> type. The real trick is meshing the template-driven send() operation with
> different transport (and serialization) schemes, but I've become convinced
> that this can work. At some point a Node type will be added, and Nodes will
> have a transport interface. So calling send() on a Tid that contains a Node
> reference will serialize to the transport layer. If the Node reference is
> null then it will work as it does now. So what you'll ultimately want to do
> is provide a transport mechanism for the method you desire.
That would mean adding a reference to the Tid for every type we would
want to be able to send messages to. If you just look at Node types
and remote actors, that's not so bad, but what I'm looking towards is
lighter local actors, IE fiber based or closure based. The problem
with thread based actors is that you can really only spin up a few
thousand of them. Fibers get maybe an order of magnitude farther, but
closures can get into the millions by sacrificing stack-based state.
If anyone wants to try to implement more fine-grained concurrency
using the actor model, this quickly becomes necessary (heck, it's one
of the mainstays of Scala's standard library and the Akka library).
I think Tid is basically a wrapper around a MessageBox, and the
abstraction we actually want is much closer to MessageBox's public
API, something like:
interface Actor { void send(Message msg); }
The Message should probably also store some way of replying to it when
applicable, and there might be a way to get a Future of some sort when
sending a message so you could wait for the reply.
(And there would be a convenient templated way to make arbitrary types
into Messages - probably just a method in the Actor base class)
Actors are going to involve heap allocation anyway, and even with
remote actors, you'll probably wind up with some sort of proxy object
on the local system representing an actor or a set of actors somewhere
else, and it seems more natural to me to directly pass references
around and let polymorphism handle actually getting the message to its
destination.
One other detail that would need to change to support remote actors is
that right now you check hasLocalAliasing, which allows shared data.
If we're going to support remote actors, it needs to be hasAliasing
(which is even more fun because Variant currently can't handle
immutable types), and if you want to continue to support sending
shared data locally, we have to define a notion of a LocalMessage as
well as Message (where LocalMessage would still use hasLocalAliasing
and Message could implicitly convert to LocalMessage).
Re: SCons support for D
On Fri, 09 Dec 2011 09:28:52 +0900 Mike Parker wrote: > Not out of the box, but it would be trivial to add as a custom Action. Thank you. All in all, premake looks very interesting & clean. Sincerely, Gour -- Bewildered by the modes of material nature, the ignorant fully engage themselves in material activities and become attached. But the wise should not unsettle them, although these duties are inferior due to the performers' lack of knowledge. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: Comma operator = broken design
On Thursday, 8 December 2011 at 17:18:57 UTC, Joshua Reusch wrote:
Ahem. So are you suggesting that (a,b) means a tuple
everywhere but in a
for loop, where it is used to separate two statements?
If we use the comma operator only for tuples, there needn't to
be a special case for loops:
for(x, y = 0 , 100; x < y ; x, y += 1,-1) { ... }
for(int x, y = 0 , 100; x < y ; x, y += 1,-1) { ... }
?
Re: Comma operator = broken design
On Fri, 09 Dec 2011 06:26:27 +0200, Robert Jacques wrote: So it clashes with another thing about D, pragmatism. I'm not sure what you mean by that. It was/is one of the defining points of D AFAIK. More than being theoretical it chose to be pragmatic, to solve the problems we face day to day. For the case at hand; Say uninitialized variables in C are undefined but all the compilers do the same thing that makes it in practice defined. So the below line should execute same on all compilers. type a; Same applies to the extensions supported in all major compilers which is absent in language spec. If compilers don't support, they can't sell. To the point. If you want to keep B-D rule with the presence of such big design mistakes (C), you are not being pragmatic at all.
Re: ow Integers Should Work
On 12/08/2011 04:15 AM, Don wrote: On 08.12.2011 05:46, bcs wrote: On 12/06/2011 11:50 PM, Don wrote: He's talking about system languages. A system language has to have a close relationship to the architecture. By contrast, if you don't care about performance, it's easy -- just use BigInts for everything. Problem solved. Looks like I have to put it more bluntly: I don't think he knows what he's talking about. (On this particular topic). I know exactly what you have been saying I just think you are wrong, not because I don't think you knows what you are talking about but because I think you are evaluating his conclusion based on a different criteria than he is. HE PROPOSES CHANGING INSTRUCTION SETS. [citation needed] I just re-scanned both posts. The closest thing I found to suggesting that instruction sets be changed is proposing iNaN be used and that (if you scan futher up) is listed as one possibility (late trapping) along side another (early trapping) that (if you scan even further up) isn't even being suggested for every operation but only for non-intermediate values. More specifically, I think we are dealing with a differing order of priories for system languages. Mine would put safety (i.e. NO undefined behaviour) over performance. I think he is going the same way. Personally, if I could only have one, I think I'd (first) go with defining overflow semantics rather than trapping but I'm not sure which is more useful in a systems context. Can we at least agree that if you are only going to have one signed integer semantic, that undefined overflow is the worst possible choice? Yes, but D doesn't have undefined overflow. So it's irrelevant. I'm not talking about D. Well, not directly anyway. So that irrelevant. And I think we have concluded that there isn't a single bit of this back and forth that we both care about.
Re: Comma operator = broken design
On Thu, 08 Dec 2011 21:23:11 -0500, so wrote: On Fri, 09 Dec 2011 03:19:34 +0200, Robert Jacques wrote: On Thu, 08 Dec 2011 13:17:44 -0500, so wrote: On Thu, 08 Dec 2011 19:25:10 +0200, Dejan Lekic wrote: type a = a + 2; // compiles with no errors, no warnings, no explosions (that i know of) If "type" has the default initialiser, then what is the problem? What does it do in both C and D context? 1. It does different things. 2. C version even worse because of debug/release difference. 3. If D still does this, it violates the B-D rule (either does the same thing or doesn't compile at all. Actually there are many things violate this rule...) type a; // even this simple code violates B-D rule. What is the use case? . Is there any? . If there is not any you think, but still compiler allows it, it generates nothing but bugs (from experience :) ). Question should be, why does it exist at all? Actually, these statements don't violate the B-D rule. In C/C++ the value of 'a' prior to use is implementation defined (i.e. it is undefined by the spec) and in practice tends to be some random stack value. D just sets that value to a consistent default, which is completely compliant with the C spec. I disagree. As you said while in C/C++ same thing gets assigned random values, in D it doesn't. As a result, it changes both the coders' expectations and programs outcome. Even the definitions are different. Undefined there and defined here. I am not sure how to express this. As far as i understand you are saying; Because uninitialized variables are undefined in C, D can act as another C compiler and interpret this rule as it pleases. But in practice no compiler i know does that. In a discussion about language specifications, practical implementation details seem tangential to me. Besides, many C++ compilers do set variables to a default bit pattern in debug mode, in order to better detect and account for uninitialized variables. D's major difference is that it also does this in release mode. Besides, strictly speaking, the B-D rule is about valid, portable C/C++ code, which (arguably) isn't anything that uses uninitialized variables. In other words, the B-D rule isn't about D mimicking the behavior of a particular C/C++ compiler, it's about the C spec. And "assuming the variable initialized to some value" is a bad programming practice, which i should say the most popular among its kind. I totally agree, from a normal control flow perspective. But .init has many uses, particularly in error detection and and repeatability of .init greatly eases debugging. So it clashes with another thing about D, pragmatism. I'm not sure what you mean by that.
Re: Comma operator = broken design
On Fri, 09 Dec 2011 03:19:34 +0200, Robert Jacques wrote: On Thu, 08 Dec 2011 13:17:44 -0500, so wrote: On Thu, 08 Dec 2011 19:25:10 +0200, Dejan Lekic wrote: type a = a + 2; // compiles with no errors, no warnings, no explosions (that i know of) If "type" has the default initialiser, then what is the problem? What does it do in both C and D context? 1. It does different things. 2. C version even worse because of debug/release difference. 3. If D still does this, it violates the B-D rule (either does the same thing or doesn't compile at all. Actually there are many things violate this rule...) type a; // even this simple code violates B-D rule. What is the use case? . Is there any? . If there is not any you think, but still compiler allows it, it generates nothing but bugs (from experience :) ). Question should be, why does it exist at all? Actually, these statements don't violate the B-D rule. In C/C++ the value of 'a' prior to use is implementation defined (i.e. it is undefined by the spec) and in practice tends to be some random stack value. D just sets that value to a consistent default, which is completely compliant with the C spec. I disagree. As you said while in C/C++ same thing gets assigned random values, in D it doesn't. As a result, it changes both the coders' expectations and programs outcome. Even the definitions are different. Undefined there and defined here. I am not sure how to express this. As far as i understand you are saying; Because uninitialized variables are undefined in C, D can act as another C compiler and interpret this rule as it pleases. But in practice no compiler i know does that. And "assuming the variable initialized to some value" is a bad programming practice, which i should say the most popular among its kind. So it clashes with another thing about D, pragmatism.
Re: On garbage collection
deadalnix wrote: http://www.infoq.com/presentations/Understanding-Java-Garbage-Collection This is java focussed, but I think this is still very interesting for D people. So I'm sharing it here. The first half wasn't even java focussed at all :-) Great intro to most of the definitions and GC algorithms in use today.
Re: Comma operator = broken design
On Thu, 08 Dec 2011 13:17:44 -0500, so wrote: On Thu, 08 Dec 2011 19:25:10 +0200, Dejan Lekic wrote: type a = a + 2; // compiles with no errors, no warnings, no explosions (that i know of) If "type" has the default initialiser, then what is the problem? What does it do in both C and D context? 1. It does different things. 2. C version even worse because of debug/release difference. 3. If D still does this, it violates the B-D rule (either does the same thing or doesn't compile at all. Actually there are many things violate this rule...) type a; // even this simple code violates B-D rule. What is the use case? . Is there any? . If there is not any you think, but still compiler allows it, it generates nothing but bugs (from experience :) ). Question should be, why does it exist at all? Actually, these statements don't violate the B-D rule. In C/C++ the value of 'a' prior to use is implementation defined (i.e. it is undefined by the spec) and in practice tends to be some random stack value. D just sets that value to a consistent default, which is completely compliant with the C spec.
Re: Comma operator = broken design
On Thu, 08 Dec 2011 12:18:56 -0500, Joshua Reusch wrote:>
Ahem. So are you suggesting that (a,b) means a tuple everywhere but in a
for loop, where it is used to separate two statements?
If we use the comma operator only for tuples, there needn't to be a
special case for loops:
for(x, y = 0 , 100; x < y ; x, y += 1,-1) { ... }
Clever! However,
1) Showing that the trivial example can be expressed with tuples is a good
first step. The next step is to go after some of the advanced comma usages.
i.e. What's the limitations of this approach? When does it break down?
2) As per the current tuple proposals, the above is a horrendous performance
sink. Granted, more tuple awareness in the compiler might fix the problem, but
that awareness is more than what's in the current tuple proposals.
Re: What would you do...
On Dec 8, 2011, at 4:13 PM, Andrew Wiley wrote: > > This is somewhat of a threadjack, but I was looking at making a > lighter actor-like abstraction for message passing, and possibly > making it compatible with std.concurrency, and I saw this: > "The general idea is that every messageable entity is represented by a > common handle type (called a Cid in this implementation), which allows > messages to be sent to in-process threads, on-host processes, and > foreign-host processes using the same interface." > > As far as I can tell, Cid does not appear outside the documentation at > the top of std.concurrency, and Tid is a direct linkage to > std.concurrency's private mailbox implementation, so I was wondering > what the best way to extend message-passing functionality to another > type would be. Originally I'd thought that Tid would be process-local and we'd have a different type for external stuff, but that sacrifices a lot of the power of the actor model. However, I think everything can be handled by the one Tid type. The real trick is meshing the template-driven send() operation with different transport (and serialization) schemes, but I've become convinced that this can work. At some point a Node type will be added, and Nodes will have a transport interface. So calling send() on a Tid that contains a Node reference will serialize to the transport layer. If the Node reference is null then it will work as it does now. So what you'll ultimately want to do is provide a transport mechanism for the method you desire.
Re: Chinese characters printing issue under windows
Bernard Helyer Wrote: > This is very useful information, so thank you for posting it, but > this looks like something that Phobos should pick up > automatically. I would note that the program works perfectly in > Linux without the need for setting the locale, so I'd imagine its > some encoding issue? Not really my area of expertise. I seeked help here years ago and many of my friends who are D fans as well have been struggled of this issue so many years but still there is no pure D way to cope with it.Win32 API is the only choice.This time one of my friend posted this in local D forum so we would like to share with everyone.
Re: Chinese characters printing issue under windows
On Friday, 9 December 2011 at 00:51:35 UTC, Sam Hu wrote:
For those who would like to print Chinese characters in windows
console properly,below information for your easy reference.
After test,write works properly all the way,writeln only works
properly when the args is no less than 2.writefln works
properly all the way.
[code]
module cnsetlocale;
import core.stdc.wchar_;
import core.stdc.locale;
import std.stdio;
import std.string;
import std.conv;
extern(C) int setlocale(int, char*);
static this() {
fwide(core.stdc.stdio.stdout, 1);
setlocale(0, cast(char*)"china"); }
int main(string[]
args)
{
printf("你好DMD2！！\n");
writefln("%s","你好DMD2！！");
string msg="你好DMD2！！";
string msg1="很好很好的同学";
string msg2="大大的了不起！";
writefln("the string is %s",msg);
writefln("the string is %s \n %s\n%s
and\n%s",msg,msg1,msg2,"很牛很牛");
readln;
return 0;
}
[/code]
printf("%.s\n",cnStr) works as well while printf(cnStr) does not.
Re-format the sample code:
module cnsetlocale;
import core.stdc.wchar_;
import core.stdc.locale;
import std.stdio;
import std.string;
import std.conv;
extern(C) int setlocale(int, char*); static this() {
fwide(core.stdc.stdio.stdout, 1);
setlocale(0, cast(char*)"china"); } int main(string[]
args)
{
printf("%*.s\n","你好DMD2！！\n");
write("你好DMD2！！\n");
writefln("%s","你好DMD2！！");
string msg="你好DMD2！！";
string msg1="很好很好的同学";
string msg2="大大的了不起！";
writefln("the string is %s",msg);
writefln("the string is %s \n %s\n%s
and\n%s",msg,msg1,msg2,"很牛很牛");
readln;
return 0;
}
Re: Haxe (From: Java > Scala -> new thread: GUI for D)
"Danny Wilson" wrote in message news:jbrjp6$n54$1...@digitalmars.com... > Nick Sabalausky wrote: > >> So anyway, with my own Haxe implementation, I can just add an optional >> "-sane" switch to enable either a runtime or compile-time check...And >> nobody >> can stop me!! Mwuuahahahaha!! AH HA HA HA!!! BWAH HA HA HA!@!!! >> > > HAHhahahaAHHAAHA - As a long time haXe user I appreciate this! :D > Heh :) > But, have you looked at the new haXe macro output feature?: > http://haxe.org/api/haxe/macro/jsgenapi > > You could write a D generator macro which acts as a JS target. Probably > alot less work too. > I'm happy with the progress I'm making so far on with my approach, but that is an interesting idea. > I find it unfortunate D -> haXe is so complex, as I'd much rather write my > code in D. If only D was as multiplatform as haXe... :-( Yes, me too. Definitely. I would still like to get around to that sometime. This Haxe->D will probably help give me some good language converstion experience, though.
Re: Chinese characters printing issue under windows
This is very useful information, so thank you for posting it, but this looks like something that Phobos should pick up automatically. I would note that the program works perfectly in Linux without the need for setting the locale, so I'd imagine its some encoding issue? Not really my area of expertise.
Chinese characters printing issue under windows
For those who would like to print Chinese characters in windows
console properly,below information for your easy reference.
After test,write works properly all the way,writeln only works
properly when the args is no less than 2.writefln works properly
all the way.
[code]
module cnsetlocale;
import core.stdc.wchar_;
import core.stdc.locale;
import std.stdio;
import std.string;
import std.conv;
extern(C) int setlocale(int, char*); static this() {
fwide(core.stdc.stdio.stdout, 1);
setlocale(0, cast(char*)"china"); } int main(string[]
args)
{
printf("你好DMD2！！\n");
writefln("%s","你好DMD2！！");
string msg="你好DMD2！！";
string msg1="很好很好的同学";
string msg2="大大的了不起！";
writefln("the string is %s",msg);
writefln("the string is %s \n %s\n%s
and\n%s",msg,msg1,msg2,"很牛很牛");
readln;
return 0;
}
[/code]
Re: SCons support for D
On 12/9/2011 2:04 AM, Gour wrote: On Thu, 8 Dec 2011 20:13:29 +1100 Andrew Gough wrote: I have to point out that I have only added DMD+make support as that is all I needed at the time, but have plans (who doesn't :-D) to add support for LDC, GDC, and other build chains. Does premake support building SWIG extensions? Sincerely, Gour Not out of the box, but it would be trivial to add as a custom Action.
Re: Haxe (From: Java > Scala -> new thread: GUI for D)
Nick Sabalausky wrote: So anyway, with my own Haxe implementation, I can just add an optional "-sane" switch to enable either a runtime or compile-time check...And nobody can stop me!! Mwuuahahahaha!! AH HA HA HA!!! BWAH HA HA HA!@!!! HAHhahahaAHHAAHA - As a long time haXe user I appreciate this! :D But, have you looked at the new haXe macro output feature?: http://haxe.org/api/haxe/macro/jsgenapi You could write a D generator macro which acts as a JS target. Probably alot less work too. I find it unfortunate D -> haXe is so complex, as I'd much rather write my code in D. If only D was as multiplatform as haXe... :-(
Re: What would you do...
On Thu, Dec 8, 2011 at 5:53 PM, Sean Kelly wrote: > On Dec 8, 2011, at 8:23 AM, Manu wrote: >> >> Just digging through concurrence.d since the docs are pretty bare, and I've >> come across this pattern, which raises a pretty worrying alarm to me. I >> wonder if this is common in D libraries... >> >> ... >> >> No overload, receives a tuple, and assumes that static-if the first tuple >> item is IMPLICITLY CONVERTIBLE to a Duration, I must be calling the >> 'overload'... >> >> I guess this means I can never pass a Duration in a message to the >> non-timeout receive()... or anything that is implicitly convertible to a >> Duration. > > Right. The only thing you can pass to receive() are functions taking one or > more parameters. mbox.get() itself is actually pretty lax in enforcing this > because it relies on the caller to do most of the filtering (via checkops). > This should be safe since the mbox itself is private. I suppose I could have > done this a different way, but overloading when one function has (T…) args is > a bit weird. > > >> This would seem to be a very obscure hidden bug to me. Is this a common >> pattern in D? > > It's probably the only case. > > >> I certainly wouldn't want to be tracking down this bug on build night... Is >> there something I've missed here? Some sort of safeguard I've overlooked? > > See above. MessageBox is private and receive() does the parameter checking. This is somewhat of a threadjack, but I was looking at making a lighter actor-like abstraction for message passing, and possibly making it compatible with std.concurrency, and I saw this: "The general idea is that every messageable entity is represented by a common handle type (called a Cid in this implementation), which allows messages to be sent to in-process threads, on-host processes, and foreign-host processes using the same interface." As far as I can tell, Cid does not appear outside the documentation at the top of std.concurrency, and Tid is a direct linkage to std.concurrency's private mailbox implementation, so I was wondering what the best way to extend message-passing functionality to another type would be.
Re: What would you do...
On 12/09/2011 12:21 AM, Manu wrote:
No overload, receives a tuple, and assumes that static-if the first
tuple item is IMPLICITLY CONVERTIBLE to a Duration, I must be
calling
the 'overload'...
I guess this means I can never pass a Duration in a message to the
non-timeout receive()... or anything that is implicitly
convertible to a
Duration.
Sure, receive cannot be called with duration. You pass callbacks to
it, not Durations. Callbacks are never implicitly convertible to
Durations, so that is fine.
Ah crap, I DID miss the magic detail in checkops() you mentioned below.
That clears it up.
However I still feel this construct is quite dangerous. I'm looking at
it from a programming 'pattern' point of view rather than the details of
this case specifically. I don't know if I've illustrated my concern
clearly though...
This would seem to be a very obscure hidden bug to me. Is this a common
pattern in D?
I don't see a 'pattern'.
I refer to the concept ('pattern' if you will) of receiving a tuple of
args, and then comparing the first as a specific type instead of using a
function overload.
That could be useful in many different contexts, some more clean than
this one.
ie. in this example with the optional first Duration parameter, but with
the assumption that the following parameters may be of any type. This
'pattern' may lead to a bug where if the first Duration parameter were
not desired, but the second parameter happened to be any type that
implicitly converted to a Duration, then the wrong code path could be
taken without the programmers knowledge... I hope that makes sense. :/
Well, it cannot be taken. And how it works exactly is an implementation
detail of std.concurrency. The bug you are talking about does not exist.
So I don't quite follow. I agree that maybe using an explicit boolean
template parameter to distinguish the two cases would be cleaner, and
that is how I usually handle that kind of code reuse.
I certainly wouldn't want to be tracking down this bug on build
night... Is there something I've missed here? Some sort of safeguard
I've overlooked?
Have a look at the checkops template. It catches your case.
I just saw it contains another bug though:
static assert( is( t1 == function ) || is( t1 == delegate ) );
Obviously, the writer meant to check for function pointers and
delegates. This is not what it does. Borken. I think the language
should be fixed here.
I can't see the problem >_<
It certainly is, but 'is' expressions still need some fixing. The code
currently tests whether or nor t1 is a function type or a delegate type.
However, it looks like it should test for function pointer or delegate.
I'd like that fixed, but it is a breaking language change...
I must confess, I'm finding some D code I look at REALLY hard to
follow... like this code for instance (mbox.get()). Granted, I'm not yet
very good at reading D code, which often appears nothing at all like
C/C++, but I'm hoping the language is overall a /simplification/ over
C/C++ ;)
Note that since the language is simpler, the bar of what you can
actually reasonably well do with it is higher. Equivalent C++ code would
likely be harder to follow.
Re: What would you do...
On Dec 8, 2011, at 8:23 AM, Manu wrote: > > Just digging through concurrence.d since the docs are pretty bare, and I've > come across this pattern, which raises a pretty worrying alarm to me. I > wonder if this is common in D libraries... > > ... > > No overload, receives a tuple, and assumes that static-if the first tuple > item is IMPLICITLY CONVERTIBLE to a Duration, I must be calling the > 'overload'... > > I guess this means I can never pass a Duration in a message to the > non-timeout receive()... or anything that is implicitly convertible to a > Duration. Right. The only thing you can pass to receive() are functions taking one or more parameters. mbox.get() itself is actually pretty lax in enforcing this because it relies on the caller to do most of the filtering (via checkops). This should be safe since the mbox itself is private. I suppose I could have done this a different way, but overloading when one function has (T…) args is a bit weird. > This would seem to be a very obscure hidden bug to me. Is this a common > pattern in D? It's probably the only case. > I certainly wouldn't want to be tracking down this bug on build night... Is > there something I've missed here? Some sort of safeguard I've overlooked? See above. MessageBox is private and receive() does the parameter checking.
Re: What would you do...
On Dec 8, 2011, at 7:51 AM, Manu wrote: > > The std.concurrency documentation is pretty bad. > So is std.concurrency.spawn() just effectively a helper for spawning a thread > that has mailbox support? Yes. Plus some restrictions on arguments to the new thread to help prevent data races. > std.concurrency.receive() has no documentation ;) .. Blocking/Non-blocking? > Should I use the one with duration==0 to do a poll? Perhaps there should be > an explicit poll() method? > What is prioritySend()? (also undocumented) This is my fault. I suppose I should do something about this for the next release. Priority messages basically live in a separate message queue. When receive is called, if the priority queue is non-empty then the receive() pattern is applied to that. If that receive() call can't handle one of the priority messages an exception is thrown. So long as the priority queue remains empty, receive() will block until a message arrives that it can handle. If you want non-blocking behavior then call receiveTimeout() instead.
Re: What would you do...
On Dec 8, 2011, at 6:00 AM, Manu wrote: > > Quite seriously. I'm trying to work out how D's threading/thread safety > architecture can help me here.. Also since there's no collections, I'm using > the associative arrays. How do I manage thread safety when accessing those? > Is there a generic lock mechanism that I've missed along the way without > manually creating semaphores? Networking does seem to be pretty bare, I'm > basically writing C sockets code. That's really the issue more than threading. Socket programming support is rather weak in Phobos so any serious network programming falls back on C API calls. And typically you'll se some async IO method and not much in the way of threading. I've thought about integrating socket IO with the messaging system in std.concurrency, but there are issues with supporting both Windows (IOCP/proactor) and non-Windows (poll/reactor) systems as invisibly as possible. There are also weird issues that arise when ownership of sockets is passed between threads, which you'll find mention of if you look into socket programming in Erlang. Longer term what I'd like is to have a standalone networking API (std.net or whatever) plus a shim to integrate it with the messaging API for people who want this level of simplicity, but it's not something I'd want to force on people.
Re: What would you do...
>
> No overload, receives a tuple, and assumes that static-if the first
>> tuple item is IMPLICITLY CONVERTIBLE to a Duration, I must be calling
>> the 'overload'...
>>
>> I guess this means I can never pass a Duration in a message to the
>> non-timeout receive()... or anything that is implicitly convertible to a
>> Duration.
>>
>
> Sure, receive cannot be called with duration. You pass callbacks to it,
> not Durations. Callbacks are never implicitly convertible to Durations, so
> that is fine.
Ah crap, I DID miss the magic detail in checkops() you mentioned below.
That clears it up.
However I still feel this construct is quite dangerous. I'm looking at it
from a programming 'pattern' point of view rather than the details of this
case specifically. I don't know if I've illustrated my concern clearly
though...
> This would seem to be a very obscure hidden bug to me. Is this a common
> pattern in D?
>
I don't see a 'pattern'.
I refer to the concept ('pattern' if you will) of receiving a tuple of
args, and then comparing the first as a specific type instead of using a
function overload.
ie. in this example with the optional first Duration parameter, but with
the assumption that the following parameters may be of any type. This
'pattern' may lead to a bug where if the first Duration parameter were not
desired, but the second parameter happened to be any type that implicitly
converted to a Duration, then the wrong code path could be taken without
the programmers knowledge... I hope that makes sense. :/
> I certainly wouldn't want to be tracking down this bug on build
>> night... Is there something I've missed here? Some sort of safeguard
>> I've overlooked?
>>
>
> Have a look at the checkops template. It catches your case.
> I just saw it contains another bug though:
>
> static assert( is( t1 == function ) || is( t1 == delegate ) );
>
> Obviously, the writer meant to check for function pointers and delegates.
> This is not what it does. Borken. I think the language should be fixed here.
>
I can't see the problem >_<
I must confess, I'm finding some D code I look at REALLY hard to follow...
like this code for instance (mbox.get()). Granted, I'm not yet very good at
reading D code, which often appears nothing at all like C/C++, but I'm
hoping the language is overall a *simplification* over C/C++ ;)
Re: DMD 2.056 cannot find -lrt
On Thu, 08 Dec 2011 17:02:24 +0100, Steve Teale wrote: On Thu, 08 Dec 2011 07:18:48 -0500, Steven Schveighoffer wrote: On Thu, 08 Dec 2011 03:25:23 -0500, Steve Teale wrote: I just got round to upgrading from 2.055. I read about this error some time ago but now can't find a reference anywhere. What do I do to get round it. Install librt? Unfortunately, the solution settled on for 2.056 is to put -lrt in dmd's source code, so it cannot be removed. Curious, what Linux OS are you using? I was under the impression that they all had librt installed by default. -Steve OK, fixed that - I'd been under the erroneous impression that librt was a D thing, and had purged that along with the numerous versions of libphobos2.a that were lurking around on my system. I put librt.a and the librt.so symlinks back, and hello.d now compiles and links. However the CodeBlocks setup that I had for my current DB project is now complaining that it can't find _tlsstart, _tlsend, _deh_beg, and _deh_end. These appear to be C functions - do you happen to know if they are in librt? Steve These symbols only get pulled in with D's main function.
Re: How to stop DMD from linking against phobos
On Thu, 08 Dec 2011 18:50:36 +0100, Benjamin Thaut wrote: Is there a way to stop dmd from linking against phobos? (Most preferred would be some command line parameters to dmd) Kind Regards Benjamin Thaut We should fix defaultlib and debuglib to accept empty values. Can you make a bug report for it. Currently you can call 'dmd ... -v' to see the linker (gcc) call, then you could repeat this step without -lphobos2.
Re: A new web newsreader
Beautiful newsgroup reader, makes a forum obselute but I am against making features only available on the web interface. Maybe smileys and code tags but no further then that.
Re: DustMite: Unwrap? Imports?
On Thursday, 8 December 2011 at 21:39:20 UTC, dsimcha wrote: I've recently started using DustMite to reduce compiler errors in SciD, which instantiates an insane number of templates and is nightmarish to reduce by hand. Two questions: 1. What exactly does unwrap (as opposed to remove) do? Unwrap is a reduction operation which tries replacing a node with its children. It will remove redundant parens and braces, for example. 2. When there are multiple imports in a single statement, i.e. "import foo, bar;", does DustMite try to get rid of individual ones without deleting the whole statement? Yes, but it can't remove the first (or the last, I forgot) item in a comma-separated list. This is because the internal representation has no notions of token-separated lists. It's a long-standing complicated problem. Is this what unwrap does? No.
DustMite: Unwrap? Imports?
I've recently started using DustMite to reduce compiler errors in SciD, which instantiates an insane number of templates and is nightmarish to reduce by hand. Two questions: 1. What exactly does unwrap (as opposed to remove) do? 2. When there are multiple imports in a single statement, i.e. "import foo, bar;", does DustMite try to get rid of individual ones without deleting the whole statement? Is this what unwrap does?
Re: A new web newsreader
On 12/8/2011 6:12 AM, Andrej Mitrovic wrote: Still, I love how fast it is. And it's written in D?! Sweet! If this were integrated to dpl.org it would kick the balls out of all the other proggy sites. Yes! I also think this forum software will be highly desirable for others to use, and can be a showcase for what D programming can do.
Re: A new web newsreader
On 12/8/2011 7:05 AM, Robert Clipsham wrote: I'm not very excited about the idea of introducing formatting features that only users of this web interface will see. Frequent use of such features would annoy users of other interfaces, and there's the risk of accidentally activating them. I've seen quite a few people using it for code snippets anyway, and it's only a minor thing - I wouldn't want to go any further and allow for bold/italic/smileys/etc. Accidentally activating them would be a problem, I think that's a minor risk for this though. Not a major thing, just something I've always wanted to see ;) I agree to not do this.
Re: A new web newsreader
On Thursday, 8 December 2011 at 20:15:38 UTC, Andrei Alexandrescu wrote: This is an absolutely fantastic development. It's exactly the kind of thing that D needs - using D to write something nontrivial and highly useful. I just got in touch with Walter about it, and as of now you have in us strong supporters for replacing the existing Web bridge with this one. I'm excited :) One thing though - you must use hyphenation everywhere :o). Now not so much :( :) Here are a few large topics that we should discuss a bit: - Would you consider merging your codebase with d-programming-language.org? That way we'd have a simple deployment target and simpler unified maintenance. I'm not against moving the project to the D-Programming-Language GitHub organization, but I'm not sure what would be achieved by merging the two git repositories. Git's "submodule" feature may be more helpful here. One thing that needs to be mentioned is that the project's scope is not solely the web interface. "DFeed" actually started out as an IRC bot, which among other sources, included the newsgroup as an event source for IRC notifications. I've refactored the code to use a publish/subscribe pattern, so IRC and the local message database (used by the web interface) are two of the consumers. A third one will be the front-page news widget I was planning to have a go at. The downside would be that your project would have less individuality as an independent NNTP-WWW bridge. (That could be partially addressed with directory structure etc.) This is actually not much of a problem right now, as the codebase wasn't written with much abstraction in mind, so refactoring it into a generic NNTP interface would be a task of its own (and probably better off as a fork of this project). - If not, how do we go about integrating with d-programming-language.org? For example say we change the navigation panel on the left. Then we'd need to coordinate with you to pull the code, regenerate your own page, and so on. This can be automated... Also, I'm not against the idea of providing direct shell access for D VIPs. - I'm thinking something with iframes may work for the above issue, but cross-domain iframes are limited. Could we serve your content off d-p-l.org? Yes. By far the best method would be subdomains (e.g. forum.d-programming-language.org or discussion.d-p-l.org). The second-best method is to use Apache's mod_proxy or mod_rewrite's [P] flag, to make a certain "directory" send web requests to my server. This would greatly affect latency, though - assuming d-p-l.org is hosted in the US, a request from an European visitor would need to make a roundtrip through the US and back to Europe, and back. Frames are not much of an option, due to their non-interoperability with browser address bars. - We should look at ways to integrate some of your code with the standard library. For example, would be great to put some NNTP and CGI support in std. I don't use CGI. The NNTP module implements little above what's needed for the task. There may be some code good enough for Phobos in the network library I use (asynchronous line-buffered sockets, HTTP client/server), but there are licensing issues I'd need to solve. My nits to be added to others': * Registration flow is odd. You register, but then you're not taken back to the forums page. It's a bug. I'll fix. * Password during registration appears in clear. That was a deliberate choice... perhaps not a very good one. * The C and C++ forums should not be on the same page. We should focus only on the D forums. It's possible to link them via a new page. Yes. I was thinking about creating a digitalmars.com stylesheet, and sending the corresponding stylesheet and list of forums depending on the used URL / subdomain. * This may be a good time to retire a few unused forums such as dtl., debugger, dwt, ide, and merge their contents with digitalmars.D. I'm not sure if merging groups is possible on the NNTP level. Doing it in DFeed would involve lots of hacks. * The forum descriptions and possibly layout should emphasize digitalmars.D as the "main" forum, and digitalmars.D.learn as the "main n00b" forum. Generally first-comers will be confused as to where they should be posting when facing a large table that must be read in full, and most of the time they want either digitalmars.D or digitalmars.D.learn. * The lists dmd-beta etc. should be under a different heading and deemphasized. They are for experts only and not nearly as prominent as the main forums. The layout is actually almost a verbatim copy of http://digitalmars.com/NewsGroup.html . The only change is a typo fix and addition of the omitted D-runtime list. * The style file should be loaded from d-p-l.org such that changes in style will be automatically picked up by the forums page. I edited the main stylesheet to avoid yet another few !important CSS over
Re: A new web newsreader
On Thu, 08 Dec 2011 15:15:37 -0500, Andrei Alexandrescu wrote: - Would you consider merging your codebase with d-programming-language.org? That way we'd have a simple deployment target and simpler unified maintenance. The downside would be that your project would have less individuality as an independent NNTP-WWW bridge. (That could be partially addressed with directory structure etc.) Hm... I don't understand the objection to having the project live on its own github repository. It's not part of the documentation, but rather a separate piece of code that lives on the same server. For example, I wouldn't expect the web newsreader to be downloaded in the zipfile. Yes the navigation has to be updated, but I would concentrate more on making the navigation/header/footer independent of the forum code (if it isn't already). -Steve
Re: A new web newsreader
On 2011-12-08 21:15, Andrei Alexandrescu wrote: On 12/8/11 4:55 AM, Vladimir Panteleev wrote: As mentioned previously, I've been working on a web frontend for the DigitalMars NNTP server. I collected ideas and inspiration from the several threads on this topic in the last few weeks, and now I think that the result is ready for beta testing and general use. The current (temporary) URL is: http://dfeed.kimsufi.thecybershadow.net/discussion/ This is an absolutely fantastic development. It's exactly the kind of thing that D needs - using D to write something nontrivial and highly useful. I just got in touch with Walter about it, and as of now you have in us strong supporters for replacing the existing Web bridge with this one. One thing though - you must use hyphenation everywhere :o). Here are a few large topics that we should discuss a bit: - Would you consider merging your codebase with d-programming-language.org? That way we'd have a simple deployment target and simpler unified maintenance. The downside would be that your project would have less individuality as an independent NNTP-WWW bridge. (That could be partially addressed with directory structure etc.) - If not, how do we go about integrating with d-programming-language.org? For example say we change the navigation panel on the left. Then we'd need to coordinate with you to pull the code, regenerate your own page, and so on. Perhaps as a git submodule in d-programming-language.org? Dfeed would change to only render the actual feed and somehow it gets included in the regular site. I'm not entirely sure how since the whole d-p-l.org site is rendered using ddoc. -- /Jacob Carlborg
Re: A new web newsreader
On 2011-12-08 21:14, Vladimir Panteleev wrote: On Thursday, 8 December 2011 at 19:58:11 UTC, Jacob Carlborg wrote: On 2011-12-08 18:49, Vladimir Panteleev wrote: On Thursday, 8 December 2011 at 17:42:09 UTC, Jacob Carlborg wrote: On 2011-12-08 15:41, Vladimir Panteleev wrote: The "threaded" view mode should look the best on small screens. Yes, but try adding the following meta tag: OK, how does it look now? Horribly broken, sorry, remove it. I was hoping the above would be a quick fix but I think a new CSS file would be needed. Don't spend time on creating a new CSS file for me, I'm fine using Thunderbird. OK. I don't have a smartphone, but if I get the chance I'll have a look at some possible simple fixes. You can download a simulator, from the Android SDK or the iOS SDK. The iOS SDK requires a Mac. The simulator in Android SDK is extremely slow. -- /Jacob Carlborg
Re: A new web newsreader
On 12/8/11 4:55 AM, Vladimir Panteleev wrote: As mentioned previously, I've been working on a web frontend for the DigitalMars NNTP server. I collected ideas and inspiration from the several threads on this topic in the last few weeks, and now I think that the result is ready for beta testing and general use. The current (temporary) URL is: http://dfeed.kimsufi.thecybershadow.net/discussion/ This is an absolutely fantastic development. It's exactly the kind of thing that D needs - using D to write something nontrivial and highly useful. I just got in touch with Walter about it, and as of now you have in us strong supporters for replacing the existing Web bridge with this one. One thing though - you must use hyphenation everywhere :o). Here are a few large topics that we should discuss a bit: - Would you consider merging your codebase with d-programming-language.org? That way we'd have a simple deployment target and simpler unified maintenance. The downside would be that your project would have less individuality as an independent NNTP-WWW bridge. (That could be partially addressed with directory structure etc.) - If not, how do we go about integrating with d-programming-language.org? For example say we change the navigation panel on the left. Then we'd need to coordinate with you to pull the code, regenerate your own page, and so on. - I'm thinking something with iframes may work for the above issue, but cross-domain iframes are limited. Could we serve your content off d-p-l.org? My nits to be added to others': * Registration flow is odd. You register, but then you're not taken back to the forums page. * Password during registration appears in clear. * The C and C++ forums should not be on the same page. We should focus only on the D forums. It's possible to link them via a new page. * This may be a good time to retire a few unused forums such as dtl., debugger, dwt, ide, and merge their contents with digitalmars.D. * The forum descriptions and possibly layout should emphasize digitalmars.D as the "main" forum, and digitalmars.D.learn as the "main n00b" forum. Generally first-comers will be confused as to where they should be posting when facing a large table that must be read in full, and most of the time they want either digitalmars.D or digitalmars.D.learn. * The lists dmd-beta etc. should be under a different heading and deemphasized. They are for experts only and not nearly as prominent as the main forums. * The style file should be loaded from d-p-l.org such that changes in style will be automatically picked up by the forums page. * In horizontal split mode, the footer is disproportionately large (btw I made it smaller recently). * Use of bold in split mode for unread posts seems a bit heavy. How about a different background color? * It's not obvious how people should set up their own gravatar. Andrei
Re: SCons support for D
On Thu, 8 Dec 2011 15:39:59 +0200 Manu wrote: > On 8 December 2011 15:27, Mike Parker wrote: > > > On 12/8/2011 6:29 PM, Andrew Gough wrote: > > > >> On Wed, 7 Dec 2011 22:39:34 +0200 > >> Manu wrote: > >> > >> premake supports D? I was planning to add D support to premake > >>> myself, but that's wonderful news. I'll add support for VisualD > >>> if it is not already done. > >>> GDC is also important. Great news! :) > >>> > >>> > >> I'd be happy to continue - I simply got my fork working for > >> DMD+make and just use it locally. It was reviewed by premake's > >> author and he seemed happy with the implementation, but I haven't > >> gotten around to providing an upstream patch. > >> > >> If there is enough interest, I can fix up some loose ends and try > >> and get the ball rolling again... > >> > >> > > +1 > > > > +10 > > I'd also be interested in forking your fork to add some stuff too > (visual studio support). > I also have a pile of local changes to support various consoles to my > local premake, which I haven't tried to push upstream. This is for > C/C++, but I'd love to add support for the same consoles via GDC. > Go for it. I think the more complete we can get premake in this area the better. -- Andrew Gough M: 0408 596 656 and...@goughy.org
Re: A new web newsreader
On 12/8/11 2:15 PM, Andrei Alexandrescu wrote: On 12/8/11 4:55 AM, Vladimir Panteleev wrote: As mentioned previously, I've been working on a web frontend for the DigitalMars NNTP server. I collected ideas and inspiration from the several threads on this topic in the last few weeks, and now I think that the result is ready for beta testing and general use. The current (temporary) URL is: http://dfeed.kimsufi.thecybershadow.net/discussion/ This is an absolutely fantastic development. One more thing: - We should look at ways to integrate some of your code with the standard library. For example, would be great to put some NNTP and CGI support in std. Andrei
Re: A new web newsreader
On Thursday, 8 December 2011 at 19:58:11 UTC, Jacob Carlborg wrote: On 2011-12-08 18:49, Vladimir Panteleev wrote: On Thursday, 8 December 2011 at 17:42:09 UTC, Jacob Carlborg wrote: On 2011-12-08 15:41, Vladimir Panteleev wrote: The "threaded" view mode should look the best on small screens. Yes, but try adding the following meta tag: Then hopefully the page won't look zoomed out on mobile devices. OK, how does it look now? Horribly broken, sorry, remove it. I was hoping the above would be a quick fix but I think a new CSS file would be needed. Don't spend time on creating a new CSS file for me, I'm fine using Thunderbird. OK. I don't have a smartphone, but if I get the chance I'll have a look at some possible simple fixes.
Re: SCons support for D
On Thu, 08 Dec 2011 16:19:27 +0100 "Kagamin" wrote: > > No problem. I disagree and think that a cross platform build > > generator > > that leverages native build tools is a better approach and > > provides > > more flexibility in the long run. Particularly for Windows VS > > users or > > people tied to an IDE - configuration that generates to various > > IDE > > build scripts keeps those devs happier IMO > > Well, native projects do make developers happier, but if the tool > can't build on its own, there's no reason to use it, if make just > works. premake will be a burden of an extra level to go through. That's the whole point, though. A build configuration allows you to target a number of native build tools - not just make. Premake4 supports: codeblocksGenerate Code::Blocks project files codelite Generate CodeLite project files gmake Generate GNU makefiles for POSIX, MinGW, and Cygwin vs2002Generate Microsoft Visual Studio 2002 project files vs2003Generate Microsoft Visual Studio 2003 project files vs2005Generate Microsoft Visual Studio 2005 project files vs2008Generate Microsoft Visual Studio 2008 project files vs2010Generate Visual Studio 2010 project files xcode3Generate Apple Xcode 3 project files (experimental) xcode4Generate Apple Xcode 4 project files (experimental) CMake supports: Borland Makefiles MSYS Makefiles MinGW Makefiles NMake Makefiles NMake Makefiles JOM Unix Makefiles Visual Studio 10 Visual Studio 10 IA64 Visual Studio 10 Win64 Visual Studio 11 Visual Studio 11 Win64 Visual Studio 6 Visual Studio 7 Visual Studio 7 .NET 2003 Visual Studio 8 2005 Visual Studio 8 2005 Win64 Visual Studio 9 2008 Visual Studio 9 2008 IA64 Visual Studio 9 2008 Win64 Watcom WMake CodeBlocks - MinGW Makefiles CodeBlocks - NMake Makefiles CodeBlocks - Unix Makefiles Eclipse CDT4 - MinGW Makefiles Eclipse CDT4 - NMake Makefiles Eclipse CDT4 - Unix Makefiles -- Andrew Gough M: 0408 596 656 and...@goughy.org
Re: A new web newsreader
On Thursday, 8 December 2011 at 19:43:04 UTC, Walter Bright wrote: I am very excited, this is freakin' awesome! I'm glad you like it :) One question: where/how is the user registration data stored? In a table in an SQLite database. Passwords are stored as salted hashes right now.
Re: A new web newsreader
On 2011-12-08 18:49, Vladimir Panteleev wrote: On Thursday, 8 December 2011 at 17:42:09 UTC, Jacob Carlborg wrote: On 2011-12-08 15:41, Vladimir Panteleev wrote: The "threaded" view mode should look the best on small screens. Yes, but try adding the following meta tag: OK, how does it look now? Horribly broken, sorry, remove it. I was hoping the above would be a quick fix but I think a new CSS file would be needed. Don't spend time on creating a new CSS file for me, I'm fine using Thunderbird. -- /Jacob Carlborg
Re: How to stop DMD from linking against phobos
On 2011-12-08 19:11, David Nadlinger wrote: On 12/8/11 6:50 PM, Benjamin Thaut wrote: Is there a way to stop dmd from linking against phobos? (Most preferred would be some command line parameters to dmd) Kind Regards Benjamin Thaut See the -defaultlib and -debuglib switches. druntime is hardcoded anyway, so you could e.g. use: druntime is statically linked with Phobos. -- /Jacob Carlborg
Re: A new web newsreader
On Thu, 08 Dec 2011 08:34:18 -0500, Vladimir Panteleev wrote: I think I'll just reverse the sorting of threads in the threaded view. Threads are already sorted differently than posts anyway (they're sorted by the time of the last reply, not by the original post's time). The new version is perfect, thanks! -Steve
Re: What would you do...
On 12/08/2011 05:23 PM, Manu wrote:
On 8 December 2011 17:51, Manu mailto:turkey...@gmail.com>> wrote:
On 8 December 2011 16:27, Jens Mueller mailto:jens.k.muel...@gmx.de>> wrote:
Manu wrote:
> On 8 December 2011 00:20, Manu mailto:turkey...@gmail.com>> wrote:
>
> > Hey peoples,
> >
> > So this might be a bit off topic... but I'm trying to think
about the best
> > way to write a small program in the most D-ish way possible
(just to make
> > sure I'm giving myself the most realistic experience with
the language),
> > and I wanted to get some thoughts.
> > I don't know which way to go on this. I know what I'd do in
various other
> > languages, but I'm curious to hear the communities opinion.
I think part of
> > the problem is that D's networking libraries are pretty
incomplete... but
> > here it is anyway.
> >
> > I basically just want to write a trivial echo server which
may have
> > hundreds of thousands of connections split into small
groups, and whenever
> > data is received from a member in any group, it is
basically echoed to the
> > others in that group.
> > Sounds super simple...
> >
> > My instinct is to have a listener on the main thread, and
spawn a thread
> > per group, each blocking on a select().. I think the
questions is around
> > thread safety and group management (managing the connection
list for each
> > group), and how to interrupt a blocking select() when a new
connection has
> > entered the group...
> > "The D way" to solve these questions is a mystery to me. I
just feel like
> > I'm writing C code, manually managing thread safety,
timeout logic. I feel
> > like D offers some fundamental features that should make
solving this
> > problem a whole lot simpler that I must be completely
missing...
> >
> > So, in a few sentences... simple problem, what would you do?
> >
>
> Nobody at all? :(
>
> Quite seriously. I'm trying to work out how D's
threading/thread safety
> architecture can help me here.. Also since there's no
collections, I'm
> using the associative arrays. How do I manage thread safety
when accessing
> those? Is there a generic lock mechanism that I've missed
along the way
> without manually creating semaphores? Networking does seem to
be pretty
> bare, I'm basically writing C sockets code.
> One of the results of my experiment here is to identify some
critical
> things that appear to be missing from the language. Places
libraries should
> really step in and make the task simple. This is a super
simple network
> app, but so far, it's just as complicated as if it were
written in C.
I'm probably wrong or not getting it.
But to me it seems you have two different things:
First threads and second connections. For the first I would give
std.concurrency a try (message passing between the threads). And
managing a set of connections within a thread is plain C. So using
select as you do is probably good. If you need to adjust the
select call
from time to time you should not let select block indefinitely.
Use a
timeout. Another option is pselect which has a signal mask. I
suppose
this can also be used to signal abort.
Jens
This is basically exactly what I have (although I'm using
core.thread, I'll swap it for std.concurrency, it does look nicer).
But it just feels... lame/./
I'm not sure why though, I can't quite put my finger on it. Maybe
something irks me about using select() this way, it feels, 1980s :P
The std.concurrency documentation is pretty bad.
So is std.concurrency.spawn() just effectively a helper for spawning
a thread that has mailbox support?
std.concurrency.receive() has no documentation ;) ..
Blocking/Non-blocking? Should I use the one with duration==0 to do a
poll? Perhaps there should be an explicit poll() method?
What is prioritySend()? (also undocumented)
Just digging through concurrence.d since the docs are pretty bare, and
I've come across this pattern, which raises a pretty worrying alarm to
me. I wonder if this is common in D libraries...
void receive(T...)( T ops )
{
checkops( ops );
mbox.get( ops );
}
bool receiveTimeout(T...)( Duration duration, T ops )
{
checkops( ops );
return mbox.get( duration, ops );
}
Okay, so one calls mbox.get with a duration, makes sense... there must
be an ov
Re: A new web newsreader
On 12/8/2011 2:55 AM, Vladimir Panteleev wrote: As mentioned previously, I've been working on a web frontend for the DigitalMars NNTP server. I collected ideas and inspiration from the several threads on this topic in the last few weeks, and now I think that the result is ready for beta testing and general use. I am very excited, this is freakin' awesome! One question: where/how is the user registration data stored?
Re: Comma operator = broken design
On 12/08/2011 05:02 PM, Regan Heath wrote:
On Thu, 08 Dec 2011 12:17:20 -, so wrote:
On Thu, 08 Dec 2011 11:17:48 +0200, Dejan Lekic
wrote:
Why is this operator still kept around?
No offense, but I find it strange/funny that you even ask why! :)
Have you never used comma in for loops???
Not sure if it is that relevant for D, but good point.
for(auto i=beg(), e=end(); i!=e; ++i)
for(auto i, j, k;; ++i, ++k)
...
It's kinda amusing that this thread appeared just as we had a case of
this here at work. The developer accidentally coded something like...
if (function(..), FALSE)
{
}
Accidentally adding the ", FALSE" /after/ the ) instead of as a new
parameter to the function.
(note; This was in C++ with default parameter values so the function can
in fact take 1-4 args).
When I pointed this out, he said "how does that even compile" and was
completely unaware of the existence of the comma operator, nor (once I
explained it) did he realise it was in any way related to the comma used
in for loops. People simply don't think of them as being the same thing
at all. Instead, people learn the comma syntax as a special
characteristic of the for loop, and use it nowhere else.
I think the comma operator is of little benefit (except where used in a
for loop) and it is a source of bugs and we'd be better off without it.
Even if it means porting C/C++ requires modification, or existing D (I
doubt very much of it) breaks.
Phobos would break, for example. And some of my code too.
[OT] opera code rendering
On Thu, 08 Dec 2011 18:23:55 +0200, Manu wrote: ... Sorry for hijacking your thread. Did you do some encoding in your post? Opera rendered your code with some nice syntax-highlighting.
Re: What would you do...
On 8 December 2011 17:51, Manu wrote:
> On 8 December 2011 16:27, Jens Mueller wrote:
>
>> Manu wrote:
>> > On 8 December 2011 00:20, Manu wrote:
>> >
>> > > Hey peoples,
>> > >
>> > > So this might be a bit off topic... but I'm trying to think about the
>> best
>> > > way to write a small program in the most D-ish way possible (just to
>> make
>> > > sure I'm giving myself the most realistic experience with the
>> language),
>> > > and I wanted to get some thoughts.
>> > > I don't know which way to go on this. I know what I'd do in various
>> other
>> > > languages, but I'm curious to hear the communities opinion. I think
>> part of
>> > > the problem is that D's networking libraries are pretty incomplete...
>> but
>> > > here it is anyway.
>> > >
>> > > I basically just want to write a trivial echo server which may have
>> > > hundreds of thousands of connections split into small groups, and
>> whenever
>> > > data is received from a member in any group, it is basically echoed
>> to the
>> > > others in that group.
>> > > Sounds super simple...
>> > >
>> > > My instinct is to have a listener on the main thread, and spawn a
>> thread
>> > > per group, each blocking on a select().. I think the questions is
>> around
>> > > thread safety and group management (managing the connection list for
>> each
>> > > group), and how to interrupt a blocking select() when a new
>> connection has
>> > > entered the group...
>> > > "The D way" to solve these questions is a mystery to me. I just feel
>> like
>> > > I'm writing C code, manually managing thread safety, timeout logic. I
>> feel
>> > > like D offers some fundamental features that should make solving this
>> > > problem a whole lot simpler that I must be completely missing...
>> > >
>> > > So, in a few sentences... simple problem, what would you do?
>> > >
>> >
>> > Nobody at all? :(
>> >
>> > Quite seriously. I'm trying to work out how D's threading/thread safety
>> > architecture can help me here.. Also since there's no collections, I'm
>> > using the associative arrays. How do I manage thread safety when
>> accessing
>> > those? Is there a generic lock mechanism that I've missed along the way
>> > without manually creating semaphores? Networking does seem to be pretty
>> > bare, I'm basically writing C sockets code.
>> > One of the results of my experiment here is to identify some critical
>> > things that appear to be missing from the language. Places libraries
>> should
>> > really step in and make the task simple. This is a super simple network
>> > app, but so far, it's just as complicated as if it were written in C.
>>
>> I'm probably wrong or not getting it.
>> But to me it seems you have two different things:
>> First threads and second connections. For the first I would give
>> std.concurrency a try (message passing between the threads). And
>> managing a set of connections within a thread is plain C. So using
>> select as you do is probably good. If you need to adjust the select call
>> from time to time you should not let select block indefinitely. Use a
>> timeout. Another option is pselect which has a signal mask. I suppose
>> this can also be used to signal abort.
>>
>> Jens
>>
>
> This is basically exactly what I have (although I'm using core.thread,
> I'll swap it for std.concurrency, it does look nicer). But it just feels...
> lame*.*
> I'm not sure why though, I can't quite put my finger on it. Maybe
> something irks me about using select() this way, it feels, 1980s :P
>
> The std.concurrency documentation is pretty bad.
> So is std.concurrency.spawn() just effectively a helper for spawning a
> thread that has mailbox support?
> std.concurrency.receive() has no documentation ;) ..
> Blocking/Non-blocking? Should I use the one with duration==0 to do a poll?
> Perhaps there should be an explicit poll() method?
> What is prioritySend()? (also undocumented)
>
Just digging through concurrence.d since the docs are pretty bare, and I've
come across this pattern, which raises a pretty worrying alarm to me. I
wonder if this is common in D libraries...
void receive(T...)( T ops )
{
checkops( ops );
mbox.get( ops );
}
bool receiveTimeout(T...)( Duration duration, T ops )
{
checkops( ops );
return mbox.get( duration, ops );
}
Okay, so one calls mbox.get with a duration, makes sense... there must be
an overload...
final bool get(T...)( T vals )
{
static assert( T.length );
static if( isImplicitlyConvertible!(T[0], Duration) )
{
alias TypeTuple!(T[1 .. $]) Ops;
alias vals[1 .. $] ops;
assert( vals[0] >= dur!"msecs"(0) );
enum timedWait = true;
Duration period = vals[0];
}
else
{
... blah blah
No overload, receives a tuple, and assumes that static-if the first tuple
item is IMPLICITLY CONVERTIBLE to a Duration, I must be calling the
'overload'..
Re: Comma operator = broken design
On Thu, 08 Dec 2011 19:25:10 +0200, Dejan Lekic wrote: type a = a + 2; // compiles with no errors, no warnings, no explosions (that i know of) If "type" has the default initialiser, then what is the problem? What does it do in both C and D context? 1. It does different things. 2. C version even worse because of debug/release difference. 3. If D still does this, it violates the B-D rule (either does the same thing or doesn't compile at all. Actually there are many things violate this rule...) type a; // even this simple code violates B-D rule. What is the use case? . Is there any? . If there is not any you think, but still compiler allows it, it generates nothing but bugs (from experience :) ). Question should be, why does it exist at all?
Re: How to stop DMD from linking against phobos
On 12/8/11 6:50 PM, Benjamin Thaut wrote: Is there a way to stop dmd from linking against phobos? (Most preferred would be some command line parameters to dmd) Kind Regards Benjamin Thaut See the -defaultlib and -debuglib switches. druntime is hardcoded anyway, so you could e.g. use: dmd -defaultlib="druntime -debuglib="druntime" Hope this helps, David
Re: How to stop DMD from linking against phobos
On Thu, 08 Dec 2011 12:50:36 -0500, Benjamin Thaut wrote: Is there a way to stop dmd from linking against phobos? (Most preferred would be some command line parameters to dmd) Just don't use dmd to link. I think there is a way to replace phobos, but not just make it disappear. -Steve
How to stop DMD from linking against phobos
Is there a way to stop dmd from linking against phobos? (Most preferred would be some command line parameters to dmd) Kind Regards Benjamin Thaut
Re: A new web newsreader
On Thursday, 8 December 2011 at 17:42:09 UTC, Jacob Carlborg wrote: On 2011-12-08 15:41, Vladimir Panteleev wrote: The "threaded" view mode should look the best on small screens. Yes, but try adding the following meta tag: Then hopefully the page won't look zoomed out on mobile devices. OK, how does it look now?
Re: SCons support for D
On 2011-12-08 16:19, Kagamin wrote: No problem. I disagree and think that a cross platform build generator that leverages native build tools is a better approach and provides more flexibility in the long run. Particularly for Windows VS users or people tied to an IDE - configuration that generates to various IDE build scripts keeps those devs happier IMO Well, native projects do make developers happier, but if the tool can't build on its own, there's no reason to use it, if make just works. premake will be a burden of an extra level to go through. Make is a burden. -- /Jacob Carlborg
Re: A new web newsreader
On 2011-12-08 15:41, Vladimir Panteleev wrote: On Thursday, 8 December 2011 at 14:21:54 UTC, Jacob Carlborg wrote: Very nice. Although I would hope for a version that would work better in mobile phones. It's probably good to add a meta tag setting the scale for mobile phones. The "threaded" view mode should look the best on small screens. Yes, but try adding the following meta tag: This is a site that works good in basically all screen sizes: http://upperdog.se/ Yes, I learned about the max-width CSS rules from that site when it was posted a while ago. However, CSS doesn't scale well for complex web pages. -- /Jacob Carlborg
Re: A new web newsreader
On 2011-12-08 15:39, Vladimir Panteleev wrote: On Thursday, 8 December 2011 at 14:35:46 UTC, Jacob Carlborg wrote: On 2011-12-08 15:06, Vladimir Panteleev wrote: On Thursday, 8 December 2011 at 13:51:21 UTC, Robert Clipsham wrote: * In the horizontal-split view if you scroll down too far in the thread you can't see the current thread title, it would be good to make that sticky until you reach the next thread so you can see where you're up to This isn't possible with just CSS. A JavaScript implementation might be possible. I'll think about it. It might be possible using the right combination of layers and absolute position. You still need to change from normal to fixed positioning when the title is scrolled offscreen, and vice-versa. Here's one example (scroll down): http://lesscss.org/ Yeah, I guess so. -- /Jacob Carlborg
Re: A new web newsreader
On Thursday, 8 December 2011 at 17:22:39 UTC, Andrei Alexandrescu wrote: On 12/8/11 8:41 AM, Vladimir Panteleev wrote: On Thursday, 8 December 2011 at 14:21:54 UTC, Jacob Carlborg wrote: This is a site that works good in basically all screen sizes: http://upperdog.se/ Yes, I learned about the max-width CSS rules from that site when it was posted a while ago. However, CSS doesn't scale well for complex web pages. How do they switch from column layout to no-column layout on tight widths? There is a CSS rule which sets the divs (which are normally at 31.25% width) to 100% width when the document is narrow enough.
Re: Comma operator = broken design
type a = a + 2; // compiles with no errors, no warnings, no explosions (that i know of) If "type" has the default initialiser, then what is the problem?
Re: What would you do...
On 12/8/11 9:51 AM, Manu wrote: The std.concurrency documentation is pretty bad. I think we should add a link to the TDPL chapter to the std.concurrency documentation page. Andrei
Re: A new web newsreader
On 12/8/11 8:41 AM, Vladimir Panteleev wrote: On Thursday, 8 December 2011 at 14:21:54 UTC, Jacob Carlborg wrote: Very nice. Although I would hope for a version that would work better in mobile phones. It's probably good to add a meta tag setting the scale for mobile phones. The "threaded" view mode should look the best on small screens. This is a site that works good in basically all screen sizes: http://upperdog.se/ Yes, I learned about the max-width CSS rules from that site when it was posted a while ago. However, CSS doesn't scale well for complex web pages. How do they switch from column layout to no-column layout on tight widths? Andrei
Re: Comma operator = broken design
Ahem. So are you suggesting that (a,b) means a tuple everywhere but in a
for loop, where it is used to separate two statements?
If we use the comma operator only for tuples, there needn't to be a
special case for loops:
for(x, y = 0 , 100; x < y ; x, y += 1,-1) { ... }
Re: SCons support for D
"Andrew Gough" wrote in message news:20111207202725.5adae...@goughy.org... > >It seems there is SCons support (python), CMake, Orbit (Ruby), DSSS >(D1 only?), xfbuild, dake, rdmd options - I've added preliminary D >support to premake. > xfbuild and rdmd are not really build managers. They're just frontends to the compiler which add the modern ability to just specify the main .d file instead of having to specify all the .d files. >Would it be a good idea to thrash out the arguments for/against a >particular tool, and build/support just one? The community doesn't >seem big enough to be so fragmented. Java has Ant, Scala has sbt - >surely D should have a canonical build tool? > I think we can get there, it's just that none of the existing ones are really up to that level yet: - xfbuild and rdmd, like I said, aren't really n the same category - SCons relies on and creates a dependency on another language, and not everyone's going to like that (and not everyone likes Python) - CMake relies on make and a lot of people would just rather let make die than build things on top of it. - Orbit, like someone else said, is a package manager, not a build tool. - DSSS/rebuild has beed dead and abandoned for a long time. - dake (as well as my alternative approach, tentatively "drake") just isn't ready yet.
Re: expression templates vs D arrays
On 12/8/11 6:16 AM, Timon Gehr wrote: Expression templates in D are syntactically more limited because it is impossible to overload the 'not' and comparison operators. I think all operators must be overloadable. The key is to overload them _properly_. C++ botched a few (&&, ||, comma, ++, --) and that gave a bad reputation to the whole notion. We've shown in D that e.g. ++ and -- are great to overload because it's done right. We can and we should do the same with all operators. Andrei
Re: SCons support for D
On Thu, 8 Dec 2011 20:29:20 +1100 Andrew Gough wrote: > If there is enough interest, I can fix up some loose ends and try and > get the ball rolling again... +1 -- In this endeavor there is no loss or diminution, and a little advancement on this path can protect one from the most dangerous type of fear. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: ow Integers Should Work
On 12/8/11 4:47 AM, Don wrote: The Loitsch paper is very interesting, it presents a simple very fast method which works in 99.5% of cases. Then, you fall back to the simple slow method for the remaining 0.5%. The slow case is rare enough that it's not worth optimizing it. I think a D implementation starting from Loitsch's paper would be absolutely terrific for Phobos. I've had these ideas of compile-time function tabulators for a long time, which would made for a great article, but I'm blocked by the inability to format floating-point numbers as strings during compilation. Andrei
Re: SCons support for D
On Thu, 8 Dec 2011 20:13:29 +1100 Andrew Gough wrote: > I have to point out that I have only added DMD+make support as that is > all I needed at the time, but have plans (who doesn't :-D) to add > support for LDC, GDC, and other build chains. Does premake support building SWIG extensions? Sincerely, Gour -- Those who are on this path are resolute in purpose, and their aim is one. O beloved child of the Kurus, the intelligence of those who are irresolute is many-branched. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: expression templates vs D arrays
On 12/8/11 1:55 AM, Walter Bright wrote: I'll add that you can do expression templates in D, but there's no point to them. There is, just for other things such as dimensional analysis. Andrei
Re: DMD 2.056 cannot find -lrt
On Thu, 08 Dec 2011 07:18:48 -0500, Steven Schveighoffer wrote: > On Thu, 08 Dec 2011 03:25:23 -0500, Steve Teale > wrote: > >> I just got round to upgrading from 2.055. I read about this error some >> time ago but now can't find a reference anywhere. >> >> What do I do to get round it. > > Install librt? > > Unfortunately, the solution settled on for 2.056 is to put -lrt in dmd's > source code, so it cannot be removed. > > Curious, what Linux OS are you using? I was under the impression that > they all had librt installed by default. > > -Steve Panic over - I had a misplaced version statement, and was consequently just compiling a bunch of imports - sorry.
Re: Comma operator = broken design
On Thu, 08 Dec 2011 18:02:11 +0200, Regan Heath wrote: When I pointed this out, he said "how does that even compile" and was completely unaware of the existence of the comma operator, nor (once I explained it) did he realise it was in any way related to the comma used in for loops. People simply don't think of them as being the same thing at all. Instead, people learn the comma syntax as a special characteristic of the for loop, and use it nowhere else. Not that related but my all time favorite is still: type a = a + 2; // compiles with no errors, no warnings, no explosions (that i know of)
Re: Comma operator = broken design
On Thu, 08 Dec 2011 12:17:20 -, so wrote:
On Thu, 08 Dec 2011 11:17:48 +0200, Dejan Lekic
wrote:
Why is this operator still kept around?
No offense, but I find it strange/funny that you even ask why! :)
Have you never used comma in for loops???
Not sure if it is that relevant for D, but good point.
for(auto i=beg(), e=end(); i!=e; ++i)
for(auto i, j, k;; ++i, ++k)
...
It's kinda amusing that this thread appeared just as we had a case of this
here at work. The developer accidentally coded something like...
if (function(..), FALSE)
{
}
Accidentally adding the ", FALSE" /after/ the ) instead of as a new
parameter to the function.
(note; This was in C++ with default parameter values so the function can
in fact take 1-4 args).
When I pointed this out, he said "how does that even compile" and was
completely unaware of the existence of the comma operator, nor (once I
explained it) did he realise it was in any way related to the comma used
in for loops. People simply don't think of them as being the same thing
at all. Instead, people learn the comma syntax as a special
characteristic of the for loop, and use it nowhere else.
I think the comma operator is of little benefit (except where used in a
for loop) and it is a source of bugs and we'd be better off without it.
Even if it means porting C/C++ requires modification, or existing D (I
doubt very much of it) breaks.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: DMD 2.056 cannot find -lrt
On Thu, 08 Dec 2011 07:18:48 -0500, Steven Schveighoffer wrote: > On Thu, 08 Dec 2011 03:25:23 -0500, Steve Teale > wrote: > >> I just got round to upgrading from 2.055. I read about this error some >> time ago but now can't find a reference anywhere. >> >> What do I do to get round it. > > Install librt? > > Unfortunately, the solution settled on for 2.056 is to put -lrt in dmd's > source code, so it cannot be removed. > > Curious, what Linux OS are you using? I was under the impression that > they all had librt installed by default. > > -Steve OK, fixed that - I'd been under the erroneous impression that librt was a D thing, and had purged that along with the numerous versions of libphobos2.a that were lurking around on my system. I put librt.a and the librt.so symlinks back, and hello.d now compiles and links. However the CodeBlocks setup that I had for my current DB project is now complaining that it can't find _tlsstart, _tlsend, _deh_beg, and _deh_end. These appear to be C functions - do you happen to know if they are in librt? Steve
Re: A new web newsreader
On Thursday, 8 December 2011 at 15:27:27 UTC, tn wrote: On Thursday, 8 December 2011 at 13:13:38 UTC, Vladimir Panteleev wrote: Generally, in a threaded discussion, replies always have to appear below their parents. Even though it's possible to sort siblings in the reverse order, it would be rather inconsistent. The same goes with entire threads - the last post in a group will appear as the *bottom-most* child of its parent, inside the *topmost* thread. In that case also paging should follow the same rule. That is, last thread should be at the bottom of the _last_ page. (And of course the last page should be viewed by default.) Now it is at the bottom of the first page which is not exactly very intuitive. I think that would be even more confusing. For one, the default page would be the last page - makes sense from your perspective, but certainly unusual in the web discussion board context. For two, the first page in one view would be the last page in another view, and page numbers no longer refer to the same set of threads (at the same point in time). E.g.: "Where was that thread you mentioned?" - "Oh, on the second or third page or so."
Re: What would you do...
On 8 December 2011 16:27, Jens Mueller wrote: > Manu wrote: > > On 8 December 2011 00:20, Manu wrote: > > > > > Hey peoples, > > > > > > So this might be a bit off topic... but I'm trying to think about the > best > > > way to write a small program in the most D-ish way possible (just to > make > > > sure I'm giving myself the most realistic experience with the > language), > > > and I wanted to get some thoughts. > > > I don't know which way to go on this. I know what I'd do in various > other > > > languages, but I'm curious to hear the communities opinion. I think > part of > > > the problem is that D's networking libraries are pretty incomplete... > but > > > here it is anyway. > > > > > > I basically just want to write a trivial echo server which may have > > > hundreds of thousands of connections split into small groups, and > whenever > > > data is received from a member in any group, it is basically echoed to > the > > > others in that group. > > > Sounds super simple... > > > > > > My instinct is to have a listener on the main thread, and spawn a > thread > > > per group, each blocking on a select().. I think the questions is > around > > > thread safety and group management (managing the connection list for > each > > > group), and how to interrupt a blocking select() when a new connection > has > > > entered the group... > > > "The D way" to solve these questions is a mystery to me. I just feel > like > > > I'm writing C code, manually managing thread safety, timeout logic. I > feel > > > like D offers some fundamental features that should make solving this > > > problem a whole lot simpler that I must be completely missing... > > > > > > So, in a few sentences... simple problem, what would you do? > > > > > > > Nobody at all? :( > > > > Quite seriously. I'm trying to work out how D's threading/thread safety > > architecture can help me here.. Also since there's no collections, I'm > > using the associative arrays. How do I manage thread safety when > accessing > > those? Is there a generic lock mechanism that I've missed along the way > > without manually creating semaphores? Networking does seem to be pretty > > bare, I'm basically writing C sockets code. > > One of the results of my experiment here is to identify some critical > > things that appear to be missing from the language. Places libraries > should > > really step in and make the task simple. This is a super simple network > > app, but so far, it's just as complicated as if it were written in C. > > I'm probably wrong or not getting it. > But to me it seems you have two different things: > First threads and second connections. For the first I would give > std.concurrency a try (message passing between the threads). And > managing a set of connections within a thread is plain C. So using > select as you do is probably good. If you need to adjust the select call > from time to time you should not let select block indefinitely. Use a > timeout. Another option is pselect which has a signal mask. I suppose > this can also be used to signal abort. > > Jens > This is basically exactly what I have (although I'm using core.thread, I'll swap it for std.concurrency, it does look nicer). But it just feels... lame* .* I'm not sure why though, I can't quite put my finger on it. Maybe something irks me about using select() this way, it feels, 1980s :P The std.concurrency documentation is pretty bad. So is std.concurrency.spawn() just effectively a helper for spawning a thread that has mailbox support? std.concurrency.receive() has no documentation ;) .. Blocking/Non-blocking? Should I use the one with duration==0 to do a poll? Perhaps there should be an explicit poll() method? What is prioritySend()? (also undocumented)
Re: A new web newsreader
On Thursday, 8 December 2011 at 15:23:20 UTC, Jeff Nowakowski wrote: On 12/08/2011 07:27 AM, Steven Schveighoffer wrote: (Posted from the new web interface). Replies to posts should follow convention and prefix the subject with "Re: " if it doesn't already have one. That was a bug I fixed shortly after the announcement.
Re: A new web newsreader
On a mailing list yes. However, on the newsgroup it is IMHO totally redundant. A matter of taste I think...
Re: A new web newsreader
On Thursday, 8 December 2011 at 13:13:38 UTC, Vladimir Panteleev wrote: On Thursday, 8 December 2011 at 12:27:44 UTC, Steven Schveighoffer wrote: you receive an A+ from me! BTW, is there any way to sort the threaded view so that the newest messages appear on top? Simply because, in a web page, the top is what shows up first. Thanks :) The reason why I chose to sort by older posts first is a bit convoluted: Generally, in a threaded discussion, replies always have to appear below their parents. Even though it's possible to sort siblings in the reverse order, it would be rather inconsistent. The same goes with entire threads - the last post in a group will appear as the *bottom-most* child of its parent, inside the *topmost* thread. In that case also paging should follow the same rule. That is, last thread should be at the bottom of the _last_ page. (And of course the last page should be viewed by default.) Now it is at the bottom of the first page which is not exactly very intuitive.
Re: A new web newsreader
On 12/08/2011 07:27 AM, Steven Schveighoffer wrote: (Posted from the new web interface). Replies to posts should follow convention and prefix the subject with "Re: " if it doesn't already have one.
Re: SCons support for D
No problem. I disagree and think that a cross platform build generator that leverages native build tools is a better approach and provides more flexibility in the long run. Particularly for Windows VS users or people tied to an IDE - configuration that generates to various IDE build scripts keeps those devs happier IMO Well, native projects do make developers happier, but if the tool can't build on its own, there's no reason to use it, if make just works. premake will be a burden of an extra level to go through.
Re: A new web newsreader
On 08/12/2011 14:06, Vladimir Panteleev wrote:
On Thursday, 8 December 2011 at 13:51:21 UTC, Robert Clipsham wrote:
* Support syntax highlighting for blocks enclosed with --- like DDoc
does, maybe other types of blocks too such as {{{}}} that trac uses,
or whatever github uses.
I'm not very excited about the idea of introducing formatting features
that only users of this web interface will see. Frequent use of such
features would annoy users of other interfaces, and there's the risk of
accidentally activating them.
I've seen quite a few people using it for code snippets anyway, and it's
only a minor thing - I wouldn't want to go any further and allow for
bold/italic/smileys/etc. Accidentally activating them would be a
problem, I think that's a minor risk for this though. Not a major thing,
just something I've always wanted to see ;)
* Does the mailing list have the same restriction as gmane has (no
posting)?
Yes. Clicking on "Create thread" or "Reply" will display a message with
a link to the Mailman page. I could probably implement posting if Brad
says it's OK, but focused discussion groups such as development mailing
lists might actually benefit from a high barrier to entry.
That's a shame, it really annoys me that I can't reply in the same place
as I read currently :(
* Thundrbird has a "mark read" function for
threads/messages/newsgroups - that'd be really useful.
"Mark thread as [un]read" keys should be easy to add. It would also be
possible to mark all posts as read, but not on a per-group basis.
Awesome! Can't wait!
* In the horizontal-split view if you scroll down too far in the
thread you can't see the current thread title, it would be good to
make that sticky until you reach the next thread so you can see where
you're up to
This isn't possible with just CSS. A JavaScript implementation might be
possible. I'll think about it.
Some of us don't have the same reservations as Nick about not using
javascript ;) If it can't be done in CSS it would still be really nice
to have.
Maybe we should just reverse the thread sort order, like for the
"threaded" view?
There could be a "Sort by" option to allow it to be sorted however the
user wants it?
Another one - log in using OpenID so I don't have to remember another
username/password ;)
I'd be happy to if you provide a D OpenID implementation :)
(Last I checked, implementing OpenID from scratch was quite hard)
I doubt I'll get chance in the near future unfortunately. Last time I
looked it didn't seem to hard, I didn't look too in depth though.
--
Robert
http://octarineparrot.com/
Re: A new web newsreader
On Thursday, 8 December 2011 at 14:21:54 UTC, Jacob Carlborg wrote: Very nice. Although I would hope for a version that would work better in mobile phones. It's probably good to add a meta tag setting the scale for mobile phones. The "threaded" view mode should look the best on small screens. This is a site that works good in basically all screen sizes: http://upperdog.se/ Yes, I learned about the max-width CSS rules from that site when it was posted a while ago. However, CSS doesn't scale well for complex web pages.
Re: A new web newsreader
On Thursday, 8 December 2011 at 14:35:46 UTC, Jacob Carlborg wrote: On 2011-12-08 15:06, Vladimir Panteleev wrote: On Thursday, 8 December 2011 at 13:51:21 UTC, Robert Clipsham wrote: * In the horizontal-split view if you scroll down too far in the thread you can't see the current thread title, it would be good to make that sticky until you reach the next thread so you can see where you're up to This isn't possible with just CSS. A JavaScript implementation might be possible. I'll think about it. It might be possible using the right combination of layers and absolute position. You still need to change from normal to fixed positioning when the title is scrolled offscreen, and vice-versa. Here's one example (scroll down): http://lesscss.org/
Re: A new web newsreader
On 2011-12-08 15:06, Vladimir Panteleev wrote: On Thursday, 8 December 2011 at 13:51:21 UTC, Robert Clipsham wrote: * In the horizontal-split view if you scroll down too far in the thread you can't see the current thread title, it would be good to make that sticky until you reach the next thread so you can see where you're up to This isn't possible with just CSS. A JavaScript implementation might be possible. I'll think about it. It might be possible using the right combination of layers and absolute position. -- /Jacob Carlborg
Re: A new web newsreader
On Thursday, 8 December 2011 at 14:10:54 UTC, Dmitry wrote: It would allow you to view all of the topics which have new messages (replies) in since your last visit. Each the topic would contain the new messages only and, if it makes sense, the original messages too. (...) Alternatively, another approach could keep it as it is for now, but indicate somehow on unread messages (e.g. change the font style or place a count of new messages). Sounds good. I think we could also create a front page that's more useful than just a group list. It could contain information such as replies to your posts, "followed" threads, etc.
Re: What would you do...
Manu wrote: > On 8 December 2011 00:20, Manu wrote: > > > Hey peoples, > > > > So this might be a bit off topic... but I'm trying to think about the best > > way to write a small program in the most D-ish way possible (just to make > > sure I'm giving myself the most realistic experience with the language), > > and I wanted to get some thoughts. > > I don't know which way to go on this. I know what I'd do in various other > > languages, but I'm curious to hear the communities opinion. I think part of > > the problem is that D's networking libraries are pretty incomplete... but > > here it is anyway. > > > > I basically just want to write a trivial echo server which may have > > hundreds of thousands of connections split into small groups, and whenever > > data is received from a member in any group, it is basically echoed to the > > others in that group. > > Sounds super simple... > > > > My instinct is to have a listener on the main thread, and spawn a thread > > per group, each blocking on a select().. I think the questions is around > > thread safety and group management (managing the connection list for each > > group), and how to interrupt a blocking select() when a new connection has > > entered the group... > > "The D way" to solve these questions is a mystery to me. I just feel like > > I'm writing C code, manually managing thread safety, timeout logic. I feel > > like D offers some fundamental features that should make solving this > > problem a whole lot simpler that I must be completely missing... > > > > So, in a few sentences... simple problem, what would you do? > > > > Nobody at all? :( > > Quite seriously. I'm trying to work out how D's threading/thread safety > architecture can help me here.. Also since there's no collections, I'm > using the associative arrays. How do I manage thread safety when accessing > those? Is there a generic lock mechanism that I've missed along the way > without manually creating semaphores? Networking does seem to be pretty > bare, I'm basically writing C sockets code. > One of the results of my experiment here is to identify some critical > things that appear to be missing from the language. Places libraries should > really step in and make the task simple. This is a super simple network > app, but so far, it's just as complicated as if it were written in C. I'm probably wrong or not getting it. But to me it seems you have two different things: First threads and second connections. For the first I would give std.concurrency a try (message passing between the threads). And managing a set of connections within a thread is plain C. So using select as you do is probably good. If you need to adjust the select call from time to time you should not let select block indefinitely. Use a timeout. Another option is pselect which has a signal mask. I suppose this can also be used to signal abort. Jens
Re: SCons support for D
On 2011-12-08 12:18, Andrew Gough wrote: On Thu, 08 Dec 2011 11:23:18 +0100 Jacob Carlborg wrote: On 2011-12-08 10:13, Andrew Gough wrote: The reasons I chose premake were primarily: 1. No external dependencies (lua embedded in an executable) 2. Simple configuration 3. Cross platform 4. Generates native build scripts: make, VS, Code::Blocks etc etc I have to point out that I have only added DMD+make support as that is all I needed at the time, but have plans (who doesn't :-D) to add support for LDC, GDC, and other build chains. So it depends on external build tools. I don't like that. I guess it could have an option to generate makefiles or similar but by default it should be able to build on its own. No problem. I disagree and think that a cross platform build generator that leverages native build tools is a better approach and provides more flexibility in the long run. Particularly for Windows VS users or people tied to an IDE - configuration that generates to various IDE build scripts keeps those devs happier IMO I don't agree. -- /Jacob Carlborg
Re: A new web newsreader
On 2011-12-08 11:55, Vladimir Panteleev wrote: As mentioned previously, I've been working on a web frontend for the DigitalMars NNTP server. I collected ideas and inspiration from the several threads on this topic in the last few weeks, and now I think that the result is ready for beta testing and general use. The current (temporary) URL is: http://dfeed.kimsufi.thecybershadow.net/discussion/ Very nice. Although I would hope for a version that would work better in mobile phones. It's probably good to add a meta tag setting the scale for mobile phones. This is a site that works good in basically all screen sizes: http://upperdog.se/ -- /Jacob Carlborg
Re: Haxe (From: Java > Scala -> new thread: GUI for D)
Am 07.12.2011 15:16, schrieb Adam Ruppe: > Adrian Wrote: >> [OT] As a side point from a not yet D developer, but someone who looks >> at the language with great interest, but also someone with a commercial >> responsibility: I am missing big projects developed in D and the most >> logic project would be the compiler itself! I know this has been >> discussed a million times before, but... > > How big is big? My app is up to about 75,000 lines of D2 (including my D > libs), > which isn't gigantic but it does a lot of things and needs to be ready > for use and changes almost every day. I meant a community driven project of course. And the only projects, which are useful for every D user and therefor have lot of contributers are the compiler itself and maybe an IDE with debugger.
Re: A new web newsreader
On Thursday, 8 December 2011 at 13:19:39 UTC, Vladimir Panteleev wrote: On Thursday, 8 December 2011 at 11:43:25 UTC, Dmitry wrote: It would be great to have a button "View New Posts". It could be very useful and I think it is only what we need actually. :) What would such a button do? It would allow you to view all of the topics which have new messages (replies) in since your last visit. Each the topic would contain the new messages only and, if it makes sense, the original messages too. For example, assume that I had already read everything and replied to your message some time ago. A few minutes later I had pressed button/link "View New Posts" on the "Forum Index" page so that there was your reply only. The page could look as follows. › Forum Index D Programming Language Forum Last Post digitalmars.D A new web newsreader by Vladimir Panteleev ? minutes ago The page would be empty at all, if there was nothing new for reading. Alternatively, another approach could keep it as it is for now, but indicate somehow on unread messages (e.g. change the font style or place a count of new messages). Then, if I had entered to "digitalmars.D" with the new message the page could look as below. › digitalmars.D === A new web newsreader Dmitry? hours ago // original message, had been already read Vladimir Panteleev? minutes ago // unread message Sorry for unclear explanation. In other words, button "View New Posts" could update a page filtering out all read messages.
Re: A new web newsreader
Such a sexy NG interface! The only thing missing is ability to quickly switch between the main newsgroups in the horizontal-split view. I mean if I'm reading D.learn there doesn't seem to be an obvious way to switch to another group like D.announce. I can click on the title to go back, of course, but it might be nice to have links to the other NGs in that view (perhaps as a set of horizontal links above the topics box). Still, I love how fast it is. And it's written in D?! Sweet! If this were integrated to dpl.org it would kick the balls out of all the other proggy sites.
Re: A new web newsreader
On Thursday, 8 December 2011 at 13:51:21 UTC, Robert Clipsham
wrote:
* Support syntax highlighting for blocks enclosed with --- like
DDoc does, maybe other types of blocks too such as {{{}}} that
trac uses, or whatever github uses.
I'm not very excited about the idea of introducing formatting
features that only users of this web interface will see. Frequent
use of such features would annoy users of other interfaces, and
there's the risk of accidentally activating them.
* Does the mailing list have the same restriction as gmane has
(no posting)?
Yes. Clicking on "Create thread" or "Reply" will display a
message with a link to the Mailman page. I could probably
implement posting if Brad says it's OK, but focused discussion
groups such as development mailing lists might actually benefit
from a high barrier to entry.
* Thundrbird has a "mark read" function for
threads/messages/newsgroups - that'd be really useful.
"Mark thread as [un]read" keys should be easy to add. It would
also be possible to mark all posts as read, but not on a
per-group basis.
* In the horizontal-split view if you scroll down too far in
the thread you can't see the current thread title, it would be
good to make that sticky until you reach the next thread so you
can see where you're up to
This isn't possible with just CSS. A JavaScript implementation
might be possible. I'll think about it.
Maybe we should just reverse the thread sort order, like for the
"threaded" view?
Another one - log in using OpenID so I don't have to remember
another username/password ;)
I'd be happy to if you provide a D OpenID implementation :)
(Last I checked, implementing OpenID from scratch was quite hard)
Re: What would you do...
On 8 December 2011 00:20, Manu wrote: > Hey peoples, > > So this might be a bit off topic... but I'm trying to think about the best > way to write a small program in the most D-ish way possible (just to make > sure I'm giving myself the most realistic experience with the language), > and I wanted to get some thoughts. > I don't know which way to go on this. I know what I'd do in various other > languages, but I'm curious to hear the communities opinion. I think part of > the problem is that D's networking libraries are pretty incomplete... but > here it is anyway. > > I basically just want to write a trivial echo server which may have > hundreds of thousands of connections split into small groups, and whenever > data is received from a member in any group, it is basically echoed to the > others in that group. > Sounds super simple... > > My instinct is to have a listener on the main thread, and spawn a thread > per group, each blocking on a select().. I think the questions is around > thread safety and group management (managing the connection list for each > group), and how to interrupt a blocking select() when a new connection has > entered the group... > "The D way" to solve these questions is a mystery to me. I just feel like > I'm writing C code, manually managing thread safety, timeout logic. I feel > like D offers some fundamental features that should make solving this > problem a whole lot simpler that I must be completely missing... > > So, in a few sentences... simple problem, what would you do? > Nobody at all? :( Quite seriously. I'm trying to work out how D's threading/thread safety architecture can help me here.. Also since there's no collections, I'm using the associative arrays. How do I manage thread safety when accessing those? Is there a generic lock mechanism that I've missed along the way without manually creating semaphores? Networking does seem to be pretty bare, I'm basically writing C sockets code. One of the results of my experiment here is to identify some critical things that appear to be missing from the language. Places libraries should really step in and make the task simple. This is a super simple network app, but so far, it's just as complicated as if it were written in C.
Re: A new web newsreader
On 08/12/2011 13:51, Robert Clipsham wrote:
On 08/12/2011 10:55, Vladimir Panteleev wrote:
As mentioned previously, I've been working on a web frontend for the
DigitalMars NNTP server. I collected ideas and inspiration from the
several threads on this topic in the last few weeks, and now I think
that the result is ready for beta testing and general use.
The current (temporary) URL is:
Here are the highlights:
* Written in D, pull requests are welcome.
https://github.com/CyberShadow/DFeed
* It remembers which posts you've seen on an individual post basis.
By default, read post history is stored in a compressed cookie.
* Optionally, you can register an account, which will store your
preferences and read post history in the server database. There is no
e-mail confirmation etc.
Oooh, it's almost ready enough to let me replace my Thunderbird usage!
A couple of feature requests (some I've already mentioned on IRC):
* Support syntax highlighting for blocks enclosed with --- like DDoc
does, maybe other types of blocks too such as {{{}}} that trac uses, or
whatever github uses.
* Does the mailing list have the same restriction as gmane has (no
posting)?
* Thundrbird has a "mark read" function for threads/messages/newsgroups
- that'd be really useful.
* In the horizontal-split view if you scroll down too far in the thread
you can't see the current thread title, it would be good to make that
sticky until you reach the next thread so you can see where you're up to
Another one - log in using OpenID so I don't have to remember another
username/password ;)
--
Robert
http://octarineparrot.com/
Re: A new web newsreader
On 08/12/2011 10:55, Vladimir Panteleev wrote:
As mentioned previously, I've been working on a web frontend for the
DigitalMars NNTP server. I collected ideas and inspiration from the
several threads on this topic in the last few weeks, and now I think
that the result is ready for beta testing and general use.
The current (temporary) URL is:
Here are the highlights:
* Written in D, pull requests are welcome.
https://github.com/CyberShadow/DFeed
* It remembers which posts you've seen on an individual post basis.
By default, read post history is stored in a compressed cookie.
* Optionally, you can register an account, which will store your
preferences and read post history in the server database. There is no
e-mail confirmation etc.
Oooh, it's almost ready enough to let me replace my Thunderbird usage!
A couple of feature requests (some I've already mentioned on IRC):
* Support syntax highlighting for blocks enclosed with --- like DDoc
does, maybe other types of blocks too such as {{{}}} that trac uses, or
whatever github uses.
* Does the mailing list have the same restriction as gmane has (no
posting)?
* Thundrbird has a "mark read" function for
threads/messages/newsgroups - that'd be really useful.
* In the horizontal-split view if you scroll down too far in the
thread you can't see the current thread title, it would be good to make
that sticky until you reach the next thread so you can see where you're
up to
--
Robert
http://octarineparrot.com/
Re: SCons support for D
On 8 December 2011 15:27, Mike Parker wrote: > On 12/8/2011 6:29 PM, Andrew Gough wrote: > >> On Wed, 7 Dec 2011 22:39:34 +0200 >> Manu wrote: >> >> premake supports D? I was planning to add D support to premake >>> myself, but that's wonderful news. I'll add support for VisualD if it >>> is not already done. >>> GDC is also important. Great news! :) >>> >>> >> I'd be happy to continue - I simply got my fork working for DMD+make >> and just use it locally. It was reviewed by premake's author and he >> seemed happy with the implementation, but I haven't gotten around to >> providing an upstream patch. >> >> If there is enough interest, I can fix up some loose ends and try and >> get the ball rolling again... >> >> > +1 > +10 I'd also be interested in forking your fork to add some stuff too (visual studio support). I also have a pile of local changes to support various consoles to my local premake, which I haven't tried to push upstream. This is for C/C++, but I'd love to add support for the same consoles via GDC.
Re: A new web newsreader
On Thursday, 8 December 2011 at 13:23:53 UTC, Steven Schveighoffer wrote: Would a simple "scroll to bottom on page load" in javascript be possible? I know there are some nicks on this newsgroup who don't like JS, but their browser simply won't scroll. So what. JavaScript which alters page content on load is bad, because by the time it executes you might have already started reading the page. I think it's best to avoid such nuisances. I understand. I'm just used to webnews which put the threads with the newest posts on top. I think I'll just reverse the sorting of threads in the threaded view. Threads are already sorted differently than posts anyway (they're sorted by the time of the last reply, not by the original post's time). Probably, this is a cool project. If I ever come across having to use forum software, I'm going to use it. The code would need a good refactoring to get the D hacks out. It's a bit of a mess in that regard. Now, you just need the management pages to administer a real forum :) Who says there isn't one? https://github.com/CyberShadow/ae/blob/master/demo/sqlite/exec.d ;)
Re: SCons support for D
On 12/8/2011 6:13 PM, Andrew Gough wrote: On Wed, 7 Dec 2011 20:56:17 +0100 Jens Mueller wrote: Andrew Gough wrote: On Tue, 06 Dec 2011 18:14:25 + Russel Winder wrote: SCons is a Python-based build tool to replace Make and much of the Autotools functionality. It has D support as part of the core. This support is though in need of development. The new Mercurial/BitBucket infrastructure for developing SCons (replacing the old Subversion/Tigris set up) is now in place, a new release 2.1.0 has been declared and everything is open for business leading to a 2.2.0 release. I got my changes to support DMD 2 into this release :-) However, support for GDC, LDC, etc. is almost certainly still sadly lacking, and indeed the support for DMD almost certainly needs a severe refactoring and most likely a rewrite. Rather than people having to work on a clone of SCons in order to work on the tool, I have created a separate Mercurial repository (https://bitbucket.org/russel/scons_dmd_new) as a development version of just the tool. When a new version of this separate tool is declared I create a pull request for the SCons mainline to get the new version in the next version of SCons. Is anyone else other than me interested in using SCons as a build tool with D code? If there is, perhaps we can collaborate in some way to progress SCons support for all the various realizations of D? I think the build tool question is in need of the same level of high level design and support that Steve Teale is working on for std.database/std.sql. It seems there is SCons support (python), CMake, Orbit (Ruby), DSSS (D1 only?), xfbuild, dake, rdmd options - I've added preliminary D support to premake. Where do I find your changes for premake? https://bitbucket.org/goughy/premake-dev-d Would it be a good idea to thrash out the arguments for/against a particular tool, and build/support just one? The community doesn't seem big enough to be so fragmented. Java has Ant, Scala has sbt - surely D should have a canonical build tool? I'm unsure whether D needs its own configuration/build tool. It definitely needs a package manager. For building there are different options but usually it's make. Most people (at least for sure on Unix variants) are using it. I think Scons does both building and configuring. Just want to say that you can have different tools for these jobs or single one. Jacob's build tool looks good but I wonder what are the major improvements over e.g. make (portability is an issue with make; maybe simplicity). For configuring there are some options and so far none of them is preferred by a majority. Different people weigh different aspects differently. But it seems people are moving away from configure scripts. As Russell already said, several build/configuration tools are used and there is no clear winner in general. So I think it's very nice that you have added support for D to premake. So we then have SCons (build and configuration), CMake (configuration and several build tools via generators), rdmd (can generate dependencies for Makefile), Jacob as a build tool and there are several others specifically for D and premake. I'm not sure about the state of each of these. But SCons and CMake work with dmd (both do configuration). premake is also configuration. Regarding build tools I wonder how important they are. make works fairly well. Jens The reasons I chose premake were primarily: 1. No external dependencies (lua embedded in an executable) 2. Simple configuration 3. Cross platform 4. Generates native build scripts: make, VS, Code::Blocks etc etc I have to point out that I have only added DMD+make support as that is all I needed at the time, but have plans (who doesn't :-D) to add support for LDC, GDC, and other build chains. I've considered doing this several times in the past. Managing the makefiles in Derelict has been a PITA, to say the least. Thanks for sharing this!
Re: SCons support for D
On 12/8/2011 6:29 PM, Andrew Gough wrote: On Wed, 7 Dec 2011 22:39:34 +0200 Manu wrote: premake supports D? I was planning to add D support to premake myself, but that's wonderful news. I'll add support for VisualD if it is not already done. GDC is also important. Great news! :) I'd be happy to continue - I simply got my fork working for DMD+make and just use it locally. It was reviewed by premake's author and he seemed happy with the implementation, but I haven't gotten around to providing an upstream patch. If there is enough interest, I can fix up some loose ends and try and get the ball rolling again... +1
Re: A new web newsreader
On Thu, 08 Dec 2011 08:13:36 -0500, Vladimir Panteleev wrote: On Thursday, 8 December 2011 at 12:27:44 UTC, Steven Schveighoffer wrote: you receive an A+ from me! BTW, is there any way to sort the threaded view so that the newest messages appear on top? Simply because, in a web page, the top is what shows up first. Thanks :) The reason why I chose to sort by older posts first is a bit convoluted: Generally, in a threaded discussion, replies always have to appear below their parents. Even though it's possible to sort siblings in the reverse order, it would be rather inconsistent. The same goes with entire threads - the last post in a group will appear as the *bottom-most* child of its parent, inside the *topmost* thread. Having the newest post at the bottom of the top-most group is acceptable for a threaded view, simply because in a threaded view, that is the natural order. But having the newest item near the bottom of the page makes it slightly annoying, since it isn't the focus when the page loads. Would a simple "scroll to bottom on page load" in javascript be possible? I know there are some nicks on this newsgroup who don't like JS, but their browser simply won't scroll. So what. This was not a problem for the split-view mode, because JavaScript scrolls down the message list when the page is loaded. I've finished the threaded view after the split-view, which inherited its order. I decided to leave it as it is for consistency with what the view was modelled after - mailing list archives. I understand. I'm just used to webnews which put the threads with the newest posts on top. But I think a simliar javascript solution would be acceptable. I'm thinking that we could eventually have a "Preferences" page, where we could go nuts with options and customization. Probably, this is a cool project. If I ever come across having to use forum software, I'm going to use it. Now, you just need the management pages to administer a real forum :) -Steve
Re: A new web newsreader
On Thursday, 8 December 2011 at 11:43:25 UTC, Dmitry wrote: It would be great to have a button "View New Posts". It could be very useful and I think it is only what we need actually. :) What would such a button do?
