Am Mon, 30 Apr 2012 15:52:36 -0700
schrieb Sean Kelly <sean@invisibleduck.org>:

> 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.

backtrace internally uses dladdr to get the function name for the
address. This has certain limits, for example dladdr _doesn't use
debug info at all_, so it only finds functions which are dynamically
exported (this means only those which could be loaded by dlsym).
This is also the reason why --export-dynamic is needed (when building a
static executable/library).

Am 29.04.2012 08:13, schrieb bls:
> Great job. Thanks Soenke et al;
>
>> - Built-in support for MongoDB and Redis databases
>
> MySQL.
> Like other folks here I need a SQL db, At least for MyQL 5.1 there is a
> socket based solution from Steve Teale.
> https://github.com/britseye/mysqln
> Means no licence trouble, and probably easier to establish async support.
>
> Quote
> Additional drivers are easy to port to vibe.d because of the blocking
> API - basically the only thing that has to be done is to replace the
> socket calls (send(), recv(), connect() etc.) with the corresponding
> vibe functions.
> EndQuote
>
> Can you elaborate a bit more ? Maybe using the vibe.d blog.
>
> There is also a socket based PostgreSQL driver available, but I have
> lost the link and dunno about the status quo.
>
> ----
> A MIT licenced *D2 crypto lib worth a look :
> http://www.dsource.org/projects/dcrypt/wiki/Features
>
> *not up to date
>
> ----
> Whishes:
> diet template documentation.
> diet template javascript example
> server side QR-code generation. (well may be I am able to contribute)

I made a post with Steve Teale's MySQL driver as an example:
http://vibed.org/blog/posts/writing-native-db-drivers

There were some hidden gotchas, but I hope the current port doesn't break anything from the original code.

On Tuesday, 1 May 2012 at 21:46:42 UTC, Sönke Ludwig wrote:
> I made a post with Steve Teale's MySQL driver as an example:
> http://vibed.org/blog/posts/writing-native-db-drivers
>
> There were some hidden gotchas, but I hope the current port doesn't break anything from the original code.

The table in that post has no styling, which makes it a bit annoying to read.

On Tue, May 1, 2012 at 5:04 PM, Matt Peterson <ricochet1k@gmail.com> wrote:

> On Tuesday, 1 May 2012 at 21:46:42 UTC, Sönke Ludwig wrote:
>
>> I made a post with Steve Teale's MySQL driver as an example: http://vibed.org/blog/posts/**writing-native-db-drivers<http://vibed.org/blog/posts/writing-native-db-drivers>
>>
>> There were some hidden gotchas, but I hope the current port doesn't break anything from the original code.
>>
>
> The table in that post has no styling, which makes it a bit annoying to read.
>

Seems to be cached.  Forcing a refresh fixed it for me.

Am 01.05.2012 23:46, schrieb Sönke Ludwig:
> I made a post with Steve Teale's MySQL driver as an example:
> http://vibed.org/blog/posts/writing-native-db-drivers
>
> There were some hidden gotchas, but I hope the current port doesn't
> break anything from the original code.

Looks good. Unfortunately I spend some time with MongoDB and I have to say : Amazing db. I thought key/value databases are just toys. At least regarding MongoDB is was completely wrong.


I have a problem with diet templates.
In order to use dojo dijit I need :

<div class="mainlayout" id="appLayout"
       data-dojo-props="region: 'center', tabPosition: 'bottom'"
       data-dojo-type="dijit.layout.TabContainer">
</div>

Is this doable in diet templates ?

Am 03.05.2012 00:18, schrieb bls:
> Am 01.05.2012 23:46, schrieb Sönke Ludwig:
>> I made a post with Steve Teale's MySQL driver as an example:
>> http://vibed.org/blog/posts/writing-native-db-drivers
>>
>> There were some hidden gotchas, but I hope the current port doesn't
>> break anything from the original code.
>
> Looks good. Unfortunately I spend some time with MongoDB and I have to
> say : Amazing db. I thought key/value databases are just toys. At least
> regarding MongoDB is was completely wrong.
>

