Re: My Reference Safety System (DIP???)
On Sunday, 1 March 2015 at 14:40:54 UTC, Marc Schütz wrote:
I don't think a callee-based solution can work:
class T {
void doSomething() scope;
}
struct S {
RC!T t;
}
void main() {
auto s = S(RC!T()); // `s.t`'s refcount is 1
T t = s.t; // borrowing from the RC wrapper
foo(s);
t.doSomething();// oops, `t` is gone
}
void foo(ref S s) {
s.t = RC!T(); // drops the old `s.t`
}
I thought of this, and I disagree. The very fact of assigning to
`T t` adds the reference count you need to keep `s.t` from
disintegrating. As soon as you borrow, you increment the count.
Re: My Reference Safety System (DIP???)
On Monday, 2 March 2015 at 00:06:52 UTC, deadalnix wrote:
On Sunday, 1 March 2015 at 23:56:02 UTC, Zach the Mystic wrote:
On Sunday, 1 March 2015 at 14:40:54 UTC, Marc Schütz wrote:
I don't think a callee-based solution can work:
class T {
void doSomething() scope;
}
struct S {
RC!T t;
}
void main() {
auto s = S(RC!T()); // `s.t`'s refcount is 1
T t = s.t; // borrowing from the RC wrapper
foo(s);
t.doSomething();// oops, `t` is gone
}
void foo(ref S s) {
s.t = RC!T(); // drops the old `s.t`
}
I thought of this, and I disagree. The very fact of assigning
to `T t` adds the reference count you need to keep `s.t` from
disintegrating. As soon as you borrow, you increment the count.
I'm sure many inc/dec can still be removed.
Do you agree or disagree with what I said? I can't tell.
Re: My Reference Safety System (DIP???)
On Sunday, 1 March 2015 at 23:56:02 UTC, Zach the Mystic wrote:
On Sunday, 1 March 2015 at 14:40:54 UTC, Marc Schütz wrote:
I don't think a callee-based solution can work:
class T {
void doSomething() scope;
}
struct S {
RC!T t;
}
void main() {
auto s = S(RC!T()); // `s.t`'s refcount is 1
T t = s.t; // borrowing from the RC wrapper
foo(s);
t.doSomething();// oops, `t` is gone
}
void foo(ref S s) {
s.t = RC!T(); // drops the old `s.t`
}
I thought of this, and I disagree. The very fact of assigning
to `T t` adds the reference count you need to keep `s.t` from
disintegrating. As soon as you borrow, you increment the count.
I'm sure many inc/dec can still be removed.
Re: Contradictory justification for status quo
On Saturday, 28 February 2015 at 23:03:23 UTC, Walter Bright wrote: On 2/28/2015 2:31 AM, bearophile wrote: Zach the Mystic: You can see exactly how D works by looking at how Kenji spends his time. For a while he's only been fixing ICEs and other little bugs which he knows for certain will be accepted. I agree that probably there are often better ways to use Kenji time for the development of D. Actually, Kenji fearlessly deals with some of the hardest bugs in the compiler that require a deep understanding of how the compiler works and how it is supposed to work. He rarely does trivia. I regard Kenji's contributions as invaluable to the community. I don't think anybody disagrees with this. Kenji's a miracle.
Re: Contradictory justification for status quo
On Mon, 02 Mar 2015 00:48:54 +, Zach the Mystic wrote: I don't think anybody disagrees with this. Kenji's a miracle. he's like Chuck Norris, only better. ;-) signature.asc Description: PGP signature
Re: Would Lcl be better if it was in D?
On Sunday, 1 March 2015 at 20:41:30 UTC, Taylor Hillegeist wrote:
So I was using the Lazarus IDE the other day, and i thought to
myself, what if i create an application with only a button in
it. well it was easy enough to do. but behold I saw the
executable and it was 14 MB, and I said 'well damn.' It seems
to me that pascal does not do lazy inclusion when it comes to
components of Lcl apart from pre-compiler directives.
I noticed some includes in d are inside of functions.
void foo() {
import thingIneed:subfoo;
subfoo();
}
would this allow people to use a large library like LCL but
with much smaller executables?
Turn off the debug build - it's then only a few meg...
-Mike-
Re: Would Lcl be better if it was in D?
On Sunday, 1 March 2015 at 21:39:08 UTC, Mike James wrote:
On Sunday, 1 March 2015 at 20:41:30 UTC, Taylor Hillegeist
wrote:
So I was using the Lazarus IDE the other day, and i thought to
myself, what if i create an application with only a button in
it. well it was easy enough to do. but behold I saw the
executable and it was 14 MB, and I said 'well damn.' It seems
to me that pascal does not do lazy inclusion when it comes to
components of Lcl apart from pre-compiler directives.
I noticed some includes in d are inside of functions.
void foo() {
import thingIneed:subfoo;
subfoo();
}
would this allow people to use a large library like LCL but
with much smaller executables?
Turn off the debug build - it's then only a few meg...
-Mike-
Yes, the debug does help quite a lot. I like the idea of LCL one
widget front end so you don't have to worry as much about
deployment. but i haven't found a good all static cross platform
solution for d.
so far my favorite GUI libraries so far are:
xwt: mono
LCL: Object Pascal
I like the write once compile anywhere of Lazarus. And I think it
makes more sense to target the platforms native widget library
than to force users to install one or package the whole library
with your executable.
But still the question was about smaller executable when
compiling d code. The linker needs to know which .o files to
include, the pascal notation is basically:
uses
thisBigoleThing, ThisOtherBigOleThing, AndMeToo;
I assume the linker just auto-magically includes the entire thing
even if your only using a single function or value from each.
Then again perhaps I am wrong.
The site engine written in D
Prompt, please, where can I find the software engine written in D?
Re: The site engine written in D
On 03/01/2015 03:03 PM, Dennis Ritchie wrote: Prompt, please, where can I find the software engine written in D? Do you mean vibe.d? http://vibed.org/ Ali
Re: My Reference Safety System (DIP???)
On Monday, 2 March 2015 at 00:37:05 UTC, Zach the Mystic wrote: On Monday, 2 March 2015 at 00:06:52 UTC, deadalnix wrote: I thought of this, and I disagree. The very fact of assigning to `T t` adds the reference count you need to keep `s.t` from disintegrating. As soon as you borrow, you increment the count. I'm sure many inc/dec can still be removed. Do you agree or disagree with what I said? I can't tell. I think I understand now. Yes, they can probably be optimized, but that's a different issue than whether you need to protect certain RC instances from the tyranny of a function call. My whole argument is that basically you don't. Only when you split pass directly in the call itself: fun(x,x), does this issue ever matter, and it's easy to deal with.
Re: The site engine written in D
On Monday, 2 March 2015 at 00:06:26 UTC, Ali Çehreli wrote: Do you mean vibe.d? http://vibed.org/ I was referring to the software engine written using the vibe.d. http://vibed.org/ written using the vibe.d?
Re: Contradictory justification for status quo
On Sunday, 1 March 2015 at 11:30:52 UTC, bearophile wrote: Walter Bright: Actually, Kenji fearlessly deals with some of the hardest bugs in the compiler that require a deep understanding of how the compiler works and how it is supposed to work. He rarely does trivia. I regard Kenji's contributions as invaluable to the community. But my point was that probably there are even better things that Kenji can do in part of the time he works on D. I think this once again brings up the issue of what might be called The Experimental Space (for which std.experimental is the only official acknowledgment thus far). Simply put, there are things which it would be nice to try out, which can be conditionally pre-approved depending on how they work in real life. There are a lot of things which would be great to have, if only some field testing could verify that they aren't laden with show-stopping flaws. But these represent a whole middle ground between pre-approved, and rejected. The middle ground is fraught with tradeoffs -- most prominently that if the field testers find the code useful it becomes the de facto standard *even if* fatal flaws are discovered in the design. Yet if you tell people honestly, this may not be the final design, a lot fewer people will be willing to test it. The Experimental Space must have a whole different philosophy about what it is -- the promises you make, or more accurately don't make, and the courage you have to reject a bad design even when it is already being used in real-world code. Basically, the experimental space must claim tentatively approved for D, pending field testing -- and it must courageously stick to that claim. That might give Kenji the motivation to implement some interesting new approaches to old problems, knowing that even if in the final analysis they fail, they will at least get a chance to prove themselves first. (Maybe there aren't really that many candidates for this approach anyway, but I thought the idea should be articulated at least.)
Re: Would Lcl be better if it was in D?
On Sun, 01 Mar 2015 22:40:28 +, Taylor Hillegeist wrote:
But still the question was about smaller executable when compiling d
code. The linker needs to know which .o files to include, the pascal
notation is basically:
uses
thisBigoleThing, ThisOtherBigOleThing, AndMeToo;
I assume the linker just auto-magically includes the entire thing even
if your only using a single function or value from each. Then again
perhaps I am wrong.
FreePascal learnt the smart linking trick years ago, so only actually
used functions ends in linked binary. but LCL is very big library, and FPC
can't drop out unused virtual methods, so resulting binaries are big.
with D we have the same situation, maybe even worse due to template
instantiation. compiler is able to merge identical template instanses,
but... empty `void main () {}` is ~200 KB in D (GNU/Linux, x86). adding
simple `import std.stdio : writeln;` increases binary size to ~300 KB.
and adding `writeln(hello!);` increases binary size to ~350 KB.
D binaries are big. ;-)
signature.asc
Description: PGP signature
[Issue 14220] Bad codegen for optimized std.conv.text in combination with concatenation
https://issues.dlang.org/show_bug.cgi?id=14220 --- Comment #7 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/9295312a23e85dcd1b026cf3b25feb0330379185 fix Issue 14220 - Bad codegen for optimized std.conv.text in combination with concatenation https://github.com/D-Programming-Language/dmd/commit/e43136308f7eb035d046a99a46ffbdaf880413b7 Merge pull request #4451 from WalterBright/fix14220 fix Issue 14220 - Bad codegen for optimized std.conv.text in combination... --
Re: DlangIDE
On 28.02.2015 10:50, Vadim Lopatin wrote:
I suspect that is implemented by the Visual Studio debugger. Have you
tried creating an IDebugPortSupplier2?
https://msdn.microsoft.com/en-us/library/bb145819.aspx
It might also only be possible from within Visual Studio, though. To
host a debug engine you might have to implement these yourself...
To create IDebugPortSupplier2, I need at least GUID for class
implementing it.
You can find some in the registry, e.g.:
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0_Config\AD7Metrics\Engine\{3B476D35-A401-11D2-AAD4-00C04F990171}\PortSupplier
I guess you can only create them while running inside Visual Studio, so
that might not really help any further...
Re: DIP74 updated with new protocol for function calls
On Sunday, 1 March 2015 at 07:04:09 UTC, Zach the Mystic wrote:
On Saturday, 28 February 2015 at 21:12:54 UTC, Andrei
Alexandrescu wrote:
Defines a significantly better function call protocol:
http://wiki.dlang.org/DIP74
Andrei
This is obviously much better, Andrei.
I think an alternative solution (I know -- another idea --
against my own first idea!) is to keep track of this from the
caller's side. The compiler, in this case, when copying a
ref-counted type (or derivative) into a parameter, would
actually check to see if it's splitting the variable in two.
Look at this:
class RcType {...}
void fun(RcType1 c, RcType1 d);
auto x = new RcType;
fun(x, x);
If the compiler were smart, it would realize that by splitting
parameters this way, it's actually adding an additional
reference to x. The function should get one x for free, and
then force an opAdd/opRelease, for every additional x (or x
derivative) it detects in the same call.
This might be even better than the improved current proposal.
The real key is realizing that duplicating an lvalue into the
same function call is subtly adding a new reference to it.
Eh??
Note that you can get the same issue without duplicate
parameters, if you pass an alias to a global variable.
static A a;
void fun(A x) {
a = null; // Releases x
x.func();
}
void main() {
a = new A();
fun(a);
}
Re: Dgame revived
On Sunday, 1 March 2015 at 00:10:22 UTC, stewarth wrote: On Saturday, 28 February 2015 at 22:52:47 UTC, Namespace wrote: On Saturday, 28 February 2015 at 11:02:31 UTC, Namespace wrote: Next step is Font, Text and Spritesheet. Then I'll inspect Clock, Power and MessageBox and in the end I'll inspect Audio. I think the most breaking changes will happen here, because I'll use this time SDL_Audio instead of OpenAL. Font, Text, Clock (renamed to StopWatch) and Power (renamed to Battery) were also ported. The Audio package also. Spritesheet should be redundant now, because Sprite has now a clipRect, to support the Spritesheet behaviour. What is left: add missing comments / complete comments and renew the documentation. After that I will update the website. We are moving forward! :) Comments are finished so far - the documentation can be generated. I've also begun to update the website and to update the tutorials, but I need at least a whole day to get ready. So I'll be ready in mid-March at the latest - because the next week I have to learn for my exams completely again. But you can already begin with your tests. ;) Thank you for updating Dgame so quickly. I'll give it a test later this week and report any issues on github. Cheers, stew Forget to mention: until aldacron fixed DerelictSDL2 (https://github.com/DerelictOrg/DerelictSDL2/issues/39) you have to manually annotate the makros and functions with @nogc. Maybe you should wait, until aldacron fixes this.
Re: Contradictory justification for status quo
On 2015-02-28 22:11, Andrei Alexandrescu wrote: I've pushed for trello for a good while, it didn't catch up. -- Andrei There's something called HuBoard [1], project management for Github issues. I haven't used it myself but might be worth taking a look at. Although it looks like you need the issues in Github, we only have pull requests. [1] https://huboard.com/ -- /Jacob Carlborg
Re: Last week for DConf 2015 submissions
+1 for the compiler-dev table. I'd be happy to take part on that.
[Issue 14220] Bad codegen for optimized std.conv.text in combination with concatenation
https://issues.dlang.org/show_bug.cgi?id=14220 --- Comment #6 from Walter Bright bugzi...@digitalmars.com --- https://github.com/D-Programming-Language/dmd/pull/4451 --
Re: DIP74 updated with new protocol for function calls
On Saturday, 28 February 2015 at 21:12:54 UTC, Andrei Alexandrescu wrote: Defines a significantly better function call protocol: http://wiki.dlang.org/DIP74 Andrei What about having an UDA or a mixin for marking the types as RCO? -- Paulo
[Issue 14233] New: Can't build Algebraic!(This[]) anymore
https://issues.dlang.org/show_bug.cgi?id=14233
Issue ID: 14233
Summary: Can't build Algebraic!(This[]) anymore
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: alil...@gmail.com
The following code compiles on DMD 2.064, 2.065, 2.066, 2.067 b1 but not 2.067
b2.
-
import std.variant;
alias Atom = Algebraic!(string, This[]);
Atom makeNil()
{
Atom[] values = [];
return Atom(values);
}
void main()
{
}
-
What I get now:
Error: static assert Cannot store a VariantN!20u[] in a VariantN!(8u, string,
This[])
It used to work nicely. I would be nice to have at least a work-around for
this.
--
Re: Is there such a thing?
On 2015-02-28 18:06, Dicebot wrote: C is pretty much a standard for cross-language ABI You still need a way to define the bindings. -- /Jacob Carlborg
Re: Contradictory justification for status quo
Walter Bright: Actually, Kenji fearlessly deals with some of the hardest bugs in the compiler that require a deep understanding of how the compiler works and how it is supposed to work. He rarely does trivia. I regard Kenji's contributions as invaluable to the community. But my point was that probably there are even better things that Kenji can do in part of the time he works on D. Bye, bearophile
Re: DIP74 updated with new protocol for function calls
On 3/1/15 1:41 AM, Paulo Pinto wrote: On Saturday, 28 February 2015 at 21:12:54 UTC, Andrei Alexandrescu wrote: Defines a significantly better function call protocol: http://wiki.dlang.org/DIP74 Andrei What about having an UDA or a mixin for marking the types as RCO? We prefer opAddRef/opRelease to define an RCO, same as empty/front/popFront define a range. -- Andrei
Re: DIP74 updated with new protocol for function calls
On 2015-02-28 22:12, Andrei Alexandrescu wrote:
Defines a significantly better function call protocol:
http://wiki.dlang.org/DIP74
Is there any checking that the signatures of these methods matches the
ones in the base class if an implicit conversion to the base class is
made? Example:
class Base
{
void opAddRef();
void opRelease();
}
class Sub : Base
{
int opAddRef();
int opRelease();
}
Base b = new Sub; // what happens here?
On all examples showing how the compiler will insert calls to opAddRef
and opRelease the return value is ignored. Is there a point in
returning anything form these methods?
--
/Jacob Carlborg
Re: DIP74 updated with new protocol for function calls
Jacob Carlborg wrote in message news:mcv342$2c9t$1...@digitalmars.com... I already commented on that. Andrei said [1] he was fine with breaking code for this feature. I don't understand why because it so easy to fix with a compiler recognized UDA [2]. Because a compiler recognized UDA is an additional complication for something that is unlikely to be a problem for anyone. Do you have code with methods named opAddRef? No? Me neither.
Re: Making RCSlice and DIP74 work with const and immutable
The RC wrapper allocates _mutable_ memory for the reference count on the heap (it has to do that anyway, because it needs to be shared by all instances). As far as I understand, mutating a mutable variable is safe if all users of that variable are aware that it's mutable, _even if it's only reachable through a const pointer_. This condition is easy to enforce in an RC wrapper, it just has to keep the pointer to the refcount private. To make it easier to prove safety, the pointer needs to be declared as const; all refcount manipulation needs to happen through two small (inlinable) helper methods that do the appropriate cast() magic. The refcount can also be stored next to the payload (better for cache locality anyway), in which case we don't even need to store a const pointer at all, which also means that nobody can accidentally access it in the wrong way.
Re: Making RCSlice and DIP74 work with const and immutable
On Sunday, 1 March 2015 at 06:42:02 UTC, H. S. Teoh wrote:
On Sun, Mar 01, 2015 at 12:53:24PM +1000, Manu via
Digitalmars-d wrote:
On 1 March 2015 at 12:48, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 2/28/15 6:33 PM, Manu via Digitalmars-d wrote:
one of the biggest recurring
complaints relating to the D type system
That didn't get talked about in I don't remember. -- Andrei
So, what's the solution?
I've never complained about it, but I still have this problem
regularly. The solution in my experience is; 'everything is
always
mutable'.
I ran into the same problem, and as a result I hardly ever make
use of
D's const system.
One possible solution that occurred to me, though, is to
introduce a
kind of logical const template that constructs a
partially-const type,
with the logical data parts const/immutable/etc., but the
metadata
parts mutable. User-defined attributes could be used for this
purpose:
struct Metadata {}
class MyClass {
int field; // regular data field
@Metadata int fieldCache; // metadata
...
}
template Const(T) {
class Const {
const {
// insert stuff not marked with
// @Metadata here
}
// insert stuff marked with @Metadata here
}
}
So then Const!MyClass is a modified version of MyClass where
the data
fields are const (similarly, we can define Immutable for the
analogous
purpose) but the fields marked as metadata will remain mutable.
Of course, this is just a crude first stab at the problem; I'm
sure
there's plenty of room for refinement to make it more usable,
and to
address some obvious roadblocks, like how to make MyClass
implicitly
convertible to Const!MyClass, etc.. But it seems likely that D's
template machinery can actually express this in a way that does
not
violate the guarantee of physical const.
You still cannot access it through a const reference, though.
Re: DIP74 updated with new protocol for function calls
On Mon, 02 Mar 2015 00:15:02 +1100, Daniel Murphy wrote: Jacob Carlborg wrote in message news:mcv342$2c9t$1...@digitalmars.com... I already commented on that. Andrei said [1] he was fine with breaking code for this feature. I don't understand why because it so easy to fix with a compiler recognized UDA [2]. Because a compiler recognized UDA is an additional complication for something that is unlikely to be a problem for anyone. Do you have code with methods named opAddRef? No? Me neither. so i should buy a reddit account with good reputation to change that, as we all know that only reddit users matters. signature.asc Description: PGP signature
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On Friday, 27 February 2015 at 15:53:18 UTC, ponce wrote: On Thursday, 26 February 2015 at 14:22:01 UTC, Ola Fosheim Grøstad wrote: No. If I can't open a file I'd better not create a File object in an invalid state. Invalid states defeats RAII. This is the attitude I don't like, because it means that you have to use pointers when you could just embed the file-handle. That leads to more allocations and more cache misses. I really don't understand how any of this is related to what we were previously discussing: error handling. You wrote: «No. If I can't open a file I'd better not create a File object in an invalid state. Invalid states defeats RAII.» If you embed the File object in other objects you also have to deal with the File object being in an invalid state. The alternative is to have discrete objects and nullable pointers to them. Makes sense for a high level programming language like Java, makes no sense for a system programming language. It does't make much sense to go on after an error, in any software that want some reliability. It does, when you do async buffering and want performance, e.g. OpenGL. Often it also makes error-handling simpler. Often you don't care about when it failed, you often only care about the transactional unit as a whole. It also makes programs more portable. There are big architectural differences when it comes to when errors can be reported. E.g. you don't want to wait for a networked drive to respond before going on. You only want to know if the closing of the transaction succeeded or not.
Re: DIP74 updated with new protocol for function calls
On 2015-03-01 10:41, Paulo Pinto wrote: What about having an UDA or a mixin for marking the types as RCO? I already commented on that. Andrei said [1] he was fine with breaking code for this feature. I don't understand why because it so easy to fix with a compiler recognized UDA [2]. [1] http://forum.dlang.org/post/mcqik9$5fu$1...@digitalmars.com [2] http://forum.dlang.org/post/mcp5nu$1nus$1...@digitalmars.com -- /Jacob Carlborg
Re: DIP74: Reference Counted Class Objects
Jacob Carlborg:
@arc class Foo
{
T1 opAddRef();
T2 opRelease();
}
...
Alternative A gives a clear documentation it's a reference
counted class without having to scan the methods.
Assuming you want something like DIP74, this design design seems
safer than the design proposed in DIP74.
Bye,
bearophile
Re: DIP74 updated with new protocol for function calls
On 2015-03-01 13:41, Andrei Alexandrescu wrote: We prefer opAddRef/opRelease to define an RCO, same as empty/front/popFront define a range. -- Andrei I don't see how a UDA would hurt. -- /Jacob Carlborg
Re: LLVM 3.6 released - LDC master branch/0.15.1 is ready to use it!
On Sunday, 1 March 2015 at 03:26:16 UTC, Dan Olson wrote: Dan Olson zans.is.for.c...@yahoo.com writes: I got LLVM 3.6 to work but I couldn't compile with LDC 0.15.1 (looks like more 3.6 fixes came in after it) and ldc master HEAD compilation ended up with an LLVM assertion failure on OS X. I backed up to ldc commit 136fe8d and that worked for both OS X and iOS. Which assertion do you get on OS X? Regards, Kai
Re: My Reference Safety System (DIP???)
On Sunday, 1 March 2015 at 05:29:19 UTC, Zach the Mystic wrote:
On Saturday, 28 February 2015 at 20:49:22 UTC, Marc Schütz
wrote:
I encountered an ugly problem. Actually, I had already run
into it in my first proposal, but Steven Schveighoffer just
posted about it here, which made me aware again:
http://forum.dlang.org/thread/mcqcor$aa$1...@digitalmars.com#post-mcqk4s:246qb:241:40digitalmars.com
class T {
void doSomething() scope;
}
struct S {
RC!T t;
}
void main() {
auto s = S(RC!T()); // `s.t`'s refcount is 1
foo(s, s.t);// borrowing, no refcount changes
}
void foo(ref S s, scope T t) {
s.t = RC!T(); // drops the old `s.t`
t.doSomething();// oops, `t` is gone
}
One quick thing. I suggest a solution here:
http://forum.dlang.org/post/jycylhdhdewtgumba...@forum.dlang.org
You do the checking and adding in the called function, not the
caller. The algorithm:
1. Keep a compile-time refcount per function. Does the
parameter get released, i.e. does the refcount ever go below 1?
If not, stop.
2. Can the parameter contain (as a member) a reference to a
refcounted struct of the types of any of the other parameters?
If not, stop.
3. Okay, you need to preserve the reference. Add a call to
opAdd at the beginning and one to opRelease at the end of the
function. Done.
I don't think a callee-based solution can work:
class T {
void doSomething() scope;
}
struct S {
RC!T t;
}
void main() {
auto s = S(RC!T()); // `s.t`'s refcount is 1
T t = s.t; // borrowing from the RC wrapper
foo(s);
t.doSomething();// oops, `t` is gone
}
void foo(ref S s) {
s.t = RC!T(); // drops the old `s.t`
}
`foo()` has no idea whether there are still `scope` borrowings to
`s.t`.
Therefore, if there _is_ a solution, it needs to work inside the
caller. You second idea [1] goes in the right direction.
Unfortunately, it is DIP74 specific; in this form, it cannot be
applied to user-defined struct-based RC wrappers. (DIP25 is also
affected by this problem, by the way.)
To keep the compiler agnostic about the purpose of the structs in
question, I'm afraid the only solution is uniqueness tracking. If
`@unique` we're a property of references, we could either
automatically make those references `const` when more than one
reference exists, or disallow passing these values to functions
if the corresponding parameter is annotated @unique.
Unfortunately, this is likely to be a very invasive change, in
contrast to `scope` :-(
[1]
http://forum.dlang.org/post/bghjqvvrdcfqmoiyy...@forum.dlang.org
Re: Does static ctor/dtor of struct behave differently in 2.067-b2?
On Saturday, 28 February 2015 at 03:26:17 UTC, ketmar wrote:
On Fri, 27 Feb 2015 23:58:16 +, amber wrote:
On Friday, 27 February 2015 at 23:50:51 UTC, amber wrote:
Hi All,
[snip]
Thanks, amber
[edited subject]
Sorry I should add that I'm talking about static ctor/dtor of
struct.
The bug I see with 2.067-b2 is this:
1. static this() {} called and static fields of struct are
initialised
2. app runs, static fields are initialised.
3. static ~this() {} called and static fields of struct are NOT
initialised.
In step 3 with 2.066.1 all the static fields of struct are
still
initialised, as expected, and my app shuts down cleanly.
is your struct GC-allocated? and can you provide dustmited code
or
something we can play with?
Hi ketmar, thanks for replying.
I think I have figured out what was happening.
DMD 2.067 spins up 5 threads when running the unittests and DMD
2.066.1 only uses one thread. This change exposed a bug in the
static ctor which I've now fixed.
Thanks,
amber
Re: RCArray is unsafe
On Sunday, 1 March 2015 at 20:51:35 UTC, Michel Fortin wrote:
On 2015-03-01 19:21:57 +, Walter Bright said:
The trouble seems to happen when there are two references to
the same object passed to a function. I.e. there can be only
one borrowed ref at a time.
I'm thinking this could be statically disallowed in @safe code.
That's actually not enough. You'll have to block access to
global variables too:
S s;
void main() {
s.array = RCArray!T([T()]); // s.array's refcount is now 1
foo(s.array[0]); // pass by ref
}
void foo(ref T t) {
s.array = RCArray!T([]); // drop the old s.array
t.doSomething(); // oops, t is gone
}
Globals to impures, that is.
Re: Would Lcl be better if it was in D?
On Monday, 2 March 2015 at 01:22:58 UTC, ketmar wrote:
On Sun, 01 Mar 2015 22:40:28 +, Taylor Hillegeist wrote:
But still the question was about smaller executable when
compiling d
code. The linker needs to know which .o files to include, the
pascal
notation is basically:
uses
thisBigoleThing, ThisOtherBigOleThing, AndMeToo;
I assume the linker just auto-magically includes the entire
thing even
if your only using a single function or value from each. Then
again
perhaps I am wrong.
FreePascal learnt the smart linking trick years ago, so only
actually
used functions ends in linked binary. but LCL is very big
library, and FPC
can't drop out unused virtual methods, so resulting binaries
are big.
with D we have the same situation, maybe even worse due to
template
instantiation. compiler is able to merge identical template
instanses,
but... empty `void main () {}` is ~200 KB in D (GNU/Linux,
x86). adding
simple `import std.stdio : writeln;` increases binary size to
~300 KB.
and adding `writeln(hello!);` increases binary size to ~350
KB.
D binaries are big. ;-)
LDC + dynamic linking gets pretty tiny binaries, C binaries
aren't all that small if you static link in glibc ;)
Re: Making RCSlice and DIP74 work with const and immutable
On Sun, Mar 01, 2015 at 03:47:36PM +, via Digitalmars-d wrote: On Sunday, 1 March 2015 at 15:08:47 UTC, H. S. Teoh wrote: On Sun, Mar 01, 2015 at 01:43:44PM +, via Digitalmars-d wrote: On Sunday, 1 March 2015 at 06:42:02 UTC, H. S. Teoh wrote: [...] So then Const!MyClass is a modified version of MyClass where the data fields are const (similarly, we can define Immutable for the analogous purpose) but the fields marked as metadata will remain mutable. Of course, this is just a crude first stab at the problem; I'm sure there's plenty of room for refinement to make it more usable, and to address some obvious roadblocks, like how to make MyClass implicitly convertible to Const!MyClass, etc.. But it seems likely that D's template machinery can actually express this in a way that does not violate the guarantee of physical const. You still cannot access it through a const reference, though. The whole point is to use Const!T instead of const(T). But that's intrusive! You can only apply it code you control, or at least you have to convince everyone to use it. I don't see any other way of supporting logical const without violating physical const in some way. As soon as const(T) means anything other than const(T), you open up a hole in the type system and the const guarantee becomes no longer a guarantee, but a mere advisory like C++ const. T -- Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry
Re: This Week in D #7 - summary of reference counting discussion
On Monday, 2 March 2015 at 04:19:08 UTC, Adam D. Ruppe wrote: This was a very active week on the forums, though most of it was centered around DIP74 and its satellite discussions, leading to a somewhat thin newsletter. http://arsdnet.net/this-week-in-d/mar-01.html https://twitter.com/adamdruppe/status/572249079352299520 This newsletter is great and has been my main source of Dlang weekly news while busy at work. Thanks.
Re: LLVM 3.6 released - LDC master branch/0.15.1 is ready to use it!
Dan Olson zans.is.for.c...@yahoo.com writes: Kai Nacke k...@redstar.de writes: On Sunday, 1 March 2015 at 03:26:16 UTC, Dan Olson wrote: Dan Olson zans.is.for.c...@yahoo.com writes: I got LLVM 3.6 to work but I couldn't compile with LDC 0.15.1 (looks like more 3.6 fixes came in after it) and ldc master HEAD compilation ended up with an LLVM assertion failure on OS X. I backed up to ldc commit 136fe8d and that worked for both OS X and iOS. Which assertion do you get on OS X? Regards, Kai I didn't save the error message. I'll have to rebuild with ldc master later today then I'll let you know. I was using an LLVM 3.6 (github mirror release_36 branch) Debug+Asserts build. False alarm Kai. I updated ldc to master but not runtime. Once I updated druntime to ldc branch HEAD, it builds ok. Probably the varargs change. BTW, this was the assertion I got in a bunch of modules: Assertion failed: (getOperand(0)-getType() == castPointerType(getOperand(1)-getType())-getElementType() Ptr must be a pointer to Val type!), function AssertOK, file /Users/dan/projects/ldc/llvm-git/lib/IR/Instructions.cpp, line 1083.
Re: This Week in D #7 - summary of reference counting discussion
On Monday, 2 March 2015 at 04:19:08 UTC, Adam D. Ruppe wrote: This was a very active week on the forums, though most of it was centered around DIP74 and its satellite discussions, leading to a somewhat thin newsletter. http://arsdnet.net/this-week-in-d/mar-01.html https://twitter.com/adamdruppe/status/572249079352299520 Typo: LDS for iOS Thanks Adam
SQLite3 and threads
Hi,
I am not able to query SQLite3 database files using threads;
without threads it is working fine.
I tried both etc.c.sqlite3 and d2sqlite3, and both seem to be
facing the same issue:
They stuck when executing a select query (using sqlite3_exec(...)
for etc.c.sqlite3 or using RowCache(db.execute(...)) in case of
d2sqlite3).
Since d2sqlite3 is a wrapper for native sqlite3, I think it faces
the same limitation which native sqlite does, so next lines will
describe native SQLite3 code.
---
This works fine (non-relevant code and validations are omitted
for simplicity)
---
import etc.c.sqlite3,...
...
extern(C) int myCallback(void *a_parm, int argc, char **argv,
char **column)
{
printf(%s\n, argv[1] ? argv[1] : NULL); // this prints
first column of each row, all is well
return 0;
}
void querySQLite(string dbName)
{
sqlite3* db;
auto ret = sqlite3_open(toStringz(dbName), db);
string query = SELECT * FROM my_table;
sqlite3_exec(db,toStringz(query),myCallback,null,null);
sqlite3_close(db);
}
void main()
{
querySQLite(db1.sl3);
querySQLite(db2.sl3);
...// in fact, here is a foreach loop which is calling
querySQLite with about 30 database files
querySQLite(db30.sl3);
}
---
However, if I change main function to spawn querySQLite, instead
of calling it in sequence from the main thread,
then myCallback() is not executed.
void main()
{
spawn(querySQLite,db1.sl3);
spawn(querySQLite,db2.sl3);
...
spawn(querySQLite,db30.sl3);
}
It is stuck inside this line in querySQLite():
sqlite3_exec(db,toStringz(query),myCallback,null,null);
If I comment it, the flow continues and returns fine from all
spawn-ed functions, so it is definitely something wrong in this
line.
---
I think I am missing some kind of thread locking code in
querySQLite() - since it is working with C code I think it needs
more attention.
I tried to compile SQLite with different multithreading options,
but that did not help.
Any advice is much appreciated.
Using dmd.2.066.1.linux
RedHat 5 64bit
Compiled using dmd
sqlite-amalgamation-3080803
Thanks,
Vitalie
Re: SQLite3 and threads
After some analysis, it looks like related to the code parts which I have omitted for simplicity, and in particular - I was creating the query using global variable which was populated in main() function. It appears that when I spawn the function, it does not see the value of the global variable, thus, the query was not correct which made it execute full scan of table and never completed (table is huge). I am checking more if anything like this is already documented anywhere.
Re: SQLite3 and threads
On 03/01/2015 09:47 PM, Vitalie Colosov wrote: global variable A module-scope variable is thread-local by-default. Every thread will have a copy of that variable. If you want to share data, you must define it as 'shared' (or __gshared). which was populated in main() function In that case only the main thread's variable would be initialized. Shared variables should be initialized in 'shared static this()' scopes. Ali
Re: Invoking MAGO debugger
On Thursday, 26 February 2015 at 18:37:17 UTC, michaelc37 wrote: On Thursday, 26 February 2015 at 10:20:31 UTC, Vadim Lopatin wrote: Hello! I'm trying to integrate MAGO into DlangIDE. I can easy create instance of MAGO DebugEngine, but having problems with obtaining of IDebugPort which is needed for invoking of LaunchSuspended. It looks like to get IDebugPort, I need IDebugCoreServer2 instance. Does anybody know how to do it? Normally, it's being created by VisualStudio AFAIK. Best regards, Vadim I once remember pulling out my hair trying todo the same in order to get it to work with a monodevelop win32 debugger addon. It resulted in a writing new clr wrapper with a different exposed interface https://github.com/aBothe/MagoWrapper e.g. of how the debugee was was launched here: https://github.com/aBothe/MagoWrapper/blob/master/DebugEngine/MagoWrapper/NativeDebugger.cpp Thank you a lot! BTW, it's not clear what license in used for MagoWrapper. In readme, it's said that it's under GPL2, but everywhere in source code I see Apache license.
Re: Why rbtree.length isn't const?
On 26.02.2015 18:44, Steven Schveighoffer wrote: Please submit an issue. http://issues.dlang.org -Steve Done: https://issues.dlang.org/show_bug.cgi?id=14234
Re: SQLite3 and threads
Now it all makes sense. Thank you. Maybe it would make also some sense if I would have gotten some kind of exception trying to access the variable which was not populated by the running thread, instead of successfully getting empty string... so this would be observed easily during the testing, but perhaps there are some reasons for it being implemented the way it is, will keep learning.
This Week in D #7 - summary of reference counting discussion
This was a very active week on the forums, though most of it was centered around DIP74 and its satellite discussions, leading to a somewhat thin newsletter. http://arsdnet.net/this-week-in-d/mar-01.html https://twitter.com/adamdruppe/status/572249079352299520
Re: Would Lcl be better if it was in D?
On Monday, 2 March 2015 at 01:22:58 UTC, ketmar wrote:
On Sun, 01 Mar 2015 22:40:28 +, Taylor Hillegeist wrote:
But still the question was about smaller executable when
compiling d
code. The linker needs to know which .o files to include, the
pascal
notation is basically:
uses
thisBigoleThing, ThisOtherBigOleThing, AndMeToo;
I assume the linker just auto-magically includes the entire
thing even
if your only using a single function or value from each. Then
again
perhaps I am wrong.
FreePascal learnt the smart linking trick years ago, so only
actually
used functions ends in linked binary. but LCL is very big
library, and FPC
can't drop out unused virtual methods, so resulting binaries
are big.
with D we have the same situation, maybe even worse due to
template
instantiation. compiler is able to merge identical template
instanses,
but... empty `void main () {}` is ~200 KB in D (GNU/Linux,
x86). adding
simple `import std.stdio : writeln;` increases binary size to
~300 KB.
and adding `writeln(hello!);` increases binary size to ~350
KB.
D binaries are big. ;-)
That seems like alot of KB for just a little bit of code. I
wasn't aware that void main(){} was anything but entry pointer...
;; pseudo-assembly-language
;; main(argc, argv, envp); call
push envp ;; rightmost argument
push argv ;;
push argc ;; leftmost argument ends up on top of stack
call main
I guess I'm confused about what is in there and why?
Re: RCArray is unsafe
On 3/1/2015 12:51 PM, Michel Fortin wrote: That's actually not enough. You'll have to block access to global variables too: Hmm. That's not so easy to solve.
[Issue 14234] New: rbtree length should be const
https://issues.dlang.org/show_bug.cgi?id=14234 Issue ID: 14234 Summary: rbtree length should be const Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: drug2...@bk.ru There is no reason for RBTree.length be non-const. --
Re: ErrnoException in Windows
Thans guys! wenforce not sutable - error code is lost. may be, i will use modified wenforce, wich throws ErrnoException.
Re: RCArray is unsafe
On 3/1/2015 7:44 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote:
A weakness of the same kind affects DIP25, too. The core of the problem is
borrowing (ref return as in DIP25), combined with manual (albeit hidden) memory
management. An example to illustrate:
struct T {
void doSomething();
}
struct S {
RCArray!T array;
}
void main() {
auto s = S(RCArray!T([T()])); // s.array's refcount is now 1
foo(s, s.array[0]); // pass by ref
}
void foo(ref S s, ref T T) {
s.array = RCArray!T([]); // drop the old s.array
t.doSomething(); // oops, t is gone
}
The trouble seems to happen when there are two references to the same object
passed to a function. I.e. there can be only one borrowed ref at a time.
I'm thinking this could be statically disallowed in @safe code.
Re: Contradictory justification for status quo
On Saturday, 28 February 2015 at 21:11:54 UTC, Andrei Alexandrescu wrote: On 2/28/15 12:20 PM, Sativa wrote: I'm curious if project management(e.g., MS Project) is used to optimize and clarify goals for the D language? I've pushed for trello for a good while, it didn't catch up. -- Andrei Note that most never had any access to it.
Re: My Reference Safety System (DIP???)
On Saturday, 28 February 2015 at 11:12:23 UTC, Marc Schütz wrote: Yes. Terminology is a problem here, I guess. When I talk about the scope of a variable, it means that only references to values can be stored there whose lifetimes are at least as large as the scope. Make sure you explicit that. The variable itself has a scope, and this scope is different from the scope of indirections stored in the variable. Additionally, this naturally bring the question of multiple indirection in a variable (for a struct for instance). You don't cover the lifetime of the address of operation, and I'm not how this is supposed to work in your proposal. It was in the examples, but it was wrong. I've corrected it: A dereference results in static lifetime. Will do a second pass on the damn thing :) I will also add examples how return and static annotations are handled. static annotation ? Seems like a bad idea and I'm sure we can do without. It's only necessary if parameters of `@safe` functions are automatically scoped; then we need a way to opt-out. This is actually optional and does not affect the consistency, but I thought it is a good idea, because it reduces the overall amount of annotations. And I assume that most @safe functions are already written in a way that conforms to this. We'd need to analyze some code bases to find out whether this is actually true. Ok I misunderstood what you meant by static anotation. Sounds good. Scope by default, and an optout. Problem is transition. We have a scope keyword what does it become ?
Re: ErrnoException in Windows
Ha, i found std.windows.syserror: WindowsException, wenforce;
Re: Making RCSlice and DIP74 work with const and immutable
On Sun, Mar 01, 2015 at 01:43:44PM +, via Digitalmars-d wrote: On Sunday, 1 March 2015 at 06:42:02 UTC, H. S. Teoh wrote: [...] So then Const!MyClass is a modified version of MyClass where the data fields are const (similarly, we can define Immutable for the analogous purpose) but the fields marked as metadata will remain mutable. Of course, this is just a crude first stab at the problem; I'm sure there's plenty of room for refinement to make it more usable, and to address some obvious roadblocks, like how to make MyClass implicitly convertible to Const!MyClass, etc.. But it seems likely that D's template machinery can actually express this in a way that does not violate the guarantee of physical const. You still cannot access it through a const reference, though. The whole point is to use Const!T instead of const(T). T -- Be in denial for long enough, and one day you'll deny yourself of things you wish you hadn't.
Re: DIP74: Reference Counted Class Objects
On 3/1/15 6:55 AM, John Colvin wrote:
On Sunday, 1 March 2015 at 03:43:24 UTC, Andrei Alexandrescu wrote:
It might be more productive to look into improvements of optimizations
related to copying objects.
Andrei
Yes please. I'd be very interested in hearing any thoughts you have on
this.
One that comes to mind is: if (a) a copy b of a struct object a is
created, (b) b is used only with non-mutating operations, and (c) a is
not changed before b goes out of scope, then a can be directly
substituted for b (no actual copy is made).
Example:
struct S {
this(this);
~this();
int method() const;
}
int fun() {
S a;
S b = a;
return b.method();
}
may be lowered to:
int fun() {
S a;
return a.method();
}
Andrei
RCArray is unsafe
Walter posted an example implementation of a reference counted
array [1], that utilizes the features introduced in DIP25 [2].
Then, in the threads about reference counted objects, several
people posted examples [3, 4] that broke the suggested
optimization of eliding `opAddRef()`/`opRelease()` calls in
certain situations.
A weakness of the same kind affects DIP25, too. The core of the
problem is borrowing (ref return as in DIP25), combined with
manual (albeit hidden) memory management. An example to
illustrate:
struct T {
void doSomething();
}
struct S {
RCArray!T array;
}
void main() {
auto s = S(RCArray!T([T()])); // s.array's refcount is
now 1
foo(s, s.array[0]); // pass by ref
}
void foo(ref S s, ref T T) {
s.array = RCArray!T([]); // drop the old s.array
t.doSomething(); // oops, t is gone
}
Any suggestions how to deal with this? As far as I can see, there
are the following options:
1) Make borrowing (return ref) @system. This would defeat the
purpose of DIP25.
2) Disallow (by convention) borrowing for refcounted objects.
Again, this would make DIP25 pointless, and strictly speaking,
anything that relies on convention cannot be @safe. And there's
no guarantee that it doesn't affect other things besides RC.
3) Introduce a full linear type system. A _very_ large and
invasive change, and probably cumbersome to work with.
4) Live with it. Accept that it's not possible to get the last
bit of @safe-ty without extreme and unjustifiable costs. Make it
@safe nevertheless, and formulate usage guides that people are
expected to follow.
5) Make `RCArray` a special type whose purpose is known to the
compiler, and implement complicated checks to verify @safe-ty.
Again, kind of defeats the purpose, and adds complexity to the
language and implementation.
6) Restrict borrowing to situations where it's @safe. Or better,
allow it everywhere, but make it @system where necessary. I think
problems can only happen at function boundaries (what happens
inside a function can be checked statically), but I'd have to
think about it more.
7) Anything else? Are there some small details (in whatever part
of the language) that can be adjusted to get us additional
guarantees?
Option 6) currently appears the most promising to me.
Comments?
[1] http://forum.dlang.org/thread/mcg8qq$1mbr$1...@digitalmars.com
[2] http://wiki.dlang.org/DIP25
[4]
http://forum.dlang.org/post/ilfwmeobprkcorpiq...@forum.dlang.org
[5] http://forum.dlang.org/post/mcqk4s$6qb$1...@digitalmars.com
Re: Making RCSlice and DIP74 work with const and immutable
On Sunday, 1 March 2015 at 02:53:34 UTC, Manu wrote: On 1 March 2015 at 12:48, Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: On 2/28/15 6:33 PM, Manu via Digitalmars-d wrote: one of the biggest recurring complaints relating to the D type system That didn't get talked about in I don't remember. -- Andrei So, what's the solution? I've never complained about it, but I still have this problem regularly. The solution in my experience is; 'everything is always mutable'. I've lost count now of how many times I've had to downgrade to auto despite always wanting immutable or const. This doesn't work: auto reg = regex(`(foo)`); const match = foo.matchAll(reg); writeln(match.captures); //oops, captures isn't const It should, but it doesn't. Maxime talked about it here as well: http://pointersgonewild.com/2014/07/11/the-constness-problem/ Atila
Re: Making RCSlice and DIP74 work with const and immutable
I haven't put much thought into this, but here's an idea:
struct MetadataWrapper(T, M) {
immutable T payload; //or const via static if?
M _metadata;
alias payload this;
ref M metadata() { return _metadata;}
}
auto withMetadata(T, Ts...)(Ts args) {
return MetadataWrapper!(T, int)(cast(immutable)(new T(args)),
0);
}
It's short and stupid but works:
void main() {
import std.stdio;
static class MyClass {
this(string s) {
this.s = s;
}
string s;
string stuff() const pure nothrow @safe { return s ~
and stuff;}
}
auto foo = withMetadata!MyClass(a string);
writeln(calling stuff on foo: , foo.stuff());
writeln(foo's metadata is , foo.metadata);
foo.metadata++;
writeln(foo's metadata is , foo.metadata);
}
On Sunday, 1 March 2015 at 01:40:40 UTC, Andrei Alexandrescu
wrote:
Tracing garbage collection can afford the luxury of e.g.
mutating data that was immutable during its lifetime.
Reference counting needs to make minute mutations to data while
references to that data are created. In fact, it's not mutation
of the useful data, the payload of a data structure; it's
mutation of metadata, additional information about the data
(i.e. a reference count integral).
The RCOs described in DIP74 and also RCSlice discussed in this
forum need to work properly with const and immutable.
Therefore, they need a way to reliably define and access
metadata for a data structure.
One possible solution is to add a @mutable or @metadata
attribute similar to C++'s keyword mutable. Walter and I both
dislike that solution because it's hamfisted and leaves too
much opportunity for abuse - people can essentially create
unbounded amounts of mutable payload for an object claimed to
be immutable. That makes it impossible (or unsafe) to optimize
code based on algebraic assumptions.
We have a few candidates for solutions, but wanted to open with
a good discussion first. So, how do you envision a way to
define and access mutable metadata for objects (including
immutable ones)?
Andrei
Re: RCArray is unsafe
On Sunday, 1 March 2015 at 15:44:49 UTC, Marc Schütz wrote:
Walter posted an example implementation of a reference counted
array [1], that utilizes the features introduced in DIP25 [2].
Then, in the threads about reference counted objects, several
people posted examples [3, 4] that broke the suggested
optimization of eliding `opAddRef()`/`opRelease()` calls in
certain situations.
A weakness of the same kind affects DIP25, too. The core of the
problem is borrowing (ref return as in DIP25), combined with
manual (albeit hidden) memory management. An example to
illustrate:
struct T {
void doSomething();
}
struct S {
RCArray!T array;
}
void main() {
auto s = S(RCArray!T([T()])); // s.array's refcount is
now 1
foo(s, s.array[0]); // pass by ref
}
void foo(ref S s, ref T T) {
s.array = RCArray!T([]); // drop the old s.array
t.doSomething(); // oops, t is gone
}
Any suggestions how to deal with this? As far as I can see,
there are the following options:
See:
http://forum.dlang.org/post/bghjqvvrdcfqmoiyy...@forum.dlang.org
...and:
http://forum.dlang.org/post/cviwlkugnothraubc...@forum.dlang.org
Re: LLVM 3.6 released - LDC master branch/0.15.1 is ready to use it!
Kai Nacke k...@redstar.de writes: On Sunday, 1 March 2015 at 03:26:16 UTC, Dan Olson wrote: Dan Olson zans.is.for.c...@yahoo.com writes: I got LLVM 3.6 to work but I couldn't compile with LDC 0.15.1 (looks like more 3.6 fixes came in after it) and ldc master HEAD compilation ended up with an LLVM assertion failure on OS X. I backed up to ldc commit 136fe8d and that worked for both OS X and iOS. Which assertion do you get on OS X? Regards, Kai I didn't save the error message. I'll have to rebuild with ldc master later today then I'll let you know. I was using an LLVM 3.6 (github mirror release_36 branch) Debug+Asserts build.
Re: DIP74: Reference Counted Class Objects
On Sunday, 1 March 2015 at 03:43:24 UTC, Andrei Alexandrescu wrote: It might be more productive to look into improvements of optimizations related to copying objects. Andrei Yes please. I'd be very interested in hearing any thoughts you have on this.
Re: Making RCSlice and DIP74 work with const and immutable
On Sunday, 1 March 2015 at 01:40:40 UTC, Andrei Alexandrescu wrote: Tracing garbage collection can afford the luxury of e.g. mutating data that was immutable during its lifetime. Reference counting needs to make minute mutations to data while references to that data are created. In fact, it's not mutation of the useful data, the payload of a data structure; it's mutation of metadata, additional information about the data (i.e. a reference count integral). The RCOs described in DIP74 and also RCSlice discussed in this forum need to work properly with const and immutable. Therefore, they need a way to reliably define and access metadata for a data structure. One possible solution is to add a @mutable or @metadata attribute similar to C++'s keyword mutable. Walter and I both dislike that solution because it's hamfisted and leaves too much opportunity for abuse - people can essentially create unbounded amounts of mutable payload for an object claimed to be immutable. That makes it impossible (or unsafe) to optimize code based on algebraic assumptions. We have a few candidates for solutions, but wanted to open with a good discussion first. So, how do you envision a way to define and access mutable metadata for objects (including immutable ones)? I need to get educated on this issue. First suggestion: Just break the type system by encouraging the idiom of using casts in opAddRef and opRelease. It's too easy, but I don't know why.
Re: ErrnoException in Windows
On Sun, 01 Mar 2015 16:39:27 +, novice2 wrote: Could you, please, help me to understand, why code: 'cause winapi functions never sets `errno`. `errno` is a libc feature, and winapi knows nothing about libc. besides, `GetLastError()` is not required to return correct errno codes. so you have to either use libc funcions, or translate `GetLastError()` codes to errno manually. signature.asc Description: PGP signature
Re: Making RCSlice and DIP74 work with const and immutable
On Sunday, 1 March 2015 at 01:40:40 UTC, Andrei Alexandrescu wrote: We have a few candidates for solutions, but wanted to open with a good discussion first. So, how do you envision a way to define and access mutable metadata for objects (including immutable ones)? Andrei I don't think const or immutable intrusive-reference-counted classes is a feasible idea. I understand the motivation: we want to dynamically allocate a class instance, initialize it and never mutate it again, and pass it around freely; *without* using tracing GC. Having it typed as immutable helps code readability and whatnot. However, AFAICS, it comes with a serious problem. Immutable objects are freely passable between threads, so surely an immutable RC object would need atomic counting just like a shared RC object, but unlike shared, immutable does not necessarily express the intent of sharing between threads; the immutable RC object could easily be counting atomically for nothing. There might be other problems, such as problems regarding ROM. This is not a problem with reference-counting as a whole but with intrusive reference-counting. With RefCounted, immutable(RefCounted!T) makes no sense, but RefCounted!(immutable T) does. It's also neatly composable; shared(RefCounted!(immutable T)) makes sense too. I wish we had external, composable reference-counting for class instances. I know why that's problematic, so sorry for posting without any suggestion on how to proceed...
Re: Making RCSlice and DIP74 work with const and immutable
On Sunday, 1 March 2015 at 15:08:47 UTC, H. S. Teoh wrote: On Sun, Mar 01, 2015 at 01:43:44PM +, via Digitalmars-d wrote: On Sunday, 1 March 2015 at 06:42:02 UTC, H. S. Teoh wrote: [...] So then Const!MyClass is a modified version of MyClass where the data fields are const (similarly, we can define Immutable for the analogous purpose) but the fields marked as metadata will remain mutable. Of course, this is just a crude first stab at the problem; I'm sure there's plenty of room for refinement to make it more usable, and to address some obvious roadblocks, like how to make MyClass implicitly convertible to Const!MyClass, etc.. But it seems likely that D's template machinery can actually express this in a way that does not violate the guarantee of physical const. You still cannot access it through a const reference, though. The whole point is to use Const!T instead of const(T). But that's intrusive! You can only apply it code you control, or at least you have to convince everyone to use it.
Re: Making RCSlice and DIP74 work with const and immutable
On Sunday, 1 March 2015 at 15:40:06 UTC, Atila Neves wrote: I've lost count now of how many times I've had to downgrade to auto despite always wanting immutable or const. This doesn't work: auto reg = regex(`(foo)`); const match = foo.matchAll(reg); writeln(match.captures); //oops, captures isn't const It should, but it doesn't. Maxime talked about it here as well: http://pointersgonewild.com/2014/07/11/the-constness-problem/ Atila `match.captures` is a range; it's only natural for a range to have mutable state to be iterable. D's const is a bridge between immutable and mutable. const has to be transitive because immutable is transitive. Don't use it as if it was C++ const: there's no logical const in D, and if there ever will be, it can't use the same `const` type qualifier.
Re: Making RCSlice and DIP74 work with const and immutable
On Sunday, 1 March 2015 at 15:28:56 UTC, Jakob Ovrum wrote: On Sunday, 1 March 2015 at 01:40:40 UTC, Andrei Alexandrescu wrote: We have a few candidates for solutions, but wanted to open with a good discussion first. So, how do you envision a way to define and access mutable metadata for objects (including immutable ones)? Andrei I don't think const or immutable intrusive-reference-counted classes is a feasible idea. I understand the motivation: we want to dynamically allocate a class instance, initialize it and never mutate it again, and pass it around freely; *without* using tracing GC. Having it typed as immutable helps code readability and whatnot. However, AFAICS, it comes with a serious problem. Immutable objects are freely passable between threads, so surely an immutable RC object would need atomic counting just like a shared RC object, but unlike shared, immutable does not necessarily express the intent of sharing between threads; the immutable RC object could easily be counting atomically for nothing. Argh! I didn't think about this. Any chance we can deprecate this behaviour? It's also an obstacle for the implementation of thread-local heaps. There might be other problems, such as problems regarding ROM. Not if the RC wrapper allocated the memory in the first place. It knows that it can't be in ROM.
Re: DIP74 updated with new protocol for function calls
On Sunday, 1 March 2015 at 07:04:09 UTC, Zach the Mystic wrote:
class RcType {...}
void fun(RcType1 c, RcType1 d);
auto x = new RcType;
fun(x, x);
If the compiler were smart, it would realize that by splitting
parameters this way, it's actually adding an additional
reference to x. The function should get one x for free, and
then force an opAdd/opRelease, for every additional x (or x
derivative) it detects in the same call.
One more tidbit:
class RcType {
RcType r;
...
}
void fun(RcType x, RcType y);
auto z = new RcType;
z.r = new RcType;
fun(z, z.r);
From within fun(), z can alias z.r, but z.r can't possibly alias
z. Thus, only z.r needs to be preserved. The algorithm should go
For each parameter, add one ref/release cycle for every other
parameter which could possibly generate an alias to it.
We're approaching optimal here. This is feeling good to me.
ErrnoException in Windows
Could you, please, help me to understand, why code:
import std.c.windows.windows;
import std.exception: ErrnoException;
import std.stdio: writefln;
import std.string: toStringz;
void main ()
{
CreateFileA(toStringz(nonexisting file name), GENERIC_READ,
FILE_SHARE_READ, null, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL,
null);
auto ex = new ErrnoException(CreateFileA);
writefln(ex.errno=%d, ex.msg=%s, lasterror=%d, ex.errno,
ex.msg, GetLastError());
}
prints:
ex.errno=0, ex.msg=CreateFileA (No error), lasterror=2
I wanted it will be:
ex.errno=2, ex.msg=CreateFileA (File not found), lasterror=2
Re: ErrnoException in Windows
On Sunday, 1 March 2015 at 16:39:29 UTC, novice2 wrote:
I wanted it will be:
ex.errno=2, ex.msg=CreateFileA (File not found), lasterror=2
Here's the right way to do this:
// test.d //
import std.c.windows.windows;
import std.string : toStringz;
import std.windows.syserror : wenforce;
void main ()
{
auto handle = CreateFileA(toStringz(nonexisting),
GENERIC_READ, FILE_SHARE_READ, null, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
null);
wenforce(handle != INVALID_HANDLE_VALUE, CreateFileA);
}
See std.windows.syserror for more information.
Re: Making RCSlice and DIP74 work with const and immutable
On 2015-03-01 01:40:42 +, Andrei Alexandrescu said: Tracing garbage collection can afford the luxury of e.g. mutating data that was immutable during its lifetime. Reference counting needs to make minute mutations to data while references to that data are created. In fact, it's not mutation of the useful data, the payload of a data structure; it's mutation of metadata, additional information about the data (i.e. a reference count integral). The RCOs described in DIP74 and also RCSlice discussed in this forum need to work properly with const and immutable. Therefore, they need a way to reliably define and access metadata for a data structure. One possible solution is to add a @mutable or @metadata attribute similar to C++'s keyword mutable. Walter and I both dislike that solution because it's hamfisted and leaves too much opportunity for abuse - people can essentially create unbounded amounts of mutable payload for an object claimed to be immutable. That makes it impossible (or unsafe) to optimize code based on algebraic assumptions. We have a few candidates for solutions, but wanted to open with a good discussion first. So, how do you envision a way to define and access mutable metadata for objects (including immutable ones)? Store the metadata in a global hash table. There's a problem with reference counting immutable objects: they are implicitly shared. Any metadata attached to them thus needs to be shared. Accessing the metadata through a global shared hash table isn't going to be that much of a performance hit compared to whatever mechanism is used to synchronize access to that data. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Would Lcl be better if it was in D?
So I was using the Lazarus IDE the other day, and i thought to
myself, what if i create an application with only a button in it.
well it was easy enough to do. but behold I saw the executable
and it was 14 MB, and I said 'well damn.' It seems to me that
pascal does not do lazy inclusion when it comes to components of
Lcl apart from pre-compiler directives.
I noticed some includes in d are inside of functions.
void foo() {
import thingIneed:subfoo;
subfoo();
}
would this allow people to use a large library like LCL but with
much smaller executables?
Re: RCArray is unsafe
On 2015-03-01 19:21:57 +, Walter Bright said:
The trouble seems to happen when there are two references to the same
object passed to a function. I.e. there can be only one borrowed ref
at a time.
I'm thinking this could be statically disallowed in @safe code.
That's actually not enough. You'll have to block access to global
variables too:
S s;
void main() {
s.array = RCArray!T([T()]); // s.array's refcount is now 1
foo(s.array[0]); // pass by ref
}
void foo(ref T t) {
s.array = RCArray!T([]); // drop the old s.array
t.doSomething(); // oops, t is gone
}
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: Would Lcl be better if it was in D?
On Sunday, 1 March 2015 at 20:41:30 UTC, Taylor Hillegeist wrote:
So I was using the Lazarus IDE the other day, and i thought to
myself, what if i create an application with only a button in
it. well it was easy enough to do. but behold I saw the
executable and it was 14 MB, and I said 'well damn.' It seems
to me that pascal does not do lazy inclusion when it comes to
components of Lcl apart from pre-compiler directives.
I noticed some includes in d are inside of functions.
void foo() {
import thingIneed:subfoo;
subfoo();
}
would this allow people to use a large library like LCL but
with much smaller executables?
Sounds like you did a debug build.
Read this: http://wiki.freepascal.org/Size_Matters
