View mode: basic / threaded / horizontal-split · Log in · Help
May 01, 2012
Re: Introducing vibe.d!
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).
May 01, 2012
Re: Introducing vibe.d!
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.
May 01, 2012
Re: Introducing vibe.d!
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.
May 02, 2012
Re: Introducing vibe.d!
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.
May 02, 2012
Re: Introducing vibe.d!
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 ?
May 03, 2012
Re: Introducing vibe.d!
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>
May 03, 2012
Re: Introducing vibe.d! SOAP .. REST?
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.
May 03, 2012
Re: Introducing vibe.d! SOAP .. REST?
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
May 03, 2012
Re: Introducing vibe.d!
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.
May 03, 2012
Re: Introducing vibe.d! SOAP .. REST?
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.
6 7 8 9 10 11 12
Top | Discussion index | About this forum | D home