On 6/21/2013 4:10 AM, Paulo Pinto wrote:
Except not everyone has the authorization to place their work code in such
public places nor the availability or desire to code after work, just to please
job interviewers.
True, but your odds of being 'discovered' go up enormously if you make such an
e
On Monday, 24 June 2013 at 02:39:30 UTC, Andrei Alexandrescu
wrote:
so what's the way to go now? One process per request? Seems
heavy to me seeing as most requests last very little.
Performance wise, I've found heard very good things about async
i/o (like vibe.d) and had very good experience w
On Monday, 24 June 2013 at 09:22:58 UTC, deadalnix wrote:
BTW, this article is full of bullshit and hand wavy stuff. I
wanted to write a article destroying it, but I then decided
that I had other thing to do than loose my time :D
Yeah, it has plenty of bullshit but core idea is the same as one
On Monday, 24 June 2013 at 09:07:54 UTC, Dicebot wrote:
Actually, server software with most impressive performance I
have seen so far was implemented as single barebone process
with all network stack and event library embedded. Slightly
similar idea was propsoed here -
http://highscalability.c
On Monday, 24 June 2013 at 02:39:30 UTC, Andrei Alexandrescu
wrote:
On 6/23/13 11:51 AM, Adam D. Ruppe wrote:
I think it is just an accident of history that mod_php ever
got used.
Classic cgi implementations were still slow enough (especially
with an
interpreted language) that people wanted to
On Sunday, 23 June 2013 at 18:42:12 UTC, Adam D. Ruppe wrote:
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 correctne
On Sunday, 23 June 2013 at 18:24:05 UTC, Andrei Alexandrescu
wrote:
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 lib
On Monday, 24 June 2013 at 02:39:30 UTC, Andrei Alexandrescu
wrote:
On 6/23/13 11:51 AM, Adam D. Ruppe wrote:
I think it is just an accident of history that mod_php ever
got used.
Classic cgi implementations were still slow enough (especially
with an
interpreted language) that people wanted to
On 6/23/13 11:51 AM, Adam D. Ruppe wrote:
I think it is just an accident of history that mod_php ever got used.
Classic cgi implementations were still slow enough (especially with an
interpreted language) that people wanted to try something else, but the
other world of options hadn't taken root y
On Sunday, 23 June 2013 at 17:54:01 UTC, Andrei Alexandrescu
wrote:
Awesome!
I realized initializing the runtime might have been a mistake
when loading the .so and moreover I was using the wrong calling
convention. Fixed that and now the shared library thing works. On
Linux at least, I hardc
BTW I should mention, I wasn't actually trying to do an Apache
module. I wanted to do a D server that watches the files for
changes, then recompiles them as needed and reloads the resulting
file as a shared lib.
I could just run the compiled executable too, cgi style, but here
I was more inte
On Sunday, 23 June 2013 at 17:54:01 UTC, Andrei Alexandrescu
wrote:
I assume it's a dynamic library.
PHP can work as fastcgi too.
But I kinda want to play with this now with shared libraries
just for
something to do so maybe I will.
Awesome!
Eh, not so much. I started playing and got a t
On Sunday, 23 June 2013 at 18:24:05 UTC, Andrei Alexandrescu
wrote:
Would separate processes work better under high load? Educate
me.
One nice thing is you can spread separate processes across
several machines. Another advantage of *cgi|embedded_httpd is
that it is portable to other web serve
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,
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 ca
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 dis
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
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 t
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 needi
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
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 th
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 imple
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)
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
On 6/22/2013 12:12 PM, Andrej Mitrovic wrote:
Most important? I've never even run across this case.
Ok, maybe not that important. It's likely a rare case.
Btw, does anyone know if the typical memcmp implementation tries to
compare the pointers' addresses first to see if they match?
I don't k
On Saturday, 22 June 2013 at 16:38:31 UTC, Andrei Alexandrescu
wrote:
It's still buggy.
What's the test case? I also forgot the empty string, blargh.
Let's scrap it.
Overly complicated, too - at 21 lines, it's about twice as
large as the canonical implementation.
Huh, even the shortest im
On 6/22/13, Walter Bright wrote:
> It's wrapped in #if 0 ... #endif ? :-)
Hehe. I should totally use that as an argument in a future interview.
I'll wrap all my coding-answers in '#if 0', and if they're wrong I'll
just say "oh, but this code doesn't *actually* exist!". :p
> The function bodies w
On Friday, 21 June 2013 at 21:33:43 UTC, Andrei Alexandrescu
wrote:
Also it's fair to ask about implementing a stdlib function
itself if the interview concerns some systems-level work; e.g.
brute-force strstr() is fair game and I think any engineer
should be able to lift it off the ground quick
On 6/22/2013 4:01 AM, Andrej Mitrovic wrote:
On 6/22/13, Walter Bright wrote:
Can I play, too? Mine from the Digital Mars C library. Haven't looked at it
#if 0 /* Smaller but slower under many circumstances. */
char *strstr(const char *s1,const char *s2)
{ size_t len2;
size_t len1;
On 6/22/13 7:10 AM, Adam D. Ruppe wrote:
On Saturday, 22 June 2013 at 13:55:26 UTC, Jérôme M. Berger wrote:
I haven't tried running it, but this looks to me like it won't find
"ababc" in "abababc"...
You're right. I should have went backwards all the way, not just in the
one case.
This passe
On Saturday, 22 June 2013 at 13:55:26 UTC, Jérôme M. Berger wrote:
I haven't tried running it, but this looks to me like it won't
find "ababc" in "abababc"...
You're right. I should have went backwards all the way, not just
in the one case.
This passes all the tests:
inout(char)* mystrstr
Adam D. Ruppe wrote:
> On Friday, 21 June 2013 at 22:35:55 UTC, Andrei Alexandrescu
> wrote:
>> Post it and I'll destroy it.
>
>
> inout(char)* mystrstr(inout(char)* haystack, const(char*) needle)
> {
> assert(haystack !is null);
>
> if(needle is null)
> return haystack;
>
On 6/22/13, Adam D. Ruppe wrote:
> On Saturday, 22 June 2013 at 11:01:53 UTC, Andrej Mitrovic wrote:
>> - You're casting a const char * to a char * in the return, you
>> should instead provide an overload of strstr taking char* and
>> returning char*.
>
> I'm pretty sure the C standard says to do
On 6/22/13, Walter Bright wrote:
> Can I play, too? Mine from the Digital Mars C library. Haven't looked at it
>
> #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 = str
On 2013-06-22 01:58, H. S. Teoh wrote:
And where's the unittest block? ;-) (OK OK, I know this wasn't written
in D. But I had to ask. :-P)
DMC does support contracts, as an extension. That is, in and out
contracts. I don't know about unit test blocks.
--
/Jacob Carlborg
On 2013-06-21 23:33, Andrei Alexandrescu wrote:
If there's any need to reach for documentation, the interviewer has
failed. When interviewing we (at Facebook) ask problems that are likely
to appear in a normal day's work, but for which the typical libraries
don't help. (E.g. many libraries don't
On Friday, 21 June 2013 at 21:33:43 UTC, Andrei Alexandrescu
wrote:
If there's any need to reach for documentation, the interviewer
has failed. When interviewing we (at Facebook) ask problems
that are likely to appear in a normal day's work, but for which
the typical libraries don't help. (E.g.
On Fri, Jun 21, 2013 at 04:02:20PM -0700, Walter Bright wrote:
[...]
> /
> See "Algorithms" Second Edition by Robert Sedgewick. Boyer-Moore string
> search routine.
> ***
On Friday, 21 June 2013 at 22:35:55 UTC, Andrei Alexandrescu
wrote:
Post it and I'll destroy it.
inout(char)* mystrstr(inout(char)* haystack, const(char*) needle)
{
assert(haystack !is null);
if(needle is null)
return haystack;
const(char)* where = needle;
inout(cha
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.
==
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.
Andrei
On 6/21/13 2:50 PM, Adam D. Ruppe wrote:
On Friday, 21 June 2013 at 21:33:43 UTC, Andrei Alexandrescu wrote:
brute-force strstr() is fair game and I think any engineer should be
able to lift it off the ground quickly (to my dismay, only a fraction
can).
But, should the return value be const or
On Friday, 21 June 2013 at 22:23:01 UTC, Adam D. Ruppe wrote:
being built in to D
Or maybe it is because everybody else does it in the
documentation and such, since #include in C isn't
*that* big of a deal. idk, all I do know for sure is that I do it
now and didn't before.
Just for laughs I just slapped together a strstr and it made me
realize a little thing I do in D that I never did in C:
assert()
I use it all over the place in D, pretty much any time I make an
assumption, I slap it down in an assert.
But I don't I ever, not once, used any kind of assertion
On Fri, Jun 21, 2013 at 05:33:45PM -0400, Andrei Alexandrescu wrote:
[...]
> Also it's fair to ask about implementing a stdlib function itself if
> the interview concerns some systems-level work; e.g. brute-force
> strstr() is fair game and I think any engineer should be able to
> lift it off the g
On Friday, 21 June 2013 at 21:33:43 UTC, Andrei Alexandrescu
wrote:
brute-force strstr() is fair game and I think any engineer
should be able to lift it off the ground quickly (to my dismay,
only a fraction can).
But, should the return value be const or not? :P
I think I'd write in D just cu
On 6/21/13 5:59 AM, Jacob Carlborg wrote:
On 2013-06-21 07:57, H. S. Teoh wrote:
we got to ask HR to first
administer a technical test before any interviews are arranged; test
results are reviewed before deciding to interview the candidate
I done tests like that, they all suck. This is how it
On 2013-06-21 17:14, H. S. Teoh wrote:
Heh, at my job, we're looking for skill in specific languages, so
candidates are explicitly asked to write C code. And this is done not in
an interview setting (which puts too much pressure on the candidate --
can *you* write code in front of interviewers w
On Fri, Jun 21, 2013 at 11:59:12AM +0200, Jacob Carlborg wrote:
> On 2013-06-21 07:57, H. S. Teoh wrote:
>
> >we got to ask HR to first administer a technical test before any
> >interviews are arranged; test results are reviewed before deciding to
> >interview the candidate
>
> I done tests like
On 2013-06-21 12:20, Andrej Mitrovic wrote:
Oh? That's cool. Which [rpkect?
I don't know if it was a particular project but at least one company was
interested in several projects, DStep (convert C/Objective-C headers to
D modules), Jazz (D frontend) and Orbit (D package manager).
https://
On Friday, 21 June 2013 at 05:59:00 UTC, H. S. Teoh wrote:
In spite of it all, though, we still sometimes end up hiring
people who,
6 months down the road, write code that makes you scratch your
head
going "huh?! that genius coder we hired wrote *this* junk?!".
But maybe
some hiring managers a
On Friday, 21 June 2013 at 06:34:09 UTC, Andrej Mitrovic wrote:
On 6/21/13, H. S. Teoh wrote:
In spite of it all, though, we still sometimes end up hiring
people who,
6 months down the road, write code that makes you scratch your
head
going "huh?! that genius coder we hired wrote *this* junk?
On 6/21/13, Jacob Carlborg wrote:
> I agree. Most interviews I have been on lately is due to my github project.
Oh? That's cool. Which [rpkect?
On 6/21/13, Andrej Mitrovic wrote:
> On 6/21/13, Jacob Carlborg wrote:
>> I agree. Most interviews I have been on lately is due to my github
>> project.
>
> Oh? That's cool. Which [rpkect?
>
Looks like I rot13'ed by accident, I meant which project?
On 2013-06-21 07:57, H. S. Teoh wrote:
we got to ask HR to first
administer a technical test before any interviews are arranged; test
results are reviewed before deciding to interview the candidate
I done tests like that, they all suck. This is how it usually works:
You get a problem to solve
On 2013-06-21 08:33, Andrej Mitrovic wrote:
Seems like nowadays it's not too far-fetched to ask for a
github/bitbucket/etc username and see the work they've done, the way
they write code, contribute, etc. It should give a better "feel" than
any interview.
I agree. Most interviews I have been o
On 6/21/13, H. S. Teoh wrote:
> In spite of it all, though, we still sometimes end up hiring people who,
> 6 months down the road, write code that makes you scratch your head
> going "huh?! that genius coder we hired wrote *this* junk?!".
Seems like nowadays it's not too far-fetched to ask for a
On Fri, Jun 21, 2013 at 01:14:28AM -0400, Nick Sabalausky wrote:
> On Thu, 20 Jun 2013 20:50:08 -0700
> "H. S. Teoh" wrote:
[...]
> > One of my previous supervisors told me that when he gets resumés, as
> > soon as he sees "Ph.D" he chucks it straight into the trash.
>
> Classic ;) I'd be likely
57 matches
Mail list logo
