View mode: basic / threaded / horizontal-split · Log in · Help
April 30, 2012
Re: Introducing vibe.d!
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.
>
>
April 30, 2012
Re: Introducing vibe.d!
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.
April 30, 2012
Re: Introducing vibe.d!
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.
April 30, 2012
Re: Introducing vibe.d!
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
April 30, 2012
Re: Introducing vibe.d!
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
April 30, 2012
Re: Introducing vibe.d!
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
April 30, 2012
Re: Introducing vibe.d!
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.
April 30, 2012
Re: Introducing vibe.d!
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.
April 30, 2012
Re: Introducing vibe.d!
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.
April 30, 2012
Re: Introducing vibe.d!
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.
5 6 7 8 9 10 11 12
Top | Discussion index | About this forum | D home