;)

>
> I have a problem with diet templates.
> In order to use dojo dijit I need :
>
> <div class="mainlayout" id="appLayout"
> data-dojo-props="region: 'center', tabPosition: 'bottom'"
> data-dojo-type="dijit.layout.TabContainer">
> </div>
>
> Is this doable in diet templates ?
>
>

This line seems to work for me:
#appLayout.mainlayout(data-dojo-props="region: 'center', tabPosition: 'bottom'", data-dojo-type="dijit.layout.TabContainer")

gives me this HTML:
<div id="appLayout" class="mainlayout" data-dojo-props="region: &#39;center&#39;, tabPosition: &#39;bottom&#39;" data-dojo-type="dijit.layout.TabContainer"></div>

Am 30.04.2012 08:38, schrieb Sönke Ludwig:
> If you mean automatic generation of a REST interface for an existing D
> interface, then it's definitely planned. I can imagine a sloppy version
> where the HTTP method is always POST or can be POST/GET as desired by
> the client. But I would also like to have a more expressive version,
> where the HTTP method is inferred from the D method somehow and maybe it
> would also be possible to specify a sub path for each method.
>
> Sönke

Yes, this is what I am asking for. I think POST/GET is not enough.

Should be POST GET PUT DELETE

I would be fantastic if vibe.d can implement a REST SERVER following this guideline :

The JsonRestStore follows
RFC 2616 (http://www.ietf.org/rfc/rfc2616.txt) whenever possible to define to interaction with server. JsonRestStore uses an HTTP GET request to retrieve data, a PUT request to change items, a DELETE request to delete items, and a POST request to create new items. It is recommended that the server follow a URL structure for resources:

    /{Table}/{id}

This URL will be used to retrieve items by identity and make modifications (PUT and DELETE). It is also recommended that a /{Table}/ URL is used to represent the collection of items for the store. When a query is performed, any query string is appended to the target URL to retrieve the results of the query. The JsonRestStore expects the results to be returned in an array (not in an object with an items property like some stores). The store will also POST to that URL to create new items.

When creating new items, the JsonRestStore will POST to the target URL for the store. If your server wants to assign the URL/location for the newly created item, it can do so by including a Location header in the response:

    Location: http://mysite.com/Table/newid

The server can also assign or change properties of the object (such an id or default values) in the response to a POST (or any other request), by simply returning the updated JSON representation of the item in the body of the response.

Note that in PHP, sometimes setting the Location will erroneously trigger a 302 status code which will cause JsonRestStore to fail. Per RFC 2616, the correct response to a POST that creates a new resource is to return a 201 status code with the Location header. In PHP, you must set the status code as well as the Location header if you want to avoid a 302 response.

Am 03.05.2012 11:22, schrieb bls:
> Should be POST GET PUT DELETE
>
> I would be fantastic if vibe.d can implement a REST SERVER following
> this guideline :

A very interesting read regarding implementing a rest server (PHP)

http://www.gen-x-design.com/archives/create-a-rest-api-with-php/

Bjoern

On Wednesday, 2 May 2012 at 22:18:12 UTC, bls wrote:
> Am 01.05.2012 23:46, schrieb Sönke Ludwig:
>> I made a post with Steve Teale's MySQL driver as an example:
>> http://vibed.org/blog/posts/writing-native-db-drivers
>>
>> There were some hidden gotchas, but I hope the current port doesn't
>> break anything from the original code.
>
> Looks good. Unfortunately I spend some time with MongoDB and I have to say : Amazing db. I thought key/value databases are just toys. At least regarding MongoDB is was completely wrong.
>
It does have its scaling problems, though. As soon as RAM is full, performance drops drastically, as it's essentially a disk backed in memory database.

I've been playing around with vibe in my free time the last few days, and here are the beginnings of a stab at REST:
https://github.com/csauls/zeal.d/blob/master/source/zeal/http/router.d

Admittedly it rips off the Rails way of recognizing and pathing the REST actions, but I admit a small bias as someone who uses Rails often.  That said, I've been trying to dream up a "more D-like" way to do it.