On 6/21/13 4:02 PM, Walter Bright wrote:
> On 6/21/2013 3:35 PM, Andrei Alexandrescu wrote:
>> On 6/21/13 3:22 PM, Adam D. Ruppe wrote:
>>> Just for laughs I just slapped together a strstr
>>
>> Post it and I'll destroy it.
>
> Can I play, too? Mine from the Digital Mars C library. Haven't looked at
> it since 2001.
> ==================================================
>
> /*_ strstr.c */
> /* Copyright (C) 1985-2001 by Digital Mars */
> /* All Rights Reserved */
> /* www.digitalmars.com */
> /* Written by Walter Bright */
>
> #include <stdio.h>
> #include <ctype.h>
> #include <stddef.h>
> #include <string.h>
> #include <stdlib.h>
>
> #if 0 /* Smaller but slower under many circumstances. */
> char *strstr(const char *s1,const char *s2)
> { size_t len2;
> size_t len1;
> char c2 = *s2;
>
> len1 = strlen(s1);
> len2 = strlen(s2);
> if (!len2)
> return (char *) s1;
> while (len2 <= len1)
> {
> if (c2 == *s1)
> if (memcmp(s2,s1,len2) == 0)
> return (char *) s1;
> s1++;
> len1--;
> }
> return NULL;
> }
> #else

I won't comment on the B-M implementation. This brute force implementation has the problem of calling strlen on both strings upfront, which is arguably unnecessary. Although it doesn't affect complexity, it is an inefficiency hard to recover from. (The tradeoff is that memcmp will help with that.)

Andrei

On 6/22/13 12:28 PM, Adam D. Ruppe wrote:
> On Saturday, 22 June 2013 at 16:38:31 UTC, Andrei Alexandrescu wrote:
> Huh, even the shortest impl I can think of is about the same length:
>
> inout(char)* mystrstr(inout(char)* haystack, const(char*) needle) {
> assert(haystack !is null);
>
> if(needle is null)
> return haystack;
>
> while(*haystack) {
> auto h = haystack;
> const(char)* n = needle;
> while(*n == *h && *n && *h) {
> h++;
> n++;
> }
> if(*n == 0)
> return haystack;
> haystack++;
> }
>
> return null;
> }
>
>
> I like this a lot better because it is more straightforward.

Still buggy. The empty string must be a prefix of any string including the empty string.

I describe the canonical implementation of substring brute for string search as far as I see it http://www.serversidemagazine.com/news/10-questions-with-facebook-research-engineer-andrei-alexandrescu/.


Andrei

On Sunday, 23 June 2013 at 16:07:05 UTC, Andrei Alexandrescu wrote:
> Still buggy. The empty string must be a prefix of any string including the empty string.

Huh. Well, that makes sense. Just change while to do while and you've got that. Probably compiles to exactly the same code as your implementation in the link at that point.

But this probably told you more about my methods than getting it right the first time would have: I'll just slap something together that's good enough for the test case(s) fed to it and then change it if new stuff arises where it fails. One of the nice things about software is you generally don't have to get it right the first time since it is so easy to change.

This is TDD-lite isn't it! lol

> http://www.serversidemagazine.com/news/10-questions-with-facebook-research-engineer-andrei-alexandrescu/.

I definitely remember reading that when you posted it a while ago because I have code that does that <?d writeln("hello, world"); ?> laying around.

http://arsdnet.net/dcode/dhp.d

It works by just reading the file and translating everything outside the <?d?> into a giant writeln(string literal), pasting in the D code, then compile+running it, inserting a bunch of imports so it works.

dom.d now supports those kinds of tags, it could probably be even nicer, especially with a D lexer so it doesn't think "?>" is the same as ?>. But as I'm sure I said then, this is a bad idea anyway since mixing code and html data leads to ugliness, whether the code is php or D.

On 6/23/13 9:21 AM, Adam D. Ruppe wrote:
> http://arsdnet.net/dcode/dhp.d
>
> It works by just reading the file and translating everything outside the
> <?d?> into a giant writeln(string literal), pasting in the D code, then
> compile+running it, inserting a bunch of imports so it works.
>
> dom.d now supports those kinds of tags, it could probably be even nicer,
> especially with a D lexer so it doesn't think "?>" is the same as ?>.
> But as I'm sure I said then, this is a bad idea anyway since mixing code
> and html data leads to ugliness, whether the code is php or D.

