[OT] Good webhost?
(Sorry for this being so wildly off-topic, but this is the only place I can think of where I already trust the people around to know what they're talking about.) Anyone know of a good webhost? I'm looking for something that matches all of these criteria (not in any order): 1. All the basics: Linux/Apache (BSD and/or Nginx might possibly be ok), PHP, MySQL (MySQL+PostgreSQL is a plus), POP3, SMTP, FTP. 2. SSH access. 3. Allows natively-compiled CGI (and not just a group of pre-selected pre-packaged CGI apps). 4. They don't make server changes without notifying you via email. And with fair lead-time whenever possible. And none of that "We only notify via twitter" bullshit. 5. They don't have a tendency to screw things up when making server changes. 6. None of your contact or other settings have a tendency to get reverted to old values. 7. All control panels work without JS, popups, Flash or any other such bullshit. 8. Allows me to use a domain name I've obtained elsewhere. 9. Allows me to use an SSL/TLS cert I've obtained elsewhere. 10. Doesn't use any Indian tech support. 11. Support is fast. 12. Support is overall good. 13. Has good uptime and performance. 14. Generally seem to know what they're doing and are professional. 15. No more than about $20/mo. 16. Large number of email addresses (probably about 30 absolute minimum). 17. Actually know WTF they're doing WRT security. Ex: 17.A. They never send any passwords through unencrypted email. 17.B. They understand that signed email is not the same as encrypted email. 17.C. Support never asks for your password. 17.D. Support makes reasonable effort to make sure you are who you claim to be. 17.E. Their control panel is 100% HTTPS (and not susceptible to session hijacking). 17.F. Supports secure FTP connections. 17.G. Performs sufficiently well on this: https://www.ssllabs.com/ssldb/ 18. No other stupid surprise bullshit that I haven't come across yet. 19. Frontpage extensions...(just kidding!!) Believe it or not, for every single one of those items there, I've actually dealt with a host that failed on it (except maybe the "All the basics" and the "domain/SSL/TLS obtained elsewhere" things). I've never even come across a host that matched all of them (except maybe virtual or dedicated hosting, but I can't afford those). Some of the hosts I've already dealt with and consider to be crap: - 1&1 - Godaddy (only dealt with them for domains, but man are they bad for that) - iPower (tied for #1 worst) - Dreamhost (tied for #1 worst) - Brinkster I'm currently with 100megswebhosting, and they're the #1 best I've ever come across. But even at that they still have their problems (#4, 5, 6, 7, and 17.A.) and I'd really like to find something better.
Re: FReD is ready for review
Am 13.09.2011, 23:22 Uhr, schrieb bearophile : Dmitry Olshansky: Goodies include popular regex-dna benchmark, by my measures we should be at least #3 among single threaded solutions. This is rather good. The #1 is of JavaScript-V8 that has received a significant amount of engineering efforts. I heard a Google engineer talk about that. In JavaScript regular expressions are often used for a wider range of operations on strings (e.g. splitting), since they were generally faster than doing the same in pure JavaScript. It is one of those few occasions where a JS developer can rely on native code in a library doing most of the work.
Re: Clean-up of std.socket
Am 13.09.2011, 18:40 Uhr, schrieb Vladimir Panteleev : On Tue, 13 Sep 2011 18:52:02 +0300, David Nadlinger wrote: Which kind of »provided details« would be interesting for you? Something like this post, thanks. If not in the standard library, where else? Granted, the difference is probably only going to cause problems in unit tests (since actual programs shouldn't rely on the exact socket timings anyway), but pushing the burden of writing platform-specific workaround codeto the std.socket users doesn't seem like a good solution to me either. The obvious problem with such hacks is forward-compatibility - the problem might be fixed in Windows 8/9/etc. and no one might notice. I guess it wouldn't be hard to add an unit test for this. Then, there's the question of expectations. For example, someone porting their code from another language might already account for this oddity, which would cause timeouts to be off 500ms in the other direction. Does any other language's standard library do something like this? Personally, I don't have a strong opinion one way or another, but I do think that if the hack is left in, it should be well-documented and its necessity be easily verifiable. Especially if the involved call looks suspiciously low-level, a user will often assume that it is a direct wrapper of the native API. So +1 in such cases on good documentation. Inspired by other language documents, a 'caveats' section or other highlighting will do, because socket experts will skip the text they think they know already.
Re: How can I use D to develop web application?
On Wed, Sep 14, 2011 at 12:04 PM, zsxxsz wrote: > == Quote from Nick Sabalausky (a@a.a)'s article >> "zsxxsz" wrote in message >> news:j4o0nn$2igh$1...@digitalmars.com... >> > == Quote from Adam Ruppe (destructiona...@gmail.com)'s article >> >> zsxxsz wrote: >> >> > I think the cgi module is lower effecient. >> >> That's not really true. The reason CGI has a perception of being >> >> slow is because it's used by slow languages most the time, but with >> >> D, it's fast. >> > I don't think so. Because I've been using C to write cgi. One http request >> > one >> > fork cgi which is the reason of slowly performance cgi. The fork process >> > is >> > expensive for any OS. >> Accessing a DB, using JS, and sending a page across the internet are all >> far, far slower than forking. > > I've make a test that forking 1000 processes to execute 1000 tasks on Linux, > which > cost my all CPU and the load average is high. But when use thread pool to > execute > these same 1000 tasks, the CPU cost and load average are more slower. > You're better off being event based than either of these options, fork per request is broken but so is thread per request.
Re: How can I use D to develop web application?
On Tue, Sep 13, 2011 at 8:54 PM, zsxxsz wrote: > == Quote from Adam Ruppe (destructiona...@gmail.com)'s article >> zsxxsz wrote: >> > The fork process is expensive for any OS. >> Have you actually measured this? > Yes, I'm sure. Fork on UNIX or CreateProcess on Win32 are expensive. Interestingly enough, this benchmark conducted ~10 years ago on a Pentium 3 found that Fork took less than a millisecond on Linux 2.6: http://bulk.fefe.de/scalability/
Re: How can I use D to develop web application?
== Quote from Nick Sabalausky (a@a.a)'s article > "zsxxsz" wrote in message > news:j4o0nn$2igh$1...@digitalmars.com... > > == Quote from Adam Ruppe (destructiona...@gmail.com)'s article > >> zsxxsz wrote: > >> > I think the cgi module is lower effecient. > >> That's not really true. The reason CGI has a perception of being > >> slow is because it's used by slow languages most the time, but with > >> D, it's fast. > > I don't think so. Because I've been using C to write cgi. One http request > > one > > fork cgi which is the reason of slowly performance cgi. The fork process > > is > > expensive for any OS. > Accessing a DB, using JS, and sending a page across the internet are all > far, far slower than forking. I've make a test that forking 1000 processes to execute 1000 tasks on Linux, which cost my all CPU and the load average is high. But when use thread pool to execute these same 1000 tasks, the CPU cost and load average are more slower.
Re: How can I use D to develop web application?
== Quote from Trass3r (u...@known.com)'s article > > Thank you very much. I think the cgi module is lower effecient. I found > > fcgi(http://www.dsource.org/projects/fastcgi4d) and > > mango(http://www.dsource.org/projects/mango) which support servlet. But > > they don't support D2, anyone else can merge them to D2? > Why don't you port them yourself? Yes, I want to port them from now on, maybe write another one. The projects's owner port them is the best way, because they are more familer with there programs.
Re: How can I use D to develop web application?
== Quote from Adam Ruppe (destructiona...@gmail.com)'s article > zsxxsz wrote: > > The fork process is expensive for any OS. > Have you actually measured this? Yes, I'm sure. Fork on UNIX or CreateProcess on Win32 are expensive. > > I feel the cgi library is too simple, so I doubt wether it supports > > fcgi for Apache, Nginx or other Webserver. > Have you actually looked at it? I've personally used it on three web > servers (IIS, Apache, and an embedded server) across two operating > systems (Windows and Linux) and three protocols (CGI, FastCGI, and > raw http). > It'll probably work on other servers and operating systems too, but > I haven't tried yet. Is so, I'll try it, thanks.
Re: FReD is ready for review
On Tuesday, September 13, 2011 14:52 Dmitry Olshansky wrote: > On 14.09.2011 1:36, Jonathan M Davis wrote: > > On Tuesday, September 13, 2011 14:04 Dmitry Olshansky wrote: > >> Speaking of source there are few artifacts that should end up in std.uni > >> and not in std.regex: > >> CodepointSet and CodepointTrie, and unicode property tables. > >> I'd rather have them all accessible to user, but their interface is > >> admittedly clunky, I'm open to ideas on better API. > > > > I suspect that there's value in reviewing the unicode stuff separately, > > and if it affects std.regex' API at all (as opposed to being simply an > > implementation detail), I'd suggest that we review and sort out the > > unicode stuff before we review then new std.regex, since that would then > > have definite impact on std.regex, and it affects a lot more than just > > std.regex. > > It doesn't affect API at all, but an important implementation detail. > Particularly one can't get reasonable performance w/o unicode > incorporated as an implementation detail yet I feel there should be a > more general interface to it. Otherwise everyone willing to tackle > unicode would have to, for instance, duplicate all of unicode property > tables, and that's some 100Kb we are looking at. > > > If the unicode stuff is entirely an implementation detail of std.regex > > and is not in the API, then we can review the unicode stuff separately > > and make std.regex use the stuff in std.uni once it's in there, but if > > you're doing major unicode stuff, I think that that's significant enough > > to merit its own review. > > It could be done in two steps, if I was to choose which way to go I'd > first folded in std.regex then moved all its hidden unicode stuff to > std.uni. It's mostly about character classification and about doing it > fast. As long as it doesn't affect the API, then we can review std.regex first, but we do definitely want to get any major unicode improvements into std.uni. And that will probably merit its own review. - Jonathan M Davis
Re: FReD is ready for review
On 9/13/11 4:37 PM, Dmitry Olshansky wrote: OK in this particular benchmark, we are slighlty behind Google inc. :) Namely RE2 and irregex. On my machine RE2 is ~5 sec while FReD does the job in ~7sec. As for irregex, ... uhm-oh I haven't actually tested it (failed to just compile) but it beats RE2 in this test by some ~30%. I'm judging by this page, RE2 I mentioned is "C++ GNU g++ #2" but with OpenMP declarations stripped: http://shootout.alioth.debian.org/u32/performance.php?test=regexdna Damn looks like we could be #4... these things change too fast :( Anyway, the rest of competition is not even close, and I still haven't spent all of my tricks. Sounds great! I advise you to invest effort in reducing the 25% handicap to <1%. As regexen have a fairly standardized interface, speed is the most impactful differentiatior people look at. Andrei
Re: FReD is ready for review
On 14.09.2011 1:55, Vladimir Panteleev wrote:
On Wed, 14 Sep 2011 00:49:47 +0300, Dmitry Olshansky
wrote:
However when it comes to some serious business like matching charsets
and doing ambiguous control flow it starts losing to more superior
design of the default engine.
Ah, okay. I thought compile-time regex was the same as the default
engine, but without the runtime parsing and bytecode interpretation(?).
Let me explain a bit. The default as chosen is fairly advanced NFA
engine which features:
- never backtracks and consequently decodes each UTF8/16/32 character
only once;
- as side effect doesn't support fully combinatorial backreferences
(why would someone use 'em anyway);
- guaranteed O(N*M) time on input with M being "size" of pattern;
This also opens up matching directly on buffered streams... but back to
the point.
There is also a slower traditional backtracking engine, it still faster
then many other engines out there but it ebbs out on some patterns like
.*.*.*Z in text with no 'Z', precisely because of combinatorial nature
of backtracking.
Then C-T is built on top of backtracking, just because it was much
easier this way :)
It's indeed replacing bytecode interpretations with hardcoded code which
is exceptionally fast, but the prime time consumer in real patterns is
usually this memoize/return. C-T regex is still a bit experimental
though and going to be improved over time.
Last but not least there is also completely dumb (as in dead simple and
fast) kickstart engine that does all of heavy lifting iff pattern starts
with something more or less constant (e.g. it does 50% of job in regex-dna).
And you can just parse at compile time and use default run-time engine
for matching:
enum r = regex("whatever");
--
Dmitry Olshansky
Re: cleaning up dsource
well thats an awkward situation: an abondonned site with a lot of abondonned projects... maybe someone knows the site-owner and can ask him to give ownership to someone else(preferably still active )? I'm always ready to do some cleaning up.
Re: FReD is ready for review
On Wed, 14 Sep 2011 00:49:47 +0300, Dmitry Olshansky wrote: However when it comes to some serious business like matching charsets and doing ambiguous control flow it starts losing to more superior design of the default engine. Ah, okay. I thought compile-time regex was the same as the default engine, but without the runtime parsing and bytecode interpretation(?). -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: FReD is ready for review
On 14.09.2011 1:36, Jonathan M Davis wrote: On Tuesday, September 13, 2011 14:04 Dmitry Olshansky wrote: Speaking of source there are few artifacts that should end up in std.uni and not in std.regex: CodepointSet and CodepointTrie, and unicode property tables. I'd rather have them all accessible to user, but their interface is admittedly clunky, I'm open to ideas on better API. I suspect that there's value in reviewing the unicode stuff separately, and if it affects std.regex' API at all (as opposed to being simply an implementation detail), I'd suggest that we review and sort out the unicode stuff before we review then new std.regex, since that would then have definite impact on std.regex, and it affects a lot more than just std.regex. It doesn't affect API at all, but an important implementation detail. Particularly one can't get reasonable performance w/o unicode incorporated as an implementation detail yet I feel there should be a more general interface to it. Otherwise everyone willing to tackle unicode would have to, for instance, duplicate all of unicode property tables, and that's some 100Kb we are looking at. If the unicode stuff is entirely an implementation detail of std.regex and is not in the API, then we can review the unicode stuff separately and make std.regex use the stuff in std.uni once it's in there, but if you're doing major unicode stuff, I think that that's significant enough to merit its own review. It could be done in two steps, if I was to choose which way to go I'd first folded in std.regex then moved all its hidden unicode stuff to std.uni. It's mostly about character classification and about doing it fast. -- Dmitry Olshansky
Re: FReD is ready for review
On 14.09.2011 1:42, Vladimir Panteleev wrote: On Wed, 14 Sep 2011 00:37:28 +0300, Dmitry Olshansky wrote: Anyway, the rest of competition is not even close, and I still haven't spent all of my tricks. That's really cool... I noticed that d_dna.d doesn't use regexCt, would that make any difference or am I overestimating the advantage of compile-time codegen? In this particular case it may very well much faster actually. The thing about this benchmark is that it exposes all the nasty constant overhead there is in the engine. On the other hand C-T regex doesn't have most of "what do we do next" overhead so it should be faster. However when it comes to some serious business like matching charsets and doing ambiguous control flow it starts losing to more superior design of the default engine. -- Dmitry Olshansky
Re: FReD is ready for review
On Wed, 14 Sep 2011 00:37:28 +0300, Dmitry Olshansky wrote: Anyway, the rest of competition is not even close, and I still haven't spent all of my tricks. That's really cool... I noticed that d_dna.d doesn't use regexCt, would that make any difference or am I overestimating the advantage of compile-time codegen? -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: FReD is ready for review
On 14.09.2011 1:18, Vladimir Panteleev wrote: Hi, thanks for your hard work! On Wed, 14 Sep 2011 00:04:08 +0300, Dmitry Olshansky wrote: https://github.com/downloads/blackwhale/FReD/FReD.zip Doesn't seem to compile on the latest DMD, due to switch case fallthrough. Agh! On serious note it is fixed in some recent pull request, but that was hopelessly late for getting in this release. Goodies include popular regex-dna benchmark, by my measures we should be at least #3 among single threaded solutions. This is awesome, but if it's not a secret, who are the first two, and how far behind is FReD? Does this regard regular or compile-time regex? OK in this particular benchmark, we are slighlty behind Google inc. :) Namely RE2 and irregex. On my machine RE2 is ~5 sec while FReD does the job in ~7sec. As for irregex, ... uhm-oh I haven't actually tested it (failed to just compile) but it beats RE2 in this test by some ~30%. I'm judging by this page, RE2 I mentioned is "C++ GNU g++ #2" but with OpenMP declarations stripped: http://shootout.alioth.debian.org/u32/performance.php?test=regexdna Damn looks like we could be #4... these things change too fast :( Anyway, the rest of competition is not even close, and I still haven't spent all of my tricks. Though I used 64bit VM linux box, on win32 sadly it runs out of memory on the same machine (false pointers?). If I'll find time to port my memory debugger to D2 before someone else figures it out, I'll have a look at this. Thanks, by my cut and paste tests shows the problem is caused by allocating large buffers in replace loop. Probably a better solution to this is alternative replace function that doesn't allocate on each call but uses a OutputRange. -- Dmitry Olshansky
Re: FReD is ready for review
On Tuesday, September 13, 2011 14:04 Dmitry Olshansky wrote: > Speaking of source there are few artifacts that should end up in std.uni > and not in std.regex: > CodepointSet and CodepointTrie, and unicode property tables. > I'd rather have them all accessible to user, but their interface is > admittedly clunky, I'm open to ideas on better API. I suspect that there's value in reviewing the unicode stuff separately, and if it affects std.regex' API at all (as opposed to being simply an implementation detail), I'd suggest that we review and sort out the unicode stuff before we review then new std.regex, since that would then have definite impact on std.regex, and it affects a lot more than just std.regex. If the unicode stuff is entirely an implementation detail of std.regex and is not in the API, then we can review the unicode stuff separately and make std.regex use the stuff in std.uni once it's in there, but if you're doing major unicode stuff, I think that that's significant enough to merit its own review. - Jonathan M Davis
Re: FReD is ready for review
On Tuesday, September 13, 2011 14:25 Vladimir Panteleev wrote: > On Wed, 14 Sep 2011 00:18:03 +0300, Vladimir Panteleev > > wrote: > > Doesn't seem to compile on the latest DMD, due to switch case > > fallthrough. > > Sorry, I had -wi enabled in my build environment. (Why would -wi cause > fatal errors, though? Sounds like a bug.) -wi shouldn't cause fatal errors, but anything going into Phobos needs to build with -w. So, if the proposed changes don't build with -w, that needs to be fixed. - Jonathan M Davis
Re: FReD is ready for review
On Wed, 14 Sep 2011 00:18:03 +0300, Vladimir Panteleev wrote: Doesn't seem to compile on the latest DMD, due to switch case fallthrough. Sorry, I had -wi enabled in my build environment. (Why would -wi cause fatal errors, though? Sounds like a bug.) -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: FReD is ready for review
Dmitry Olshansky: > Goodies include popular regex-dna benchmark, by my measures we should be > at least #3 among single threaded solutions. This is rather good. The #1 is of JavaScript-V8 that has received a significant amount of engineering efforts. > Though I used 64bit VM > linux box, on win32 sadly it runs out of memory on the same machine > (false pointers?). This is not so good. Even if this problem is not solved soon, it will be good to know its real cause. > P.S. I'm taking a seat somewhere in review queue, and busying myself > with newspaper :) *Gives some fine white-golden tea* Bye, bearophile
Re: FReD is ready for review
Hi, thanks for your hard work! On Wed, 14 Sep 2011 00:04:08 +0300, Dmitry Olshansky wrote: https://github.com/downloads/blackwhale/FReD/FReD.zip Doesn't seem to compile on the latest DMD, due to switch case fallthrough. Goodies include popular regex-dna benchmark, by my measures we should be at least #3 among single threaded solutions. This is awesome, but if it's not a secret, who are the first two, and how far behind is FReD? Does this regard regular or compile-time regex? Though I used 64bit VM linux box, on win32 sadly it runs out of memory on the same machine (false pointers?). If I'll find time to port my memory debugger to D2 before someone else figures it out, I'll have a look at this. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: clear()
On 14.09.2011 1:12, Alix Pexton wrote: On 13/09/2011 17:05, sclytrack wrote: Rename "clear" to "blank" in D version 3. Like blank a CD it is ready for writing but not ready for use. It is ready for use after you have burned something on it. Unless you consider burning a CD using it. blank(); wipe(); //?? A... my favorite still: nuke(x); //now it's obvious x is not valid ;) -- Dmitry Olshansky
Re: D in the TIOBE top
I trust Tiobe. Tiobe has recently been correct about Objective-C and C#, in regard to their popularity increase. Why would it not be correct about D'? On Tue, Sep 13, 2011 at 3:07 PM, Sean Kelly wrote: > On Sep 13, 2011, at 8:07 AM, Steven Schveighoffer wrote: > > > On Mon, 12 Sep 2011 20:11:57 -0400, Jeff Nowakowski > wrote: > > > >> On 09/12/2011 07:06 PM, Andrei Alexandrescu wrote: > >>> > >>> If you were in my position, wouldn't you have posted that > >>> article? > >> > >> I hope I wouldn't have published it, since I don't like misleading > marketing. > > > > Since when is marketing *ever* not misleading? I've yet to see the > marketing campaign where Coke or Pepsi touts how their products make you > fat. > > Marketing and advertising are not the same thing.
Re: clear()
On 13/09/2011 17:05, sclytrack wrote: Rename "clear" to "blank" in D version 3. Like blank a CD it is ready for writing but not ready for use. It is ready for use after you have burned something on it. Unless you consider burning a CD using it. blank(); wipe(); //?? A...
FReD is ready for review
FReD ( Fast Regular expressions for D) is a GSOC project proposed as source level compatible replacement for std.regex. Needless to say it is also superior in many ways ;) Source + docs + goodies packaged here: https://github.com/downloads/blackwhale/FReD/FReD.zip Goodies include popular regex-dna benchmark, by my measures we should be at least #3 among single threaded solutions. Though I used 64bit VM linux box, on win32 sadly it runs out of memory on the same machine (false pointers?). Speaking of source there are few artifacts that should end up in std.uni and not in std.regex: CodepointSet and CodepointTrie, and unicode property tables. I'd rather have them all accessible to user, but their interface is admittedly clunky, I'm open to ideas on better API. Notable caveats: - backreferences allowed only to locally unique groups, e.g. \b(\w+)\b\1 is allowed, same w/o any of \b - not. - replace with delegeate now takes Captures!R where R is e.g. string. This is due to having few types of engine and RegexMatch!X respectively. Previous signature allowed a certain measure of abuse e.g. you could have done a couple of popFronts on it matcher(!) in this delegate. However in most cases the code inside can be left as is. Otherwise it should work with existing code after replacing imports. P.S. I'm taking a seat somewhere in review queue, and busying myself with newspaper :) -- Dmitry Olshansky
Re: D in the TIOBE top
On Sep 13, 2011, at 8:07 AM, Steven Schveighoffer wrote: > On Mon, 12 Sep 2011 20:11:57 -0400, Jeff Nowakowski wrote: > >> On 09/12/2011 07:06 PM, Andrei Alexandrescu wrote: >>> >>> If you were in my position, wouldn't you have posted that >>> article? >> >> I hope I wouldn't have published it, since I don't like misleading marketing. > > Since when is marketing *ever* not misleading? I've yet to see the marketing > campaign where Coke or Pepsi touts how their products make you fat. Marketing and advertising are not the same thing.
Re: D in the TIOBE top
On 9/13/2011 8:07 AM, Steven Schveighoffer wrote: Since when is marketing *ever* not misleading? I don't think that's quite a fair statement. Good marketing informs a customer about a product that may be just the thing for his needs. With any product, there are different ways to view it, positive and negative, and they aren't wrong or misleading, just different. As for popularity of a programming language, no two people will even agree on a definition of it, let alone an accurate means of measuring it. Tiobe explains their methodology, and readers are free to interpret it as they see fit. I don't see that as misleading.
Re: How can I use D to develop web application?
"zsxxsz" wrote in message news:j4o0nn$2igh$1...@digitalmars.com... > == Quote from Adam Ruppe (destructiona...@gmail.com)'s article >> zsxxsz wrote: >> > I think the cgi module is lower effecient. >> That's not really true. The reason CGI has a perception of being >> slow is because it's used by slow languages most the time, but with >> D, it's fast. > I don't think so. Because I've been using C to write cgi. One http request > one > fork cgi which is the reason of slowly performance cgi. The fork process > is > expensive for any OS. Accessing a DB, using JS, and sending a page across the internet are all far, far slower than forking.
Re: How can I use D to develop web application?
Thank you very much. I think the cgi module is lower effecient. I found fcgi(http://www.dsource.org/projects/fastcgi4d) and mango(http://www.dsource.org/projects/mango) which support servlet. But they don't support D2, anyone else can merge them to D2? Why don't you port them yourself?
Re: Clean-up of std.socket
On Tue, 13 Sep 2011 18:52:02 +0300, David Nadlinger wrote: Which kind of »provided details« would be interesting for you? Something like this post, thanks. If not in the standard library, where else? Granted, the difference is probably only going to cause problems in unit tests (since actual programs shouldn't rely on the exact socket timings anyway), but pushing the burden of writing platform-specific workaround codeto the std.socket users doesn't seem like a good solution to me either. The obvious problem with such hacks is forward-compatibility - the problem might be fixed in Windows 8/9/etc. and no one might notice. I guess it wouldn't be hard to add an unit test for this. Then, there's the question of expectations. For example, someone porting their code from another language might already account for this oddity, which would cause timeouts to be off 500ms in the other direction. Does any other language's standard library do something like this? Personally, I don't have a strong opinion one way or another, but I do think that if the hack is left in, it should be well-documented and its necessity be easily verifiable. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: How can I use D to develop web application?
zsxxsz wrote: > The fork process is expensive for any OS. Have you actually measured this? > I feel the cgi library is too simple, so I doubt wether it supports > fcgi for Apache, Nginx or other Webserver. Have you actually looked at it? I've personally used it on three web servers (IIS, Apache, and an embedded server) across two operating systems (Windows and Linux) and three protocols (CGI, FastCGI, and raw http). It'll probably work on other servers and operating systems too, but I haven't tried yet.
Re: How can I use D to develop web application?
== Quote from Adam Ruppe (destructiona...@gmail.com)'s article > zsxxsz wrote: > > I think the cgi module is lower effecient. > That's not really true. The reason CGI has a perception of being > slow is because it's used by slow languages most the time, but with > D, it's fast. I don't think so. Because I've been using C to write cgi. One http request one fork cgi which is the reason of slowly performance cgi. The fork process is expensive for any OS. > That said, if you still want to use fast cgi, just use -version=fastcgi > when compiling with that same module. I feel the cgi library is too simple, so I doubt wether it supports fcgi for Apache, Nginx or other Webserver.
Re: How can I use D to develop web application?
zsxxsz wrote: > I think the cgi module is lower effecient. That's not really true. The reason CGI has a perception of being slow is because it's used by slow languages most the time, but with D, it's fast. That said, if you still want to use fast cgi, just use -version=fastcgi when compiling with that same module.
Re: Support for feeding data to engine threads?
== Quote from David Nadlinger (s...@klickverbot.at)'s article > On 9/12/11 7:23 PM, Jerry Quinn wrote: > > Am I missing something or do I need to roll a shared queue object? > A concurrent queue (SharedQueue?) would be a nice addition to Phobos > regardless, imho. > David A lock-free queue is one of the examples in TDPL if I recall correctly. Maybe we should just put a slightly embellished version of that in.
Re: How can I use D to develop web application?
== Quote from sclytrack (sclytr...@idiot.com)'s article > https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff > cgi > == Quote from zsxxsz (zsx...@263.net)'s article > > I find D is a excellent program lang. I usualy use C/C++, sometime using > > Java/Php. I hate C/C++ for its lowerly effecient development, and I have > > Java/Php for it virtual machine. So, I love D very much. But when I want to > > write some web program, I can't find any useful resources. Anybody else can > > tell me libraries for web applications? > > Thanks > > zsxxsz Thank you very much. I think the cgi module is lower effecient. I found fcgi(http://www.dsource.org/projects/fastcgi4d) and mango(http://www.dsource.org/projects/mango) which support servlet. But they don't support D2, anyone else can merge them to D2? zsxxsz
Re: clear()
Rename "clear" to "blank" in D version 3. Like blank a CD it is ready for writing but not ready for use. It is ready for use after you have burned something on it. Unless you consider burning a CD using it. blank();
Re: Clean-up of std.socket
* David Nadlinger added functionality to work around an apparent oddity of the Windows socket implementation (see WINSOCK_TIMEOUT_SKEW). Although the hack is documented, I'm a bit uncomfortable with that there are no provided details or instructions on how to reproduce the experiments and measurements which led to the inclusion of this hack. Which kind of »provided details« would be interesting for you? The WinSock receive timeout duration seems to be be off by half a second on all Windows boxes I and other helpful people on IRC tested (no personal firewall/antivirus software/… involved), and that's about it. A test case is trivial to write, e.g. https://gist.github.com/1211819. I tried hard to find any official information about the issue, but except for a few other people having stumbled across the issue, I couldn't really turn up anything (see e.g. http://us.generation-nt.com/answer/recv-timeout-so-rcvtimeo-plus-half-second-help-26653302.html). (There's also the question whether a language library's purpose includes working around apparent bugs in platforms' implementations.) If not in the standard library, where else? Granted, the difference is probably only going to cause problems in unit tests (since actual programs shouldn't rely on the exact socket timings anyway), but pushing the burden of writing platform-specific workaround codeto the std.socket users doesn't seem like a good solution to me either. David
Re: How can I use D to develop web application?
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff cgi == Quote from zsxxsz (zsx...@263.net)'s article > I find D is a excellent program lang. I usualy use C/C++, sometime using > Java/Php. I hate C/C++ for its lowerly effecient development, and I have > Java/Php for it virtual machine. So, I love D very much. But when I want to > write some web program, I can't find any useful resources. Anybody else can > tell me libraries for web applications? > Thanks > zsxxsz
Re: Line lengths discussed in eclipse forum and on reddit
On Tuesday, September 13, 2011 17:15:16 Simen Kjaeraas wrote: > On Tue, 13 Sep 2011 07:53:24 +0200, Jouko Koski > > wrote: > > "Andrei Alexandrescu" wrote: > >> Anyhow, let's move on to date formats. I'm archiving some receipt > >> right > >> now, and I find the mm/dd/yy notation notation quite unpleasant... > > > > Touché! :-) > > I have converted fully to ISO-8601, the *only* reasonable way to write > dates. Indeed. Both the American and European way of writing dates are abysmal. ISO-8601 (-MM-DD), on the other hand, is unambiguous and sorts wonderfully. - Jonathan M Davis
Re: Support for feeding data to engine threads?
On 9/12/11 7:23 PM, Jerry Quinn wrote: Am I missing something or do I need to roll a shared queue object? A concurrent queue (SharedQueue?) would be a nice addition to Phobos regardless, imho. David
Re: clear()
On Mon, 12 Sep 2011 17:36:09 -0400, Michel Fortin
wrote:
On 2011-09-12 20:04:05 +, "Steven Schveighoffer"
said:
How does an author of a struct "not expect" the destructor to be
called on
an .init version of itself? Isn't that an error? Do you have a
counter-case?
struct S
{
@disable this();
}
That is a brand new feature that was added after clear was implemented,
and I'm not sure of the semantics yet. I'd suspect that clear probably
should be statically disallowed if no default ctor is allowed.
If what Andrei says is true, however, then assigning to .init is still
feasible, and should be able to be destructed.
I hated having clear call the default constructor.
… because you use 'clear' to release resources. Which makes sense, but
goes contrary to expectations for something called 'clear'. What I am
saying is that 'clear' shouldn't be used to release resources, something
else should be used for that.
I agree the name clear isn't ideal. I don't think we can change it now,
though.
But we need *something* that releases resources without reacquiring them.
The case for reinitializing resources after releasing them is pretty
uncommon. And in those cases, the object itself can support that, we
don't need a language solution.
I think that's
entirely the wrong thing to do. clear + deallocate replaces delete,
wit h
clear being the finalization of the data.
Well, if you really wanted clear + deallocate to replace delete
(regardless of the suitability of the name), don't make it so it looks
like you can reuse the object/struct afterward. Saying it is assigning
the 'init' state makes people believe the object will still be in a
usable state although actually there is no guaranty of that, and that's
true for a struct too (as shown above).
You can only reuse the object after if it's a struct. If it's an object,
you cannot. I think that's pretty much universal (does not depend on the
implementation of the struct/class).
I think the point of clear is, you are deallocating, and no longer using
that item. Using it afterwards is not supported without reinitialization.
Also, if 'clear' is meant to replace 'delete', it should give an error
when called on non-GC memory because there's no way you can prevent the
destructor from being called a second time otherwise.
Clear is not meant to replace delete, clear + deallocate is.
The notion that the library provides a mechanism to do what clear does
*without* deallocation is a new concept. That concept extends very well
into non-heap-based types.
-Steve
Re: Line lengths discussed in eclipse forum and on reddit
On Tue, 13 Sep 2011 07:53:24 +0200, Jouko Koski wrote: "Andrei Alexandrescu" wrote: Anyhow, let's move on to date formats. I'm archiving some receipt right now, and I find the mm/dd/yy notation notation quite unpleasant... Touché! :-) I have converted fully to ISO-8601, the *only* reasonable way to write dates. -- Simen
Re: Line lengths discussed in eclipse forum and on reddit
On Tue, 13 Sep 2011 02:52:19 +0200, Adam Ruppe wrote: Andrei Alexandrescu wrote: Surely you're jesting. Partially. For the most part, the metric system is better for science, but for day to day stuff? Poo. Lots of silly things to remember and the numbers don't line up well to regular stuff. Could be due to the fact that I'm more used to it, but it's more likely that my preferences are objectively superior to anyone who disagrees :) For what it's worth, I use metric all the time, it being the standard around these here parts (Norway). But - when speaking English, I can't help but think in inches, feet and pounds (not so much drachms, roods and gills). It feels better matched with the language. (Feel free to interpret that in any way you may wish) -- Simen
How can I use D to develop web application?
I find D is a excellent program lang. I usualy use C/C++, sometime using Java/Php. I hate C/C++ for its lowerly effecient development, and I have Java/Php for it virtual machine. So, I love D very much. But when I want to write some web program, I can't find any useful resources. Anybody else can tell me libraries for web applications? Thanks zsxxsz
Re: D in the TIOBE top
On Mon, 12 Sep 2011 20:11:57 -0400, Jeff Nowakowski wrote: On 09/12/2011 07:06 PM, Andrei Alexandrescu wrote: If you were in my position, wouldn't you have posted that article? I hope I wouldn't have published it, since I don't like misleading marketing. Since when is marketing *ever* not misleading? I've yet to see the marketing campaign where Coke or Pepsi touts how their products make you fat. Watch the movie Crazy People. It's a good movie about being truthful in advertising :) -Steve
Re: Goto into catch blocks
On 09/13/2011 08:58 AM, Iain Buclaw wrote:
== Quote from Timon Gehr (timon.g...@gmx.ch)'s article
On 09/13/2011 12:27 AM, Iain Buclaw wrote:
I have been merging Phobos that got released with the latest DMD release into
GDC. And couldn't help but notice this nostalgic error I implemented a while
back:
std/format.d:1520: Error: cannot goto into catch block
Line of concern in phobos:
https://github.com/D-Programming-Language/phobos/blob/master/std/format.d#L1539
Part of spec which error implements:
http://www.digitalmars.com/d/2.0/statement.html#GotoStatement
Where does it say that a goto into a catch block is categorically
banned? It only says that a goto cannot skip a variable initialization.
Which it does in this situation (what is initialising UtfException e?).
catch(Type){}
and
catch{}
are valid forms too. Neither one contains a declaration.
Sure, usually a goto into a catch block means that someone is abusing
exceptions for regular control flow, but if you just want a quick and
dirty hack, or if a third-party API forces you to, I don't think the
language should stand in your way.
In terms of codegen for such, you will still pass through any cleanup that was
generated when the catch block ends (ie: builtin unwind routines).
OK, that is a reason. Thanks. What exactly is done in the cleanup block?
Re: Clean-up of std.socket
On Tue, 13 Sep 2011 13:12:47 +0100, Vladimir Panteleev wrote: On Tue, 13 Sep 2011 12:59:35 +0300, Regan Heath wrote: I'm thinking of making all of Address.to(Addr|HostName|Port|Service)String return null on failure for consistency. Sounds good? In some of these cases you'll be returning null for incorrect input (essentially) Why do you say that? Let's look at each of those functions. My bad, I didn't take a good look at the source and assumed these were static methods converting to/from string representation or similar.
Re: Clean-up of std.socket
On Tue, 13 Sep 2011 12:59:35 +0300, Regan Heath wrote: I'm thinking of making all of Address.to(Addr|HostName|Port|Service)String return null on failure for consistency. Sounds good? In some of these cases you'll be returning null for incorrect input (essentially) Why do you say that? Let's look at each of those functions. An Address class encapsulates a socket address that has already been parsed/resolved/retrieved to a binary numeric format. Address.toAddrString returns a numeric string representation of the host address. For IPv4, it means taking the 32-bit value and formatting it to the common %d.%d.%d.%d format. I don't see how that could fail, except for catastrophic conditions (out-of-memory etc). Same with IPv6 - AFAIK any 16-byte sequence can be represented as an IPv6 string (%02x:%02x:%02x...). Same with Address.toPortString. The only question regarding the above is with address families which do not have a meaningful host address/port, for example Unix domain sockets. Address.toHostNameString was the point of our discussion. The method attempts a reverse lookup, which can be expected to fail. Address.toServiceString is similar, however it doesn't need to perform a network lookup - it only needs to check the host's database of service names. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Line lengths discussed in eclipse forum and on reddit
Adam D. Ruppe Wrote: > > Fuck these stupid imperial units. > > Imperial units are superior. Only america uses them. You just learn international standards.
Re: Clean-up of std.socket
On 13.09.2011 2:44, Adam Burton wrote: Adam Burton wrote: Jonathan M Davis wrote: On Monday, September 12, 2011 14:53 Adam Burton wrote: Simen Kjaeraas wrote: On Mon, 12 Sep 2011 23:13:29 +0200, Adam Burton wrote: I quite like the idea of void[] representing a chunk of memory that could contain anything, serialized data; an array of ubytes or strings, and allow ubyte[] to just represent an array of ubytes (after all is serialized data an array of bytes or a block of data containing various data types cramed into it in some organised manner?). In the end it is just a convention I like, not attached to it or anything, and D tends to discourage working based on conventions anyway, I guess I am somewhat playing devil's advocate in this paragraph :-). I believe the reasons for not using void[] is exactly that it could contain anything, including pointers, which likely would not be valid in the other end. How does a ubyte[] prevent that? If you've serialized an int (or even a pointer) then ubyte[] is just as bad, ubyte[0] would seem to indicate a meaningful unit of data itself when it's actually just the first byte of an int (or pointer). void[] at least says "I don't know, I just know the start and how long, you figure it out, I presume I have somewhere to go to be given context". With void[], you can pass something like int*[] to it without having to worry about converting it, because the conversion is implicity. ubyte[], on the other hand, forces you to do the conversion explicitly. So yes, you could still make it so that the ubyte[] passed in contains pointers, but you have to do it explicitly, whereas with void[], it'll take any array without complaining. - Jonathan M Davis Fair enough that's more clear, I hadn't actually thought of an array of pointers as I was thinking of a pointer forced into ubyte[] with other data types. I suppose that'll help remind people to double check what they are sending but if you are going to send int*[] down a socket then you're probably gonna put cast(ubyte[]) without looking anyway. Just a thought then, rather than using ubyte[] and casting to force someone to check (and possibly encourage a bad habit of automatically putting in a cast without checking, through fustration or over confidence) make send and receive templates methods that don't accept types we are unable to determine how to handle (like pointers and classes)? Maybe even give a static assert with an error message explaining pointers etc are not allowed? Don't forget that there is also network byte order vs host machine byte order. In other words everything should be (de)serialized, except plain bytes/chars. There was a talk of making result of e.g. htonl a special type so that it can be send directly w/o cast, dunno if it's that useful. As a safety net untill complementary call to ntohl this special type is unusable for anything else except storage/copy. Actually now when I recalled it, it seems to me like a good thing. Being able to catch wrong byte order statically is nice, since it's a hard to track bug (e.g. missing both of hton*/ntoh*). -- Dmitry Olshansky
Re: Line lengths discussed in eclipse forum and on reddit
Sean Kelly Wrote: > On Sep 9, 2011, at 8:49 AM, Andrei Alexandrescu wrote: > > > http://www.reddit.com/r/programming/comments/k7pwu/eclipse_default_line_length_of_80_chars_outdated/ > Does anyone actually like having an editor auto line-wrap code? I have scintilla with custom soft-wrapping code. I write winapi calls in one line and it looks ok.
Re: Line lengths discussed in eclipse forum and on reddit
Imperial units are superior. "It's zero degrees out." 0 F is actually pretty cold. 0 C is slightly chilly, but nothing to get worked up about. Real men use Kelvin. 0 K is cold. Inches beat centimeters any day of the week. Just like with kilometers, centimeters are useless. (ever gone on a kilometer run? Weak. Mile runs are where it's at.) I always use furlongs/fortnight when quoting speeds to Americans, to make them feel comfortable. There's a wonderful conversion factor: 1 furlong per fortnight = 1 cm per minute.
Re: Clean-up of std.socket
On Mon, 12 Sep 2011 23:10:29 +0100, Vladimir Panteleev wrote: On Mon, 12 Sep 2011 20:55:42 +0300, David Nadlinger wrote: As discussed on IRC, throwing on reverse lookup failure seems very wrong to me, as it is certainly expected. In my opinion, the best solution would be to return null (empty string), but I am not certain if it should still throw if something went wrong during lookup (besides the IP address not being found). I'm thinking of making all of Address.to(Addr|HostName|Port|Service)String return null on failure for consistency. Sounds good? This is one of those things I haven't managed to come to a definite opinion on myself. In some of these cases you'll be returning null for incorrect input (essentially) which is something you could argue warrants an exception, or does it warrant an assertion? The line, to me, between where to use assert and when to throw often blurs. I guess at the end of the day you should throw in cases where the arguments may have been 'user' input.. but that seems to me, to be all the time, because you cannot be certain. So, that leaves us using assert only for 'internal' functions, where we know the arguments are not user input, or should have been sanitized already by our own code. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Clean-up of std.socket
On Mon, 12 Sep 2011 18:55:42 +0100, David Nadlinger wrote: On 9/12/11 4:11 PM, Vladimir Panteleev wrote: * Currently, reverse hostname lookup functions throw on failure. Such lookups are not reliable and are expected to sometimes fail, so perhaps a more appropriate behavior would be to return the requested IP address unchanged, or a value indicating failure (null or false). As discussed on IRC, throwing on reverse lookup failure seems very wrong to me, as it is certainly expected. In my opinion, the best solution would be to return null (empty string), but I am not certain if it should still throw if something went wrong during lookup (besides the IP address not being found). I agree. To me, throwing on lookup failure will end up being "using exceptions for flow control" (which is a well known 'bad'(TM) thing, right?) for callers specifically who will almost always want to/have to catch the (hopefully specific) exception and handle it. Or, to look at it another way it is using an exception for something which is not actually exceptional, which just seems wrong. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: D in the TIOBE top
On 9/12/2011 11:38 AM, Jeff Nowakowski wrote: Lame marketing, Andrei. But hey, it works, right? I think D is doing spectacularly well considering that there is $0 spent on marketing it.
Re: Goto into catch blocks
== Quote from Timon Gehr (timon.g...@gmx.ch)'s article
> On 09/13/2011 12:27 AM, Iain Buclaw wrote:
> > I have been merging Phobos that got released with the latest DMD release
> > into
> > GDC. And couldn't help but notice this nostalgic error I implemented a
> > while back:
> >
> > std/format.d:1520: Error: cannot goto into catch block
> >
> >
> > Line of concern in phobos:
> > https://github.com/D-Programming-Language/phobos/blob/master/std/format.d#L1539
> >
> > Part of spec which error implements:
> > http://www.digitalmars.com/d/2.0/statement.html#GotoStatement
> Where does it say that a goto into a catch block is categorically
> banned? It only says that a goto cannot skip a variable initialization.
Which it does in this situation (what is initialising UtfException e?).
> catch(Type){}
> and
> catch{}
> are valid forms too. Neither one contains a declaration.
> Sure, usually a goto into a catch block means that someone is abusing
> exceptions for regular control flow, but if you just want a quick and
> dirty hack, or if a third-party API forces you to, I don't think the
> language should stand in your way.
In terms of codegen for such, you will still pass through any cleanup that was
generated when the catch block ends (ie: builtin unwind routines).
Think of your latter example as being rewritten as:
try
{
// questionable user code
}
catch
{
try
{
// user catch code
}
finally
{
// compiler generated clean-up block
}
}
Regards
Iain
