On Sunday, 29 January 2017 at 00:14:02 UTC, Adam D. Ruppe wrote:
> On Saturday, 28 January 2017 at 21:03:08 UTC, Stefan Koch wrote:
>> It's not native though.
>
> It's a mistake to ask for native D implementations of mature C libraries, especially a public domain one like sqlite. There's just no advantage in production use to rewrite it.

Well, native implementations are useful at least for building self-contained applications. Also, one can learn more advanced features of the language studying them.

On the other hand, while for example C has a low overhead, I believe a properly optimized implementation in D could match and perhaps even surpass C code in terms of performance and safety, so at least for me, if someone has the knowledge and time to reimplement mature libraries in D, kudos to him/her, as a mere ignorant mortal I will certainly appreciate the effort. ;)

On 01/28/2017 04:14 PM, Adam D. Ruppe wrote:
> On Saturday, 28 January 2017 at 21:03:08 UTC, Stefan Koch wrote:
>> It's not native though.
>
> It's a mistake to ask for native D implementations of mature C
> libraries, especially a public domain one like sqlite. There's just no
> advantage in production use to rewrite it.

Agreed but there can be happy surprises. :) Just because it's fresh in my mind: Jon Degenhardt implemented D versions of existing C, Go, and Rust tool kits in D and saw 3 to 10 times performance increase in many cases (not all).

  http://forum.dlang.org/thread/o6c9tj$2bdp$1@digitalmars.com

Ali

On Saturday, 28 January 2017 at 21:09:25 UTC, Stefan Koch wrote:
> On Saturday, 28 January 2017 at 12:09:35 UTC, Nestor wrote:
>> On Friday, 27 January 2017 at 12:55:55 UTC, Stefan Koch wrote:
>>> [...]
>>
>> Thanks. It did compile using dub, though I had a couple of issues with dub, by the way.
>>
>> [...]
>
> I think you have to remove the app.d that comes with sqlite-d file if you want to use it.
> Because that tries to open views/test-2.3.sqlite.
>
> Please try to read the source-code in app.d and in test.d that come with sqlite-d.
>
> If you have questions about that I am happy to answer them.
> Sqlite-d is a work in progress and I have not used it for an actual project.
>
> Currently I am busy with improving the ctfe engine.
> So I don't have to many resources should sqlite-d need improvements.

Thanks for your willingness to help.

Removing app.d from the library seems to make no difference. I just made an empty project as before (specifying your package as a dependency), like this:

dub init sqlite-test

Then I try to build using simply dub without parameters. However I get this message:

Fetching sqlite-d 0.1.0 (getting selected version)...
Non-optional dependency sqlite-d of sqlite-test not found in dependency tree!?.

Am I missing a parameter or something?

On Sunday, 29 January 2017 at 01:47:44 UTC, Nestor wrote:
> On Saturday, 28 January 2017 at 21:09:25 UTC, Stefan Koch wrote:
>> On Saturday, 28 January 2017 at 12:09:35 UTC, Nestor wrote:
>>> On Friday, 27 January 2017 at 12:55:55 UTC, Stefan Koch wrote:
>>>> [...]
>>>
>>> Thanks. It did compile using dub, though I had a couple of issues with dub, by the way.
>>>
>>> [...]
>>
>> I think you have to remove the app.d that comes with sqlite-d file if you want to use it.
>> Because that tries to open views/test-2.3.sqlite.
>>
>> Please try to read the source-code in app.d and in test.d that come with sqlite-d.
>>
>> If you have questions about that I am happy to answer them.
>> Sqlite-d is a work in progress and I have not used it for an actual project.
>>
>> Currently I am busy with improving the ctfe engine.
>> So I don't have to many resources should sqlite-d need improvements.
>
> Thanks for your willingness to help.
>
> Removing app.d from the library seems to make no difference. I just made an empty project as before (specifying your package as a dependency), like this:
>
> dub init sqlite-test
>
> Then I try to build using simply dub without parameters. However I get this message:
>
> Fetching sqlite-d 0.1.0 (getting selected version)...
> Non-optional dependency sqlite-d of sqlite-test not found in dependency tree!?.
>
> Am I missing a parameter or something?

I just called dub fetch and see what the problem is.
I am going to push an update to fix it.
should be there in a minute