Nice! (BTW:

foreach(ln; stdin.byLine) {
		string line = ln.idup ~ "\n";

is simpler written as

foreach(ln; stdin.byLine(KeepTerminator.yes)) {
		string line = ln.idup;

.)

Would be awesome if an Apache extension would make it trivial to write Web pages in D.


Andrei

On Sunday, 23 June 2013 at 16:28:56 UTC, Andrei Alexandrescu wrote:
> foreach(ln; stdin.byLine(KeepTerminator.yes)) {

Yeah.

> Would be awesome if an Apache extension would make it trivial to write Web pages in D.

Just use cgi or fastcgi, both are really easy to configure on apache (often needing nothing more than copying your executable into /cgi-bin/, or adding three lines to ,htaccess), and being separate processes, if you crash them it is no big deal. No need to do set up a reverse proxy or get your system administrator to load strange new Apache modules.

Or if you are just playing, you can skip apache altogether and use a D http server, like my cgi.d and vibe.d both offer (vibe.d's scales way better but mine is simpler).


But I kinda want to play with this now with shared libraries just for something to do so maybe I will.

On 6/23/13 10:34 AM, Adam D. Ruppe wrote:
> Just use cgi or fastcgi, both are really easy to configure on apache
> (often needing nothing more than copying your executable into /cgi-bin/,
> or adding three lines to ,htaccess), and being separate processes, if
> you crash them it is no big deal. No need to do set up a reverse proxy
> or get your system administrator to load strange new Apache modules.

We should do what php does, it was very successful. I assume it's a dynamic library.

> Or if you are just playing, you can skip apache altogether and use a D
> http server, like my cgi.d and vibe.d both offer (vibe.d's scales way
> better but mine is simpler).
>
>
> But I kinda want to play with this now with shared libraries just for
> something to do so maybe I will.

Awesome!

The more I think of it the more I get to the conclusion I should migrate my own website (www.erdani.com) to a 100% D toolchain.


Andrei

On Sunday, 23 June 2013 at 17:34:52 UTC, Adam D. Ruppe wrote:
>> Would be awesome if an Apache extension would make it trivial to write Web pages in D.
>
> Just use cgi or fastcgi, both are really easy to configure on apache (often needing nothing more than copying your executable into /cgi-bin/, or adding three lines to ,htaccess), and being separate processes, if you crash them it is no big deal. No need to do set up a reverse proxy or get your system administrator to load strange new Apache modules.
>
> Or if you are just playing, you can skip apache altogether and use a D http server, like my cgi.d and vibe.d both offer (vibe.d's scales way better but mine is simpler).

Actually vibe.d embedded HTTP outperforms Apache. With high concurrency - a lot. I can see reasons for wanting to keep it behind reverse proxy like nginx, but Apache? I dream of the day this freaking monstrosity dies together with web app infrastructure it has developed. Please, don't help it survive with D module support. :(

On Sunday, 23 June 2013 at 17:54:01 UTC, Andrei Alexandrescu wrote:
> On 6/23/13 10:34 AM, Adam D. Ruppe wrote:
> We should do what php does, it was very successful. I assume it's a dynamic library.

And what reason behind this other than "millions of lemmings can't be wrong"? This approach is disaster when it comes to high load.

On 6/23/13 11:04 AM, Dicebot wrote:
> On Sunday, 23 June 2013 at 17:54:01 UTC, Andrei Alexandrescu wrote:
>> On 6/23/13 10:34 AM, Adam D. Ruppe wrote:
>> We should do what php does, it was very successful. I assume it's a
>> dynamic library.
>
> And what reason behind this other than "millions of lemmings can't be
> wrong"? This approach is disaster when it comes to high load.

Would separate processes work better under high load? Educate me.

Andrei

On Sunday, 23 June 2013 at 18:02:04 UTC, Dicebot wrote:
> I can see reasons for wanting to keep it behind reverse proxy like nginx, but Apache?

Generally, I don't trust random http servers connected to the open internet for correctness, stability, security, and logging.

Especially not my code, There's a lot of the http protocol I never implemented, and putting apache, nginx, IIS, whatever, I'm just using Apache here because Andrei mentioned it, out in front will filter some of that out before it gets to my app.

And who knows what kinds of hidden bugs my code has, so having a tested and reliable server out there to revive my process if it dies is nice too.