Re: core.stdc.fenv on Win64
On 7/16/2014 3:42 PM, Trass3r wrote:
The implementation doesn't seem to be correct.
Could anybody versed in this look into it?
version(Windows)
{
private extern __gshared fenv_t _FE_DFL_ENV;
fenv_t* FE_DFL_ENV = &_FE_DFL_ENV;
}
There's no such symbol in the libcmt and it fails to link.
http://sourceforge.net/p/mingw/mingw-org-wsl/ci/master/tree/include/fenv.h#l87
That code is for Win32 and was never ported properly for Win64. Please file a
bugzilla issue for it.
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
On 7/16/2014 1:12 PM, Johannes Pfau wrote: I'll take this as you pre-approve all the mentioned extensions? * way to disable typeinfo for struct Worth investigating. It'd probably be much more effective to work the linker angle of removing items for which no references exist. Martin was working on that, but his latest attempt had to be reverted, as it needed a new approach. * way to disable initializer T t = void; // no initialization * force inlining http://wiki.dlang.org/DIP56 (Note the author!) * (way to omit copy constructor function / force inline) I don't know what that means
Re: DIP65: Fixing Exception Handling Syntax
On Thursday, 17 July 2014 at 04:41:14 UTC, Walter Bright wrote: On 7/16/2014 4:04 PM, safety0ff wrote: On Wednesday, 9 July 2014 at 23:14:49 UTC, Brian Schott wrote: If I'm understanding this correctly, you want to deprecate the (somewhat popular) nameless exception syntax so that we can keep the "should be removed with prejudice" catch-everything syntax? Is this the bottom line? Is DIP65 formally rejected? ping... Unless a convincing counter argument emerges, yes. I'll just go over the existing arguments because I think they're strong enough: 1. LastCatch is (in the opinion of many people) a misfeature. 2. LastCatch syntax is not used in Phobos. 3. LastCatch syntax is very, very trivial to update with a "dfix" tool. 4. The unnamed exception syntax is used 25 places in Phobos. 5. Making the spec consistent with itself[1] introduces a parse ambiguity. This makes tooling D more difficult. [1] "If just type T is given and no variable v, then the catch clause is still executed." Previously I was just reading the grammar spec and didn't catch this, but it turns out that this syntax IS present in the spec and has been for many years. Your plan of deprecating this syntax will break FAR more code than my plan for correctly documenting it.
Re: DIP65: Fixing Exception Handling Syntax
On 7/16/2014 4:04 PM, safety0ff wrote: On Wednesday, 9 July 2014 at 23:14:49 UTC, Brian Schott wrote: If I'm understanding this correctly, you want to deprecate the (somewhat popular) nameless exception syntax so that we can keep the "should be removed with prejudice" catch-everything syntax? Is this the bottom line? Is DIP65 formally rejected? ping... Unless a convincing counter argument emerges, yes.
Re: DIP65: Fixing Exception Handling Syntax
On Wednesday, 9 July 2014 at 23:14:49 UTC, Brian Schott wrote: If I'm understanding this correctly, you want to deprecate the (somewhat popular) nameless exception syntax so that we can keep the "should be removed with prejudice" catch-everything syntax? Is this the bottom line? Is DIP65 formally rejected? ping...
core.stdc.fenv on Win64
The implementation doesn't seem to be correct.
Could anybody versed in this look into it?
version(Windows)
{
private extern __gshared fenv_t _FE_DFL_ENV;
fenv_t* FE_DFL_ENV = &_FE_DFL_ENV;
}
There's no such symbol in the libcmt and it fails to link.
http://sourceforge.net/p/mingw/mingw-org-wsl/ci/master/tree/include/fenv.h#l87
Re: Weird…
On Tuesday, 15 July 2014 at 18:28:14 UTC, Walter Bright wrote: On 7/15/2014 9:56 AM, Russel Winder via Digitalmars-d wrote: Funny how when people send big smiles, they always mention D? :-D :D Even more amazing, Germans all have "D" plastered on their cars! Although 'Schland start's with Sch*.
Re: Integer overflow and underflow semantics?
On 07/17/2014 12:18 AM, Walter Bright wrote: On 7/16/2014 2:26 PM, Gary Willoughby wrote: What is the current situation of integer overflow and underflow? https://github.com/D-Programming-Language/druntime/pull/839 (His question was whether there is wrap-around behaviour for signed types, which I think does not have a good answer at the moment.)
Re: Integer overflow and underflow semantics?
On 7/16/2014 2:26 PM, Gary Willoughby wrote: What is the current situation of integer overflow and underflow? https://github.com/D-Programming-Language/druntime/pull/839
Integer overflow and underflow semantics?
This was asked a few years ago and i could find a definitive answer. http://forum.dlang.org/thread/jo2c0a$31hh$1...@digitalmars.com On Saturday, 5 May 2012 at 04:57:48 UTC, Alex Rønne Petersen wrote: I don't think the language really makes it clear whether overflows and underflows are well-defined. Do we guarantee that for any integral type T, T.max + 1 == T.min and T.min - 1 == T.max? What is the current situation of integer overflow and underflow?
Re: D blog?
On Wednesday, 16 July 2014 at 19:00:42 UTC, Meta wrote: On Wednesday, 16 July 2014 at 17:00:16 UTC, Kiith-Sa wrote: On Wednesday, 16 July 2014 at 16:04:32 UTC, Meta wrote: On Wednesday, 16 July 2014 at 14:21:26 UTC, Dicebot wrote: On Wednesday, 16 July 2014 at 01:34:58 UTC, Kiith-Sa wrote: Just noticed this: http://blog.octayn.net/blog/2014/06/30/this-week-in-rust-54/ This is precisely the kind of thing we need. Huge amount of non-interesting effort. There was someone trying to do similar digest for D but effort seems to have stalled and I can totally see why. That was me. I ran into some ongoing school and life related issues on top of my current work. Right now all I have time for is some intermittent hacking in D, but I still do intend to get something going within the next few months. I think a monthly digest of news would be perfect for such a blog format. Can you post a link to those posts? http://forum.dlang.org/post/hjrrbeelwkbnhkbdm...@forum.dlang.org Thanks. I'm thinking about trying something similar but probably much less "professional", not regular, not focused on DMD/Phobos itself etc. (Of course, whether I actually end up doing it depends on time, I'm in a university too)
Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.
On Wednesday, 16 July 2014 at 19:51:39 UTC, H. S. Teoh via Digitalmars-d wrote: It's like saying that sorting, in general, cannot perform better than O(n log n), but the subset of sorting problems where the data is already almost sorted, there are algorithms that will perform better than O(n log n). The only problem is, they will suck when given data outside of that "easy" subset. Nah, it's like picking keys that allows you to use a trie. management problems. It doesn't change the fact, though, that when there is a mismatch, you're back in the "hard" set, and the problem is costly to solve no matter what algorithm you use. GC is always easier, sure.
Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.
On 07/16/2014 01:22 PM, Remo wrote: On Monday, 14 July 2014 at 23:43:57 UTC, H. S. Teoh via Digitalmars-d wrote: On Mon, Jul 14, 2014 at 11:22:53PM +, John Carter via Digitalmars-d wrote: [...] Any other good blog posts / social media comments / pointers I can digest and use? This one came to mind: http://bartoszmilewski.com/2013/09/19/edward-chands/ This is pretty bad promotion for Haskell. The Author of this post apparently do not know C++ well enough or just ignore this knowledge. That would be somewhat curious. http://www.amazon.com/In-Action-Industrial-Programming-Techniques/dp/0201699486 In any case, personal attacks are irrelevant and do not belong here. There are less intrusive ways of formulating this thought. Me as a C++ developer who likes Haskell (and D) after reading this I like C++ a bit more and Haskell a bit less. ... You are entitled to your opinion, but I'll still point out that taking disagreement with some piece of writing as evidence for the (assumed!) contrary is not a valid way of building a well-reasoned one. It’s a common but false belief that reference counting (using shared pointers in particular) is better than garbage collection. And then he pointed to a "A Unified Theory of Garbage Collection" paper where "reference counting" as a strategy (method) for a Garbage Collection will be disused. This is NOT the same as std::shared_ptr do ! ... This seems a little bit superficial; what would be a _rebuttal_ of his fundamental point?
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
On 07/16/14 22:09, Johannes Pfau via Digitalmars-d wrote: > Well I guess this is already decided anyway. Well, peek/poke is not the right solution either... > I think it's kinda ridiculous that D embedded code will only be usable > with strong optimization flags, but whatever. Maybe it works better Why would it be unusable without "strong optimization flags"? At -O0 the generated code will be so slow and bloated that it will be unusable in a constrained embedded environment. Yes, the implicitly generated asserts are a problem - but _this is not a problem specific to volatile_. Ditto for RTTI, unwinding tables, dead code etc. Those issues needs to be dealt with anyway. artur
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
Am Wed, 16 Jul 2014 11:49:21 -0700 schrieb Walter Bright : > On 7/16/2014 7:14 AM, Daniel Murphy wrote: > > Intrinsics get us away from our current 'there is no portable way > > to do this' situation. They are _trivial_ to implement for any of > > the compilers. I have complete faith that it is possible to make a > > performant wrapper for both the single-register read/write and the > > struct pattern you posted. And if I'm wrong > > - we can add a volatile type modifier later! > > I'll add that if it turns out we can't do a wrapper because of some > limitations/bugs in D's expressiveness, that is the problem with D we > need to fix, not adding another type modifier. > > It all comes down to leverage. Making user defined types more capable > has far, far more productive leverage than welding specifics into the > compiler. > I'll take this as you pre-approve all the mentioned extensions? * way to disable typeinfo for struct * way to disable initializer * force inlining * (way to omit copy constructor function / force inline)
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
Am Wed, 16 Jul 2014 21:59:57 +0200
schrieb Artur Skawina via Digitalmars-d :
> On 07/16/14 15:02, Johannes Pfau via Digitalmars-d wrote:
> > Am Tue, 15 Jul 2014 19:44:51 +0200
> > schrieb Artur Skawina via Digitalmars-d
> > :
> >
> >> Could you show one (concrete) example where using 'volatile' is
> >> better than my approach?
> >
> > I experimented a little more with Volatile!T and I don't think you
> > can make this example work:
> >
> > struct Timer
> > {
> > uint control;
> > uint data;
> > }
> >
> > enum timerA = (Volatile!Timer)* = cast()0xDEADBEAF;
> >
> > timerA.control |= 0b1;
>
> Thank you very much for showing actual code. There are many (wrong)
> assumptions being made in this thread (and the one on the gdc list).
> Claims like "A is required" or "B is impossible", where A and B are
> not actually defined and only vaguely described, do not usually lead
> to a productive dialogue. Concrete examples and code make it possible
> for the discussion to be about facts and not perceptions.
>
>struct Timer
>{
>uint control;
>uint data;
>}
>
>enum timerA = cast(Volatile!(Timer)*)0xDEADBEAF;
>//enum timerA = volatile_(cast(Timer*)0xDEADBEAF); // works too.
>
>void main() {
> timerA.control |= 0b1;
>}
>
>struct Volatile(PT) {
> PT raw;
>
> auto opDispatch(string M)() @property { return
> volatile_(mixin(q{&raw.}~M)); }
>
> auto opOpAssign(string OP, B)(B b) {
> auto a = load(*raw);
> auto r = mixin("a "~OP~" b");
> store(*raw, r);
> return this;
> }
>
>static:
> T load(T)(ref T v) {
> asm { "" : "+m" v; }
> T res = v;
> asm { "" : "+g" res; }
> return res;
> }
>
> T store(T)(ref T v, const T a) {
> asm { "" : : "m" v; }
> v = a;
> asm { "" : "+m" v; }
> return a;
> }
>}
>auto volatile_(A)(A a) { return Volatile!A(a); } // Just for IFTI.
>
>
> when compiled w/ "gdc -O1" results in
>
> 00402949 <_Dmain>:
> 402949: b8 af be ad de mov$0xdeadbeaf,%eax
> 40294e: 8b 10 mov(%rax),%edx
> 402950: 83 ca 01or $0x1,%edx
> 402953: 89 10 mov%edx,(%rax)
> 402955: b8 00 00 00 00 mov$0x0,%eax
> 40295a: c3 retq
>
> which is the exact op sequence you'd expect. Doing it as just one
> R-M-W op would be possible too, but that might not be supported by
> all HW/platforms.
> And, yes, gdc inlines it even at -O0, if @inline is used. But at -O0
> the generated code is /already/ huge and inefficient, hence not really
> usable in constrained mem environments.
>
> Obviously, this is just a proof of concept and the minimal
> implementation that can only handle your example. But it's enough to
> disprove the it-cannot-be-made-to-work-without-c-volatile claim. Are
> there any other examples of things that cannot be efficiently handled
> w/o a built-in volatile type qualifier?
>
> artur
Well I guess this is already decided anyway.
I think it's kinda ridiculous that D embedded code will only be usable
with strong optimization flags, but whatever. Maybe it works better
if the usage is restricted to basic types only.
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
On 07/16/14 15:02, Johannes Pfau via Digitalmars-d wrote:
> Am Tue, 15 Jul 2014 19:44:51 +0200
> schrieb Artur Skawina via Digitalmars-d :
>
>> Could you show one (concrete) example where using 'volatile' is better
>> than my approach?
>
> I experimented a little more with Volatile!T and I don't think you can
> make this example work:
>
> struct Timer
> {
> uint control;
> uint data;
> }
>
> enum timerA = (Volatile!Timer)* = cast()0xDEADBEAF;
>
> timerA.control |= 0b1;
Thank you very much for showing actual code. There are many (wrong)
assumptions being made in this thread (and the one on the gdc list).
Claims like "A is required" or "B is impossible", where A and B are
not actually defined and only vaguely described, do not usually lead
to a productive dialogue. Concrete examples and code make it possible
for the discussion to be about facts and not perceptions.
struct Timer
{
uint control;
uint data;
}
enum timerA = cast(Volatile!(Timer)*)0xDEADBEAF;
//enum timerA = volatile_(cast(Timer*)0xDEADBEAF); // works too.
void main() {
timerA.control |= 0b1;
}
struct Volatile(PT) {
PT raw;
auto opDispatch(string M)() @property { return
volatile_(mixin(q{&raw.}~M)); }
auto opOpAssign(string OP, B)(B b) {
auto a = load(*raw);
auto r = mixin("a "~OP~" b");
store(*raw, r);
return this;
}
static:
T load(T)(ref T v) {
asm { "" : "+m" v; }
T res = v;
asm { "" : "+g" res; }
return res;
}
T store(T)(ref T v, const T a) {
asm { "" : : "m" v; }
v = a;
asm { "" : "+m" v; }
return a;
}
}
auto volatile_(A)(A a) { return Volatile!A(a); } // Just for IFTI.
when compiled w/ "gdc -O1" results in
00402949 <_Dmain>:
402949: b8 af be ad de mov$0xdeadbeaf,%eax
40294e: 8b 10 mov(%rax),%edx
402950: 83 ca 01or $0x1,%edx
402953: 89 10 mov%edx,(%rax)
402955: b8 00 00 00 00 mov$0x0,%eax
40295a: c3 retq
which is the exact op sequence you'd expect. Doing it as just one
R-M-W op would be possible too, but that might not be supported by
all HW/platforms.
And, yes, gdc inlines it even at -O0, if @inline is used. But at -O0
the generated code is /already/ huge and inefficient, hence not really
usable in constrained mem environments.
Obviously, this is just a proof of concept and the minimal implementation
that can only handle your example. But it's enough to disprove the
it-cannot-be-made-to-work-without-c-volatile claim. Are there any other
examples of things that cannot be efficiently handled w/o a built-in
volatile type qualifier?
artur
Re: Using D
Am 16.07.2014 21:26, schrieb "Ola Fosheim Grøstad"
":
On Wednesday, 16 July 2014 at 17:18:11 UTC, Paulo Pinto wrote:
Apple is stating that Swift is a C replacement ("Swift is a successor
to the C and Objective-C languages." -
https://developer.apple.com/swift/).
"Swift is an innovative new programming language for Cocoa and Cocoa
Touch." and "Swift is a successor to the C and Objective-C languages. It
includes low-level primitives such as types, flow control, and
operators." Yes, that's low level!
Swift is Objective-C in a new dress, but not a system level programming
language (and neither is Objective-C IMHO). It is an application level
language for Cocoa frameworks.
Just like ANSI C without the usual set of language extensions.
Having done system programming in Turbo Pascal and Oberon, I guess I
don't seek C like features in system programming languages.
--
Paulo
Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.
On Wed, Jul 16, 2014 at 07:14:25PM +, via Digitalmars-d wrote: > On Wednesday, 16 July 2014 at 18:24:11 UTC, H. S. Teoh via Digitalmars-d > wrote: > >They are just duals of each other, and optimized GC/RC algorithms > >tend to approach the middle ground, with time/memory tradeoffs as an > >adjustable parameter. > > Not really. If you are performance conscious you structure your data > and algorithms to match the tools you are using. [...] Well, yes, so what we're saying here is that the set of general memory management problems is hard to solve, but if we can rewrite our program so that its particular instance of memory management lies in an "easy" subset for which there are known superior solutions, then performance will be better. This doesn't invalidate the fact that the *general* memory management problem is hard. It's like saying that sorting, in general, cannot perform better than O(n log n), but the subset of sorting problems where the data is already almost sorted, there are algorithms that will perform better than O(n log n). The only problem is, they will suck when given data outside of that "easy" subset. Is it possible to transform given any arbitrary program into an equivalent program whose particular instance of memory management lies in the "easy" subset? I don't know. But even if it's possible, you still have to "pay" for the cost of memory management -- this time by paying with program structure rather than runtime performance: you will have to constrain the way you write the program, otherwise you will have to deal with a memory management problem instance outside the "easy" set. This leads back to my idea of some kind of structural matching between memory lifetime and program structure. If you can somehow structure your program such that it corresponds with the structure of its memory usage patterns, then you're in an "easy" subset of the set of general memory management problems. It doesn't change the fact, though, that when there is a mismatch, you're back in the "hard" set, and the problem is costly to solve no matter what algorithm you use. T -- MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs
Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.
Yes, and my point was that you pay for the (implicit) deallocation by the need to copy all live objects. The cost of copying is not zero compared to a non-copying GC. No matter how you do it, the cost has to be paid *somewhere*. It's just a question of which method will be less costly based on what your application does. The cost models are vastly different and as you finally note application dependent. *The* cost does not have to paid *somewhere* because there is not a single cost to begin with.
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
On 7/16/2014 12:10 PM, Iain Buclaw via Digitalmars-d wrote: By the way, it's 'so-called' bugs like this that make we want to remove any notion of volatile from shared. Right.
Re: Using D
On Wednesday, 16 July 2014 at 17:18:11 UTC, Paulo Pinto wrote:
Apple is stating that Swift is a C replacement ("Swift is a
successor to the C and Objective-C languages." -
https://developer.apple.com/swift/).
"Swift is an innovative new programming language for Cocoa and
Cocoa Touch." and "Swift is a successor to the C and Objective-C
languages. It includes low-level primitives such as types, flow
control, and operators." Yes, that's low level!
Swift is Objective-C in a new dress, but not a system level
programming language (and neither is Objective-C IMHO). It is an
application level language for Cocoa frameworks.
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
On 7/16/2014 5:59 AM, Johannes Pfau wrote:
And how do you implement this with a wrapper? This is common in C/C++:
struct Timer
{
uint control;
uint data;
}
enum timerA = (Volatile!Timer)* = cast()oxDEADBEAF;
timerA.control |= 0b1;
auto timerA = VolatileStruct!Timer(0xDEADBEAF);
timerA.control |= 1;
i.e. with introspection, the template can automatically generate the
getters/setters and operator overloads.
The more I think about it the more corner cases appear. After all
implementing this in the library is much more complex than a type
qualifier. Some of the complexity is already implemented (alias
this, ...) so there's less changes in DMD. But any bug in alias this,
templates, etc will immediately leak into Volatile!T.
It's true that VolatileStruct will be more complex than the average template.
But it's quite doable, and the user won't see that complexity.
The point is it is not perfectly safe. There is no definition, and
certainly no portable definition, as to how many read/write cycles
such an operation entails. That's what I meant, and DIP62 says pretty
much said the same thing. Please allow me to quote:
In cases where you use |= the exact number of accesses usually does not
matter. What matters is that there's at least one access and that it's
not reordered with other reads/writes to volatile.
I understand, but the pedantic in me notes the word "usually".
For example |= is used on control registers. But I don't care if I
read/set the bit twice or once, I just doesn't matter.
I understand that it usually does not matter. But sometimes it does. It should
be under user control rather than "whatever the compiler does" which can change
with optimization settings. C compiler semantics for volatile are
"implementation defined", which pretty much means "random".
And what does peek/poke guarantee in that case?
It guarantees semantics for (A op= B) to be (A = A op B).
One important point is that this must be as effective as
c+volatile (in terms of code size and execution cycles). This is an
important aspect for embedded programming
I fully agree.
and it'll take ages and many
language changes to make a type wrapper as efficient.
This is unduly pessimistic.
If it's even possible at all.
I see no reason to quit before we start.
That is not what I'm saying at all. Please do not conflate
disagreement about the best way to achieve a goal with disagreement
about the goal.
So you do think peek/poke is a better solution than DIP62? Then you
have to explain this. All arguments so far have been it's too
complex in the compiler implementation, but never that peek/poke is a
better way to achieve that goal of accessing volatile memory.
In the end it's a judgement call between complexity and more
convenience for embedded programming and it's absolutely your decision.
But as long as I'm not convinced that peek/poke is a _better_ solution
I'll think that embedded programming is not important enough for you to
implement the _best_ solution, as it causes some implementation
complexity. And this in the end means it's of lower priority to you
than keeping some complexity out of the compiler.
I think it unfair to impute motives when I've specifically said otherwise.
I understand that you and others put a lot of work into DIP62. As I
said before, it's a very nice example of a well-done DIP.
That's not the point.
I think it is fair to acknowledge the good work you've done.
If I were convinced there's a better solution,
I'd be glad to accept it. But I'm not convinced at all, the only
argument against DIP62 so far was complexity.
Complexity is not a minor issue. Complexity means time and bugs. I am all too
familiar with how volatile in C++ has been costly in a lot of effort, bugs,
specification, and code that had no use for volatile, yet had to account for it.
BTW, testing of "volatile" behavior in the compiler is problematic as there just
doesn't seem to be a reasonable way to do it. This engenders a regular risk of
compiler breakage, and shows up to the end user as erratic behavior and lots of
cursing at the compiler vendor.
Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.
On Wednesday, 16 July 2014 at 17:18:56 UTC, Kagamin wrote: On Wednesday, 16 July 2014 at 11:22:45 UTC, Remo wrote: And then he pointed to a "A Unified Theory of Garbage Collection" paper where "reference counting" as a strategy (method) for a Garbage Collection will be disused. This is NOT the same as std::shared_ptr do ! How std::shared_ptr manages cycles? There is std::weak_ptr to handle cycles. http://en.cppreference.com/w/cpp/memory/weak_ptr The only question is how often one need to handle cycles ? Using GC is probably easier as shared_ptr in some case. But in many other cases only lightweight and deterministic unique_ptr is required. Apparently in Rust one can decide what to use. Box the same as std::unique_ptr in C++. Rc is something like std::shared_ptr in C++ but not exactly the same. But there are also Gc (Immutable garbage-collected pointer) and Arc without counterparts in C++ at this time.
Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.
On Wed, Jul 16, 2014 at 07:02:15PM +, Araq via Digitalmars-d wrote: > On Wednesday, 16 July 2014 at 18:24:11 UTC, H. S. Teoh via Digitalmars-d > wrote: > >On Wed, Jul 16, 2014 at 06:11:54PM +, Araq via Digitalmars-d wrote: > >>On Wednesday, 16 July 2014 at 16:57:18 UTC, Kagamin wrote: > >>>On Tuesday, 15 July 2014 at 20:44:35 UTC, H. S. Teoh via >Digitalmars-d > >>>wrote: > Not to mention, when you need to deallocate a large complex >>data > structure, *somebody* has to do the work -- either you do it > yourself, or the reference counting implementation, or the >>GC. > >>> > >>>The first and the last options are still prominent. > >> > >>A copying GC copies the live data, deallocation of a large complex > >>data structure is free in this scenario. Same if you use a manually > >>managed memory region for the data structure and then deallocate the > >>region via some batch operation. But hey, this simple fact must be > >>wrong because some guy read a single paper about GCs that doesn't > >>even cover this point. > > > >Have you even read the paper? What you just said is exactly what the > >paper is describing. There are two ends of the spectrum of memory > >reclamation algorithms, at one end, you're tracing "matter" (live > >objects), and the other end you're tracing "antimatter" (dead > >objects). They are just duals of each other, and optimized GC/RC > >algorithms tend to approach the middle ground, with time/memory > >tradeoffs as an adjustable parameter. > > The paper focusses on RC vs "tracing". My point is "tracing" vs > "copying" is another tradeoff. Here is a mark&sweep algorithm: > > - Trace live objects. > - For each dead object: Deallocate. > > Here is a copying GC: > > - Trace and copy live objects. > - There is no deallocation step. The old region is free for further usage. Yes, and my point was that you pay for the (implicit) deallocation by the need to copy all live objects. The cost of copying is not zero compared to a non-copying GC. No matter how you do it, the cost has to be paid *somewhere*. It's just a question of which method will be less costly based on what your application does. T -- Too many people have open minds but closed eyes.
Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.
On Wednesday, 16 July 2014 at 18:24:11 UTC, H. S. Teoh via Digitalmars-d wrote: They are just duals of each other, and optimized GC/RC algorithms tend to approach the middle ground, with time/memory tradeoffs as an adjustable parameter. Not really. If you are performance conscious you structure your data and algorithms to match the tools you are using. Therefore performance oriented RC outperforms GC. You can have a lot more special-casing with RC in a realistic implementation. Few application authors consider rewriting the GC, but doing your own minimal overhead specialized RC is quite common…
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
On 16 July 2014 20:03, Iain Buclaw wrote: > On 16 July 2014 19:58, Walter Bright via Digitalmars-d > wrote: >> On 7/16/2014 7:31 AM, Iain Buclaw via Digitalmars-d wrote: They are _trivial_ to implement for any of the compilers. >>> >>> No they aren't, unless you are talking specifically about volatile., >>> >>> in which case, that depends... >> >> >> If the compiler back end doesn't support volatile, then it's a problem >> regardless of how the front end handles it, so the point is moot. >> >> In any case, the compiler front end can always implement an intrinsic by >> just calling a function. >> >> > > I was thinking: > http://bugzilla.gdcproject.org/show_bug.cgi?id=84 By the way, it's 'so-called' bugs like this that make we want to remove any notion of volatile from shared. Regards Iain
Re: D blog?
On Wednesday, 16 July 2014 at 17:00:16 UTC, Kiith-Sa wrote: On Wednesday, 16 July 2014 at 16:04:32 UTC, Meta wrote: On Wednesday, 16 July 2014 at 14:21:26 UTC, Dicebot wrote: On Wednesday, 16 July 2014 at 01:34:58 UTC, Kiith-Sa wrote: Just noticed this: http://blog.octayn.net/blog/2014/06/30/this-week-in-rust-54/ This is precisely the kind of thing we need. Huge amount of non-interesting effort. There was someone trying to do similar digest for D but effort seems to have stalled and I can totally see why. That was me. I ran into some ongoing school and life related issues on top of my current work. Right now all I have time for is some intermittent hacking in D, but I still do intend to get something going within the next few months. I think a monthly digest of news would be perfect for such a blog format. Can you post a link to those posts? http://forum.dlang.org/post/hjrrbeelwkbnhkbdm...@forum.dlang.org
Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.
On Wednesday, 16 July 2014 at 18:24:11 UTC, H. S. Teoh via Digitalmars-d wrote: On Wed, Jul 16, 2014 at 06:11:54PM +, Araq via Digitalmars-d wrote: On Wednesday, 16 July 2014 at 16:57:18 UTC, Kagamin wrote: >On Tuesday, 15 July 2014 at 20:44:35 UTC, H. S. Teoh via >Digitalmars-d >wrote: >>Not to mention, when you need to deallocate a large complex >>data >>structure, *somebody* has to do the work -- either you do it >>yourself, or the reference counting implementation, or the >>GC. > >The first and the last options are still prominent. A copying GC copies the live data, deallocation of a large complex data structure is free in this scenario. Same if you use a manually managed memory region for the data structure and then deallocate the region via some batch operation. But hey, this simple fact must be wrong because some guy read a single paper about GCs that doesn't even cover this point. Have you even read the paper? What you just said is exactly what the paper is describing. There are two ends of the spectrum of memory reclamation algorithms, at one end, you're tracing "matter" (live objects), and the other end you're tracing "antimatter" (dead objects). They are just duals of each other, and optimized GC/RC algorithms tend to approach the middle ground, with time/memory tradeoffs as an adjustable parameter. The paper focusses on RC vs "tracing". My point is "tracing" vs "copying" is another tradeoff. Here is a mark&sweep algorithm: - Trace live objects. - For each dead object: Deallocate. Here is a copying GC: - Trace and copy live objects. - There is no deallocation step. The old region is free for further usage.
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
On 16 July 2014 19:58, Walter Bright via Digitalmars-d wrote: > On 7/16/2014 7:31 AM, Iain Buclaw via Digitalmars-d wrote: >>> >>> They are _trivial_ to implement for any of the compilers. >> >> No they aren't, unless you are talking specifically about volatile., >> >> in which case, that depends... > > > If the compiler back end doesn't support volatile, then it's a problem > regardless of how the front end handles it, so the point is moot. > > In any case, the compiler front end can always implement an intrinsic by > just calling a function. > > I was thinking: http://bugzilla.gdcproject.org/show_bug.cgi?id=84
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
On 7/16/2014 7:31 AM, Iain Buclaw via Digitalmars-d wrote: They are _trivial_ to implement for any of the compilers. No they aren't, unless you are talking specifically about volatile., in which case, that depends... If the compiler back end doesn't support volatile, then it's a problem regardless of how the front end handles it, so the point is moot. In any case, the compiler front end can always implement an intrinsic by just calling a function.
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
On 7/16/2014 7:14 AM, Daniel Murphy wrote: Intrinsics get us away from our current 'there is no portable way to do this' situation. They are _trivial_ to implement for any of the compilers. I have complete faith that it is possible to make a performant wrapper for both the single-register read/write and the struct pattern you posted. And if I'm wrong - we can add a volatile type modifier later! I'll add that if it turns out we can't do a wrapper because of some limitations/bugs in D's expressiveness, that is the problem with D we need to fix, not adding another type modifier. It all comes down to leverage. Making user defined types more capable has far, far more productive leverage than welding specifics into the compiler.
Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.
On Wed, Jul 16, 2014 at 06:11:54PM +, Araq via Digitalmars-d wrote: > On Wednesday, 16 July 2014 at 16:57:18 UTC, Kagamin wrote: > >On Tuesday, 15 July 2014 at 20:44:35 UTC, H. S. Teoh via Digitalmars-d > >wrote: > >>Not to mention, when you need to deallocate a large complex data > >>structure, *somebody* has to do the work -- either you do it > >>yourself, or the reference counting implementation, or the GC. > > > >The first and the last options are still prominent. > > A copying GC copies the live data, deallocation of a large complex > data structure is free in this scenario. Same if you use a manually > managed memory region for the data structure and then deallocate the > region via some batch operation. But hey, this simple fact must be > wrong because some guy read a single paper about GCs that doesn't even > cover this point. Have you even read the paper? What you just said is exactly what the paper is describing. There are two ends of the spectrum of memory reclamation algorithms, at one end, you're tracing "matter" (live objects), and the other end you're tracing "antimatter" (dead objects). They are just duals of each other, and optimized GC/RC algorithms tend to approach the middle ground, with time/memory tradeoffs as an adjustable parameter. T -- People tell me that I'm paranoid, but they're just out to get me.
Re: Ambiguous mangling of symbols declared in nested scopes
On Wed, Jul 16, 2014 at 05:36:45PM +, Ivan Kazmenko via Digitalmars-d wrote: > On Wednesday, 16 July 2014 at 17:24:27 UTC, H. S. Teoh via Digitalmars-d > wrote: > >Today I was investigating this bug: > > > >https://issues.dlang.org/show_bug.cgi?id=10619 > > > >and found that the problem appears to be an ambiguous mangling of > >local variables declared in nested scopes. <...> > > Amazing how such a bug survived until now! Well, I found out about it last year and filed a bug, but it seems to have escaped everyone's attention. Prior to that, a friend of mine who occasionally dabbles in D has seen the problem, I don't know how long ago. It makes me wonder if others may have seen it too, but only haven't spoken up about it. :-/ In any case, I've been wanting to familiarize myself more with dmd code, so this is as good an opportunity as any other. Plus, I'm tired of waiting around for somebody more familiar with dmd to take notice, so I decided that I'm gonna do something about it myself, even if it means taking longer 'cos right now I've no idea what I'm doing. :-P > Can all (meaningful) scopes of a module be numbered internally to > distinguish them? Some way, like lambdas are. Or is it too much of a > change? > If they can, the scope's unique ID can then go into the mangled name. [...] Ultimately we'll have to do something like that, I think, since I can't think of any other way to disambiguate between all these local variables. But maybe some of the DMD experts can speak up about this. ;-) T -- Freedom: (n.) Man's self-given right to be enslaved by his own depravity.
Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.
On Wednesday, 16 July 2014 at 16:57:18 UTC, Kagamin wrote: On Tuesday, 15 July 2014 at 20:44:35 UTC, H. S. Teoh via Digitalmars-d wrote: Not to mention, when you need to deallocate a large complex data structure, *somebody* has to do the work -- either you do it yourself, or the reference counting implementation, or the GC. The first and the last options are still prominent. A copying GC copies the live data, deallocation of a large complex data structure is free in this scenario. Same if you use a manually managed memory region for the data structure and then deallocate the region via some batch operation. But hey, this simple fact must be wrong because some guy read a single paper about GCs that doesn't even cover this point.
Re: Weird…
On 7/15/2014 3:56 PM, Robert burner Schadek wrote: On Tuesday, 15 July 2014 at 18:28:14 UTC, Walter Bright wrote: Even more amazing, Germans all have "D" plastered on their cars! So we don't forget were we are :D That's always been my preferred explanation for Americans posting US flags on their houses and cars. :) "Uhh, yes, I'm well aware what country I'm in. I'm not THAT drunk..."
Re: Ambiguous mangling of symbols declared in nested scopes
On Wednesday, 16 July 2014 at 17:24:27 UTC, H. S. Teoh via Digitalmars-d wrote: Today I was investigating this bug: https://issues.dlang.org/show_bug.cgi?id=10619 and found that the problem appears to be an ambiguous mangling of local variables declared in nested scopes. <...> Amazing how such a bug survived until now! Can all (meaningful) scopes of a module be numbered internally to distinguish them? Some way, like lambdas are. Or is it too much of a change? If they can, the scope's unique ID can then go into the mangled name. Ivan Kazmenko.
Ambiguous mangling of symbols declared in nested scopes
Today I was investigating this bug:
https://issues.dlang.org/show_bug.cgi?id=10619
and found that the problem appears to be an ambiguous mangling of local
variables declared in nested scopes. For example, given this code:
import std.stdio;
void myFunc(alias Sym)()
{
writeln(Sym);
}
void main()
{
{
{
int x = 789;
myFunc!x();
}
int x = 456;
myFunc!x();
}
int x = 123;
myFunc!x();
}
The expected output is:
789
456
123
However, the actual output is:
789
789
789
Checking the compiler output, myFunc is only instantiated once, with the
mangled name:
_D4test31__T6myFuncS17_D4test4mainFZ1xiZ6myFuncMFZv
This name is ambiguous, since there is no way to distinguish between the
three different instances of 'x' in main(). So it seems that the
compiler conflates them into a single function, even though they should
be 3 distinct ones.
Interestingly enough, moving the nested blocks to after the outer
block's 'x' is declared will trigger a variable shadowing error, but in
the above code, there is actually no shadowing since the inner 'x' is
already out of scope by the time the outer 'x' is declared, so it's
ostensibly legal code.
The question then is, how should we fix this bug? Outlaw the above code?
Or change the mangling scheme to uniquely identify local variables
declared in nested blocks?
P.S. Hmph, looks like we're going to have to go with the second route,
because the following clearly-legal code is broken:
import std.stdio;
void myFunc(alias Sym)()
{
pragma(msg, myFunc.mangleof);
writeln(Sym);
}
void main()
{
foreach (i; 0..3) {
myFunc!i();
}
foreach (i; 5..8) {
myFunc!i();
}
}
Output:
0
1
2
2
2
2
Notice how the second invocation of myFunc appears to reference the
first, out-of-scope, 'i'. Moreover, 'i' is local to both scopes, so we
*can't* outlaw this usage!
So looks like we'll have to change the mangling scheme of templates with
alias arguments to local variables.
T
--
"No, John. I want formats that are actually useful, rather than
over-featured megaliths that address all questions by piling on
ridiculous internal links in forms which are hideously over-complex." --
Simon St. Laurent on xml-dev
Re: Using D
Am 16.07.2014 17:39, schrieb Vic:
On Monday, 14 July 2014 at 10:13:43 UTC, Chris wrote:
On Saturday, 12 July 2014 at 10:27:12 UTC, Russel Winder via
I think we need to address these issues, because they are of a
psychological nature and not really language issues. I'm sure that if
we fixed GC and had the best implementation ever, people would find
something else to complain about "D doesn't have blah, I don't like it!"
I'm sort of getting the idea that D goal would to be a better Java.
I'm running away from Java (after 10 years). I hope that someone at D
has power and can say NO to a feature the way Linus does as opposed to
adding more 'JCP' features, pushing such stuff downstream. Adding more
features to be good at everything, aka a submarine that is a law mover.
It's all done w/ best intentions. But forcing GC into base library of a
system programing language? Maybe D is not a system programing language,
but a enterprise app productivity lang. At least give us a choice, to
use D why do I have to re-write the base lib.
Cheers, Vic
Yes, it has been done many times before.
Starting at Xerox PARC, those beautiful systems were many ideas of the
modern web were pioneered.
Interlisp-D, Smalltalk and Mesa/Cedar, all had a mix of RC/GC.
Olivetti was playing around with Modula-3 with the SPIN OS, before
Digital closed their R&D unit.
Niklaus Wirth and his colleagues created Oberon at the Swiss Federal
Institute of Technology, which was an workable desktop OS used by a few
at the informatics department and OS research topics, specially version
System 3 with its gadgest toolkit. This spunned quite a few derivatives
namely EthOS and AOS. Active Oberon on AOS already offered a concurrent
compiler before that was a theme.
Microsoft created Singularity with Sing#. Although the project was
cancelled, many of its outcomes live on WP8 native compiler and on the
upcoming .NET Native.
Apple is stating that Swift is a C replacement ("Swift is a successor to
the C and Objective-C languages." - https://developer.apple.com/swift/).
We just need a successful mainstream OS vendor to push a RC/GC enabled
systems language to anyone targeting their OS, to finally break the
stigma that GC enabled systems programming languages don't leave the
research lab.
--
Paulo
Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.
On Wednesday, 16 July 2014 at 11:22:45 UTC, Remo wrote: And then he pointed to a "A Unified Theory of Garbage Collection" paper where "reference counting" as a strategy (method) for a Garbage Collection will be disused. This is NOT the same as std::shared_ptr do ! How std::shared_ptr manages cycles?
Re: Random points from a D n00b CTO
On Wednesday, 16 July 2014 at 16:10:30 UTC, Kiith-Sa wrote: Qt is an excellent framework, but pretty much completely irrelevant to memory management. Its object trees and refcounted containers are convenient for conventional programs, but if you are doing want to extract decent performaare with 100's of gigs, you'll need custom memory management, whether with D or Qt/C++ (and just like *some* parts of Phobos, Qt locks you into is types and whatever memory management they use. STL would make more sense but afaik it's allocator interface is quite a PITA) Thx Kiith.
Re: D blog?
On Wednesday, 16 July 2014 at 16:04:32 UTC, Meta wrote: On Wednesday, 16 July 2014 at 14:21:26 UTC, Dicebot wrote: On Wednesday, 16 July 2014 at 01:34:58 UTC, Kiith-Sa wrote: Just noticed this: http://blog.octayn.net/blog/2014/06/30/this-week-in-rust-54/ This is precisely the kind of thing we need. Huge amount of non-interesting effort. There was someone trying to do similar digest for D but effort seems to have stalled and I can totally see why. That was me. I ran into some ongoing school and life related issues on top of my current work. Right now all I have time for is some intermittent hacking in D, but I still do intend to get something going within the next few months. I think a monthly digest of news would be perfect for such a blog format. Can you post a link to those posts?
Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.
On Tuesday, 15 July 2014 at 20:44:35 UTC, H. S. Teoh via Digitalmars-d wrote: Not to mention, when you need to deallocate a large complex data structure, *somebody* has to do the work -- either you do it yourself, or the reference counting implementation, or the GC. The first and the last options are still prominent.
Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.
On Wednesday, 16 July 2014 at 10:13:44 UTC, Chris wrote: The problem you described above is omnipresent. Objective-C has autorelease, in plain C programs one has to be careful where and when to free what, etc. I was wondering after reading your post, whether it would be possible to have an automatic memory management system that could help to create a 1-1-match, or if even the compiler + language features could help to _easily_ achieve that. Of course. Allocating something on the stack and passing around pointers to it is safe iff you can guarantee that all the pointers to it are gone once you leave the stack frame (actually the variables scope). This is what is currently being discussed in the parallel thread(s) about borrowing with `scope`. Maybe the copy approach mentioned earlier points into that direction. Anyway, I think you are on to something here. Maybe the solution is not a hyper-super-waterproof GC algorithm (that will never be achieved, I guess, in any language), but eliminating the need to collect the garbage as much as possible. +1 Borrowing makes it possible to do this safely, and in addition, enables crucial performance optimizations for reference counting, when it is needed.
Re: D blog?
On Wednesday, 16 July 2014 at 14:21:26 UTC, Dicebot wrote: On Wednesday, 16 July 2014 at 01:34:58 UTC, Kiith-Sa wrote: Just noticed this: http://blog.octayn.net/blog/2014/06/30/this-week-in-rust-54/ This is precisely the kind of thing we need. Huge amount of non-interesting effort. There was someone trying to do similar digest for D but effort seems to have stalled and I can totally see why. It serves as a single, compact source with quick access to what happened in the last $TIME_PERIOD and make it visible for people outside of the core community (can be put on reddit, hackernews, etc.). It is much more "interesting" that having to search the newsgroup or GitHub for news. I think the main important thing is "what happened in the community", i.e. projects, articles/books/tutorials and such; for presenting D news (again, outside of core community) 1 digest with links is better than 10 small announcements for niche projects. Data such as 'new committers', etc is much less useful. What is useful is mentioning big feature changes going to the next release or fixes to major bugs.
Re: D logo copyright
On Wednesday, 16 July 2014 at 08:16:56 UTC, Sönke Ludwig wrote: BTW, the shape of the logo itself isn't covered by either copyright, or "Urheberrecht", AFAIK. That's what trademarks are for. So a full redo of the logo should be unaffected by the original work. Of course it would still be fair to properly negotiate with the original author... The composed shape is covered by copyright if you don't arrive at it independently... Which is unlikely for dlang.org. No different than a melody. But all you need is to get written permission to modify it and use it for promoting commercial products related to D as covered by dlang.org without compensation. No reason to make it complex.
Re: D logo copyright
On Wednesday, 16 July 2014 at 14:54:26 UTC, Alix Pexton wrote: I'm optimistic that this can all be resolved without having to get any lawyers involved, but it is a shame that the intersection of D-users and international-copyright-lawyers seems to have a cardinality of zero. A... This is probably one of those things that a lawyer should at lest consulted on. Not saying people here are not capable, but this is one of those things that needs to be done right.
Re: Continuous integration testing with travis and drone
Hi Pavel! On Wednesday, 16 July 2014 at 03:30:18 UTC, Pavel Evstigneev wrote: I want to share how I made testing for some open source project. I try with http://travis-ci.org and http://drone.io [...] **For travis ci:** A more complex example for travis can be found in the LDC repository: https://github.com/ldc-developers/ldc/blob/master/.travis.yml Regards, Kai
Re: Random points from a D n00b CTO
On Wednesday, 16 July 2014 at 15:25:22 UTC, Vic wrote: On Wednesday, 16 July 2014 at 12:35:29 UTC, Bastiaan Veelo wrote: I am not sure why you think Qt makes memory management easier. QObjects are generally given a parent that destructs its children when it terminates, but that is merely a convenience in GUI programming I think. Yeah, I don't know if Qt or D makes manual memory easier, but at some point I want to find out. So if any more input, great. I'd hate to have to hire like so: Ideal candidate knows some Qt AND D Lang. I'm not doing GUI, it's a socket server w/ large RAM. Also 'large', if the CPU has 30meg L3, I don't think 128Gig RAM is large anymore. Cheers, Vic Qt is an excellent framework, but pretty much completely irrelevant to memory management. Its object trees and refcounted containers are convenient for conventional programs, but if you are doing want to extract decent performaare with 100's of gigs, you'll need custom memory management, whether with D or Qt/C++ (and just like *some* parts of Phobos, Qt locks you into is types and whatever memory management they use. STL would make more sense but afaik it's allocator interface is quite a PITA)
Re: D blog?
On Wednesday, 16 July 2014 at 14:21:26 UTC, Dicebot wrote: On Wednesday, 16 July 2014 at 01:34:58 UTC, Kiith-Sa wrote: Just noticed this: http://blog.octayn.net/blog/2014/06/30/this-week-in-rust-54/ This is precisely the kind of thing we need. Huge amount of non-interesting effort. There was someone trying to do similar digest for D but effort seems to have stalled and I can totally see why. That was me. I ran into some ongoing school and life related issues on top of my current work. Right now all I have time for is some intermittent hacking in D, but I still do intend to get something going within the next few months. I think a monthly digest of news would be perfect for such a blog format.
Re: Using D
On Monday, 14 July 2014 at 10:13:43 UTC, Chris wrote: On Saturday, 12 July 2014 at 10:27:12 UTC, Russel Winder via I think we need to address these issues, because they are of a psychological nature and not really language issues. I'm sure that if we fixed GC and had the best implementation ever, people would find something else to complain about "D doesn't have blah, I don't like it!" I'm sort of getting the idea that D goal would to be a better Java. I'm running away from Java (after 10 years). I hope that someone at D has power and can say NO to a feature the way Linus does as opposed to adding more 'JCP' features, pushing such stuff downstream. Adding more features to be good at everything, aka a submarine that is a law mover. It's all done w/ best intentions. But forcing GC into base library of a system programing language? Maybe D is not a system programing language, but a enterprise app productivity lang. At least give us a choice, to use D why do I have to re-write the base lib. Cheers, Vic
Re: Continuous integration testing with travis and drone
On Wednesday, 16 July 2014 at 13:49:29 UTC, Pavel wrote: On Wednesday, 16 July 2014 at 04:11:28 UTC, Kapps wrote: On Wednesday, 16 July 2014 at 03:31:13 UTC, Pavel Evstigneev wrote: May I improve forum to support markdown? The forum is actually an interface to a newsgroup, so most forms of markdown would not be supported in the interest of having a consistent UI for people who use mail / newsgroup clients vs people who use the online web interface. Well, we can serve html in newsgroup/emails, or as plain text with striped markdown's markup For example user writes "hello, **people**", on online interface its "hello, people", in plain text format (for people who dislike html) it's: "hello, people". I don'y think we should give markdown as plain text, or we should limit features, for example only titles, code blocks, horisontal line, links. Everything is still same, but code snippets and links looks nice on web ui. How you think? I suggest you put together a minimal pull request for DFeed (https://github.com/CyberShadow/DFeed), maybe a patch that just handles one or two markup tokens, then open another forum thread here asking if there are any objections, as many people likely won't see this thread because of the unrelated title. If that's too much effort, at least open another thread without the pull request. I don't think there's anything wrong with sending markdown as plain text to the newsgroup and email lists, as it's meant to be readable.
Re: Random points from a D n00b CTO
On Wednesday, 16 July 2014 at 12:35:29 UTC, Bastiaan Veelo wrote: I am not sure why you think Qt makes memory management easier. QObjects are generally given a parent that destructs its children when it terminates, but that is merely a convenience in GUI programming I think. Yeah, I don't know if Qt or D makes manual memory easier, but at some point I want to find out. So if any more input, great. I'd hate to have to hire like so: Ideal candidate knows some Qt AND D Lang. I'm not doing GUI, it's a socket server w/ large RAM. Also 'large', if the CPU has 30meg L3, I don't think 128Gig RAM is large anymore. Cheers, Vic
Re: Brighton [was Using D]
On 13 July 2014 08:21, Walter Bright via Digitalmars-d wrote: > On 7/12/2014 8:03 AM, Iain Buclaw via Digitalmars-d wrote: >> >> My only way >> of getting around would be train due to lack of a car, or license. > > > A lack of a car would be an advantage in London. I've touristed around there > a bit, and never felt the need for a car, nor would I have ever wanted to > try and find a parking space. This I find is England in general.
Re: D logo copyright
On 16/07/2014 9:12 AM, Sönke Ludwig wrote: As far as I know, this is the "Verwertungsrecht" (roughly the right to distribute) and the "Nutzungsrecht" (the right to use). Both can be granted to third parties using a proper license, or using a work contract. Thanks, that could be useful ^^ I think what we need here isn't really a change of the ownership, but rather a proper license, either a liberal public license (e.g. some CC variant), or a personal license for Walter that grants him all rights to use, distribute and relicense the logo. I haven't been able to find a licence that grants the appropriate permissions because all the common public ones are about non-exclusive rights. If the graphic just had a CC license, other organisations would have just the same usage rights as Digital Mars. The graphic could have a more restrictive license and then Digital Mars could have additional rights granted separately, but that wouldn't really help. Crafting a new license is dangerous territory that I think is best avoided. Having said that, I'm pretty sure that he can still transfer the "copyright" according to U.S. laws to another person. It's just that he could then possibly still sue the person according to German laws. So a license would probably be the best bet. That is my understanding too. There are no standard forms for this, it only requires a signed letter from the creator, and there isn't even a requirement for the transaction to be registered in any way (although it can). Because international law is so hand-wavy, such documents often include clauses that state what jurisdiction disputes are resolved under and even waivers for things like the right to sue, but to get things like that right, you need at least 2 lawyers. Disclaimer: I'm not a lawyer, so this is just my limited personal understanding of the matter. I'm optimistic that this can all be resolved without having to get any lawyers involved, but it is a shame that the intersection of D-users and international-copyright-lawyers seems to have a cardinality of zero. A...
Re: Continuous integration testing with travis and drone
On Wednesday, 16 July 2014 at 04:11:28 UTC, Kapps wrote: On Wednesday, 16 July 2014 at 03:31:13 UTC, Pavel Evstigneev wrote: May I improve forum to support markdown? The forum is actually an interface to a newsgroup, so most forms of markdown would not be supported in the interest of having a consistent UI for people who use mail / newsgroup clients vs people who use the online web interface. I see no problem with markdown in this context - it is specifically designed to be very readable as raw source.
Re: Random points from a D n00b CTO
On Wednesday, 16 July 2014 at 09:56:06 UTC, Vic wrote: Any comments on Qt as choice? Pros: mature and widely used framework Cons: it is still C++ :)
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
On 16 July 2014 15:14, Daniel Murphy via Digitalmars-d wrote: > "Johannes Pfau" wrote in message news:lq5pv1$2nfb$1...@digitalmars.com... > > >> > The problem is not 'this feature is too complex', the problems is >> > that it's more complex than necessary. >> >> So what's necessary in this specific case? > > > Use intrinsics with a nice template wrapper. They get inlined, the unused > function bodies get stripped, and the debug info/typeinfo is just as big a > problem as it is for every other function in your program. > > Intrinsics get us away from our current 'there is no portable way to do > this' situation. No they don't. Intrinsics make things worse. > They are _trivial_ to implement for any of the compilers. No they aren't, unless you are talking specifically about volatile., in which case, that depends... > I have complete faith that it is possible to make a performant wrapper for > both the single-register read/write and the struct pattern you posted. And > if I'm wrong - we can add a volatile type modifier later! > > I just don't see volatile pulling it's weight. Hardware access is supposed to be correct, not performant. Regards Iain
Re: D logo copyright
On 16/07/2014 9:17 AM, Sönke Ludwig wrote: BTW, the shape of the logo itself isn't covered by either copyright, or "Urheberrecht", AFAIK. That's what trademarks are for. So a full redo of the logo should be unaffected by the original work. Of course it would still be fair to properly negotiate with the original author... I don't think it would be safe to assume that, the logo didn't exist before the graphic was created, so there was nothing to be used as a Trademark. By my reading of US Trademark law, the author would have grounds to appeal against any attempt to register it as long as they retained the copyright to the image on which the logo is based. But Trademark protection is a few steps further along the path. A...
Re: D blog?
On Wednesday, 16 July 2014 at 01:34:58 UTC, Kiith-Sa wrote: Just noticed this: http://blog.octayn.net/blog/2014/06/30/this-week-in-rust-54/ This is precisely the kind of thing we need. Huge amount of non-interesting effort. There was someone trying to do similar digest for D but effort seems to have stalled and I can totally see why.
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
"Johannes Pfau" wrote in message news:lq5pv1$2nfb$1...@digitalmars.com... > The problem is not 'this feature is too complex', the problems is > that it's more complex than necessary. So what's necessary in this specific case? Use intrinsics with a nice template wrapper. They get inlined, the unused function bodies get stripped, and the debug info/typeinfo is just as big a problem as it is for every other function in your program. Intrinsics get us away from our current 'there is no portable way to do this' situation. They are _trivial_ to implement for any of the compilers. I have complete faith that it is possible to make a performant wrapper for both the single-register read/write and the struct pattern you posted. And if I'm wrong - we can add a volatile type modifier later! I just don't see volatile pulling it's weight.
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
On Wednesday, 16 July 2014 at 13:04:37 UTC, Johannes Pfau wrote:
I experimented a little more with Volatile!T and I don't think
you can
make this example work:
struct Timer
{
uint control;
uint data;
}
enum timerA = (Volatile!Timer)* = cast()0xDEADBEAF;
timerA.control |= 0b1;
The actual code is a little different:
http://forum.dlang.org/thread/lq3kq8$pa3$1...@digitalmars.com?page=5#post-fkgjcnqyoqltftbfmwqd:40forum.dlang.org
Re: Review: std.logger
I just pushed a new version to dub and the PR. Highlights: * LogManager is gone. ( s/LogManager\.//g should fix all user code) * The codegen was replaced by some format token strings * log(lcf) and trace(cf) now present documentation * trace(cf) stands as an example for info, warning ... and so forth * StdIOLogger is now thread safe * StdIOLogger docu tells you that it is thread safe I also updated the html documents so you don't have to read through the source, but you are of course welcome to do so.
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
On Wednesday, 16 July 2014 at 13:51:49 UTC, Kagamin wrote:
On Wednesday, 16 July 2014 at 13:04:37 UTC, Johannes Pfau wrote:
I experimented a little more with Volatile!T and I don't think
you can
make this example work:
struct Timer
{
uint control;
uint data;
}
enum timerA = (Volatile!Timer)* = cast()0xDEADBEAF;
timerA.control |= 0b1;
The actual code is a little different:
http://forum.dlang.org/thread/lq3kq8$pa3$1...@digitalmars.com?page=5#post-fkgjcnqyoqltftbfmwqd:40forum.dlang.org
I think, the idea behind such declarations is to not let user to
set volatile qualifiers. What if he forgets?
Re: Continuous integration testing with travis and drone
On Wednesday, 16 July 2014 at 04:11:28 UTC, Kapps wrote: On Wednesday, 16 July 2014 at 03:31:13 UTC, Pavel Evstigneev wrote: May I improve forum to support markdown? The forum is actually an interface to a newsgroup, so most forms of markdown would not be supported in the interest of having a consistent UI for people who use mail / newsgroup clients vs people who use the online web interface. Well, we can serve html in newsgroup/emails, or as plain text with striped markdown's markup For example user writes "hello, **people**", on online interface its "hello, people", in plain text format (for people who dislike html) it's: "hello, people". I don'y think we should give markdown as plain text, or we should limit features, for example only titles, code blocks, horisontal line, links. Everything is still same, but code snippets and links looks nice on web ui. How you think?
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
On Wednesday, 16 July 2014 at 13:04:37 UTC, Johannes Pfau wrote:
I experimented a little more with Volatile!T and I don't think
you can make this example work:
struct Timer
{
uint control;
uint data;
}
enum timerA = (Volatile!Timer)* = cast()0xDEADBEAF;
timerA.control |= 0b1;
How about
struct VolatileTimer
{
Volatile!uint control;
Volatile!uint data;
}
enum timerA = cast(VolatileTimer*)0xDEADBEAF;
timerA.control |= 0b1;
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
Am Tue, 15 Jul 2014 19:44:51 +0200
schrieb Artur Skawina via Digitalmars-d :
> it originally and also the gdc ml discussion that followed. I have
> not seen any good argument for introducing a volatile type qualifier.
> Could you show one (concrete) example where using 'volatile' is better
> than my approach?
>
> artur
I experimented a little more with Volatile!T and I don't think you can
make this example work:
struct Timer
{
uint control;
uint data;
}
enum timerA = (Volatile!Timer)* = cast()0xDEADBEAF;
timerA.control |= 0b1;
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
Am Tue, 15 Jul 2014 23:38:21 -0700
schrieb Walter Bright :
> On 7/15/2014 10:15 PM, Johannes Pfau wrote:
> > Yes, I actually tried tested that simple implementation with gdc.
> > With aggressive optimizations the code inlines just fine and it'll
> > generate the same asm as an access to a volatile variable in C. But
> > it's not space-effecient: Even if it inlines, the function is still
> > in the object file as a distinct function. There's TypeInfo and
> > there's the assert(this), there's an initializer symbol and I guess
> > there could be copy constructors as well. I expect many bug
> > reports/fixes till we get a Volatile!T wrapper to be really
> > space-efficient.
>
> D is intended to have a robust enough feature set in order to
> implement types as library types rather than builtin, and have them
> operate as good as a builtin type would. These are more general
> issues, and are not specific to volatile.
>
And how do you implement this with a wrapper? This is common in C/C++:
struct Timer
{
uint control;
uint data;
}
enum timerA = (Volatile!Timer)* = cast()oxDEADBEAF;
timerA.control |= 0b1;
Your peek/poke intrinsics don't even consider this example. If you
extend peek/poke to T, then it'll always load the complete type,
whereas the C code loads only the field. And you can't even do anything
about it, cause peek!T explicitly tells the compiler to load the
complete type and prevent optimization of this load...
And it seems timerA.control |= 0b1; produces absolute nonsense. It
compiles, but
* The codegen is horrible. In C this compiles to 3 instructions, in D
30-40 instructions
* This doesn't do what it's supposed to do at all. For example it calls
the getter twice and never calls the setter.
The more I think about it the more corner cases appear. After all
implementing this in the library is much more complex than a type
qualifier. Some of the complexity is already implemented (alias
this, ...) so there's less changes in DMD. But any bug in alias this,
templates, etc will immediately leak into Volatile!T.
>
> 3. if you really hate peek/poke calls appearing in the code, you
> can use UFCS to make them look like variables
> >>> But you cant do REGISTER.peek() |= 0b1;
> >> As you mentioned in the DIP, read-modify-write operations should be
> >> split up, as their semantics are murky.
> > But not necessarily in user code. REGISTER |= is quite common in C
> > and it's perfectly safe.
>
> The point is it is not perfectly safe. There is no definition, and
> certainly no portable definition, as to how many read/write cycles
> such an operation entails. That's what I meant, and DIP62 says pretty
> much said the same thing. Please allow me to quote:
In cases where you use |= the exact number of accesses usually does not
matter. What matters is that there's at least one access and that it's
not reordered with other reads/writes to volatile.
For example |= is used on control registers. But I don't care if I
read/set the bit twice or once, I just doesn't matter.
>
> "CISC machines may allow other operations to memory than simple
> load/store operations. The question is then if a read-modify-write
> operation like 'x++' should translate to 'r = load x; r++; x = store
> r' or to a single add instruction 'add x;'. This DIP does not dictate
> any specific behaviour, but this is recommended: If it is known that
> instructions operating on memory do not work for memory mapped IO as
> expected, compilers should default to generating a load/modify/store
> sequence. Otherwise compilers should generate the same code sequence
> as for regular variables. It is recommended to provide a compiler
> switch on CISC architectures to allow the user to choose between
> these two different behaviours."
And what does peek/poke guarantee in that case? Everything you could
specify for peek/poke can be specified for volatile variables as well.
>
> > If people will have to split this up into peek |=
> > poke that's a step backwards from C.
>
> Support for op= is fairly simple for VolatilePointerToUint to
> implement, and it can implement them in terms of peek/poke for
> precise and portable semantics.
See above
> I do believe that a wrapper type around peek/poke satisfies
> essentially all your necessary requirements, except for transitivity.
See above. One important point is that this must be as effective as
c+volatile (in terms of code size and execution cycles). This is an
important aspect for embedded programming and it'll take ages and many
language changes to make a type wrapper as efficient. If it's even
possible at all.
> > I think it's a correct argument to say that you think
> > embedded system programming is not important enough for the
> > additional complexity introduced by a new qualifier.
>
> That is not what I'm saying at all. Please do not conflate
> disagreement about the best way to achieve a goal with disagreement
> about the goal.
So you do think peek/poke is a better sol
Re: Random points from a D n00b CTO
On Wednesday, 16 July 2014 at 09:56:06 UTC, Vic wrote: But if D is not my first choice to port(from Java), than my second choice is Qt. It seems simpler to manage memory and Hash Associative Array. Any comments on Qt as choice? I my experience, Qt makes programming in C++ a pleasure. Containers (with implicit sharing, foreach), strings, UTF8, i18n, signals and slots, dynamic type information, qmake, the state machine framework, of course the GUI framework, undo/redo framework, help reader and inline documentation generation, its IDE, and cross-platform portability are some of the aspects of Qt that I value the most. I am not sure why you think Qt makes memory management easier. QObjects are generally given a parent that destructs its children when it terminates, but that is merely a convenience in GUI programming I think. Bastiaan.
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
Am Wed, 16 Jul 2014 15:59:46 +1000 schrieb "Daniel Murphy" : > The problem is not 'this feature is too complex', the problems is > that it's more complex than necessary. So what's necessary in this specific case?
Re: Continuous integration testing with travis and drone
On Wednesday, 16 July 2014 at 04:11:28 UTC, Kapps wrote:
On Wednesday, 16 July 2014 at 03:31:13 UTC, Pavel Evstigneev
wrote:
May I improve forum to support markdown?
The forum is actually an interface to a newsgroup, so most
forms of markdown would not be supported in the interest of
having a consistent UI for people who use mail / newsgroup
clients vs people who use the online web interface.
Yes, but if used cautiously, [markdown][1] will not hinder the
*readability* as a **plain text**.
especially when there are code blocks:
```d
void main()
{
writeln("Please colorize me with Javascript if this message is
sent to web interface.");
}
```
[1]: http://daringfireball.net/projects/markdown/
Re: Continuous integration testing with travis and drone
On Wednesday, 16 July 2014 at 11:25:25 UTC, Joakim wrote: On Wednesday, 16 July 2014 at 04:11:28 UTC, Kapps wrote: On Wednesday, 16 July 2014 at 03:31:13 UTC, Pavel Evstigneev wrote: May I improve forum to support markdown? The forum is actually an interface to a newsgroup, so most forms of markdown would not be supported in the interest of having a consistent UI for people who use mail / newsgroup clients vs people who use the online web interface. Sigh, this always struck me as a problem with the current multi-mode setup, hobbling the forum to the lowest-common denominator capabilities of the older newsgroup/mail readers. Markdown is meant to be readable as a markup language, so maybe it can be supported by the DFeed forum alone: http://daringfireball.net/projects/markdown/syntax If another, more capable but less readable markup is wanted, another possibility I just thought of is to only accept markup from the web interface and then to have DFeed convert the markup into something readable in plain text when sending to the newgroup/mailing list, ie DFeed keeps its own slightly different version of any particular post. If Pavel or whoever puts in markdown support in DFeed, which is perfectly readable on its own, or does some sort of conversion of markup for the newsgroup/mail, are there any objections to sending straight markdown or this conversion workaround? As a fan of Markdown, I'd advise against using it for the forums. Many important posters use email instead.
Re: Continuous integration testing with travis and drone
On Wednesday, 16 July 2014 at 04:11:28 UTC, Kapps wrote: On Wednesday, 16 July 2014 at 03:31:13 UTC, Pavel Evstigneev wrote: May I improve forum to support markdown? The forum is actually an interface to a newsgroup, so most forms of markdown would not be supported in the interest of having a consistent UI for people who use mail / newsgroup clients vs people who use the online web interface. Sigh, this always struck me as a problem with the current multi-mode setup, hobbling the forum to the lowest-common denominator capabilities of the older newsgroup/mail readers. Markdown is meant to be readable as a markup language, so maybe it can be supported by the DFeed forum alone: http://daringfireball.net/projects/markdown/syntax If another, more capable but less readable markup is wanted, another possibility I just thought of is to only accept markup from the web interface and then to have DFeed convert the markup into something readable in plain text when sending to the newgroup/mailing list, ie DFeed keeps its own slightly different version of any particular post. If Pavel or whoever puts in markdown support in DFeed, which is perfectly readable on its own, or does some sort of conversion of markup for the newsgroup/mail, are there any objections to sending straight markdown or this conversion workaround?
Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.
On Monday, 14 July 2014 at 23:43:57 UTC, H. S. Teoh via Digitalmars-d wrote: On Mon, Jul 14, 2014 at 11:22:53PM +, John Carter via Digitalmars-d wrote: [...] Any other good blog posts / social media comments / pointers I can digest and use? This one came to mind: http://bartoszmilewski.com/2013/09/19/edward-chands/ This is pretty bad promotion for Haskell. The Author of this post apparently do not know C++ well enough or just ignore this knowledge. Me as a C++ developer who likes Haskell (and D) after reading this I like C++ a bit more and Haskell a bit less. It’s a common but false belief that reference counting (using shared pointers in particular) is better than garbage collection. And then he pointed to a "A Unified Theory of Garbage Collection" paper where "reference counting" as a strategy (method) for a Garbage Collection will be disused. This is NOT the same as std::shared_ptr do ! So if some one really hates D then he can write post like this about C++ and D.
Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.
On Tuesday, 15 July 2014 at 21:57:30 UTC, H. S. Teoh via Digitalmars-d wrote: On Tue, Jul 15, 2014 at 09:11:23PM +, John Colvin via Digitalmars-d wrote: On Tuesday, 15 July 2014 at 20:03:15 UTC, Chris wrote: >On Monday, 14 July 2014 at 23:43:57 UTC, H. S. Teoh via >Digitalmars-d >wrote: [...] >>http://bartoszmilewski.com/2013/09/19/edward-chands/ >> >> > >From the link above: > >"It’s a common but false belief that reference counting >(using shared >pointers in particular) is better than garbage collection. >There is >actual research* showing that the two approaches are just two >sides >of the same coin. You should realize that deleting a shared >pointer >may lead to an arbitrary long pause in program execution, with >similar performance characteristics as a garbage sweep. It’s >not only >because every serious reference counting algorithm must be >able to >deal with cycles, but also because every time a reference >count goes >to zero on a piece of data a whole graph of pointers >reachable from >that object has to be traversed. A data structure built with >shared >pointers might take a long time to delete and, except for >simple >cases, you’ll never know which shared pointer will go out of >scope >last and trigger it." > >* http://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf I've been wondering about this. Could the following argument be true? Situations where automatic memory management are necessary are, by definition, the situations where one cannot easily reason about where memory freeing can occur. Therefore, no automatic memory management system can be considered practically predictable, unless you didn't* need it in the first place. *strictly speaking Sounds about right. Which is why you have advice like preallocating everything before a game level (i.e., eliminate the need for memory management during that level), or minimizing GC load by avoiding frequent allocations of small objects (i.e., reduce the amount work that needs to be done by the memory management system), keeping things on stack rather than heap if possible (maximize trivial instances of memory management and minimize non-trivial instances -- can also be viewed as: if you structure your program to correspond with the structure of your memory usage, then memory management has a 1-to-1 correspondence with the control structure of the program itself so it doesn't need to be done as a separate task). Hmm. Now that I come to think of it, it seems that the complexity of memory management arises due to structural mismatch between memory usage and program structure, that is, memory acquisition and release do not correspond 1-to-1 with the call structure of the program. If your program can be structured such that it matches your memory usage pattern exactly, then everything can be stack-allocated, and there is no need for sophisticated memory management schemes. It's when the lifetimes of your memory allocations differ from the lifetime of program units (i.e., functions), that extra work, in the form of memory management algorithms, is needed to compensate for the "impedance mismatch", so to speak. Which suggests the rather interesting idea that perhaps some innovative way of structuring the parts of your program such that each corresponds with the structure (and lifetime) of a particular piece of data, then it should minimize, or maybe completely eliminate, the need for complex memory management! (I have no idea if such a thing exists, though. But it's an interesting thought.) For example, if your code creates a string in one section of a function, which is subsequently consumed by the second section, then by the time the function exits the string is not needed anymore, so you could ostensibly just allocate it on the stack instead of the heap. It's when you need to return the string that things become complicated: because now there's a mismatch between the lifetime of your function and the lifetime of the string. So now you need some way of keeping track of the lifetime of the string, and dispose of it when it's no longer needed. But if your program can be structured such that the allocators of memory and the consumers of memory are always matched together 1-to-1, then you can always allocate only on the stack and no memory will need to persist past the function in which it is allocated. Not sure when such a structuring is possible, or whether it is at all possible to structure arbitrary programs this way, though. Definitely not possible in a stack-only paradigm, I think; but maybe possible (or we can go a little farther) with concurrent paradigms? T This is a rather interesting thought and boils down to the usual conflict of machine logic not matching program / real world logic. You mentioned a while ago that one of your teachers said that programs were often overly complicated, bug and error prone, because there was a mismatch of data structu
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
On Tuesday, 15 July 2014 at 21:28:24 UTC, Walter Bright wrote: Peek/poke has a 40 year history of being used for MMIO, and I've never heard of it being used for concurrency. I don't think there's endemic confusion, quite unlike volatile. There is a huge confusion about volatile in the native space. No one really knows what it does and when it should be used, because it's kind of rare. I've seen pervasive volatile use make some GPU kernels 100x slower. Programming by coincidence, sure, but _explicit_ barriers, being read/write/optimizer barriers, I find them much better. volatile is more like denial, and importing the history behind the keyword would negative PR. Pascal had no volatile, and using &= from a memory-mapped location doesn't exactly scream "performance".
Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.
On Tuesday, 15 July 2014 at 23:02:19 UTC, Araq wrote: On Tuesday, 15 July 2014 at 21:11:24 UTC, H. S. Teoh via Digitalmars-d wrote: On Tue, Jul 15, 2014 at 09:03:36PM +, Araq via Digitalmars-d wrote: > >The only way to *really* guarantee 100% predictable memory >reclamation is to write your own. Except that we all know how >scalable and bug-free that is. Not to mention, when you need >to >deallocate a large complex data structure, *somebody* has to >do the >work -- either you do it yourself, or the reference counting >implementation, or the GC. No matter how you cut it, it's >work that >has to be done, and you have to pay for it somehow; the cost >isn't >going to magically disappear just because you use reference >counting >(or whatever other scheme you dream up). > Actually it completely disappears in a copying collector since only the live data is copied over ... Nope, you pay for it during the copy. Read the linked paper, it explains the duality of tracing and reference-counting. Whether you trace the references from live objects or from dead objects, the overall computation is equivalent, and the cost is effectively the same. Once you've applied the usual optimizations, it's just a matter of time/space tradeoffs. This is wrong on so many levels... Oh well, I don't care. Believe what you want. Please enlighten us.
Re: Random points from a D n00b CTO
On Tuesday, 15 July 2014 at 17:15:08 UTC, Kagamin wrote: On Monday, 14 July 2014 at 13:54:51 UTC, Vic wrote: Xeon CPU lets you use 128Gig, 386 gig, 512 gig, etc. It has become cheap to do that. Java can't hog gigs? Unbelievable. Java is the devil I know. But if D is not my first choice to port(from Java), than my second choice is Qt. It seems simpler to manage memory and Hash Associative Array. Any comments on Qt as choice?
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
On 7/16/2014 1:35 AM, Iain Buclaw via Digitalmars-d wrote: Which would you prefer? The simplest, which is just to use a version declaration to select whatever works for any particular compiler/CPU.
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
On 16 July 2014 08:16, Walter Bright via Digitalmars-d
wrote:
> On 7/15/2014 11:23 PM, Iain Buclaw via Digitalmars-d wrote:
>>
>> GDC doesn't support it as compiler intrinsics.
>
>
> I know.
>
>
>
>> Also, isn't inp/outp all x86-specific?
>
> Yes. This is not an argument that x86 compilers shouldn't support them.
> After all, D is supposed to be a systems programming language.
>
It certainly isn't! And it is never my intention to prevent
optimisations on one platform if another doesn't benefit.
I think my argument comes down to this, consider the following
compiler intrisinsic.
---
ubyte inp(uint port_address);
It should instead be written as.
---
ubyte inp()(uint port_address)
{
version(ARM)
{
asm { /* ... */ }
}
else
static assert(false, "Not Implemented");
}
What's going on here?
1) If the compiler recognises the function as an intrinsic, it
discards the body and does whatever it knows to be correct.
2) If its not an intrinsic, it falls back to the library implementation.
3) So not to hurt targets that do not support inp/outp, it only errors
at compile-time if *actually* used.
As an alternative, instead of a template, we could use core.internal
to do the same thing in this way.
core/internal/bitops.d
---
module core.bitops;
version(ARM)
{
ubyte inp(uint port_address)
{
/* ... */
}
}
core/bitops.d
---
module core.bitops;
ubyte inp(uint port_address);
But then it falls down to a linker error if
1) The compiler didn't expand inp() in the backend
2) core.internal.bitops doesn't implement inp()
Which would you prefer?
Regards
Iain.
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
On Wednesday, 16 July 2014 at 05:17:56 UTC, Johannes Pfau wrote: There's TypeInfo and there's the assert(this) The optimizer should be able to eliminate this assert after inlining as it knows it's not null. It should be looked into, why the optimizer didn't remove it.
Re: D logo copyright
Am 16.07.2014 10:12, schrieb Sönke Ludwig: Am 15.07.2014 13:13, schrieb Alix Pexton: I've been researching what is necessary to transfer the copyright of the D logo to Digital Mars, which is complicated by international issues. It seems that the term "copyright" is often aliased to the German "Deutsches Urheberrecht" which is what we call the "moral rights of the author" in the UK. This is something very different from copyright as it is inalienable from the originating creator and not something that can be transferred other that by inheritance. This makes me wonder if previous attempts to negotiate a new copyright for the logo have gone unanswered because the terminology used has lost something in translation. Do any of our native German D users know what the right terminology for the international concept of "copyright" is? European copyright law is something that is currently being debated for unification and there is no actual legislation in place so any negotiations regarding the logo have to be conducted based on the common ground between German and U.S. laws. A... As far as I know, this is the "Verwertungsrecht" (roughly the right to distribute) and the "Nutzungsrecht" (the right to use). Both can be granted to third parties using a proper license, or using a work contract. I think what we need here isn't really a change of the ownership, but rather a proper license, either a liberal public license (e.g. some CC variant), or a personal license for Walter that grants him all rights to use, distribute and relicense the logo. Having said that, I'm pretty sure that he can still transfer the "copyright" according to U.S. laws to another person. It's just that he could then possibly still sue the person according to German laws. So a license would probably be the best bet. Disclaimer: I'm not a lawyer, so this is just my limited personal understanding of the matter. BTW, the shape of the logo itself isn't covered by either copyright, or "Urheberrecht", AFAIK. That's what trademarks are for. So a full redo of the logo should be unaffected by the original work. Of course it would still be fair to properly negotiate with the original author...
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
Then we can have phantom functions for porting C macros instead of templates :) (oh it's spelled with 'ph').
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
Walter Bright:
struct VolatilePointerToUint {
private:
size_t ptr;
public:
this(size_t ptr) { this.ptr = ptr; }
uint read() { return peek(cast(uint*)ptr); }
void write(uint value) { poke(cast(uint*)ptr, value); }
}
You'd probably wish to flesh this out a bit more, but it's the
general idea.
To be added to Phobos?
It's a zero cost abstraction. D has very capable abilities to
create types that are restricted versions of other types - this
should be explored and exhausted before considering language
extensions.
See also the @fantom suggested by Kagamin.
Bye,
bearophile
Re: D logo copyright
Am 15.07.2014 13:13, schrieb Alix Pexton: I've been researching what is necessary to transfer the copyright of the D logo to Digital Mars, which is complicated by international issues. It seems that the term "copyright" is often aliased to the German "Deutsches Urheberrecht" which is what we call the "moral rights of the author" in the UK. This is something very different from copyright as it is inalienable from the originating creator and not something that can be transferred other that by inheritance. This makes me wonder if previous attempts to negotiate a new copyright for the logo have gone unanswered because the terminology used has lost something in translation. Do any of our native German D users know what the right terminology for the international concept of "copyright" is? European copyright law is something that is currently being debated for unification and there is no actual legislation in place so any negotiations regarding the logo have to be conducted based on the common ground between German and U.S. laws. A... As far as I know, this is the "Verwertungsrecht" (roughly the right to distribute) and the "Nutzungsrecht" (the right to use). Both can be granted to third parties using a proper license, or using a work contract. I think what we need here isn't really a change of the ownership, but rather a proper license, either a liberal public license (e.g. some CC variant), or a personal license for Walter that grants him all rights to use, distribute and relicense the logo. Having said that, I'm pretty sure that he can still transfer the "copyright" according to U.S. laws to another person. It's just that he could then possibly still sue the person according to German laws. So a license would probably be the best bet. Disclaimer: I'm not a lawyer, so this is just my limited personal understanding of the matter.
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
On 16 July 2014 08:08, Walter Bright via Digitalmars-d wrote: > On 7/15/2014 11:32 PM, Iain Buclaw via Digitalmars-d wrote: >> >> On 16 July 2014 07:12, Walter Bright via Digitalmars-d >> wrote: >>> >>> On 7/15/2014 9:29 PM, Brad Roberts via Digitalmars-d wrote: I don't have any skin in this particular discussion, but it's worth pointing out here that while it's cute that builtin's can be added, when they're not part of the language definition, they're not really part of a portable solution. >> >> > They're as portable as we want them to be. >> I read that as, not portable at all then. :o) > > > > C'mon, guys. It's our spec and we can make it work. And we are trying to make it work. I actually have quite a bit to be planned out after removing the 'volatility' from shared. >From the following spec: ''' Unlike the shared attribute, __gshared provides no safe-guards against data races or other multi-threaded synchronization issues. It is the responsibility of the programmer to ensure that access to variables marked __gshared is synchronized correctly. ''' GDC will likely in future emit atomic loads, stores, and possibly fences around the use of shared data. As there is no specific meaning to what 'safe-guards' come with shared. I interpret that to keep in line with a happens-before style relationship with sequential reads/writes to shared data. Regards Iain
Re: D logo copyright
On 15/07/2014 9:05 PM, Chris wrote: On Tuesday, 15 July 2014 at 11:12:57 UTC, Alix Pexton wrote: I've been researching what is necessary to transfer the copyright of the D logo to Digital Mars, which is complicated by international issues. It seems that the term "copyright" is often aliased to the German "Deutsches Urheberrecht" which is what we call the "moral rights of the author" in the UK. This is something very different from copyright as it is inalienable from the originating creator and not something that can be transferred other that by inheritance. This makes me wonder if previous attempts to negotiate a new copyright for the logo have gone unanswered because the terminology used has lost something in translation. Do any of our native German D users know what the right terminology for the international concept of "copyright" is? European copyright law is something that is currently being debated for unification and there is no actual legislation in place so any negotiations regarding the logo have to be conducted based on the common ground between German and U.S. laws. A... Does it make a difference a. where the author lives and b. where the logo is hosted? As far as I can work out, its a no for both questions. My problem is that every time that I search for information on German copyright law I get information about Urheberrecht, often with a note saying that it should not be confused with copyright >< This makes it hard to plan a polite approach. A...
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
Kagamin: I'd recommend @fantom name, because not only type wrappers can benefit from these optimizations. Should be also applicable to functions and maybe modules. This sounds like something fit for D too, not just gdc. You can use it for std.typecons.Typedef too. Bye, bearophile
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
On Wednesday, 16 July 2014 at 05:17:56 UTC, Johannes Pfau wrote: I think if we decide that Volatile!T is the solution I'd probably hack an attribute @TypeWrapper for gdc which simply recognized Volatile!T and does the right thing. I'd recommend @fantom name, because not only type wrappers can benefit from these optimizations. Should be also applicable to functions and maybe modules.
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
On 7/15/2014 11:23 PM, Iain Buclaw via Digitalmars-d wrote: GDC doesn't support it as compiler intrinsics. I know. Also, isn't inp/outp all x86-specific? Yes. This is not an argument that x86 compilers shouldn't support them. After all, D is supposed to be a systems programming language. I've never come across a similar thing in other architectures (at least, of the same name) I have. Special I/O ports and associated special instructions used to be commonplace in microprocessors. Remember, D is supposed to be a systems programming language, not a language restricted to the least common denominator of every CPU now and in the future. One needs access to the system parts of the CPU.
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
On 7/15/2014 11:32 PM, Iain Buclaw via Digitalmars-d wrote: On 16 July 2014 07:12, Walter Bright via Digitalmars-d wrote: On 7/15/2014 9:29 PM, Brad Roberts via Digitalmars-d wrote: I don't have any skin in this particular discussion, but it's worth pointing out here that while it's cute that builtin's can be added, when they're not part of the language definition, they're not really part of a portable solution. > They're as portable as we want them to be. I read that as, not portable at all then. :o) C'mon, guys. It's our spec and we can make it work.