On Sunday, 29 January 2017 at 01:53:30 UTC, Stefan Koch wrote:
> On Sunday, 29 January 2017 at 01:47:44 UTC, Nestor wrote:
>> On Saturday, 28 January 2017 at 21:09:25 UTC, Stefan Koch wrote:
>>> On Saturday, 28 January 2017 at 12:09:35 UTC, Nestor wrote:
>>>> On Friday, 27 January 2017 at 12:55:55 UTC, Stefan Koch wrote:
>>>>> [...]
>>>>
>>>> Thanks. It did compile using dub, though I had a couple of issues with dub, by the way.
>>>>
>>>> [...]
>>>
>>> I think you have to remove the app.d that comes with sqlite-d file if you want to use it.
>>> Because that tries to open views/test-2.3.sqlite.
>>>
>>> Please try to read the source-code in app.d and in test.d that come with sqlite-d.
>>>
>>> If you have questions about that I am happy to answer them.
>>> Sqlite-d is a work in progress and I have not used it for an actual project.
>>>
>>> Currently I am busy with improving the ctfe engine.
>>> So I don't have to many resources should sqlite-d need improvements.
>>
>> Thanks for your willingness to help.
>>
>> Removing app.d from the library seems to make no difference. I just made an empty project as before (specifying your package as a dependency), like this:
>>
>> dub init sqlite-test
>>
>> Then I try to build using simply dub without parameters. However I get this message:
>>
>> Fetching sqlite-d 0.1.0 (getting selected version)...
>> Non-optional dependency sqlite-d of sqlite-test not found in dependency tree!?.
>>
>> Am I missing a parameter or something?
>
> I just called dub fetch and see what the problem is.
> I am going to push an update to fix it.
> should be there in a minute

Thanks, it compiled now. However keep in mind there was a warning for sqlited.d:

C:\Users\nestor\AppData\Roaming\dub\packages\sqlite-d-0.1.5\sqlite-d\source\sqlited.d(743,5): Deprecation: Implicit string concatenation is deprecated, use "I do not expect us to ever get here\x0a" ~ "If we ever do, uncomment the two lines below and delete this assert" instead

On Sunday, 29 January 2017 at 01:02:07 UTC, Ali Çehreli wrote:
> Agreed but there can be happy surprises. :) Just because it's fresh in my mind: Jon Degenhardt implemented D versions of existing C, Go, and Rust tool kits in D and saw 3 to 10 times performance increase in many cases (not all).

Yeah, but those are relatively simple tools, not a heavily used database like sqlite.

I support the creation of sqlite-d, it does some cool stuff and there is potential for more, but I just don't agree that using the C functions should be a dealbreaker (or even a serious negative, given sqlite's nature especially)

On Sunday, 29 January 2017 at 00:36:34 UTC, Nestor wrote:
> Well, native implementations are useful at least for building self-contained applications.

Sometimes true, but sqlite can be easily embedded and statically linked, so your binary is still self-contained, there's just a small compile time dependency on the sqlite3.lib.

> Also, one can learn more advanced features of the language studying them.

Oh, certainly, writing and studying it is a good thing.

On Sunday, 29 January 2017 at 02:55:04 UTC, Adam D. Ruppe wrote:
> On Sunday, 29 January 2017 at 00:36:34 UTC, Nestor wrote:
>> Well, native implementations are useful at least for building self-contained applications.
>
> Sometimes true, but sqlite can be easily embedded and statically linked, so your binary is still self-contained, there's just a small compile time dependency on the sqlite3.lib.
>
>> Also, one can learn more advanced features of the language studying them.
>
> Oh, certainly, writing and studying it is a good thing.

In the case of Windows, where libraries are usually dlls, how could this be achieved, using your wrapper for example?

On Sunday, 29 January 2017 at 02:59:12 UTC, Nestor wrote:
> On Sunday, 29 January 2017 at 02:55:04 UTC, Adam D. Ruppe wrote:
>> On Sunday, 29 January 2017 at 00:36:34 UTC, Nestor wrote:
>>> Well, native implementations are useful at least for building self-contained applications.
>>
>> Sometimes true, but sqlite can be easily embedded and statically linked, so your binary is still self-contained, there's just a small compile time dependency on the sqlite3.lib.
>>
>>> Also, one can learn more advanced features of the language studying them.
>>
>> Oh, certainly, writing and studying it is a good thing.
>
> In the case of Windows, where libraries are usually dlls, how could this be achieved, using your wrapper for example?

dmd can link to dlls now. if just specify them on the commandline.

On Sunday, 29 January 2017 at 03:11:34 UTC, Stefan Koch wrote:
> On Sunday, 29 January 2017 at 02:59:12 UTC, Nestor wrote:
>> On Sunday, 29 January 2017 at 02:55:04 UTC, Adam D. Ruppe wrote:
>>> On Sunday, 29 January 2017 at 00:36:34 UTC, Nestor wrote:
>>>> Well, native implementations are useful at least for building self-contained applications.
>>>
>>> Sometimes true, but sqlite can be easily embedded and statically linked, so your binary is still self-contained, there's just a small compile time dependency on the sqlite3.lib.
>>>
>>>> Also, one can learn more advanced features of the language studying them.
>>>
>>> Oh, certainly, writing and studying it is a good thing.
>>
>> In the case of Windows, where libraries are usually dlls, how could this be achieved, using your wrapper for example?
>
> dmd can link to dlls now. if just specify them on the commandline.

Can dlls be embedded as well? I mean can I make a static dmd executable with the functionality of the library embedded and not just stored as a resource to be extracted and run at runtime?