On 15-10-2012 08:49, Alex Rønne Petersen wrote:
Hi,
Is there a GC-free hash map implementation for D somewhere on the
intertubes? (Preferably in a Git repository and under a
liberal/non-viral license.)
... s/have/have a/ ...
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
Hi,
Is there a GC-free hash map implementation for D somewhere on the
intertubes? (Preferably in a Git repository and under a
liberal/non-viral license.)
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
On 10/14/2012 10:43 PM, H. S. Teoh wrote:
I have an array of reals that I want to format with writefln, but the
precision field needs to be passed in a variable. For a single real, it
would be writefln("%.*f", precision, x); but when I try this:
int precision = ...;
real[] array
I have an array of reals that I want to format with writefln, but the
precision field needs to be passed in a variable. For a single real, it
would be writefln("%.*f", precision, x); but when I try this:
int precision = ...;
real[] array = ...;
writefln("%(%.*f, %)", precis
On Sat, 13 Oct 2012 18:53:48 -0700
Charles Hixson wrote:
> If std.stream is being deprecated, what is the correct way to deal
> with file BOMs. This is particularly concerning utf8 files, which I
> understand to be a bit problematic, as there isn't, actually, a utf8
> BOM, merely a convention
On 10/15/12 02:14, Andrej Mitrovic wrote:
> Johannes, are you still working on gobject introspection? libgit has
> gobject bindings so I remembered you mentioning something about
> working on gobject for D.
FWIW gobject bindings are part of my gtk2 bindings too;
http://repo.or.cz/w/girtod.git/b
On Oct 14, 2012, at 9:59 AM, Dmitry Olshansky wrote:
> On 14-Oct-12 20:19, Sean Kelly wrote:
>> On Oct 12, 2012, at 2:29 AM, Russel Winder wrote:
>>
>>> On Thu, 2012-10-11 at 20:30 -0700, Charles Hixson wrote:
>>> […]
I'm not clear on what Fibers are. From Ruby they seem to mean
co-r
On Monday, October 15, 2012 02:04:44 Andrej Mitrovic wrote:
> On 10/15/12, Jonathan M Davis wrote:
> > snip
>
> Hmm ok, this sheds some light on things.
>
> If a C function takes a const pointer and has no documentation about
> ownership then maybe it's a good guess to say it won't store that
>
On 10/15/12, Jonathan M Davis wrote:
> snip
Hmm ok, this sheds some light on things.
If a C function takes a const pointer and has no documentation about
ownership then maybe it's a good guess to say it won't store that
pointer anywhere and will only use it as a temporary?
On Monday, October 15, 2012 01:36:27 Andrej Mitrovic wrote:
> On 10/15/12, Jonathan M Davis wrote:
> > I'd have to see exactly what TDPL says to comment on that accurately
>
> Maybe I've misread it. On Page 288 it says:
>
> "An immutable value is cast in stone: as soon as it's been
> initialized
On 10/14/2012 04:36 PM, Andrej Mitrovic wrote:
> On 10/15/12, Jonathan M Davis wrote:
>> I'd have to see exactly what TDPL says to comment on that accurately
>
> Maybe I've misread it. On Page 288 it says:
>
> "An immutable value is cast in stone: as soon as it's been
> initialized, you may as we
On 10/15/12, Jonathan M Davis wrote:
> I'd have to see exactly what TDPL says to comment on that accurately
Maybe I've misread it. On Page 288 it says:
"An immutable value is cast in stone: as soon as it's been
initialized, you may as well
consider it has been burned forever into the memory stor
On Monday, October 15, 2012 00:51:34 Andrej Mitrovic wrote:
> On 10/15/12, Jonathan M Davis wrote:
> > Anything and everything with no references to it any
> > longer should be up for collection.
>
> I think this is fuzzy territory and it's a good opportunity to
> properly document GC behavior.
On Sunday, October 14, 2012 23:38:48 Andrej Mitrovic wrote:
> toStringz takes a string (immutable(char)[]), and the GC will not
> reclaim immutable data until app exit.
If the GC never collects immutable data which has no references to it until
the app closes, then there's a serious problem. Immu
On Sunday, 14 October 2012 at 19:04:22 UTC, Richard Webb wrote:
I haven't tried to run it, but as a random guess, does the user
your running it as have permissions to write to
HKEY_CLASSES_ROOT ?
Guess that would be it. Specifically told the program to run as
admin and it works. Should have c
On Sunday, 14 October 2012 at 07:14:25 UTC, Maxim Fomin wrote:
If this request is approved and compiler has opUnary definition
outside type (which suits better then alias
this) such function would hijack alias this.
Free functions cannot and must not ever hijack, i.e. modify
existing function
On 10/14/12 08:13, Maxim Fomin wrote:
> The only mentioned reason is to allow writing operator overloading methods
> outside type scope - just because somebody (currently two people) consider it
> logical to broaden UFCS usage.
It's more than two people... Also, it's not about "broadening UFCS u
I haven't tried to run it, but as a random guess, does the user
your running it as have permissions to write to HKEY_CLASSES_ROOT
?
On Sunday, 14 October 2012 at 09:40:36 UTC, Benjamin Thaut wrote:
Is there a way to make dmd ignore the default imports and
library search paths inside sc.ini?
Currently I have to keep two versions of dmd around, one with a
modified sc.ini and one with the original one, which is a bit
annoyin
On 14-Oct-12 20:19, Sean Kelly wrote:
On Oct 12, 2012, at 2:29 AM, Russel Winder wrote:
On Thu, 2012-10-11 at 20:30 -0700, Charles Hixson wrote:
[…]
I'm not clear on what Fibers are. From Ruby they seem to mean
co-routines, and that doesn't have much advantage. But it also seems as
[…]
I
On Oct 12, 2012, at 2:29 AM, Russel Winder wrote:
> On Thu, 2012-10-11 at 20:30 -0700, Charles Hixson wrote:
> […]
>> I'm not clear on what Fibers are. From Ruby they seem to mean
>> co-routines, and that doesn't have much advantage. But it also seems as
> […]
>
> I think the emerging consens
On 10/14/12, Benjamin Thaut wrote:
> Is there a way to make dmd ignore the default imports and library search
> paths inside sc.ini?
See http://dlang.org/dmd-windows.html#sc_ini
On Sunday, 14 October 2012 at 12:58:24 UTC, Simen Kjaeraas wrote:
On 2012-10-14, 14:28, Martin wrote:
Hey everyone, I'm new to D so bare with me please. I've been
trying to figure out what's up with the strange forward
refernce errors the compiler (DMD 2.060) is giving me. Here's
a code snipp
On 2012-10-14, 14:28, Martin wrote:
Hey everyone, I'm new to D so bare with me please. I've been trying to
figure out what's up with the strange forward refernce errors the
compiler (DMD 2.060) is giving me. Here's a code snippet that's
generating a forward reference error:
public class A
Hey everyone, I'm new to D so bare with me please. I've been
trying to figure out what's up with the strange forward refernce
errors the compiler (DMD 2.060) is giving me. Here's a code
snippet that's generating a forward reference error:
public class AliasTestClass(alias func)
{
On Friday, 12 October 2012 at 23:05:27 UTC, Jonathan M Davis
wrote:
You can have the variable be private and alias a function which
returns by ref
instead of the variable itself. Something like
class C
{
@property ref inout(Impl) get() inout { return _impl; }
alias get this;
private:
Impl
Is there a way to make dmd ignore the default imports and library search
paths inside sc.ini?
Currently I have to keep two versions of dmd around, one with a modified
sc.ini and one with the original one, which is a bit annoying.
A command line option for the compiler to ignore the defaults ins
On Sunday, 14 October 2012 at 07:01:30 UTC, Tommi wrote:
Actually, it seems that alias this has precedence over UFCS.
So, a free function opUnary wouldn't ever suit better than an
actual method opUnary of the thing referred to by that alias
this.
http://dpaste.dzfl.pl/d0a4431d
Free function
On Saturday, 13 October 2012 at 19:50:02 UTC, Timon Gehr wrote:
On 10/13/2012 06:02 PM, Maxim Fomin wrote:
...
Different groups of people have different mind and same things
produce
different sense on them. From my point of view operator
overloading
methods are special functions and not treati
On Sunday, 14 October 2012 at 06:22:03 UTC, Maxim Fomin wrote:
On Saturday, 13 October 2012 at 17:01:27 UTC, Tommi wrote:
Another way to describe my reasoning...
According to TDPL, if var is a variable of a user-defined
type, then:
++var
gets rewritten as:
var.opUnary!"++"()
Not always. If
30 matches
Mail list logo
