Re: Reference to D class instance with a C library
On 2013-07-15 00:06, Leandro Motta Barros wrote: The documentation of GC.addRoot() (mentioned by Simen), contains this interesting piece of example code: // Also ensure that a moving collector does not relocate // the object. GC.setAttr(cast(void*)context, GC.BlkAttr.NO_MOVE); Looks like we *already* have the way to pin objects to their current memory location. (This compiles and is running without errors so far, though I didn't try to look if it is actually doing something under the hood -- which currently doesn't matter much, since the current GC doesn't move objects). (And yes, a GC.clrAttr() call does exist, too.) That's good to know about. But as you say, we're not there yet. -- /Jacob Carlborg
Re: Conditional Inheritance
Thanks. Now I realise that D is much less intuitive than C++.
Re: interacting with a process with redirected stdin/stdout/stderr
On Monday, 15 July 2013 at 03:49:10 UTC, Timothee Cour wrote:
I'm trying to interact with a process using std.process and
redirected stdin/stdout/stderr.
What would be the recommended way?
For example:
auto pipes=pipeShell(myprocess,Redirect.all);
while(true){
pipes.stdin.rawWrite(some_command);
foreach (line; pipes.stdout.byLine) {
//do something with line
}
}
This doesn't work because it might block inside
pipes.stdout.byLine, as the
process is requesting more inputs to be written to its stdin
before
outputting more bytes to its stdout.
What's the right approach?
* fcntl(fd, F_SETFL, O_NONBLOCK); didn't seem to work
* reading pipes.stdout inside a separate thread?
In that second case, how to cleanly dispose of a blocked thread
when we no
longer need it?
Any detailed example would help.
Thanks!
I tried using a separate thread for reading the process' stdout.
It works, except that sometimes the output is shuffled out of
order.
Is there anything buggy in this:
__gshared string output;
void readBlocking(){
while ((c = fgetc(filepointer)) = 0)
output~=cast(char) c;
//NOTE: i can use something more efficient here but that's beside
the question
}
thread = new Thread( readBlocking);
output=null;
while(true){
Thread.sleep(...);
if(condition) break;
}
//now output is shuffled out of order sometimes
Furthermore, is there a standard way to tell when a process is
waiting for stdin input ? (cf condition above). Currently I'm
checking whether 'output' was modified within a timeout period T,
but that's fragile and incurs of penalty of T at least.
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 )
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
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);
}
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(`(n=(?:hello|goodbye))*`,g));
auto c = m.captures;
writeln(c);
return 0;
}
---
Content of testregexd.txt:
n=hello n=goodbye
Any way to workaround ?
Thanks !
Larry
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(`(n=(?:hello|goodbye))*`,g));
auto c = m.captures;
writeln(c);
return 0;
}
---
Content of testregexd.txt:
n=hello n=goodbye
Any way to workaround ?
Thanks !
Larry
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 =
n=hello n=goodbye
;
auto m = match(fl, regex(`(n=(?:hello|goodbye))`,g));
foreach (c; m)
writeln(c);
return 0;
}
--
Simen
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
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 !
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: 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 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
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: 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)?
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 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: 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: 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: 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: 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?
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
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.
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
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: 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: 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: 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.
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: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.
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: 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: 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: 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: 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: 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: 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: 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: 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: 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
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: 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: 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: 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 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 -- Старый друг лучше новых двух.
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: 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.
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 Mon, Jul 15, 2013 at 4:02 PM, H. S. Teoh hst...@quickfur.ath.cx 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: 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: 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: 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: 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: 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
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: 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: 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...
