What is pure used for?
My understanding is that pure is used for compiler optimization in loops and expressions. It leaves out multiple calls if it figures out it is not needed. Is pure used for anything else? int * pureFunction() 1) the pointer needs to be the same. 2) the value that the pointer points to needs to be the same. I call this the "value of interest" with relation to pure. The pointer doesn't matter. 3) both the pointer and the value the pointer is pointing too needs to be the same. pureCalloc() satisfies (2) pureMalloc() violates everything. Does the D compiler do any optimizations?
Reference Counted Class
Would reference counted classes by default be too much of a change? Is it a bad idea? Currently there a changes in the language where you can avoid the reference count, right? Combination both the rc and the stop-the-world gc, for the cycles.
Re: dip1000 rule 5
On Monday, 26 November 2018 at 09:10:23 UTC, sclytrack wrote:
On Sunday, 25 November 2018 at 19:22:36 UTC, sclytrack wrote:
There are 4 rules listed.
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
What is rule 5?
int* global_ptr;
void abc() {
scope int* a;
int* b;
scope int* c = a; // Error, rule 5
scope int* d = b; // Ok
int* i = a;// Ok, scope is inferred for i
global_ptr = d;// Error, lifetime(d) <
lifetime(global_ptr)
global_ptr = i;// Error, lifetime(i) <
lifetime(global_ptr)
int* j;
global_ptr = j;// Ok, j is not scope
}
---
Are the following assumptions correct?
lifetime(a) < lifetime(b)
Means that b is older and lives longer than a. Or better, the
data that b is pointing
to is older and lives longer than the one that a is pointing
too. With the exception
of the null pointer which gets unlimited lifetime because it
does not corrupt memory.
---
scope int * a;
The variable gets unlimited lifetime because the value it is
pointing is assigned
null. And that throws exception when trying to access the
memory and because
it does not corrupt memory it is assigned unlimited lifetime.
Also once a variable
is assigned unlimited lifetime, then it retains that unlimited
lifetime during
the entire reachability of the variable.
scope int * c = a;
works
The above is allowed. You are assigning a variable that
according to the compiler
has unlimited lifetime. Therefore the variable c will be
handled like it has
unlimited lifetime by the compiler.
lifetime(c) <= lifetime(a)
The dip talks about longer and shorter, but is equal okay too?
int * c = a;
works (compiles without error and is inferred scope)
The above can not be inferred because scope is only inferred
when it is assigned
a limited lifetime. So it is an error.
Rule number 2 of the DIP1000 between quotes
"2. A variable is inferred to be scope if it is initialized with
a value that has a non-∞ lifetime."
I made an error here. Once scope always scope. And will infer
scope as much as
possible. Rule two is more for local variables that haven't even
been marked
with scope. A pointer to them needs to be inferred scope.
---
How is a person able to understand this DIP?
./dmd -betterC -dip1000 test.d
---
How many DIP manager are there?
I'll assume single person.
When is a DIP assigned a number?
---
Re: dip1000 rule 5
On Sunday, 25 November 2018 at 19:22:36 UTC, sclytrack wrote:
There are 4 rules listed.
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
What is rule 5?
int* global_ptr;
void abc() {
scope int* a;
int* b;
scope int* c = a; // Error, rule 5
scope int* d = b; // Ok
int* i = a;// Ok, scope is inferred for i
global_ptr = d;// Error, lifetime(d) <
lifetime(global_ptr)
global_ptr = i;// Error, lifetime(i) <
lifetime(global_ptr)
int* j;
global_ptr = j;// Ok, j is not scope
}
---
Are the following assumptions correct?
lifetime(a) < lifetime(b)
Means that b is older and lives longer than a. Or better, the
data that b is pointing
to is older and lives longer than the one that a is pointing too.
With the exception
of the null pointer which gets unlimited lifetime because it does
not corrupt memory.
---
scope int * a;
The variable gets unlimited lifetime because the value it is
pointing is assigned
null. And that throws exception when trying to access the memory
and because
it does not corrupt memory it is assigned unlimited lifetime.
Also once a variable
is assigned unlimited lifetime, then it retains that unlimited
lifetime during
the entire reachability of the variable.
scope int * c = a;
The above is allowed. You are assigning a variable that according
to the compiler
has unlimited lifetime. Therefore the variable c will be handled
like it has
unlimited lifetime by the compiler.
lifetime(c) <= lifetime(a)
The dip talks about longer and shorter, but is equal okay too?
int * c = a;
The above can not be inferred because scope is only inferred when
it is assigned
a limited lifetime. So it is an error.
---
How is a person able to understand this DIP?
---
How many DIP manager are there?
When is a DIP assigned a number?
---
Re: dip1000 rule 5
On Sunday, 25 November 2018 at 19:49:03 UTC, Stanislav Blinov wrote: On Sunday, 25 November 2018 at 19:22:36 UTC, sclytrack wrote: There are 4 rules listed. ... What is rule 5? ... Wouldn't you call it D3 because of the name mangling of DIP1000 once activated by default? That "rule 5" looks like a straight up mistake. As for D3... IMHO, no, not by a long shot. There's 1014 and 1016, 1008, there's `shared`, there are improved move-assignments, there's `__mutable` and `@__future`, there are tons of issues in Bugzilla, the standard library is long overdue for a huge look-over... Did DIP1000 go through any review process? I'm seeing it is a draft. https://github.com/dlang/DIPs/blob/master/PROCEDURE.md Keeps talking about a Drafts subdirectory. I don't see any directory named "Drafts". I only see accepted archived //old stuff rejected
dip1000 rule 5
There are 4 rules listed.
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
What is rule 5?
int* global_ptr;
void abc() {
scope int* a;
int* b;
scope int* c = a; // Error, rule 5
scope int* d = b; // Ok
int* i = a;// Ok, scope is inferred for i
global_ptr = d;// Error, lifetime(d) <
lifetime(global_ptr)
global_ptr = i;// Error, lifetime(i) <
lifetime(global_ptr)
int* j;
global_ptr = j;// Ok, j is not scope
}
Also it says scope inferred for i
int * i = a;
So inferred, does that mean?
scope int *i = a;
It looks very similar to the error rule 5.
scope int* c = a; // Error, rule 5
When DIP1000 is in and copy constructors, then the language is
more or less finished?
Wouldn't you call it D3 because of the name mangling of DIP1000
once activated
by default?
Re: Copy Constructor DIP
On Friday, 13 July 2018 at 11:02:57 UTC, RazvanN wrote: [...] Indeed, but this was the source of the problem also, because you could modify immutable fields that way. [...] Affirmative. The DIP needs to specify how assignment is handled if no opAssign is present but a copy ctor is present. Thanks! The difference between a copy constructor and opAssign is how the type checking is performed. This leads to situations where a copy constructor is not suitable as an assignment operator. However, if a copy ... What are your opinions on this? What about going the other way? Can you use the unqualified opAssign as the unqualified copy constructor? I assume these @implicit copy constructors are normal constructors.
multiqualifier
I'm going to post this in learn in order not to disturb "the
guys".
Multiqualifiers
---
Warning: Stop reading if you don't have time. Tail-const rant in
disguise.
(1) Going from immutable to mutable, one layer deep.
---
In the D programming language const(int ***) means the same as
const int ***
const int *** source; //head-const body-tail-const or just
const
const (int **)* destination;//head-mutable body-tail-const
destination = source; //works with ldc2 (1.2.0)
Assigning the source to the destination is possible and the head
which was
initially const becomes mutable. This is possible because a copy
is made
of that head pointer.
const int *** source; //const
const (int *)** destination;//head-body-mutable tail-const
//error
destination = source; //error
Assigning the source to the destination is not possible because
you would
have to alter the initial head. To clarify with invalid D code
(no-code).
//warning: Fake D code
const (int ***) source;
const (int *)dup(*)dupchange(*) destination;
const (int ) source;
const (int *)dup(*)dupchange(**) destination;
So we don't do this altering of the values and go only one layer
deep. The D
programming language is even able to figure this one layer deep
out with
regard to structs.
struct HeadMutableTailConst
{
const (int*) * pMutableHeadPointer; //head-mutable
body-tail-const
}
const(HeadMutableTailConst) source;
HeadMutableTailConst destination;
//const-head to mutable-head with destination body-tail-const
destination = source; //works with ldc2 (1.2.0)
The important part is that the head is either mutable or const
and the
rest must always be body-tail-const.
1.a) Naming
---
Starting to realize I need a different wording. The first pointer
on the right
is the head and the second pointer is the body.
const(int ***)*** tailConst; //tail-const
const(int **) headTailConst; //head-const body-tail-const
const(int *)* bodyTailConst; //head-mutable body-tail-const
Which means that body-tail-const can be either
const(int **) headTailConst; //head-const body-tail-const
const(int *)* bodyTailConst; //head-mutable body-tail-const
body-tail-const completally ignores the head.
(2) Going the other way.
mutable can be assigned to const, and so does immutable.
int *** source;
const(int **)* destination;
destination = source; //works
The destination needs to be body-tail-const not just tail-const.
int source;
const(int*)*** destination;
destination = source; //error
struct Container1
{
int * data;
}
struct Container2
{
const(int) * data;
}
Container1 source;
Container2 destination;
destination = source; //error
Both cases "mutable to const tail" and "const head to mutable
head" with
full BODY-TAIL-CONST (or recently head-mutability)
(3) Multiple tails
--
3.a
---
A user defined type can have multiple tails so it should have
multiple
qualifiers, one for each tail. I've numbered them here with $1
and $2 in fake
D code or no-code.
//warning: Fake D code
struct MultiTail
{
qual$1 (int) * a; //Mandatory BODY-TAIL-QUAL$1 or head-body-tail
qual$2 (int) * b; //Mandatory BODY-TAIL-QUAL$2
this()(const, immutable)
{
//qual$1 is const
//qual$2 is immutable
}
}
(const, immutable) MultiTail a; //impossible D code.
I'm going to be verbose so. The first "$1" becomes "const" and
the second
"$2" becomes immutable. Field "a" defined as const(int) * a; and
the second
field "b" is immutable(int) * b;
I will use (const) for the multiqualifier between those ().
(const) vs const
3.b
---
warning: fake D code
struct MultiTail
{
qual$1 (int) * a; //mandatory applied to body-tail or
head-body-tail
qual$1 (int) * b;
qual$1 (int) * c;
qual$2 (int) * z;
}
(const, immutable) MultiTail a; //impossible D code.
A qualifier in a multitail qualifier applying to more tails then
the number of
qualifiers in a multiqualifier.
3.c
---
Can you determine that a type is passable to a routine by just
looking at the
multiqualifier?
(immutable, immutable) MultiTail parameter;
void routine( (const, immutable) MultiTail a)
{
}
3.d classes
Since classes are reference types.
class MultiQualifiedType
{
qual$1(int) field; //mandatory on head-body-tail and not just
body-tail for classes
qual$2(int *) other;
}
(immutable, const) MultiQualifiedType a;
Similarly for structs
//--
struct HeadQualified
{
qual$1(int) field;
}
(const) HeadQualified * a; //a is body-tail-const
//--
struct HeadMutableBodyTailQualified
{
qual$1(int) * field;
}
(const) HeadMutableTailQualified * a; //a is not body-tail-const
error
/--
4.
Re: Implementing tail-const in D
On Monday, 29 January 2018 at 13:07:05 UTC, Simen Kjærås wrote:
On Thursday, 25 January 2018 at 21:33:10 UTC, Simen Kjærås
wrote:
On Thursday, 25 January 2018 at 19:54:55 UTC, H. S. Teoh wrote:
In fact, if the standard implementation of opHeadMutable is
basically the same across all types (or most types), it could
even be provided as a mixin template in the library, then all
you have to do is to `mixin headMutable` or something along
those lines, and off you go.
I believe this should be possible
I wrote up a more formal description of what I'm suggesting:
https://gist.github.com/Biotronic/c6eefeb9796309360a5e8696d91d924d
--
Simen
@headUnqualified
struct HeadUnqualifiedType1
{
HeadUnqualifiedType2 field;
}
tailQualifierHeadUnqualified(const) HeadUnqualifiedType1 a;
//Stupid opaque data types.
Re: An idea for commercial support for D
On Monday, 12 January 2015 at 06:30:20 UTC, Zach the Mystic wrote: Convenience, to me, is one-click downloading from the home page, one click installation, and full IDE support akin to what Apple, Microsoft and any other behemoth has done for their language. The language has nothing to do with it. D can't even remotely compete with these languages in terms of convenience. It needs a new slogan, and it can't get one until it knows what it is. Here's a suggestion: "A Language for Programmers". It would obviously need to be vetted by the big wigs, but from my perspective, it's already a real brand without any extra work. I wonder if they'll agree with me? pgModeler (for postgres) sells the binaries for a small price. The source code is GPL so it is available in linux distributions. https://www.pgmodeler.com.br/ Text from their website: "pgModeler is an open source software and you can get its source code anytime if you want to compile it for yourself. As a facility, we provide compiled binary packages at a really small price. Also, if you're interested in evaluate a binary package, you can get a demo copy before proceed with the purchase. Since this is an independent project by purchasing any binary package you'll help to keep its development alive and at full speed! " There you go, full speed.
Re: DIP1000: Scoped Pointers (Discussion)
On Thursday, 11 August 2016 at 21:28:57 UTC, sclytrack wrote: On Wednesday, 10 August 2016 at 20:36:38 UTC, Dicebot wrote: [...] There is confusion between what lifetime and visibility in the DIP. (Well, I am confused) [...] What are those puppy dogs doing there? I don't have a gravatar account.
Re: DIP1000: Scoped Pointers (Discussion)
On Wednesday, 10 August 2016 at 20:36:38 UTC, Dicebot wrote:
http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org
The first DIP has just landed into the new queue. It is a
proposal from language authors and thus it bypasses usual
nitpicking process and proceeds straight to requesting
community (your!) feedback.
Essentially, it is an attempt to solve reference lifetime
problem by extending implementation of `scope` keyword.
Proposal text:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
Few notes:
- Please submit pull requests to adjust the markdown document
if you want to propose any improvements (mentioning
@WalterBright and @andralex for confirmation).
- The proposal refers to a number of other documents and it is
recommended to become familiar at least briefly with all of
them.
- At this point the question I'd personally suggest to be
evaluated is "does this proposal enable enough useful
designs?". A good check would be to try taking some of your
projects and see if having DIP1000 approved and implemented
could improve them.
There is confusion between what lifetime and visibility in the
DIP.
(Well, I am confused)
1) infinite lifetime null
int * p;
The lifetime(p) is infinite while the visibility(p) starts here.
It seems to be the lifetime of p is determined by the value
assigned to it,
which in this case is null and the lifetime of lifetime(null) is
infinite.
2) Fundamentals of scope.
This declares 4 scope rules as of 11 August of which the first
rule is:
"A scope variable can only be initialized and assigned from
values that have lifetimes longer than the variable's lifetime"
int global_var;
int* global_ptr;
void bar(scope int* input);
void fun1() {
scope int* a = _var; // OK per rule 1,
lifetime(_var) > lifetime(a)
int b;
a = // Disallowed per rule 1, lifetime() < lifetime(a)
Shouldn't the rule be:
"A scope variable can only be initialized and assigned from
values that have lifetimes longer than the variable's VISIBILITY"
As in the case above. What is the lifetime(a) "scope int *a" when
the _var
has not yet been assigned to it? It doesn't have a lifetime yet,
it gets the lifetime from _var.
Peter
Re: Head Const
On Wednesday, 17 February 2016 at 12:46:08 UTC, Jonathan M Davis
wrote:
but violate the type system by casting away const and mutating,
not realizing that unlike C++, it's undefined behavior in D.
Regardless of whether Walter's (and thus D's) stance on const
is the right one, it clearly doesn't jive with what a lot of
folks (particularly those from C++) are looking for or
expecting.
- Jonathan M Davis
struct (bla1, bla2) Test
{
int rc;
bla1 int number;
(bla2) Payload payload;
void doSomething() (shared, immutable)
{
}
}
(shared, immutable) Test obj;
bla1 becomes shared and bla2 becomes immutable, but
the payload might not be immutable because it is
(bla2) instead of just bla2.
---
Can it be made in a way that the blablas do not
participate in the static if?
Could "shared", "immutable" be separated from
the type int, float?
(shared, immutable) Test!(int, float) obj;
---
I did some "const(immutable) int" and the the
compiler says basic type expected.
What is the basic type from "const(shared, immutable)",
would that be "const(shared const, const)"?
And then the basic type from "const(const, immutable)"
would be "const".
---
Also would it be possible to determine the implicit
conversion rules based solely on these qualifiers and
not on the content of the object?
(const, const) Test t = new (const, immutable) Test();
const Test t = new (const,const) Test();
---
Re: [dlang.org] Let's talk about the logo
On Friday, 22 January 2016 at 20:28:57 UTC, anonymous wrote: On 22.01.2016 20:53, ronaldmc wrote: I don't want to start a war, but this isn't community? I mean aren't we trying to make things better, because the way you said it seems like a dictatorship. It's dictatorship insofar as Walter and Andrei have veto power. If they don't want something in, it doesn't go in. I don't think this is a problem in practice. If it was, the community could always fork the project and then play by their own rules. And of all things, the logo wouldn't be a good reason to divide over, in my opinion. Just use all 4 logos. Change them at every new D release or something. I like a bit change. My desktop background also changes a bit.
Re: Website contains a virus?
On Thursday, 21 January 2016 at 18:46:15 UTC, Dominikus Dittes Scherkl wrote: Hi. I'm using Norton Security from Symantec, and it claims that the current compiler dmd-2.069.2.exe is infected with the "Trojan.Gen.2". Not a particularly harmful virus, but nevertheless I hope that's not true or you can fix that rather soon! Does this pose a problem for the linux variant?
Re: Safe reference counting cannot be implemented as a library
On Monday, 2 November 2015 at 09:56:14 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 1 November 2015 at 22:04:51 UTC, deadalnix wrote:
On Sunday, 1 November 2015 at 20:55:00 UTC, Martin Nowak wrote:
On 11/01/2015 09:51 PM, Martin Nowak wrote:
http://lists.puremagic.com/cgi-bin/mailman/listinfo/dlang-study
The last post on the study group ended a while ago. Does that
mean it is not going forward. It suggest to talk about lifetime.
Is that with or without talking about
reference counting simultaneously?
What approach will be taken?
1) Will for every assignment to the object a hidden temporary be
created by the compiler to keep the object alive.
RCObject obj = new RCObject();
Item item = obj.items[x];
_temp1 = obj; //The compiler inserts this automatically and
is not seen.
obj=new RCObject();
2) Will you disable the item by some magical way? Item might
still be valid.
RCObject obj = new RCObject();
...
Item item = obj.items[x];
obj=new RCObject();
//item is no longer accessible beyond this point.
writeln(item); //error
3) Somehow disable the RCObject for the duration of the borrowing.
with(Item item = RCObject.items[x])
{
writeln(item)
}
4) Solved by eating pizza or watching a movie ...
Maybe the discussion should be a tree.
Re: Safe reference counting cannot be implemented as a library
On Thursday, 29 October 2015 at 20:31:49 UTC, Zach the Mystic
wrote:
On Tuesday, 27 October 2015 at 18:10:18 UTC, deadalnix wrote:
I've made the claim that we should implement reference
counting as a library many time, so I think I should explicit
my position. Indeed, RC require some level a compiler support
to be safe. That being said, the support does not need to be
specific to RC. On fact, my position is that the language
should provide some basic mechanism on top of which safe RC
can be implemented, as a library.
The problem at hand here is escape analysis. The compiler must
be able to ensure that a reference doesn't escape the RC
mechanism in an uncontrolled manner. I'd like to add such
mechanism to the language rather than bake in reference
counting, as it can be used to solve other problem we are
facing today (@nogc exception for instance).
Here's a link to the reference safety system I proposed some
months ago:
http://forum.dlang.org/post/offurllmuxjewizxe...@forum.dlang.org
I'm very far from having the expertise needed to know whether
it would be worth its weight in practice, but it was better to
write it out than to keep it bottled up in my head. I hope it
will be of some use.
1) Assignment to RCObject
-
{
RCObject obj = new RCObject()
Item item1 = obj.items[x];
_temp1 = obj;
obj = new RCObject();
_temp2 = obj;
obj = new RCObject();
}
2) Entering a subscope
--
With this I mean entering a subscope that assigns to the RCObject.
{
RCObject obj2 = new RCObject()
RCObject obj = new RCObject()
_temp1 = obj; //(2) Entering a subscope
{
_temp2 = obj; //(1) Assignment to RCObject
obj = new RCObject();
}
}
3) Leaving a scope.
---
The Item is not reference counted.
{
Item item1;
{
RCObject obj = new RCObject();
//item1 = obj.items[x]; //(3) Leaving subscope
}
}
{
RCObject obj = new RCObject();
Item item1;
_temp1 = obj; //(2) Entering subscope
{
_temp2 = obj; //(1) Assignement to RCObject
obj = new RCObject();
//item1 = obj.items[x]; //(3) Leaving subscope
_temp3 = obj; //(1) Assignement to RCObject
obj = new RCObject();
}
}
4) RCObject joins a scope
-
{
_temp1 = obj.field.rcobject;//(4) RCObject joins current
scope.
Item item1 = obj.field.rcobject.a.items[0];
//_temp1; //(2) Entering subscope
{
_temp3 = obj.field.rcobject;//(1) Assignment to RCObject
obj.field.rcobject = new RCObject();
}
_temp4 = obj.field.rcobject;//(4) RCObject joins current
scope.
item1 = obj.field.rcobject.a.items[2];
}
Re: Object.factory() and exe file size bloat
On Friday, 21 August 2015 at 05:24:52 UTC, BBasile wrote:
On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
This function:
http://dlang.org/phobos/object.html#.Object.factory
enables a program to instantiate any class defined in the
program. To make it work, though, every class in the program
has to have a TypeInfo generated for it:
...
Other alternatives would be a pragma or an attribute to disable
TypeInfo generation.
@NoTI.
1. Since it is compiled in the {$M+} state, the compiler
generates RTTI (Run-Time Type Information) for it and all classes
that descend from it.
http://freepascal.org/docs-html/rtl/classes/tpersistent.html
2. Published properties are included in RTTI, public properties
aren't
http://stackoverflow.com/questions/3157648/whats-the-difference-between-public-and-published-class-members-in-delphi
Re: Why aren't you using D at work?
On Thursday, 16 July 2015 at 12:04:11 UTC, Sönke Ludwig wrote: Am 15.07.2015 um 18:06 schrieb Poyeyo: On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote: I've been using D in all my personal projects for years now, but I lament coding C at work every day, and I pine for salvation. I seem to have reasonable influence in my workplaces, and I suspect I could have my workplace adopt D, but when considering the notion with other staff, we always seem to encounter hard blockers to migration that stop us in our tracks. [...] Lack of a complete MySQL driver. No DECIMAL support that I know of. Lack of MySQL support in vibe.d. The mysql-native driver is fully vibe.d compatible. What is the postgresql variant for vibe.d? There are so many database api's for D.
Re: What wrong?
On Tuesday, 5 May 2015 at 07:41:04 UTC, sclytrack wrote:
On Monday, 4 May 2015 at 01:03:43 UTC, Fyodor Ustinov wrote:
On Saturday, 2 May 2015 at 20:46:32 UTC, Dennis Ritchie wrote:
On Saturday, 2 May 2015 at 19:38:01 UTC, Fyodor Ustinov wrote:
I see it by the lack of 42. :)
But why is this receive breaks down?
import std.stdio;
import std.variant;
struct SoMany
{
int number = 10;
~this()
{
writeln(number);
}
}
void main()
{
Variant v = SoMany();
}
DMD64 D Compiler v2.067.1
10
10
10
10
gdc (Debian 4.9.2-10) 4.9.2
10
10
For DMD I'm getting 4x10 and for gdc 2x10
Re: What wrong?
On Monday, 4 May 2015 at 01:03:43 UTC, Fyodor Ustinov wrote:
On Saturday, 2 May 2015 at 20:46:32 UTC, Dennis Ritchie wrote:
On Saturday, 2 May 2015 at 19:38:01 UTC, Fyodor Ustinov wrote:
I see it by the lack of 42. :)
But why is this receive breaks down?
import std.stdio;
import std.concurrency;
struct Answer
{
int number = 10;
~this()
{
writeln(number);
}
}
void threadRoutine()
{
receive(
(int value){ } //handle question
);
ownerTid.send( Answer() ); //answer
}
void main()
{
Tid childId = spawn(threadRoutine);
childId.send(100); //question
receive((Answer t) {}); //answer
}
//DMD64 D Compiler v2.067.1
/*
10
10
10
10
10
10
10
10
10
10
10
7080544
10
10
10
*/
Re: error with std.range.put - readN
On Monday, 4 May 2015 at 14:33:23 UTC, Baz wrote:
the following program fails because of the `put` function :
---
import std.stdio;
import std.range;
size_t readN(T, Range)(ref Range src, ref Range dst, size_t n)
if (isInputRange!Range isOutputRange!(Range, T))
{
size_t result;
while(1)
{
if (src.empty || result == n)
break;
put(dst, src.front()); // here
src.popFront;
++result;
}
return result;
}
void main(string[] args)
{
int[] src = [1,2,3];
int[] dst = [0];
auto n = readN!int(src, dst, 2);
writeln(dst);
}
---
If i replace `put` by a cat op (`~`) it works, however the cat
op only works here because i test the template with two int[].
What's wrong ?
I believe the put(R,E) calls the doPut(R, E)
private void doPut(R, E)(ref R r, auto ref E e)
{
//...
else static if (isInputRange!R)
{
static assert(is(typeof(r.front = e)),
Cannot nativaly put a ~ E.stringof ~ into a ~
R.stringof ~ .);
r.front = e;
r.popFront();
}
//...
}
So basically you put elements into the list until it is empty.
import std.stdio;
import std.range;
void main()
{
int [] list = new int [10];
writeln(list);//10 zeros
list.front = 5; //1 five and 9 zeroes
writeln(list);
list.popFront(); //9 zeroes left.
writeln(list);
}
Re: Interrogative: What's a good blog title?
On Tuesday, 28 April 2015 at 15:33:52 UTC, ixid wrote: Please let me know of any thoughts you might have! Thanks, Andrei Andrei to the Drescu D to the rescue The road to programming heaven. W A with a backpack, some desert landscape.
o!(const(T)) parameter.
I want a function with parameter o!(const(Form)) to accept both
o!(Form) and o!(immutable(Form))
Is there a way to do it?
import std.stdio;
import std.traits;
class Form
{
int number = 10;
}
struct o(T)
{
T data;
this(T data)
{
this.data = data;
}
o!(const(Unqual!(T))) constify() const
{
return o!(const(Unqual!(T)))(data);
}
alias constify this;
}
void hello(o!(const(Form)) frm)
{
writeln(frm.data.number);
writeln(typeof(frm.data).stringof);
}
void main()
{
writeln(This application works nicely);
auto frm = o!(Form) (new Form());
// auto ifrm = o!(immutable(Form)) (new immutable Form());
hello(frm);
// hello(ifrm);
}
Re: o!(const(T)) parameter.
It works when you exclude the recursive alias this: static if(!is(T == const)) alias constify this; Your original program crashes the compiler, which is always a bug. I filed an issue: https://issues.dlang.org/show_bug.cgi?id=14499 Thank you, very much.
Re: using exceptions in @nogc
On Tuesday, 31 March 2015 at 01:40:54 UTC, weaselcat wrote: was this ever solved? I did some research and saw static immutable ones suggested a few times, but they can't be chained AFAIK. Reference counted exceptions. Not solved.
Re: DTanks Alpha
On Saturday, 21 March 2015 at 02:39:23 UTC, Rikki Cattermole wrote: On 21/03/2015 10:55 a.m., Kingsley wrote: In preparation for the London D meetup I have got the DTanks robot battle framework into the first alpha release state - good enough to use at the meetup anyway. https://github.com/masterthought/dtanks --K Are you aware of what turtles are? Because this looks pretty close api wise, to be used for it. Logo?
Re: is eC alot like D?
On Wednesday, 11 March 2015 at 04:10:51 UTC, Taylor Hillegeist wrote: On Wednesday, 11 March 2015 at 03:55:21 UTC, Rikki Cattermole wrote: On 11/03/2015 4:16 p.m., Taylor Hillegeist wrote: So I found http://ec-lang.org/ it seems alot like D, But it has a company backing it. It just seems interesting. There is almost no meta programming support. Let alone CTFE. And no generics in the form of e.g. Java's is not the same as D's meta-programming support. Yes, D is a very powerful language with a boatload of features. eC almost seems like a subset. but what I find fascinating is the infrastructure built around it. Of course when someone's full time job is to build infrastructure, I tends to happen more predictably. But like all things in life you have to take the good, and carry it with you into the future. I bet there is alot we can learn from eC. I wonder how compatible the two languages are, I have been experimenting with language to language porting techniques, every language is in similar in some way to another, but to varying degrees. A quote from Jerome on the eC forum. eC is yet another multiparadigm procedural/object-oriented language which has C for its foundation. This puts it alongside Java, C++, C#, D, Objective C and probably countless others less famous programming languages. What this means: - You can include C library headers directly in your .ec code, without any special keyword (like extern C in C++) - There is no special mangling going on for normal functions (C binary compatibility), which means you can interface in both directions with any language supporting C bindings. - Simply put, eC does not take anything away from C, it only adds useful features to it
Re: RCArray is unsafe
On Wednesday, 4 March 2015 at 08:56:20 UTC, Ivan Timokhin wrote:
Excuse me if I miss something obvious, but:
void main()
{
auto arr = RCArray!int([0]);
foo(arr, arr[0]);
}
void foo(ref RCArray!int arr, ref int val)
{
{
auto copy = arr; //arr's (and copy's) reference
counts are both 2
arr = RCArray!int([]); // There is another owner,
so arr
// forgets about the old
payload
} // Last owner of the array ('copy') gets destroyed
and happily
// frees the payload.
val = 3; // Oops.
}
struct PileInfo Red TOP of PILE
{
int refCount;
RCDataBlock * top;
RCDataBlock * bottom;
}
struct RCDataBlock Blue
{
PileInfo * pileInfo;
RCDataBlock * next;
Array * payload;//Actual Data.
}
struct RCArray
{
RCDataBlock * block;
}
RCArray a,b,c,d;//all different piles
a = b;
b = c;
d = a; //makes them one single pile.
What if you pile them up. Blue cubes which contain the data.
And a Red cube containing the reference count equal to
the sum of all references to the blue cube of the same pile.
Basically a pile of blue cubes with a red cube on top.
1) RCArray a,b,c,d; //
[1]
x -a
[1]
x -b
[1]
x -c
[1]
x -d
2) a = b; //
[2]
x -[old b1]
x -a,b
[1]
x -c
[1]
x -d
3) b = c; //
[3]
x -b,c
x -[old b1]
x -a,[old b2]
[1]
x -d
4) d=a; //
[4]
x -b,c
x -[old b1]
x -[old a1],[old b2]
x -d,a
Re: DList.Range magically becomes empty.
On Wednesday, 25 February 2015 at 09:07:17 UTC, Tobias Pankrath
wrote:
import std.container;
import std.stdio;
void main()
{
DList!int list;
Array!(DList!int.Range) stack;
foreach(i; 0 .. 4)
{
list.stableInsertBack(i);
stack.insertBack(list[]);
}
writefln(list: %s, list[]); // fine
writefln(stack: %s, stack[]); //fine
foreach(s; stack[])
writefln(s: %s, s); // all s are empty?
writefln(stack: %s, stack[]); //not fine
}
It prints:
list: [0, 1, 2, 3]
stack: [[0], [0, 1], [0, 1, 2], [0, 1, 2, 3]]
s: []
s: []
s: []
s: []
stack: [[], [], [], []]
Ranges aren't containers. It's more like a view of a container
that gets smaller (or empty) the more you use it. There might not
be a container behind a range.
Re: tail const ?
On Thursday, 30 October 2014 at 10:28:42 UTC, Simon A wrote:
I don't know about syntax, but D sure needs first-class support
of tail immutability.
struct A
{
}
Re: tail const ?
On Thursday, 30 October 2014 at 10:28:42 UTC, Simon A wrote:
I don't know about syntax, but D sure needs first-class support
of tail immutability.
struct A
{
float * a;
void foo() tailconst
{
writeln(typeof(a).stringof); //outputs const(float) *
}
}
class B
{
float * a;
void foo() tailconst
{
writeln(typeof(this).stringof); //outputs tailconst(B)
writeln(typeof(a).stringof); //outputs const float *
}
}
tailconst for struct and classes.
How about this?
*sorry about the previous almost empty post.
tail const ?
As Stewart Gordon mentioned before (2012) What about adding tailConst to the D programming language? tailConst MyStruct a; All fields of the MyStruct would be tailConst and ... tailConst MyClass b; would make the the pointer mutable but all the fields of b const. ...tailImmutable, ...
monodevelop mono-d versions
I can't seem to install mono-d. It always seems to want a newer version of MonoDevelop. I'm on Ubuntu 14.04 LTS and it has version 4.0.12 of MonoDevelop. Has anybody else got this to work with this version? I have this file called MonoDevelop.D-1.9.6.mpack Tools-Add In Manager-Install From File Select the MonoDevelop.D-1.9.6.mpack file. Press Open Dialog Window: The Following Packages will be Installed. D Language Binding v2.1.14 (In User Directory)
Re: If you had money to place for a bounty, what would you choose?
On Thursday, 5 December 2013 at 05:09:03 UTC, Marco Leise wrote: Am Sun, 01 Dec 2013 09:09:32 +0100 schrieb sclytrack sclytr...@fake.com: Re: If you had money to place for a bounty, what would you choose? Official debian packages for gdc, derelict, gtkd, vibed. What compiler and D version should those libraries be compiled with? The reason I ask this is that current D compilers produce incompatible ecosystems. You would need a gtkd-dmd, gtkd-gdc and gtkd-ldc package (or one big package with all three) and give what is supposedly one library three different file names to link against. gdc version. ldc seems to be stuck in unstable.
Re: Real time captioning of D presentations
On Sunday, 1 June 2014 at 20:52:16 UTC, bearophile wrote: Walter Bright: what do you guys think? The caption I'd like to see is the name of the speaker during the live transmissions. Bye, bearophile Steno? You can type in realtime? Then why the hell did I spend time learning to type using a normal keyboard with two different character sets. Plover: http://www.youtube.com/watch?v=K3MYFT6VZk8 I am wondering. Should we all start learning plover? http://www.youtube.com/watch?v=Fu7DygveoB4 Somebody can start practising for the next D Conf :-)
Re: Per popular demand, here are Adam D Ruppe's presentation slides
On Saturday, 24 May 2014 at 20:53:18 UTC, Adam D. Ruppe wrote:
On Saturday, 24 May 2014 at 20:46:30 UTC, sclytrack wrote:
Were there actual slides?
Nope, I never actually got around to creating any.
Okay, busy guy.
I just had an outline on my desktop of stuff I was thinking
about creating, but just didn't finish it. The paper was my
recreation of that outline from memory.
Here's the outline.txt stuff I didn't mention on the paper btw:
* Replacing functions with the linker
* Reflection: Using RTInfo's lint to enforce ownership rules
(e.g. make it a compile time error to define a struct with a
mutable slice. This has a few pros and a lot of cons.)
* Doing a custom calling convention with naked functions and
mixins
* Talk about ABI details and the implementation of scope
statements (e.g. scope(exit). I briefly talked about it being
lowered to finally {} but didn't go into the asm like I was
considering
* The -betterC switch and what I want more from it.
Otherwise, my memory was pretty decent for remembering what I
had in mind! Then my random on-the-spot digressions padded out
the time.
I would have preferred slides though. I'm not so good at
listening. The visual impact helps ME better at remembering.
Yeah, your memory is fine.
:-)
Re: Livestreaming DConf?
On Wednesday, 21 May 2014 at 03:03:11 UTC, Manu via Digitalmars-d-announce wrote: My timezone will keep me awake from 2am - 9am to watch the live streams... which I probably will do ;) Yeah, you were there. Don't do this a second night. On 21 May 2014 07:01, Nick via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Friday, 9 May 2014 at 19:48:20 UTC, Andrei Alexandrescu wrote: Hi folks, We at Facebook are very excited about the upcoming DConf 2014. In fact, so excited we're considering livestreaming the event for the benefit of the many of us who can't make it to Menlo Park, CA. Livestreaming entails additional costs so we're trying to assess the size of the online audience. Please follow up here and on twitter: https://twitter.com/D_Programming/status/464854296001933312 Thanks, Andrei I'll probably watch most of it if it's streamed. Lost sleep leads to loss of brain cells http://www.bbc.com/news/health-26630647 You need those brain cells.
Re: More radical ideas about gc and reference counting
On Sunday, 11 May 2014 at 11:42:37 UTC, ponce wrote:
On Sunday, 11 May 2014 at 08:59:42 UTC, Walter Bright wrote:
D also cannot be performance competitive with C++ if pervasive
ARC is used and memory safety is retained. Rust is attempting
to solve this problem by using 'borrowed' pointers, but this
is unproven technology, see my reply to Manu about it.
I work in a C++ shop and as I see it, resource management is
becoming a solved problem:
- resource owners holds a std::unique_ptrT on them. Resource
release is taken care by C++ destructors normally. That means
to be exception-safe, each resource type must better have its
class.
- resource users eventually borrow the resource by taking a
raw pointer out of the unique pointer. What Rust would do with
lifetimes here is ensure that the resource is still there since
move semantics seems pervasive in this language. In C++ we
ensure the resource holder outlive the users.
- std::shared_ptr is not needed with such constraints. This
means no cycles in the object graph. TBH I have yet to find a
dependency scheme that can't be done that way.
When I use D I can't help but think that releasing resources
feels more manual and error-prone (oops that resource should
have been a struct not a class and such traps).
I do not have huge concerns about D GC, but I would be glad to
have more support for owned pointers (ie. Unique!T in Phobos or
better). I have no idea how to make it safe ie. ensure the
resource outlive its users.
I like this owner/unique, borrow thing.
@ is managed (currently reference counted)
~ is owner
is borrow
fn example3() - int {
let mut x = ~X {f: 3};
let y = x.f;
x = ~X {f: 4}; // Error reported here.
*y
}
According to Debian Rust is still too experimental to be packaged.
http://web.mit.edu/rust-lang_v0.8/doc/tutorial-borrowed-ptr.html
servo is written in Rust.
https://github.com/mozilla/servo
There is very little use of @, it's mostly and ~. Heck I
didn't find any @ while casually browsing the code. It's like
they are not using it at all.
I don't know Rust, it is the first day I look (read
documentation) at it.
Re: From slices to perfect imitators: opByValue
void main()
{
DemoStruct m;
test(m);
acceptor(immutable) i;
I mean:
acceptor(immutable) DemoStruct i
test(i);
}
Re: From slices to perfect imitators: opByValue
On Thursday, 8 May 2014 at 11:05:20 UTC, monarch_dodra wrote:
On Thursday, 8 May 2014 at 07:09:24 UTC, Sönke Ludwig wrote:
Just a general note: This is not only interesting for
range/slice types, but for any user defined reference type
(e.g. RefCounted!T or Isolated!T).
Not necessarily: As soon as indirections come into play, you
are basically screwed, since const is turtles all the way
down.
So for example, the conversion from const RefCounted!T to
RefCounted!(const T) is simply not possible, because it
strips the const-ness of the ref count.
What we would *really* need here is NOT:
const RefCounted!T = RefCounted!(const T)
But rather
RefCounted!T = RefCounted!(const T)
The idea is to cut out the head const directly. This also
applies to most ranges too BTW.
Skip paragraph.
Okay daedalnix. Second attempt. Started with
Container!(const(T)). Thought about
separating the the const. Container!(T, const) and then only one
const. None of
that Container!(A,B, immutable, const). Then thought about int
qual(*) * a.
With qual as entry point. Then decided to go tail const only,
single head mutable. But then seeing that there are two cases
above, decided to
go acceptor, copy.
---
a) I'm going to call this the copying case where the value types
are copied
const RefCounted!T = RefCounted!(const T)
immutable int [] a = immutable (int) [] a;
immutable to mutable
b) Acceptor case.
RefCounted!T = RefCounted!(const T)
e.g a const field accepts the mutable or immutable field.
---
struct DemoStruct
{
int * * a;
acceptor int * * b;
void demonstrate() acceptor
{
assert(typeof(a).stringof == int * *);
assert(typeof(b).stringof == acceptor(int *) *);
}
}
void test(acceptor(const) DemoStruct v)
{
assert(typeof(v.a).stringof == int * *);
assert(typeof(v.b).stringof == const(int *) *);
}
void main()
{
DemoStruct m;
test(m);
acceptor(immutable) i;
test(i);
}
Like having acceptor behave like inout or something. The acceptor
field can
receive the following.
int * * a;
immutable (int *) * b;
const(int *) * acceptorfield = a;
acceptorfield = b;
const(int) * * oops = b; // not valid acceptor.
const(int * *) meh = b; // will choose the first pointer mutable
since
// is a copy so meh.
The acceptor field is tail const or something with the first
entry being mutable.
---
struct DemoStruct
{
int * * a;
acceptor int * * b;
void demonstrate() copy
{
assert(typeof(a).stringof == copy(int *) *);
assert(typeof(b).stringof == copy(int *) *);
}
}
void test(copy(const) DemoStruct v)
{
assert(typeof(v.a).stringof == const(int *) *);
assert(typeof(v.b).stringof == const(int *) *);
}
void main()
{
immutable DemoStruct i;
test(i);
}
For the copying version, immutable == mutable the acceptor is
applied to all
fields.
Please forgive me for pressing the send button.
Sclytrack
Re: More radical ideas about gc and reference counting
On Wednesday, 30 April 2014 at 21:17:23 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Wed, Apr 30, 2014 at 02:13:32PM -0700, Andrei Alexandrescu
via Digitalmars-d wrote:
On 4/30/14, 2:09 PM, Timon Gehr wrote:
On 04/30/2014 10:58 PM, Andrei Alexandrescu wrote:
On 4/30/14, 1:56 PM, Timon Gehr wrote:
struct S{
~this(){ /* ... */ }
/* ... */
}
class C{
S s;
}
?
By hand, as I mentioned. -- Andrei
I meant, is it going to be deprecated too?
No, that will continue to be allowed. -- Andrei
Then what is it going to do? S.~this will never get called?
It gets called when the gc runs.
T
Re: std.file.read returns void[] why?
On Thursday, 17 April 2014 at 14:05:50 UTC, Regan Heath wrote: On Thu, 17 Apr 2014 13:59:20 +0100, Steven Schveighoffer schvei...@yahoo.com wrote: It was never possible. You must explicitly cast to void[]. to - from? void[] makes actually little sense as the result of whole-file read that allocates. byte[] is at least usable and more accurate. In fact, it's a little dangerous to use void[], since you could assign pointer-containing values to the void[] and it should be marked as NOSCAN (no pointers inside file data). I see what you're saying, byte[] is what *is* allocated.. but my point is that it's not what those bytes actually represent. Are you saying void[] *is* currently marked NOSCAN? However, when using the more conventional read(void[]) makes a LOT of sense, since any T[] implicitly casts to void[]. Indeed. :) R auto a1 = new ubyte[10]; //NO_SCAN set auto a2 = new ubyte*[10]; // NO_SCAN not set auto a3 = new void[10]; //NO_SCAN not set auto a4 = new void *[10]; //NO_SCAN not set void [] retains = a1;//NO_SCAN REMAINS SET from the ubyte [] at creation time. Since read comes straight from the file. It contains no memory pointers and the NO_SCAN can be set.
Re: std.file.read returns void[] why?
Are you saying void[] *is* currently marked NOSCAN? import std.stdio; import core.memory; writeln(int* [], GC.query(cast(void *) arr2).attr);
Re: DIP60: @nogc attribute
On Wednesday, 16 April 2014 at 10:13:06 UTC, bearophile wrote:
JN:
I doubt @nogc will change anything, people will just start
complaining about limitations of @nogc
Having a way to say this piece of program doesn't cause heap
activity is quite useful for certain piece of code. It makes a
difference in both performance and safety.
But not being able to call core.stdc.stdlib.alloca in a @nogc
pure function sub-three is not good.
Bye,
bearophile
What about adding custom annotations that don't do any checking by
itself. Like when @nogc doesn't actually verify that the
~ is not used for strings.
void hello() require(@nogc)
{
}
Just a verification by the compiler that you use only routines
that are marked with certain annotations.
void boe()
{
}
@(nasaverified)
void test()
{
}
//
void hello() require(@(nasaverified))
{
test(); // ok
boe(); // not ok.
}
Re: std.stream replacement
On Saturday, 14 December 2013 at 15:16:50 UTC, Jacob Carlborg
wrote:
On 2013-12-14 15:53, Steven Schveighoffer wrote:
I realize this is really old, and I sort of dropped off the D
cliff
because all of a sudden I had 0 extra time.
But I am going to get back into working on this (if it's still
an issue,
I still need to peruse the NG completely to see what has
happened in the
last few months).
Yeah, it still need to be replaced. In this case you can have a
look at the review queue to see what's being worked on:
http://wiki.dlang.org/Review_Queue
SINK, TAP
-
https://github.com/schveiguy/phobos/blob/new-io/std/io.d
What about adding a single property named sink or tap depending
on how you want the chain to be. That could be either a struct or
a class. Each sink would provide another interface.
struct/class ArchiveWriter(SINK)
{
@property sink //pointer to sink
}
writer.sink.sink.sink
arch.sink.sink.sink.open(filename);
ArchiveReader!(InputStream) * reader;
Warning: As usual I don't know what I'm talking about.
