Re: printing array of strings with writefln?
On Sunday, 16 November 2014 at 15:08:10 UTC, JR wrote: On Sunday, 16 November 2014 at 14:16:55 UTC, Artem Tarasov wrote: writefln(%(%s-%), [a, b, c]) doesn't print the intended a-b-c but surrounds each string with double quotes - a-b-c, which I find inconsistent with the fact that writefln(%s, a string) prints the string without any quotes. How do I get the desired behaviour using just the format string? writefln(%-(%s-%), [a, b, c]) http://ddili.org/ders/d.en/formatted_output.html What I find surprising is that %-(ch%) without %s inside also works, although ch is prepended to each string and not a separator (which makes sense, but still). This does not seem to be mentioned in the documentation, neither in Ali's book. Is this a bug?
Re: Russian translation of the range term?
On Wednesday, 12 November 2014 at 20:48:00 UTC, Jack Applegame wrote: интервал, область Thanks to all for the suggestions and reasoning! I don't yet see a word which clicks in this case, but we got multiple reasonable suggestions here. Perhaps I'll be fine with one of them. Ivan Kazmenko.
get machine arch
Hi there, I'm trying to determinate machine architecture; using core.cpuid return anything except i686 or x86-64; that simple thing is all I need...
InvalidMemoryOperationError@(0)
Hi,
the following coding is an extract from the DGUI library.
On my system (Win 8) I receive InvalidMemoryOperationError@.
I got the information that this Error doesn't not occur on
a WinXP system.
I think there is definetely a bug in the following coding.
The Grid class has a Collection of Rows. Each Row has a Collection
of Cols.
The class Row has a destructor which has an empty foreach over
the Collection of Cols. If I comment this empty foreach no
error is thrown. I assume the class Collection accesses a Col
object which is already destructed?
Does DMD behave correctly (InvalidMemoryOperationError) and
can where in the Collection class exactly the invalid object is
accessed? I tried to find the invalid coding line, but without
success.
class Collection(T)
{
private T[] _t;
int add(T t)
{
this._t ~= t;
return this._t.length - 1;
}
void clear()
{
this._t.length = 0;
}
T[] get()
{
return this._t;
}
@property int length()
{
return this._t.length;
}
T opIndex(int i) nothrow
{
if(i = 0 i this._t.length)
{
return this._t[i];
}
assert(false, Index out of range);
}
int opApply(int delegate(ref T) dg)
{
int res = 0;
if(this._t.length)
{
for(int i = 0; i this._t.length; i++)
{
res = dg(this._t[i]);
if(res)
{
break;
}
}
}
return res;
}
}
class Col {}
class Row
{
private Collection!(Col) _columns;
this()
{
this._columns = new Collection!(Col)();
}
~this()
{
foreach(cp; this._columns)
{
}
}
Col addColumn()
{
Col cp = new Col();
this._columns.add(cp);
return cp;
}
}
class Grid
{
private Collection!(Row) _rows;
this()
{
this._rows = new Collection!(Row)();
}
@property public Row[] rows()
{
return this._rows.get();
}
Row addRow()
{
Row rp = new Row();
this._rows.add(rp);
return rp;
}
void clear()
{
_rows.clear();
}
}
void main()
{
auto grid = new Grid();
for(int i=0; i 10; i++)
{
grid.clear();
with(grid.addRow())
{
addColumn();
addColumn();
addColumn();
}
}
}
Simple timing
I'm trying to write a program that involves simple timing; I like to be able to execute some function at a point no sooner than, say, 3500 milliseconds from now so I need to read the current 'system time' in ticks and calculate the required point in the future using ticks per sec. In other languages I've done something like this (pseudo code). now = currentTime; target = now + 3500 do something .. until currentTime target execute function I'm completely new to D and find the help pages on this subject very confusing (or at least a bit too detailed for a beginner!). Can anyone point me to a simple example or tell me how to go about this? Many thanks Paul
Re: Simple timing
The easiest way isn't to read the clock at all and instead just
put your program to sleep for a while:
void main() {
import std.stdio;
import core.thread;
writeln(started);
Thread.sleep(3500.msecs);
writeln(ended);
}
Re: InvalidMemoryOperationError@(0)
On Mon, 17 Nov 2014 15:41:25 +
Andre via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
~this()
{
foreach(cp; this._columns)
{
}
}
don't do that in destructors. `_columns` field can be already collected
by GC.
signature.asc
Description: PGP signature
Re: Simple timing
On Monday, 17 November 2014 at 16:24:10 UTC, Paul wrote:
I'm trying to write a program that involves simple timing; I
like to be able to execute some function at a point no sooner
than, say, 3500 milliseconds from now so I need to read the
current 'system time' in ticks and calculate the required point
in the future using ticks per sec. In other languages I've done
something like this (pseudo code).
now = currentTime;
target = now + 3500
do something
..
until currentTime target
execute function
I'm completely new to D and find the help pages on this subject
very confusing (or at least a bit too detailed for a
beginner!). Can anyone point me to a simple example or tell me
how to go about this?
Many thanks
Paul
You can get the current 'system time' from std.datetime using
Clock.currTime.
Subtracting one SysTime from another results in a 'Duration',
which you can then compare to your target duration:
var startTime = Clock.currTime;
doSomething();
while(Clock.currTime - startTime 3500.msecs)
{
executeFunction();
}
Clock.currTime uses a high performance timer,
QueryPerformanceCounter on Windows for example, so you shouldn't
have to worry about timer accuracy.
Re: Simple timing [solved]
Thank you both, I'm sure that answers my question.
Paul
On Monday, 17 November 2014 at 16:38:45 UTC, Rene Zwanenburg
wrote:
On Monday, 17 November 2014 at 16:24:10 UTC, Paul wrote:
I'm trying to write a program that involves simple timing; I
like to be able to execute some function at a point no sooner
than, say, 3500 milliseconds from now so I need to read the
current 'system time' in ticks and calculate the required
point in the future using ticks per sec. In other languages
I've done something like this (pseudo code).
now = currentTime;
target = now + 3500
do something
..
until currentTime target
execute function
I'm completely new to D and find the help pages on this
subject very confusing (or at least a bit too detailed for a
beginner!). Can anyone point me to a simple example or tell me
how to go about this?
Many thanks
Paul
You can get the current 'system time' from std.datetime using
Clock.currTime.
Subtracting one SysTime from another results in a 'Duration',
which you can then compare to your target duration:
var startTime = Clock.currTime;
doSomething();
while(Clock.currTime - startTime 3500.msecs)
{
executeFunction();
}
Clock.currTime uses a high performance timer,
QueryPerformanceCounter on Windows for example, so you
shouldn't have to worry about timer accuracy.
Re: undefined reference to class template
Could anyone help me please?
Re: undefined reference to class template
On 11/14/14 6:29 PM, Satoshi wrote:
Hi, Im using GDC 4.9.0 compiler. I have template classes like public
class LinkedList(T) {...} and when I try compile it together,
everything works fine. But when I compile every source file to separate
object file and link it together with ld Ill get errors like:
/os/KernelLand/Kernel/TaskManager/Thread.d:99: undefined reference to
`_D7Library10LinkedList45__T10LinkedListTC11TaskManager6Thread6ThreadZ10LinkedList6__ctorMFNaNbNfZC7Library10LinkedList45__T10LinkedListTC11TaskManager6Thread6ThreadZ10LinkedList'
Im compiling it with command like:
gdc -mcmodel=kernel -nostdlib -mno-red-zone -Wall -masm=intel -frelease
-finline-functions -O3 -o obj-x86_64/abc.d.o -c abc.d
Here is
full error log http://pastebin.com/SjnYjqKh
makefile
https://github.com/Bloodmanovski/Trinix/blob/dc80f3197f59fe96e9f4e29cea670ff2c7eaa342/KernelLand/Kernel/Makefile#L104
LinkedList class
https://github.com/Bloodmanovski/Trinix/blob/dc80f3197f59fe96e9f4e29cea670ff2c7eaa342/KernelLand/Kernel/Library/LinkedList.d
Can anyone help me how to solve this problem? Thanks
(Sorry for bad english)
Try linking with gdc instead of ld.
-Steve
Re: InvalidMemoryOperationError@(0)
Thanks a lot.
I will forward this recommendation (DGUI BitBucket).
Kind regards
André
On Monday, 17 November 2014 at 16:40:18 UTC, ketmar via
Digitalmars-d-learn wrote:
On Mon, 17 Nov 2014 15:41:25 +
Andre via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
~this()
{
foreach(cp; this._columns)
{
}
}
don't do that in destructors. `_columns` field can be already
collected
by GC.
vibe.d problem
Hi there folks, let me the fact talk for me lazaro@leviatan:~$ dub init aplicacion vibe.d Successfully created an empty project in '/home/lazaro/aplicacion'. lazaro@leviatan:~$ cd aplicacion/ lazaro@leviatan:~/aplicacion$ dub run Building vibe-d 0.7.20 configuration libevent, build type debug. Running dmd... ../.dub/packages/vibe-d-0.7.20/source/vibe/templ/parsertools.d(12): Deprecation: module std.metastrings is deprecated - Please use std.string.format, std.conv.to or std.conv.parse instead ../.dub/packages/vibe-d-0.7.20/source/vibe/templ/diet.d(28): Deprecation: module std.metastrings is deprecated - Please use std.string.format, std.conv.to or std.conv.parse instead ../.dub/packages/vibe-d-0.7.20/source/vibe/core/drivers/libevent2.d(491): Deprecation: function core.time.Duration.fracSec is deprecated - Please use split instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/core/drivers/libevent2_tcp.d(110): Deprecation: function core.time.Duration.fracSec is deprecated - Please use split instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/core/drivers/libevent2_tcp.d(269): Deprecation: function core.time.Duration.fracSec is deprecated - Please use split instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/core/task.d(203): Deprecation: alias object.clear is deprecated - Please use destroy instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/core/task.d(204): Deprecation: alias object.clear is deprecated - Please use destroy instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/inet/message.d(186): Deprecation: constructor std.datetime.SimpleTimeZone.this is deprecated - Please use the overload which takes a Duration. ../.dub/packages/vibe-d-0.7.20/source/vibe/inet/webform.d(53): Error: std.string.indexOfAny!(char, char).indexOfAny at /usr/include/dmd/phobos/std/string.d(1044) conflicts with vibe.utils.string.indexOfAny at ../.dub/packages/vibe-d-0.7.20/source/vibe/utils/string.d(123) ../.dub/packages/vibe-d-0.7.20/source/vibe/inet/webform.d(63): Error: std.string.indexOfAny!(char, char).indexOfAny at /usr/include/dmd/phobos/std/string.d(1044) conflicts with vibe.utils.string.indexOfAny at ../.dub/packages/vibe-d-0.7.20/source/vibe/utils/string.d(123) ../.dub/packages/vibe-d-0.7.20/source/vibe/utils/memory.d(124): Deprecation: Read-modify-write operations are not allowed for shared variables. Use core.atomic.atomicOp!+=(this.m_bytes, sz) instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/utils/memory.d(140): Deprecation: Read-modify-write operations are not allowed for shared variables. Use core.atomic.atomicOp!-=(this.m_bytes, *pb) instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/utils/memory.d(143): Deprecation: Read-modify-write operations are not allowed for shared variables. Use core.atomic.atomicOp!+=(this.m_bytes, new_size) instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/utils/memory.d(152): Deprecation: Read-modify-write operations are not allowed for shared variables. Use core.atomic.atomicOp!-=(this.m_bytes, *pb) instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/utils/memory.d(161): Warning: calling std.exception.enforceEx!(OutOfMemoryError).enforceEx!bool.enforceEx without side effects discards return value of type bool, prepend a cast(void) if intentional ../.dub/packages/vibe-d-0.7.20/source/vibe/utils/memory.d(466): Deprecation: Read-modify-write operations are not allowed for shared variables. Use core.atomic.atomicOp!-=(this.m_nfree, 1) instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/utils/memory.d(471): Deprecation: Read-modify-write operations are not allowed for shared variables. Use core.atomic.atomicOp!+=(this.m_nalloc, 1) instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/utils/memory.d(489): Deprecation: Read-modify-write operations are not allowed for shared variables. Use core.atomic.atomicOp!-=(this.m_nalloc, 1) instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/utils/memory.d(490): Deprecation: Read-modify-write operations are not allowed for shared variables. Use core.atomic.atomicOp!+=(this.m_nfree, 1) instead. FAIL ../.dub/packages/vibe-d-0.7.20/.dub/build/libevent-debug-linux.posix-x86-dmd_2066-316CEFCAEB0F07469ED054933004D631/ vibe-d staticLibrary Error executing command run: dmd failed with exit code 1.
Re: Russian translation of the range term?
On Tuesday, 11 November 2014 at 11:50:18 UTC, Ivan Kazmenko wrote: Is there an official translation already? In TDPL, the (very few) occurrences of range are translated as диапазон (Cyrillic for diapason), how official is that? In Russian, the term diapason in computerspeak is used to refer to a range of possible values, as in the range (diapason) for an ubyte variable is from 0 to 255. Also, it has four syllables, making it long-ish to pronounce. Range sounds as odd to people new to D as диапазон, and has the same issue with the existing interpretation of an interval of values. Thus, диапазон is an accurate translation. Anyway, using established terminology outweighs accuracy of translation, as the former is less likely to confuse readers familiar with the subject.
Re: vibe.d problem
On Mon, 17 Nov 2014 16:24:17 -0500 låzaro via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Building vibe-d 0.7.20 configuration libevent, build type debug. this is very old. try git HEAD instead, it should help. signature.asc Description: PGP signature
Re: InvalidMemoryOperationError@(0)
On Monday, 17 November 2014 at 16:40:18 UTC, ketmar via
Digitalmars-d-learn wrote:
On Mon, 17 Nov 2014 15:41:25 +
Andre via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
~this()
{
foreach(cp; this._columns)
{
}
}
don't do that in destructors. `_columns` field can be already
collected
by GC.
Last I checked, the GC finalizes all dead objects before freeing
them. InvalidMemoryOperation indicates that an allocation
occurred, where is it?
I can't reproduce the problem with D from git HEAD.
Re: InvalidMemoryOperationError@(0)
On Monday, 17 November 2014 at 22:19:04 UTC, Vladimir Panteleev
wrote:
On Monday, 17 November 2014 at 16:40:18 UTC, ketmar via
Digitalmars-d-learn wrote:
On Mon, 17 Nov 2014 15:41:25 +
Andre via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
~this()
{
foreach(cp; this._columns)
{
}
}
don't do that in destructors. `_columns` field can be already
collected
by GC.
Last I checked, the GC finalizes all dead objects before
freeing them. InvalidMemoryOperation indicates that an
allocation occurred, where is it?
Found it. opApply is virtual, so the vtable is needed to call it.
The pointer is cleared during destruction, thus an access
violation occurs, which is attempted to be translated into a D
exception. However, when D attempts to allocate it, an
InvalidMemoryOperation occurs.
Re: InvalidMemoryOperationError@(0)
On 11/17/14 5:19 PM, Vladimir Panteleev wrote:
On Monday, 17 November 2014 at 16:40:18 UTC, ketmar via
Digitalmars-d-learn wrote:
On Mon, 17 Nov 2014 15:41:25 +
Andre via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
~this()
{
foreach(cp; this._columns)
{
}
}
don't do that in destructors. `_columns` field can be already collected
by GC.
Last I checked, the GC finalizes all dead objects before freeing them.
The GC is not guaranteed to finalize them all before freeing them all.
I would not count on that property -- even if it's currently true.
Expect that any GC-allocated memory in your dtor is invalid except for
the memory of the object itself.
-Steve
Debugging a Memory Leak
There seems to be a memory leak in the Higgs compiler. This problem shows up when running our test suite (`make test` command). A new VM object is created for each unittest block, e.g.: https://github.com/maximecb/Higgs/blob/master/source/runtime/tests.d#L201 These VM objects are unfortunately *never freed*. Not until the whole series of tests is run and the process terminates. The VM objects keep references to many other objects, and so the process keeps using more and more memory, up to over 2GB. The VM allocates it's own JS data heap that it manages itself, i.e.: https://github.com/maximecb/Higgs/blob/master/source/runtime/gc.d#L186 This memory is clearly marked as NO_SCAN, and so references to the VM in there should presumably not be counted. There is also executable memory I allocate with mmap, but this should also be ignored by the D GC in principle (I do not mark executable code as roots): https://github.com/maximecb/Higgs/blob/master/source/jit/codeblock.d#L129 I don't know where the problem lies. There could be false pointers, but I'm on a 64-bit system, which should presumably make this less likely. I wish there was a way to ask the D runtime can you tell me what is pointing to this object?, but the situation is more complex because many objects in my system refer to the VM object, there is a complicated graph of references. If anything points into that graph, the whole thing stays live. Help or advice on solving this problem is welcome.
Re: InvalidMemoryOperationError@(0)
On Monday, 17 November 2014 at 22:40:36 UTC, Steven Schveighoffer
wrote:
On 11/17/14 5:19 PM, Vladimir Panteleev wrote:
On Monday, 17 November 2014 at 16:40:18 UTC, ketmar via
Digitalmars-d-learn wrote:
On Mon, 17 Nov 2014 15:41:25 +
Andre via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
~this()
{
foreach(cp; this._columns)
{
}
}
don't do that in destructors. `_columns` field can be already
collected
by GC.
Last I checked, the GC finalizes all dead objects before
freeing them.
The GC is not guaranteed to finalize them all before freeing
them all.
I would not count on that property -- even if it's currently
true. Expect that any GC-allocated memory in your dtor is
invalid except for the memory of the object itself.
That's disappointing because it makes destructors considerably
less useful. I think that at this point, this will probably
become a guarantee for compatibility with existing code.
Compiling with SQLite
I'm new to D, and I'm trying to use SQLite, but I can't get this
basic program to compile:
import etc.c.sqlite3 : sqlite3_open;
void main(string[] args){
sqlite3_open(test.sqlite, null);
}
When compiling with DMD v2.066.1, I get this error:
test.o: In function `_Dmain':
test.d:(.text._Dmain+0x2f): undefined reference to `sqlite3_open'
collect2: ld returned 1 exit status
--- errorlevel 1
Any idea what I'm doing wrong? I'm on Ubuntu 12.04 64-bit, but I
doubt that matters. I've tried a couple alternatives, but they
didn't work either.
Re: Compiling with SQLite
Addendum: I'm using DDT for Eclipse, and the names I'm using come up in its autocomplete. They also appear at http://dlang.org/phobos/etc_c_sqlite3.html, which is why I'm stumped. I get what the error means, but I don't understand why it's occurring.
Re: Compiling with SQLite
On Tuesday, 18 November 2014 at 01:14:26 UTC, impatient-dev wrote:
I'm new to D, and I'm trying to use SQLite, but I can't get
this basic program to compile:
import etc.c.sqlite3 : sqlite3_open;
void main(string[] args){
sqlite3_open(test.sqlite, null);
}
When compiling with DMD v2.066.1, I get this error:
test.o: In function `_Dmain':
test.d:(.text._Dmain+0x2f): undefined reference to
`sqlite3_open'
collect2: ld returned 1 exit status
--- errorlevel 1
Any idea what I'm doing wrong? I'm on Ubuntu 12.04 64-bit, but
I doubt that matters. I've tried a couple alternatives, but
they didn't work either.
Are you linking with libsqlite3.a?
For example:
$ dmd prog.d -L-lsqlite3
Re: Debugging a Memory Leak
On 11/17/14 6:12 PM, Maxime Chevalier-Boisvert wrote: There seems to be a memory leak in the Higgs compiler. This problem shows up when running our test suite (`make test` command). A new VM object is created for each unittest block, e.g.: https://github.com/maximecb/Higgs/blob/master/source/runtime/tests.d#L201 These VM objects are unfortunately *never freed*. Not until the whole series of tests is run and the process terminates. The VM objects keep references to many other objects, and so the process keeps using more and more memory, up to over 2GB. The VM allocates it's own JS data heap that it manages itself, i.e.: https://github.com/maximecb/Higgs/blob/master/source/runtime/gc.d#L186 This memory is clearly marked as NO_SCAN, and so references to the VM in there should presumably not be counted. There is also executable memory I allocate with mmap, but this should also be ignored by the D GC in principle (I do not mark executable code as roots): https://github.com/maximecb/Higgs/blob/master/source/jit/codeblock.d#L129 I don't know where the problem lies. There could be false pointers, but I'm on a 64-bit system, which should presumably make this less likely. I wish there was a way to ask the D runtime can you tell me what is pointing to this object?, but the situation is more complex because many objects in my system refer to the VM object, there is a complicated graph of references. If anything points into that graph, the whole thing stays live. Hm... such a function could be created. However, it would be tricky to make work. First, you would need a way to store the pointer without having it actually point at the data. Clearly, if you pass the pointer to the function, it's going to be on the stack, so that would then refer to it. You have to somehow obfuscate it the whole time. Second, you may be given memory x is pointing at your target, but what does memory x actually mean? That isn't something the GC can deal with. Perhaps when precise scanning is included (and I think we are close on that), you will have at least some type info. Help or advice on solving this problem is welcome. GC problems are *nasty*. My advice is to run the simplest program you can think of that still exhibits the problem, and then put in printf debugging everywhere to see where it breaks down. Not sure if this is useful. -Steve
Re: InvalidMemoryOperationError@(0)
On 11/17/14 6:38 PM, Vladimir Panteleev wrote:
On Monday, 17 November 2014 at 22:40:36 UTC, Steven Schveighoffer wrote:
On 11/17/14 5:19 PM, Vladimir Panteleev wrote:
On Monday, 17 November 2014 at 16:40:18 UTC, ketmar via
Digitalmars-d-learn wrote:
On Mon, 17 Nov 2014 15:41:25 +
Andre via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
~this()
{
foreach(cp; this._columns)
{
}
}
don't do that in destructors. `_columns` field can be already collected
by GC.
Last I checked, the GC finalizes all dead objects before freeing them.
The GC is not guaranteed to finalize them all before freeing them all.
I would not count on that property -- even if it's currently true.
Expect that any GC-allocated memory in your dtor is invalid except for
the memory of the object itself.
That's disappointing because it makes destructors considerably less
useful. I think that at this point, this will probably become a
guarantee for compatibility with existing code.
destructors are *strictly* for freeing non-GC resources. That has been
in the spec from Day 1 (well, at least the earliest I can remember), and
it's the same for other GC-based systems as well, such as Java.
I don't want to say that making this requirement would hinder
performance, but I'd hate to lock us into the current GC model, as it
pretty much sucks performance-wise. I'd rather keep as many options open
as possible, to allow GC tinkering for performance.
-Steve
Re: Debugging a Memory Leak
GC problems are *nasty*. My advice is to run the simplest program you can think of that still exhibits the problem, and then put in printf debugging everywhere to see where it breaks down. Not sure if this is useful. Unfortunately, the program doesn't break or crash. It just keeps allocating memory that doesn't get freed. There must be some false reference somewhere. I'm not sure how I can printf debug my way out of that.
Re: Debugging a Memory Leak
On Monday, 17 November 2014 at 23:12:10 UTC, Maxime Chevalier-Boisvert wrote: Help or advice on solving this problem is welcome. The D GC has some debugging code which might be a little helpful (check the commented-out debug = X lines in druntime/src/gc/gc.d). Specifically, debug=LOGGING activates some sort of leak detector, though I'm not sure how effective it is as I've never used it. I've begun work on reviving Diamond to work for D2, multiple threads and x64. Once complete it should be able to answer such questions definitely, but it'll probably take a few days at least. Watch this space: https://github.com/CyberShadow/druntime/commits/diamond https://github.com/CyberShadow/Diamond
Re: Compiling with SQLite
On Tuesday, 18 November 2014 at 03:41:42 UTC, uri wrote: Are you linking with libsqlite3.a? For example: $ dmd prog.d -L-lsqlite3 That worked, thanks. I didn't know you had to anything special to link with code in the standard library; is there documentation for this somewhere? Also, is there a way I could make SQLite work with DUB rather than building manually? The command-line help and web page don't seem to mention this anywhere.
