Am 28.04.2012 20:47, schrieb Rory McGuire:
> Awesome! that was one of my concerns with D in general with server
> software and its long running nature.
> I've been thinking about fibers and socket.d this week. Glad you
> anounced this before I started working on something :D.

Yeah I've also tought about this for a while before I was finally fed up with a REST-server project and finally started vibe. Of course it's much more work now in total but making web applications is finally fun now :)

>
> How difficult would it be for you to split the async IO parts into a
> separate library? This would be very much like gevent (python:
> http://www.gevent.org/).

That would basically be vibe.core and vibe.stream. Those have no dependencies to other modules so they can already be used without the rest of the code adding overhead of any kind.

>
> Any chance of supporting WSGI?

It's not directly planned from our side but either eventually or if someone else writes a version I think it will get in.

>
> On Sat, Apr 28, 2012 at 2:36 PM, Sönke Ludwig <sludwig@outerproduct.org
> <mailto:sludwig@outerproduct.org>> wrote:
>
>     Am 27.04.2012 11 <tel:27.04.2012%2011>:34, schrieb Sönke Ludwig:
>
>
>         I'm starting to monitor it now. Directly after startup, the
>         website is
>         at 32 MB. The traffic has dropped a bit but hopefully it's
>         enough to see
>         something if there is a hidden leak.
>
>
>     A mid-term test now shows that shortly after startup the virtual
>     memory usage went up from 32MB to about 44MB. After 24h and about
>     50k requests it stays at 43.5MB. Real memory usage is 15MB.
>
>

Am 27.04.2012 16:50, schrieb Sean Kelly:
> In _d_throw call abort().  That'll give you a core file.
>

Thanks, I've tracked it down to an assertion by logging stderr for now, but next time I will try the abort method (with __d_assert*), because just a call stack without line numbers was a bit sparse on information.

On Mon, Apr 30, 2012 at 9:57 AM, Sönke Ludwig <sludwig@outerproduct.org>wrote:

>
>> How difficult would it be for you to split the async IO parts into a separate library? This would be very much like gevent (python: http://www.gevent.org/).
>>
>
> That would basically be vibe.core and vibe.stream. Those have no dependencies to other modules so they can already be used without the rest of the code adding overhead of any kind.


Thanks.

I wonder how vibe.d performs vs a gevent based web server.

On 2012-04-30 09:00, Sönke Ludwig wrote:

> Interesting haven't thought about going that far :)
>
> Somehow that reminds me of:
> #define IF if(
> #define THEN ){
> #define ELSE } else {
> #define ENDIF }
>
> to transform C into BASIC. The scripting-only people would probably be
> thrilled ;) But I have the tendency to think that this bends the
> language a bit too far. They will also soon wonder why they cannot put
> top-level code in their other files.
>
> Sönke

Yeah, I guess that will most likely be a problem.

-- 
/Jacob Carlborg

On Monday, 30 April 2012 at 09:14:31 UTC, Jacob Carlborg wrote:
> On 2012-04-30 09:00, Sönke Ludwig wrote:
>> They will also soon wonder why they cannot put
>> top-level code in their other files.
> Yeah, I guess that will most likely be a problem.

Also, doesn't ImportExpression require passing -J to the compiler? That'd potentially only add another source of confusion for newcomers.

David

On 2012-04-30 13:05, David Nadlinger wrote:
> On Monday, 30 April 2012 at 09:14:31 UTC, Jacob Carlborg wrote:
>> On 2012-04-30 09:00, Sönke Ludwig wrote:
>>> They will also soon wonder why they cannot put
>>> top-level code in their other files.
>> Yeah, I guess that will most likely be a problem.
>
> Also, doesn't ImportExpression require passing -J to the compiler?
> That'd potentially only add another source of confusion for newcomers.
>
> David
>

You're correct, it does.

-- 
/Jacob Carlborg

On Apr 30, 2012, at 1:03 AM, Sönke Ludwig wrote:

> Am 27.04.2012 16:50, schrieb Sean Kelly:
>> In _d_throw call abort().  That'll give you a core file.
>> 
> 
> Thanks, I've tracked it down to an assertion by logging stderr for now, but next time I will try the abort method (with __d_assert*), because just a call stack without line numbers was a bit sparse on information.

What platform are you on?  You should be getting stack traces.

Am 30.04.2012 15:48, schrieb Sean Kelly:
> On Apr 30, 2012, at 1:03 AM, Sönke Ludwig wrote:
>
>> Am 27.04.2012 16:50, schrieb Sean Kelly:
>>> In _d_throw call abort().  That'll give you a core file.
>>>
>>
>> Thanks, I've tracked it down to an assertion by logging stderr for now, but next time I will try the abort method (with __d_assert*), because just a call stack without line numbers was a bit sparse on information.
>
> What platform are you on?  You should be getting stack traces.

I get a stack trace with function names but no line numbers (just byte offsets). It's Linux/64bit, compiled with -g.

On Mon, 30 Apr 2012 17:26:54 +0200, Sönke Ludwig <sludwig@outerproduct.org> wrote:

> Am 30.04.2012 15:48, schrieb Sean Kelly:
>> On Apr 30, 2012, at 1:03 AM, Sönke Ludwig wrote:
>>
>>> Am 27.04.2012 16:50, schrieb Sean Kelly:
>>>> In _d_throw call abort().  That'll give you a core file.
>>>>
>>>
>>> Thanks, I've tracked it down to an assertion by logging stderr for now, but next time I will try the abort method (with __d_assert*), because just a call stack without line numbers was a bit sparse on information.
>>
>> What platform are you on?  You should be getting stack traces.
>
> I get a stack trace with function names but no line numbers (just byte offsets). It's Linux/64bit, compiled with -g.

Yup, pretty annoying. Use addr2line.

On Apr 30, 2012, at 8:26 AM, Sönke Ludwig wrote:

> Am 30.04.2012 15:48, schrieb Sean Kelly:
>> On Apr 30, 2012, at 1:03 AM, Sönke Ludwig wrote:
>> 
>>> Am 27.04.2012 16:50, schrieb Sean Kelly:
>>>> In _d_throw call abort().  That'll give you a core file.
>>>> 
>>> 
>>> Thanks, I've tracked it down to an assertion by logging stderr for now, but next time I will try the abort method (with __d_assert*), because just a call stack without line numbers was a bit sparse on information.
>> 
>> What platform are you on?  You should be getting stack traces.
> 
> I get a stack trace with function names but no line numbers (just byte offsets). It's Linux/64bit, compiled with -g.

Druntime uses backtrace() on Linux, and I've seen it give offsets at times instead of line numbers.  Can't say exactly why.  You may already know this, but you can figure out the offending line by calling "objdump -d -S" on the executable, then doing some hex math from the address of the reported function.