Re: Types of regex
I have gdc 4.6 on Debian testing. Is that so old ?
Re: nested enum like template generator
On Tuesday, 16 July 2013 at 04:37:33 UTC, Ali Çehreli wrote:
On 07/15/2013 08:43 PM, JS wrote:
> http://dpaste.dzfl.pl/7c8b0ba9
>
> Why the heck can't we use integers in ctfe's? There seems to
be no
> simple way to create a counter and this is one of the most
basic
> programming constructs to use.. yet with ctfe's it's
impossible.
>
> I'd like each variable in the nested structs to be
incremented properly.
I did not read the code but just from your description, the
separate compilation model that D uses would preclude that. For
example, compilation of a.d would not know anything about the
counter that b.d has counted during its compilation.
Ali
Huh? what is a.d and b.d?
The template transforms a string into a D code string... which is
then string mixed in. The counter and code generation have
nothing to do with the result. A counter is needed in the
generation of the code to generate enum like characteristics.
It does use recursion, and I could pass a variable that counts
the number of elements but this too would probably not work due
to D bitching about using ints.
I imagine one could hack D to make it's flawed CTFE system work,
to some degree... like using strings:
template inc(string s)
{
string _(string a)
{
if (a == "0") return "1";
if (a == "1") return "2";
if (a == "2") return "3";
if (a == "3") return "4";
return "0";
}
enum inc = _(s); pragma(msg, ":"~_(s));
}
which is a modulo 4 incrementer. So, CTFE's have the ability to
count... but extremely short sighted that they don't. I imagine
can write a whole template library using strings to emulate ints
in ctfe's... what a shame though...
Re: nested enum like template generator
On 07/15/2013 08:43 PM, JS wrote: > http://dpaste.dzfl.pl/7c8b0ba9 > > Why the heck can't we use integers in ctfe's? There seems to be no > simple way to create a counter and this is one of the most basic > programming constructs to use.. yet with ctfe's it's impossible. > > I'd like each variable in the nested structs to be incremented properly. I did not read the code but just from your description, the separate compilation model that D uses would preclude that. For example, compilation of a.d would not know anything about the counter that b.d has counted during its compilation. Ali
Re: immutable struct/class is mutable!
On Tuesday, 16 July 2013 at 02:59:50 UTC, Ali Çehreli wrote:
On 07/15/2013 07:50 AM, JS wrote:
> Why does isMutable and isAssignable return true for a
struct/class that
> are immutable?
>
> immutable struct A { }
>
> isMutable!A returns true.
import std.traits;
struct S
{}
alias ImmutableS = immutable(S);
void main()
{
static assert(!isMutable!ImmutableS);
static assert(!isAssignable!ImmutableS);
}
Is that what you are looking for?
Ali
This would essentially work but I really would prefer a short
hand notation immutable(struct) S. I am nesting structs and
would have a lot of aliases.
nested enum like template generator
http://dpaste.dzfl.pl/7c8b0ba9 Why the heck can't we use integers in ctfe's? There seems to be no simple way to create a counter and this is one of the most basic programming constructs to use.. yet with ctfe's it's impossible. I'd like each variable in the nested structs to be incremented properly.
Re: immutable struct/class is mutable!
On 07/15/2013 07:50 AM, JS wrote:
> Why does isMutable and isAssignable return true for a struct/class that
> are immutable?
>
> immutable struct A { }
>
> isMutable!A returns true.
import std.traits;
struct S
{}
alias ImmutableS = immutable(S);
void main()
{
static assert(!isMutable!ImmutableS);
static assert(!isAssignable!ImmutableS);
}
Is that what you are looking for?
Ali
Re: immutable struct/class is mutable!
On Tuesday, July 16, 2013 03:46:06 JS wrote:
> On Tuesday, 16 July 2013 at 01:24:37 UTC, Jonathan M Davis wrote:
> > On Monday, July 15, 2013 21:08:03 Dicebot wrote:
> >> On Monday, 15 July 2013 at 18:39:08 UTC, JS wrote:
> >> > and immutability doesn't nest. immutable struct A { struct B
> >> > {
> >> > }}, struct B is mutable.
> >>
> >> What I have meant by "may be intended behavior" is that
> >> immutable
> >> qualifier does not attach at aggregate definitions. At all. It
> >> is
> >> irrelevant to the fact if B is nested or not.
> >
> > Yes. Attributes such as immutable or private have no effect on
> > structs or
> > classes, just their members. It's a bit weird that way, but
> > that's the way
> > that it works.
>
> Then we should be able to make a struct immutable itself. e.g.,
> immutable immutable(struct) A makes both A and it's members
> immutable. An immutable struct makes nested structs also
> immutable.
The way it works is that immutable on a struct should make anything within
that struct (member variables, member functions, etc.) immutable. That should
include nested members but apparently does not currently due to a bug. That
behavior makes perfect sense to me. Aside from the bug fix, I don't understand
what you're trying to gain here. As far as immutability goes, this behavior
seems perfectly fine to me. I just find it a bit weird with regards to private,
since it makes it so that you can't actually make a struct or class private -
just its members. But since you can't do anything to it without accessing its
members, AFAIK that behavior doesn't actually cause any problems.
- Jonathan M Davis
Re: Naming convention for template parameters
On Monday, 15 July 2013 at 23:03:45 UTC, H. S. Teoh wrote: I generally use R 'cos it's less typing and I'm lazy, but Walter has been recently of the opinion that a more descriptive name is necessary for ddoc purposes, e.g., MyStruct(InputRange)(InputRange r) One thing about that is that the type is being encoded into the name of the template parameter. Ideally, the type shouldn't be important, with the template constraints documenting anything noteworthy. With MyStruct, for example, I think MyStruct(Range)(Range r) would be better than the former, as it's more general. Then a template constraint such as if(isInputRange!Range) documents that the type must be at least an input range.
Re: immutable struct/class is mutable!
On Tuesday, 16 July 2013 at 01:24:37 UTC, Jonathan M Davis wrote:
On Monday, July 15, 2013 21:08:03 Dicebot wrote:
On Monday, 15 July 2013 at 18:39:08 UTC, JS wrote:
> and immutability doesn't nest. immutable struct A { struct B
> {
> }}, struct B is mutable.
What I have meant by "may be intended behavior" is that
immutable
qualifier does not attach at aggregate definitions. At all. It
is
irrelevant to the fact if B is nested or not.
Yes. Attributes such as immutable or private have no effect on
structs or
classes, just their members. It's a bit weird that way, but
that's the way
that it works.
Then we should be able to make a struct immutable itself. e.g.,
immutable immutable(struct) A makes both A and it's members
immutable. An immutable struct makes nested structs also
immutable.
However, I have just checked and adding a member field to B
also
leaves it mutable. And that is really frustrating.
That definitely sounds like a bug.
- Jonathan M Davis
Re: immutable struct/class is mutable!
On Monday, July 15, 2013 21:08:03 Dicebot wrote:
> On Monday, 15 July 2013 at 18:39:08 UTC, JS wrote:
> > and immutability doesn't nest. immutable struct A { struct B {
> > }}, struct B is mutable.
>
> What I have meant by "may be intended behavior" is that immutable
> qualifier does not attach at aggregate definitions. At all. It is
> irrelevant to the fact if B is nested or not.
Yes. Attributes such as immutable or private have no effect on structs or
classes, just their members. It's a bit weird that way, but that's the way
that it works.
> However, I have just checked and adding a member field to B also
> leaves it mutable. And that is really frustrating.
That definitely sounds like a bug.
- Jonathan M Davis
Re: Reverse Lexical Order
On Mon, Jul 15, 2013 at 08:59:44PM -0400, Jonathan M Davis wrote: > On Monday, July 15, 2013 14:48:08 Manfred Nowak wrote: > > Jonathan M Davis wrote: > > > gotos in such a context seem like a bit > > > of a nightmare to me though. > > > > I did realize this nightmare. Therefore the assurance in the docs > > is probably true only in the absence within the scope of at least > > gotos to targets within the scope. > > Well, I'd have to study exactly how goto works to say how exactly it > would interact with stuff like try-catch. I've pretty much only used > goto with case statements and loops and haven't spent the time trying > to sort out all of its idiosyncracies. I guess that I should add that > to be my todo list. [...] My understanding is that goto translates directly to a jump in assembly, so jumping in/out of blocks with declarations or stuff that needs cleanups should immediately raise red flags. Of course, the compiler may do something intelligent by inserting implicit stack pointer adjustments and/or cleanup blocks, but I wouldn't count on it unless the language spec explicitly requires so. T -- I am Ohm of Borg. Resistance is voltage over current.
Re: Reverse Lexical Order
On Monday, July 15, 2013 14:48:08 Manfred Nowak wrote: > Jonathan M Davis wrote: > > gotos in such a context seem like a bit > > of a nightmare to me though. > > I did realize this nightmare. Therefore the assurance in the docs > is probably true only in the absence within the scope of at least > gotos to targets within the scope. Well, I'd have to study exactly how goto works to say how exactly it would interact with stuff like try-catch. I've pretty much only used goto with case statements and loops and haven't spent the time trying to sort out all of its idiosyncracies. I guess that I should add that to be my todo list. - Jonathan M Davis
Re: Naming convention for template parameters
On Mon, Jul 15, 2013 at 4:02 PM, H. S. Teoh wrote: > On Tue, Jul 16, 2013 at 12:52:21AM +0200, Joseph Rushton Wakeling wrote: > > Hello all, > > > > Quick query -- what's the preferred template variable name for a range > type? > > > > I've seen both R and Range used as options but want to confirm if > there's a > > preference for one or the other. It occurs to me that Range might > potentially > > clash with some library or user-created entity. > [...] > > I don't think it matters in this case, as the name would only be visible > within the scope of the template, and AFAICT would shadow any external > definitions, so you shouldn't get into trouble with it. > > I generally use R 'cos it's less typing and I'm lazy, but Walter has > been recently of the opinion that a more descriptive name is necessary > for ddoc purposes, e.g., MyStruct(InputRange)(InputRange r) is much more > self-documenting than MyStruct(R)(R r). Template signatures aren't > included in ddoc output IIRC, so this can be an important consideration. > > Using Range is vague (inputRange? etc) anyways so might as well use R. Including template constraints in generated doc would make this a non-issue. I don't understand the rationale for not including them. I've raised the issue before, see [1]. For example in http://dlang.org/phobos/std_algorithm.html we have: void reverse(Range)(Range r); void reverse(Range)(Range r); which is really not helpful. It should show full signature: void reverse(Range)(Range r) if (isBidirectionalRange!Range && !isRandomAccessRange!Range && hasSwappableElements!Range) void reverse(Range)(Range r) if (isRandomAccessRange!Range && hasLength!Range) and even better, with shorter type: void reverse(R)(R r) if (isBidirectionalRange!R && !isRandomAccessRange!R && hasSwappableElements!R) void reverse(R)(R r) if (isRandomAccessRange!R && hasLength!R) [1]: implicit template constraint notation : http://forum.dlang.org/post/mailman.1006.1370836279.13711.digitalmar...@puremagic.com ).
Re: Naming convention for template parameters
On 07/16/2013 01:02 AM, H. S. Teoh wrote: > I generally use R 'cos it's less typing and I'm lazy ... ditto ... :-) > but Walter has been recently of the opinion that a more descriptive name > is necessary for ddoc purposes, e.g., MyStruct(InputRange)(InputRange r) > is much more self-documenting than MyStruct(R)(R r). Yes, that was my main consideration for this case. I'm worried about the potential for clashes with other elements of the namespace, though. I'm thinking in particular of the tendency to use Random as the template parameter name for a random number generator, when Random is actually an alias for the default RNG type. I've proposed a blanket rewrite of such template parameter names to Rng: http://d.puremagic.com/issues/show_bug.cgi?id=10434 Particular context is that I'm trying to tidy up/standardize some bits of std.random and I'd like my standards to be future-proof. :-)
Re: Naming convention for template parameters
On Tue, Jul 16, 2013 at 12:52:21AM +0200, Joseph Rushton Wakeling wrote: > Hello all, > > Quick query -- what's the preferred template variable name for a range type? > > I've seen both R and Range used as options but want to confirm if there's a > preference for one or the other. It occurs to me that Range might potentially > clash with some library or user-created entity. [...] I don't think it matters in this case, as the name would only be visible within the scope of the template, and AFAICT would shadow any external definitions, so you shouldn't get into trouble with it. I generally use R 'cos it's less typing and I'm lazy, but Walter has been recently of the opinion that a more descriptive name is necessary for ddoc purposes, e.g., MyStruct(InputRange)(InputRange r) is much more self-documenting than MyStruct(R)(R r). Template signatures aren't included in ddoc output IIRC, so this can be an important consideration. T -- Today's society is one of specialization: as you grow, you learn more and more about less and less. Eventually, you know everything about nothing.
Naming convention for template parameters
Hello all, Quick query -- what's the preferred template variable name for a range type? I've seen both R and Range used as options but want to confirm if there's a preference for one or the other. It occurs to me that Range might potentially clash with some library or user-created entity. Thanks & best wishes, -- Joe
Re: enum inheritance
On Monday, 15 July 2013 at 19:24:27 UTC, Dicebot wrote: On Monday, 15 July 2013 at 18:26:26 UTC, JS wrote: Original I had it as a class. I'm not sure if it matters much between a class and a struct though? It does matter a lot. structs are value types, classes are polymorphic reference types. There is a nice summary table in docs: http://dlang.org/struct.html , please notice that "inheritance" and this "final" applies only for classes. um, but I'm only using the type at compile time. the immutable fields in it all result in compile time literals... the struct itself never gets used at run time... so there is no runtime difference(or shouldn't be) except maybe a little more wasted space with the class unless it is optimized out. In any case, I solved this problem by using an attribute to test instead of using isMutable. Obviously this requires adding a symbol but not a huge deal. e.g., @Enum immutable struct ... and hasAttribute(T, Enum) replaces isMutable(T). Yeah, that may work, despite being not that pretty. I personally think it is better for now chose some not-that-elegant approach in your code, at least until enums will become more robust. Currently it tries to workaround some very basic type system assumptions, which rarely ends good. I really don't have 10 years to wait for enums to become more robust and hope in the way I am trying to use them.
Re: Allocate N elements
Namespace: Ah, good to know. But anyway malloc allocates exact N elements, without ugly overhead. Would be really good if there was a way to avoid that the GC takes over the memory. That wasted space is what you pay to reduce memory fragmentation with a not copying GC. Bye, bearophile
Re: Allocate N elements
On Mon, Jul 15, 2013 at 09:53:32PM +0200, Namespace wrote: > On Monday, 15 July 2013 at 18:29:12 UTC, Adam D. Ruppe wrote: > >On Monday, 15 July 2013 at 18:16:45 UTC, Namespace wrote: > >>writeln(arr.length, "::", arr.capacity); > > > >arr.capacity checks the GC block, and since you malloced it, there > >is no gc block for it to check. So it simply doesn't know if > >there's any extra capacity there and reports 0 just to be safe. > > Ah, good to know. But anyway malloc allocates exact N elements, > without ugly overhead. [...] I doubt malloc has no overhead. AFAIK, many malloc implementations store some kind of bookkeeping info in the area of memory just before the pointer that's returned. After all, malloc/free has to somehow know which memory blocks are allocated and which are free. Some implementations also store canary values in that area in order to detect memory corruptions. T -- Старый друг лучше новых двух.
Re: Allocate N elements
On 07/15/2013 12:53 PM, Namespace wrote: > But anyway malloc allocates exact N elements, without ugly overhead. I doubt it. If its allocating from a bucket, then what actually gets used is the size of that bucket. Ali
Re: Allocate N elements
On Monday, 15 July 2013 at 18:29:12 UTC, Adam D. Ruppe wrote: On Monday, 15 July 2013 at 18:16:45 UTC, Namespace wrote: writeln(arr.length, "::", arr.capacity); arr.capacity checks the GC block, and since you malloced it, there is no gc block for it to check. So it simply doesn't know if there's any extra capacity there and reports 0 just to be safe. Ah, good to know. But anyway malloc allocates exact N elements, without ugly overhead. Would be really good if there was a way to avoid that the GC takes over the memory.
Re: Question about function type parameter type hints?
On 07/15/2013 11:56 AM, Gary Willoughby wrote:
> class TypeHint
> {
> public T method(T)() if (is(T == int))
> {
> return T.init;
> }
> }
>
> ...
>
> class TypeHint
> {
> public T method(T : int)()
> {
> return T.init;
> }
> }
>
> ...
Classes make this question more complicated than it actually is. :) The
same can be said for non-member functions as well.
> Are the two above class declarations achieving the same thing? i.e. is
> the type hint of the second snippet shorthand for the first's 'if'?
They are not the same feature but sometimes they achieve the same purpose.
The former uses a template constraint, communicating to the callers that
T can only be int. This allows the compiler to generate an error
message, importantly at the call site. So, it is the responsibility of
the caller to ensure that method() member function is called by an int.
The latter is a template specialization. (Although, I remember reading
here that D templates don't have specialization; I don't understand the
technicalities.) When this form is used, generally I would expect to see
a non-specialized overload of method() as well. The non-specialized
would be for all the other types and (T : int) would be for int.
> If so which is preferred?
When constraining the use, I prefer the former. When defining a special
implementation for int, I prefer the latter.
Ali
Re: enum inheritance
On Monday, 15 July 2013 at 18:26:26 UTC, JS wrote: Original I had it as a class. I'm not sure if it matters much between a class and a struct though? It does matter a lot. structs are value types, classes are polymorphic reference types. There is a nice summary table in docs: http://dlang.org/struct.html , please notice that "inheritance" and this "final" applies only for classes. In any case, I solved this problem by using an attribute to test instead of using isMutable. Obviously this requires adding a symbol but not a huge deal. e.g., @Enum immutable struct ... and hasAttribute(T, Enum) replaces isMutable(T). Yeah, that may work, despite being not that pretty. I personally think it is better for now chose some not-that-elegant approach in your code, at least until enums will become more robust. Currently it tries to workaround some very basic type system assumptions, which rarely ends good.
Re: Question about function type parameter type hints?
On Monday, 15 July 2013 at 18:56:38 UTC, Gary Willoughby wrote:
Are the two above class declarations achieving the same thing?
i.e. is the type hint of the second snippet shorthand for the
first's 'if'? If so which is preferred?
No, ":" stands for "same or implicitly convertible" while "==" is
strict "same":
T foo1(T : int)()
{
return T.init;
}
T foo2(T)()
if (is(T == int))
{
return T.init;
}
void main()
{
foo1!short();
foo2!short(); // error
}
As far as I know there are no "==" syntax for template
specialization. Usually template specialization syntax is
preferable for simple cases because it is more readable but any
complex case pretty much requires "if" constraint.
Re: immutable struct/class is mutable!
On Monday, 15 July 2013 at 18:39:08 UTC, JS wrote:
and immutability doesn't nest. immutable struct A { struct B {
}}, struct B is mutable.
What I have meant by "may be intended behavior" is that immutable
qualifier does not attach at aggregate definitions. At all. It is
irrelevant to the fact if B is nested or not.
However, I have just checked and adding a member field to B also
leaves it mutable. And that is really frustrating.
Have filed a bugzilla issue:
http://d.puremagic.com/issues/show_bug.cgi?id=10649
Question about function type parameter type hints?
class TypeHint
{
public T method(T)() if (is(T == int))
{
return T.init;
}
}
...
class TypeHint
{
public T method(T : int)()
{
return T.init;
}
}
...
Are the two above class declarations achieving the same thing?
i.e. is the type hint of the second snippet shorthand for the
first's 'if'? If so which is preferred?
Re: immutable struct/class is mutable!
On Monday, 15 July 2013 at 15:08:58 UTC, Dicebot wrote:
On Monday, 15 July 2013 at 14:50:04 UTC, JS wrote:
Why does isMutable and isAssignable return true for a
struct/class that are immutable?
immutable struct A { }
isMutable!A returns true.
looks like
immutable struct A
{
int a;
}
acts as a
struct A
{
immutable:
int a;
}
Now, I don't see this use case (qualified aggregate definition)
anywhere in spec and this may be intended behavior. But I do
agree this looks misleading.
and immutability doesn't nest. immutable struct A { struct B {
}}, struct B is mutable.
Re: enum inheritance
On Monday, 15 July 2013 at 13:47:10 UTC, Dicebot wrote: On Monday, 15 July 2013 at 13:01:05 UTC, JS wrote: ... I see. No, unfortunately, I am currently not aware of a way to make symbol act as type and and value at the same time. However it is worth noting that you use plenty of excessive attributes. Currently it is not a compiler error but makes code much harder to read and confusing. For example, "final" has no meaning for structs as they can't be inherited from anyway. Duplicating immutable is also excessive because it is transitive. Original I had it as a class. I'm not sure if it matters much between a class and a struct though? In any case, I solved this problem by using an attribute to test instead of using isMutable. Obviously this requires adding a symbol but not a huge deal. e.g., @Enum immutable struct ... and hasAttribute(T, Enum) replaces isMutable(T).
Re: Allocate N elements
On Monday, 15 July 2013 at 18:16:45 UTC, Namespace wrote: writeln(arr.length, "::", arr.capacity); arr.capacity checks the GC block, and since you malloced it, there is no gc block for it to check. So it simply doesn't know if there's any extra capacity there and reports 0 just to be safe.
Re: Allocate N elements
No. *EVEN* with an "ugly malloc", you'll still over allocate (see above). int* ptr = cast(int*) malloc(513 * int.sizeof); int[] arr = ptr[0 .. 513]; writeln(arr.length, "::", arr.capacity); Output: 513::0 Where is the over allocation?
Re: Types of regex
15-Jul-2013 14:21, Larry пишет: Humm, A copy-paste of your code lead to : "[[segmentation fault" So it doesn't work for me. I use gdc if it might help ! It looks like a _very_ old GDC. What's you version string/OS/package ? -- Dmitry Olshansky
Re: immutable struct/class is mutable!
On Monday, 15 July 2013 at 16:17:02 UTC, John Colvin wrote:
On Monday, 15 July 2013 at 15:59:44 UTC, JS wrote:
On Monday, 15 July 2013 at 15:08:58 UTC, Dicebot wrote:
On Monday, 15 July 2013 at 14:50:04 UTC, JS wrote:
Why does isMutable and isAssignable return true for a
struct/class that are immutable?
immutable struct A { }
isMutable!A returns true.
looks like
immutable struct A
{
int a;
}
acts as a
struct A
{
immutable:
int a;
}
Now, I don't see this use case (qualified aggregate
definition) anywhere in spec and this may be intended
behavior. But I do agree this looks misleading.
Yes, I need immutable to do what it does but also need a way
to emulate an enum.
This is because I need to constrain my templates properly. If
struct A isn't immutable then it is no different than any
other struct which is bad because I want only enum like
structs.
maybe immutable immutable(struct) A would be a good way to
specify this.
An immutable struct should be similar to an enum... a purely
compile time construct not meant to be instantiated in any way.
Why is it you're trying to emulate an enum? Perhaps there's a
way to achieve what you want by more normal means.
see my other recent post...
Re: Allocate N elements
On Mon, Jul 15, 2013 at 07:32:37PM +0200, monarch_dodra wrote: > On Monday, 15 July 2013 at 15:54:57 UTC, bearophile wrote: > >monarch_dodra: > > > >>>But that (of new arrays) is a bad design, it wastes too much > >>>memory, and I think it should be fixed. In Python this doesn't > >>>overallocate: > >> > >>So what? The only thing you showed, is that minimallyInitialized > >>doesn't know how much it allocated. If you allocate 513 elements > >>with malloc, you'll way over allocate too. What's your point? > >>You'll waste memory either way. > > > >I didn't know it, sorry. I forgot. > >Can we let minimallyInitializedArray know the capacity? > > I'm working on it ;) > > >Regarding the small arrays, so to avoid the memory wasting you > >need to allocate a larger one and slice it. > > > >Bye, > >bearophile > > One of the problems is that when you want an arbitrarily sized > allocation, it is usually standard to allocate 2^N in size. While > this is optimal for "traditional" malloc, it's actually the *worst* > allocation size you could ask for a GC array with appendable info > (eg, traditional new) :/ This is wrong. The 2^N size should be applied *after* GC appendable info (or whatever else bookkeeping info you need) has been accounted for, not before. If the GC header/whatever requires, say, 16 bytes, then the ideal array size should be 2^N-16, so that everything fits neatly within a power of 2. Otherwise you end up with 2^N+16 bytes that are actually allocated, and it just goes downhill from there. T -- What do you call optometrist jokes? Vitreous humor.
Re: Allocate N elements
On Monday, 15 July 2013 at 15:54:57 UTC, bearophile wrote: monarch_dodra: But that (of new arrays) is a bad design, it wastes too much memory, and I think it should be fixed. In Python this doesn't overallocate: So what? The only thing you showed, is that minimallyInitialized doesn't know how much it allocated. If you allocate 513 elements with malloc, you'll way over allocate too. What's your point? You'll waste memory either way. I didn't know it, sorry. I forgot. Can we let minimallyInitializedArray know the capacity? I'm working on it ;) Regarding the small arrays, so to avoid the memory wasting you need to allocate a larger one and slice it. Bye, bearophile One of the problems is that when you want an arbitrarily sized allocation, it is usually standard to allocate 2^N in size. While this is optimal for "traditional" malloc, it's actually the *worst* allocation size you could ask for a GC array with appendable info (eg, traditional new) :/
Re: Is there anything in the standard library to help writing a file watcher?
https://code.google.com/p/simplefilewatcher/ may help with platform specific solutions. On Thursday, 23 May 2013 at 18:56:41 UTC, Gary Willoughby wrote: Hmmm.. this is what i first thought. I think i'll implement a simple watcher based on modification times as a first iteration. Then if time allows add platform specific solutions based on the above. Thanks.
Re: immutable struct/class is mutable!
On Monday, 15 July 2013 at 15:59:44 UTC, JS wrote:
On Monday, 15 July 2013 at 15:08:58 UTC, Dicebot wrote:
On Monday, 15 July 2013 at 14:50:04 UTC, JS wrote:
Why does isMutable and isAssignable return true for a
struct/class that are immutable?
immutable struct A { }
isMutable!A returns true.
looks like
immutable struct A
{
int a;
}
acts as a
struct A
{
immutable:
int a;
}
Now, I don't see this use case (qualified aggregate
definition) anywhere in spec and this may be intended
behavior. But I do agree this looks misleading.
Yes, I need immutable to do what it does but also need a way to
emulate an enum.
This is because I need to constrain my templates properly. If
struct A isn't immutable then it is no different than any other
struct which is bad because I want only enum like structs.
maybe immutable immutable(struct) A would be a good way to
specify this.
An immutable struct should be similar to an enum... a purely
compile time construct not meant to be instantiated in any way.
Why is it you're trying to emulate an enum? Perhaps there's a way
to achieve what you want by more normal means.
getter/setter in one function (almost)
unfortunately, dmd doesn't accept the signature as a valid property.
import std.stdio;
import std.typecons;
struct T {
int _i;
@property int i(Nullable!int derp = Nullable!int.init) {
return _i = derp.isNull ? _i : derp.get;
}
}
void main () {
T t;
t.i = 1;
writeln(t.i);
}
Re: immutable struct/class is mutable!
On Monday, 15 July 2013 at 15:08:58 UTC, Dicebot wrote:
On Monday, 15 July 2013 at 14:50:04 UTC, JS wrote:
Why does isMutable and isAssignable return true for a
struct/class that are immutable?
immutable struct A { }
isMutable!A returns true.
looks like
immutable struct A
{
int a;
}
acts as a
struct A
{
immutable:
int a;
}
Now, I don't see this use case (qualified aggregate definition)
anywhere in spec and this may be intended behavior. But I do
agree this looks misleading.
Yes, I need immutable to do what it does but also need a way to
emulate an enum.
This is because I need to constrain my templates properly. If
struct A isn't immutable then it is no different than any other
struct which is bad because I want only enum like structs.
maybe immutable immutable(struct) A would be a good way to
specify this.
An immutable struct should be similar to an enum... a purely
compile time construct not meant to be instantiated in any way.
Re: DLLs: Cleaning up
On Monday, 15 July 2013 at 15:26:49 UTC, Ellery Newcomer wrote: On 07/15/2013 07:18 AM, Chris wrote: doesn't work with newer versions of dmd does too. (I'm the maintainer) https://bitbucket.org/ariovistus/pyd Thank you very much (I used an old version of pyd I had found at http://pyd.dsource.org/), which gave me loads of warnings from the latest dmd compiler. But I have installed the latest version now and the obligatory "hello world" program works! I'll try to build my dll with pyd and will let you know what happened. I hope it can cope with the third party libraries my dll uses ... We'll see. Thanks again.
Re: Allocate N elements
monarch_dodra: But that (of new arrays) is a bad design, it wastes too much memory, and I think it should be fixed. In Python this doesn't overallocate: So what? The only thing you showed, is that minimallyInitialized doesn't know how much it allocated. If you allocate 513 elements with malloc, you'll way over allocate too. What's your point? You'll waste memory either way. I didn't know it, sorry. I forgot. Can we let minimallyInitializedArray know the capacity? Regarding the small arrays, so to avoid the memory wasting you need to allocate a larger one and slice it. Bye, bearophile
Re: Allocate N elements
On Monday, 15 July 2013 at 13:13:42 UTC, bearophile wrote:
Output:
512 1019
512 1019
512 0
But that (of new arrays) is a bad design, it wastes too much
memory, and I think it should be fixed. In Python this doesn't
overallocate:
So what? The only thing you showed, is that minimallyInitialized
doesn't know how much it allocated. If you allocate 513 elements
with malloc, you'll way over allocate too. What's your point?
//
import std.stdio, core.memory;
void main()
{
auto u = GC.qalloc(513);
writeln(u.size); //print 1024. Oops.
}
//
You'll waste memory either way. The only difference is a 1-2 byte
difference for arrays smaller than 2K, and 16 bytes for arrays
larger than 2K.
The comparison is very unfair, and the wasted room is minimal.
It's just more visible... yet more exploitable. Dynamic GC arrays
have a tendency to grow in-place, and use all their capacity,
when malloc always eagerly relocates.
To answer the original question:
Is there no way (besides the ugly malloc or any wrappers) to
allocate _exactly_ N elements at runtime (no static array)?
I tried
No. *EVEN* with an "ugly malloc", you'll still over allocate (see
above).
Hell, at the end of the day, it's even worst, because you
over-allocate, yet you don't know it, nor exploit the
over-allocated data (unless you *very* manually use qalloc).
Another question:
I have this code:
[...]
Is it possible to prohibit that the slice is resized,
to avoid GC allocations?
No. The only way this works is *if* there is a GC to safety net
catch you if relocation must occur. That said, you can very
easily write your own:
//
//Disclaimer: VERY unsafe.
ref T[] unsafeAppend(T, U)(ref T[] arr, U u)
{
immutable len = arr.length;
arr.ptr[len] = u;
arr = arr[0 .. len + 1];
}
//
void main()
{
auto u = GC.qalloc(512);
int[] arr = (cast(int*)u.base)[0 .. 0];
arr.unsafeAppend(1).unsafeAppend(2).unsafeAppend(3).writeln();
}
//
Disclaimer: This will give you 0 overflow protection. Also, do
NOT use this with GC arrays: The added elements will not be
"seen" by the GC, and will also be clobbered by normal appends.
Re: DLLs: Cleaning up
On 07/15/2013 07:18 AM, Chris wrote: doesn't work with newer versions of dmd does too. (I'm the maintainer) https://bitbucket.org/ariovistus/pyd
Re: Allocate N elements
Namespace:
Is it possible to prohibit that the slice is resized, to avoid
GC allocations?
For that I think you need to define a struct that disables the
append and uses an alias this. But then some of your array
function argument signatures need to change, because lot of D
code uses "raw" arrays signatures like:
void foo(int[] arg) {}
Instead of:
alias MArr = int[];
void foo(MArr arg) {}
Or using Typedef (untested):
alias MArr = Typedef!(int[]);
void foo(MArr arg) {}
Bye,
bearophile
Re: immutable struct/class is mutable!
On Monday, 15 July 2013 at 14:50:04 UTC, JS wrote:
Why does isMutable and isAssignable return true for a
struct/class that are immutable?
immutable struct A { }
isMutable!A returns true.
looks like
immutable struct A
{
int a;
}
acts as a
struct A
{
immutable:
int a;
}
Now, I don't see this use case (qualified aggregate definition)
anywhere in spec and this may be intended behavior. But I do
agree this looks misleading.
immutable struct/class is mutable!
Why does isMutable and isAssignable return true for a
struct/class that are immutable?
immutable struct A { }
isMutable!A returns true.
Re: Allocate N elements
Another question:
I have this code:
void main() {
int* ptr = cast(int*) malloc(11 * int.sizeof);
int[] arr = ptr[0 .. 11];
assert(arr.ptr is ptr);
arr ~= 42;
assert(ptr !is arr.ptr);
}
Is it possible to prohibit that the slice is resized, to avoid GC
allocations?
Re: DLLs: Cleaning up
On Sunday, 14 July 2013 at 21:10:53 UTC, Ellery Newcomer wrote:
On 07/11/2013 05:58 AM, Chris wrote:
I have a DLL written in D I load into a Python application via
ctypes
like so:
lib = CDLL("mydll")
The DLL loads and can be used no problem. However, once the
DLL is
discarded of by the program, the program either doesn't react
or
crashes. I still haven't worked out how to clean up the DLL
correctly
before it is unloaded / detached (from Python). I guess it's
the GC
and/or some C stuff I've overlooked. I have tried both
approaches
described on this page: http://dlang.org/dll.html.
Maybe someone of yous once had a similar problem and found a
solution.
Any hints or suggestions would be appreciated. Thanks.
hmm. pyd uses the example under 'DLLs with a C Interface' for
its windows dll code and it seems pretty stable, but then it
doesn't use ctypes. It doesn't look like you need to be mucking
with rt_init and rt_term, so maybe the garbage collector is
trying to collect something that python still has a reference
to?
Also, if you can finagle a dll out of gdc I would love to hear
about it. I have not used it on windows, though.
Yes, I think so too, that it has something to do with GC. What
happens in the program is that Python passes a string to the DLL
but nothing is returned. The DLL somehow interferes with the main
thread. Other DLLs/threads are fine. I'll check again.
Thanks for the info about Pyd, unfortunately it is out of date
and doesn't work with newer versions of dmd, but I'll have a look
at the source code anyway.
"Finagle" is the right word. Phew. But first I could try and
write a C wrapper (with rt_init etc), I did that once and it
worked.
Re: enum inheritance
On Monday, 15 July 2013 at 13:01:05 UTC, JS wrote: ... I see. No, unfortunately, I am currently not aware of a way to make symbol act as type and and value at the same time. However it is worth noting that you use plenty of excessive attributes. Currently it is not a compiler error but makes code much harder to read and confusing. For example, "final" has no meaning for structs as they can't be inherited from anyway. Duplicating immutable is also excessive because it is transitive.
Re: Allocate N elements
Namespace:
void main()
{
int[] arr1 = new int[512];
writeln(arr1.length, "::", arr1.capacity);
int[] arr2 = new int[](512);
writeln(arr2.length, "::", arr2.capacity);
}
Output:
512::1019
512::1019
import std.stdio, std.array;
void main() {
auto a1 = new int[512];
writeln(a1.length, " ", a1.capacity);
auto a2 = new int[](512);
writeln(a2.length, " ", a2.capacity);
auto a3 = minimallyInitializedArray!(int[])(512);
writeln(a3.length, " ", a3.capacity);
}
Output:
512 1019
512 1019
512 0
But that (of new arrays) is a bad design, it wastes too much
memory, and I think it should be fixed. In Python this doesn't
overallocate:
a4 = [0] * 512
An alternative is to introduce a function like
std.array.InitializedArray.
Bye,
bearophile
Re: enum inheritance
On Monday, 15 July 2013 at 11:00:59 UTC, Dicebot wrote:
On Monday, 15 July 2013 at 04:24:59 UTC, JS wrote:
...
I think closest solution you can get is having bunch of private
enum definitions and combining them into single public one via
compile-time reflection. Something like
"mixin(generateEnum!(Red, Green, blue))".
That might solve the partitioning problem and solve part of the
hierarchical problem but won't allow submember access, e.g.,
colors.red.redorange. It seems like a good start though.
I imagine one could potentially build up a set of nested struct
with immutable members representing the enums:
final immutable struct Colors
{
final immutable struct Red
{
private immutable int _Red = 1;
immutable int RedOrange = 10001;
alias _Red this; // obviously doesn't work
}
final immutable struct Green
{
immutable int Green = 2;
}
}
but with the glitch on the alias(Colors.Red doesn't work)...
which sort of throws a kink in the solution making more than a
2-deep nest useless.
Re: Allocate N elements
On Monday, 15 July 2013 at 12:23:21 UTC, Adam D. Ruppe wrote:
On Monday, 15 July 2013 at 11:46:54 UTC, Namespace wrote:
int[] arr = new int[sizeOfItems];
Did you also try int[] arr = new int[](sizeOfItems)?
Example code:
void main()
{
int[] arr1 = new int[512];
writeln(arr1.length, "::", arr1.capacity);
int[] arr2 = new int[](512);
writeln(arr2.length, "::", arr2.capacity);
}
Output:
512::1019
512::1019
Re: Reverse Lexical Order
Jonathan M Davis wrote: gotos in such a context seem like a bit of a nightmare to me though. I did realize this nightmare. Therefore the assurance in the docs is probably true only in the absence within the scope of at least gotos to targets within the scope. -manfred
Re: Allocate N elements
On Monday, 15 July 2013 at 11:46:54 UTC, Namespace wrote: int[] arr = new int[sizeOfItems]; Did you also try int[] arr = new int[](sizeOfItems)?
Allocate N elements
Is there no way (besides the ugly malloc or any wrappers) to allocate _exactly_ N elements at runtime (no static array)? I tried int[] arr = new int[sizeOfItems]; but if sizeOfItems is e.g. 512, it allocates 1024. So is there no way to allocate a fixed memory block without the usage of C functions?
Re: Reverse Lexical Order
On Monday, July 15, 2013 13:02:54 Manfred Nowak wrote: > Jonathan M Davis wrote: > > Under what circumstances would they not be the same thing? > > http://dlang.org/statement.html#GotoStatement > At least the famous gots can make lexical ordering different to > executional ordering. Well, what that would do would depend on what happens with gotos and try- catch-finally blocks, because scope statements are lowered to try-catch-finally blocks. So, if you know what gotos do with them (and I personally have no idea how gotos affect stuff like destructors being run when you leave the scope, since you're not leaving it normally or properly), then you can figure it out by translating the scope statements to the set of try-catch-finally statements which would have the same semantics. gotos in such a context seem like a bit of a nightmare to me though. - Jonathan M Davis
Re: enum inheritance
On Monday, 15 July 2013 at 10:23:22 UTC, JS wrote:
On Monday, 15 July 2013 at 10:17:08 UTC, JS wrote:
On Monday, 15 July 2013 at 08:20:20 UTC, Namespace wrote:
Maybe this way?
final abstract class Colors
{
enum Red { RedOrange }
enum Green { GreenBlue}
enum Blue { BlueYellow }
}
void main() {
Colors.Red foo = Colors.Red.RedOrange;
assert(foo >= Colors.Red.min && foo <= Colors.Red.max);
}
but RedOrange and GreenBlue have the same value!
Also, Colors.Red is not a value!
Then: good luck.
Re: Reverse Lexical Order
Jonathan M Davis wrote: Under what circumstances would they not be the same thing? http://dlang.org/statement.html#GotoStatement At least the famous gots can make lexical ordering different to executional ordering. -manfred
Re: enum inheritance
On Monday, 15 July 2013 at 04:24:59 UTC, JS wrote: ... I think closest solution you can get is having bunch of private enum definitions and combining them into single public one via compile-time reflection. Something like "mixin(generateEnum!(Red, Green, blue))".
Re: Reverse Lexical Order
On Monday, July 15, 2013 12:20:57 Manfred Nowak wrote: > From the docs: > > "If there are multiple ScopeGuardStatements in a scope, they are > executed in the reverse lexical order in which they appear." > > Is lexical or executional order meant? Under what circumstances would they not be the same thing? - Jonathan M Davis
Re: enum inheritance
On Monday, 15 July 2013 at 10:17:08 UTC, JS wrote:
On Monday, 15 July 2013 at 08:20:20 UTC, Namespace wrote:
Maybe this way?
final abstract class Colors
{
enum Red { RedOrange }
enum Green { GreenBlue}
enum Blue { BlueYellow }
}
void main() {
Colors.Red foo = Colors.Red.RedOrange;
assert(foo >= Colors.Red.min && foo <= Colors.Red.max);
}
but RedOrange and GreenBlue have the same value!
Also, Colors.Red is not a value!
Re: Types of regex
Humm, A copy-paste of your code lead to : "[[segmentation fault" So it doesn't work for me. I use gdc if it might help !
Reverse Lexical Order
From the docs: "If there are multiple ScopeGuardStatements in a scope, they are executed in the reverse lexical order in which they appear." Is lexical or executional order meant? -manfred
Re: enum inheritance
On Monday, 15 July 2013 at 08:20:20 UTC, Namespace wrote:
Maybe this way?
final abstract class Colors
{
enum Red { RedOrange }
enum Green { GreenBlue}
enum Blue { BlueYellow }
}
void main() {
Colors.Red foo = Colors.Red.RedOrange;
assert(foo >= Colors.Red.min && foo <= Colors.Red.max);
}
but RedOrange and GreenBlue have the same value!
Re: Types of regex
On 2013-07-15, 11:32, Larry wrote:
Hello,
I read the library reference for regex.
I really miss python's equivalent of finditer.
Sometimes matching is not on purpose and one will want to match all the
occurences to iterate over it since it is much more regarding concerning
the orders and repetitions.
my code :
-
version(Tango) extern (C) int printf(char *, ...);
import std.stdio;
import std.regex;
import std.file;
import std.format;
int main(char[][] args)
{
string fl = readText("testregexd.txt");
auto m = match(fl, regex(`(
Have you tried iterating over m? This works for me:
import std.stdio;
import std.regex;
import std.file;
import std.format;
int main(char[][] args)
{
string fl = "
Types of regex
Hello,
I read the library reference for regex.
I really miss python's equivalent of finditer.
Sometimes matching is not on purpose and one will want to match
all the occurences to iterate over it since it is much more
regarding concerning the orders and repetitions.
my code :
-
version(Tango) extern (C) int printf(char *, ...);
import std.stdio;
import std.regex;
import std.file;
import std.format;
int main(char[][] args)
{
string fl = readText("testregexd.txt");
auto m = match(fl, regex(`(
Re: enum inheritance
Maybe this way?
final abstract class Colors
{
enum Red { RedOrange }
enum Green { GreenBlue}
enum Blue { BlueYellow }
}
void main() {
Colors.Red foo = Colors.Red.RedOrange;
assert(foo >= Colors.Red.min && foo <= Colors.Red.max);
}
Re: enum inheritance
On Monday, 15 July 2013 at 07:37:36 UTC, Mike Parker wrote:
On Monday, 15 July 2013 at 04:27:42 UTC, JS wrote:
BTW, the usefulness is to group sub-enums into the same range.
This would make it easy/efficient to branch over a range in
the enum:
if (v in colors.Red) { v is a color in red }
instead of
if (v is color.Red || v is color.RedOrange || ...)
if( v >= Red && v <= LastRed )
The problem is if a binary is already compiled and changes are
made. If a red color is inserted your range has changed. Also, it
requires you to keep your entries sorted properly. Also, a
"LastRed" entry is needed and there is no other reason to have it.
Since an int is 4B entries, and that's way more than most will
use, It think it's better to be able to have the compiler
partition of the range for you and save "space" for future
entries. This prevents an addition entry from screwing up
everything.
e.g.,
enum colors
{
enum Red : 1M { RedOrange, ... }
enum Green : 2M { ... }
...
}
In this case, one can have up to 1M unordered sub entries(should
be plenty) and ~4.2k main entries. One could order further,
enum colors
{
enum Red : 1M { enum RedOrange : 10k { }, ... }
enum Green : 2M { ... }
...
}
Basically the idea is to distribute the elements of enum and sub
enums in such a way as to maximize space between each entry. This
allows any binaries using an old version not to crash and burn.
This does require an estimation of the maximum entries that will
be used.
I'm particularly thinking of a messaging system where ints can be
passed around with 10's of thousands of defined messages with
messages grouped into common functionality(hence the inheritance
aspect) and adding new messages won't ruin the communications
between new and old systems.
Nested switch statements can easily and quickly pare down
determination of a message(not as fast as a flattened hierarchy
though).
Re: enum inheritance
On Monday, 15 July 2013 at 04:27:42 UTC, JS wrote:
BTW, the usefulness is to group sub-enums into the same range.
This would make it easy/efficient to branch over a range in the
enum:
if (v in colors.Red) { v is a color in red }
instead of
if (v is color.Red || v is color.RedOrange || ...)
if( v >= Red && v <= LastRed )
