Re: Contradictory justification for status quo
On Fri, 27 Feb 2015 06:34:40 +, weaselcat wrote: On Friday, 27 February 2015 at 02:46:57 UTC, ketmar wrote: On Thu, 26 Feb 2015 18:13:12 -0800, Jonathan M Davis via Digitalmars-d wrote: whereas creating a PR for dmd will sometimes put things in a position where Walter finally approves it (or rejects it) rather than simply discussing it and getting nowhere. oh, i see. i really enjoy multiple `alias this` now, it's a great merge! and that great new tuple syntax... i love it! ah, sorry, i was daydreaming. Didn't multiple alias this get merged? I wasn't even following it. it was blessed and... and then everybody forgot about it. signature.asc Description: PGP signature
Re: Mac Apps That Use Garbage Collection Must Move to ARC
Am 27.02.2015 um 00:05 schrieb deadalnix: Note that in D, you have union and all kind of crap like that, so what is writing a pointer is non obvious and so the tradeof is very different than it is in other languages. To have any chance of implementing a better GC in D I would simly start of with assuming all code is @safe. For code that is not @safe the user would have to make sure it plays nice with the GC. This would also apply to unions which contain pointer types. If you wan't to write a good GC that does support non @safe features without user input you don't even have to start in my opinion.
Re: Will D have a serious dedicated well supported IDE like Visual Studio or Eclipse?
On 02/26/2015 08:30 PM, weaselcat wrote: GDB works fine with D, I use it regularly. http://wiki.dlang.org/Open_Source_Projects#Debugging_support_by_compiler: What version of gdb is needed and is that version easy to install? Ali
Re: DIP74: Reference Counted Class Objects
On Friday, 27 February 2015 at 00:10:00 UTC, deadalnix wrote: On Thursday, 26 February 2015 at 21:50:56 UTC, Andrei Alexandrescu wrote: http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and discuss. Thanks, Andrei The compiler detects automatically and treats specially all classes and interfaces that define the following two methods: Well, RefCounted could use compile time reflexion to do so. Even better, we could define a lvalue property for RefCounted to use a counter so we can do intrusive counting in both classes and structs. @safe code may not issue explicit calls to opAddRef/opRelease. I guess we could simply make them @system . RCOs objects are subject to additional limitations compared to their GC counterparts: No conversion to Object or interfaces that are not reference counted No problem, I'm gonna duplicate all my code and as will every single library writer out there. Missing: All write of RCO reference to statics must be atomic and ordered as long as the language can't enforce thread locality (at least in @safe code). Generally: This DIP works around (announced) limitations of DIP25. As escape can only be checked properly for type with no indirections, and only solve the problem for classes/interfaces. Other type with indirection remains an unsolved problem. If I were in charge, that would be a clear no, and the sign that DIP25 approach needs to be reworked, as wack-a-mole is not a good way to handle design. We all pray you become less of a gaping asshole before youre in charge of anything.
Re: [OT] HTML: div/iframe hybrid?
On Thu, Feb 26, 2015 at 11:50:04PM -0500, Nick Sabalausky via Digitalmars-d wrote: On 02/26/2015 04:34 PM, H. S. Teoh via Digitalmars-d wrote: On Thu, Feb 26, 2015 at 03:36:04PM -0500, Nick Sabalausky via Digitalmars-d wrote: Yea. Speaking of, that mobile-directed no zoom css thing is seriously fucking evil. If browser devs had any basic integrity whatsoever they'd deliberately ignore that abomination of an attribute, or at least let any BD users who enjoy being told what they can't do on their own miniature device just opt-in to it. I find this trend extremely disturbing and exceptionally annoying. I wish every browser would come with an option to override everything the author tries to shove down your throat and using what YOU, the user, specify as default instead. Yea. I'm a steadfast believer in the the design principle of highly configurable with reasonable defaults. Ideally, everything should be configurable and nothing should NEED to be configured. Or as close to that as possible. Making everything configurable is hard, though. Well, not *that* hard if you design your code properly, but in the webdev world, sometimes it's all about unreasonable deadlines and shipping it as fast as possible. Good design -- what's that?? As a result, making things configurable is harder than it ought to be, and the returns are low 'cos most people won't even bother configuring anything in the first place. Result: nobody cares, and nobody implements it. [...] One of these days I still want to make an FF addon to just bring sanity back to the whole freaking thing. Maybe later split it off into its own Webkit/Chromium-based browser. I'm seriously fed up with Mozilla's BS (like you mentioned in a later post, way too much Chrome-envy, among other issues), but the only alternatives are worse. When Opera ditched Presto, I died a little inside. Back in the day, Presto was the only serious alternative to the other major offerings (I even introduced Opera to my non-techie cousin and she liked it!), and was the only one that offered the level of configurability that I liked. In the early days it was also slim and fast, though it started bloating up toward the final days. But then Opera died and went the way of Chrome and now we're stuck with the IMO inferior choices. At least Vimperator made FF tolerable. Not enough, though. Perhaps one of these days when I have time (har har) I'll take it even further, and fully eradicate the rodent dependence and other Chrome-envy and replace it with something useful. Like a D REPL, I dunno. j/k :-P Just give me the content, m'am, keep all the frills to yourself. Oh, you mean there's nothing left after the frills and eye-candy are gone? Well, then, I'll move on to another site that actually sports content, thank you very much, have a nice day. And content does NOT mean A barely-meaningful slogan or two and a vaguely related image tossed onto a mostly-blank page. Scroll down to get a few more slogans and clipart. (*cough* mobile-first design *cough*) I've already given up that fight. I used to think time machines were fictitious, but clearly *somebody* has invented one and is seriously screwing with our timeline, it's now the 90's in 2015 and contentless splash pages are all the rage. Only, instead of Flash or Java like in the real 90's, it's now CSS and HTML5 canvas. I don't know where all the lessons learned in the 90's went -- y'know, all those webpage design tutorials advising against contentless splash pages and recommending delivering oh, y'know, actual content? And sane navigation? -- but clearly the guy with the time machine has seriously screwed things up and nobody remembers the past to learn from its mistakes. Except users, whose memories were left intact so that they'll suffer for it needlessly. Sigh... But yea, that's the thing I don't get about the JS proponents: The argument always goes back to It allows sites to be more dynamic![1] Umm, ok, and that's a good thing why exactly? They never seem to have a real reason of course, it's just taken for granted that more dynamic is unquestionably better, because it just is, and because we can. Oh yea, and call something passe because that'll REALLY prove some sort of worthwhile point. It's just like how in the bad ole days, MS would label something smart because it sells better that way, yet everytime people hear MS say smart they go on the alert for something really dumb. Or active (aka public arbitrary code execution service), dynamic (aka marquee repackaged in a less offensive name), or any of those overused, beaten-to-death adjectives that have been bleached of all traces of actual meaning. [1] Then they also like tossing around the meaningless buzzword of richer experience, thus proving they're only regurgitating groupthink and haven't actually thought through much of anything. Yep, caveman-style point-n-grunt is obviously richer experience because it's more
Re: DIP74: Reference Counted Class Objects
On 2015-02-26 22:50, Andrei Alexandrescu wrote:
http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and
discuss.
* What will happen if these methods are defined on a class that is
allocated on the GC? Is there any enforcement against this? Is there any
way an unsafe operation can happen, i.e. the GC deleting a class that
has already been destroyed by reference counting?
What about enforcing a third method, allocate or similar. This method
will do the actually allocation of a class instance. new Foo could be
lowered to a call to allocate.
* I know this is bikeshedding but I think it's important. This is a
breaking change, like it or not, and it's the worst kind. The kind that
if a class exists with these methods it will continue to happily compile
without errors or warnings but will have different semantic behavior.
Therefore I recommend requiring a compiler recognized UDA, in one of the
following ways:
A.
@arc class Foo
{
T1 opAddRef();
T2 opRelease();
}
If a class is marked with @arc the compiler will enforce that both
opAddRef and opRelease are defined with the expected signatures.
B.
class Foo
{
@arc T1 opAddRef();
@arc T2 opRelease();
}
If either a method is called opAddRef or opRelease and it's marked
with @arc, the compiler will enforce that the other method is defined
and marked with @arc as well. The signatures of the methods are enforced
as well.
C.
class Foo
{
@arc(addRef) T1 foo();
@arc(release) T2 bar();
}
Basically the same as B but the actual methods can be called anything.
Alternative A gives a clear documentation it's a reference counted class
without having to scan the methods.
--
/Jacob Carlborg
[Issue 13320] Redundant error messages for missing operation on struct instance
https://issues.dlang.org/show_bug.cgi?id=13320 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13320] Redundant error messages for missing operation on struct instance
https://issues.dlang.org/show_bug.cgi?id=13320 --- Comment #2 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/0bbdb88c7aacab5837ed5d1cddb1199a7b6182f9 fix Issue 13320 - Redundant error messages for missing operation on struct instance --
Re: Is there such a thing?
On 2015-02-26 20:53, Taylor Hillegeist wrote: So, In languages like .net they have dll's that contain not only bytecode but also the necessary headers to make them usable in any .net language. I was curious if this kind of thing has ever been attempted for static libraries? basically some type of universal header + static library = Everything Needed to use in project file. of course they would be targeted for a certain platform but would be really easy to grab/use. And if the header could be agreed upon any compiled language could use the library which would be a huge benefit. Perhaps i'm incorrect in my assumptions. Let me know what you think about the idea? I think it's better to use a package manager to handle this. It will also automatically download the necessary files. Also it will help (hopefully) you to find the libraries you need. -- /Jacob Carlborg
Re: DIP74: Reference Counted Class Objects
On 2/26/2015 5:37 PM, H. S. Teoh via Digitalmars-d wrote:
Wait, are you saying that forgetting the 'return' annotation will still
compile without any warning?? Wow, that's ... not nice. :-(
Indeed, and the compiler will error out if you try that:
---
struct S {
int x;
}
ref int foo(ref S s) {
return s.x;
}
---
dmd -c foo -dip25
foo.d(7): Error: escaping reference to local ref variable s
There'd be no point to DIP25 if it didn't.
Re: Contradictory justification for status quo
On 2/26/2015 6:58 PM, Andrei Alexandrescu wrote: I should add, however, that effort in and by itself does not warrant approval per se. Labor is a prerequisite of any good accomplishment, but is not all that's needed. Yeah, that's always a problem. Ideally, how much work someone put into a proposal should have nothing to do with whether it is incorporated or not. But being human, we feel a tug to incorporate something because someone expended much effort on it. It's always much harder to turn them down.
Re: A Refcounted Array Type
On Thu, 26 Feb 2015 23:13:01 -0500, Steven Schveighoffer wrote: I think it's going to be difficult to impossible to prevent people from using TLS in destructors anyway. It can probably be a guideline more than a compiler error. and a warning, please! a warning that i can silence, of course. signature.asc Description: PGP signature
hai
what is string? Read More: Hotels in Tirunelveli near railway station |Budget hotels in tirunelveli http://www.hotelmnhroyalpark.com/
[Issue 11746] invalid enum forward reference pattern not detected
https://issues.dlang.org/show_bug.cgi?id=11746 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 11746] invalid enum forward reference pattern not detected
https://issues.dlang.org/show_bug.cgi?id=11746 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/1b419fb6972bdf30e71d35f0a93aac900e11e1dd fix Issue 11746 - invalid enum forward reference pattern not detected https://github.com/D-Programming-Language/dmd/commit/e6e194a2be6be97b23df4bfa397d70a34c5d8177 Merge pull request #4440 from 9rnsr/fix11746 Issue 11746 - invalid enum forward reference pattern not detected --
Re: Contradictory justification for status quo
On Friday, 27 February 2015 at 02:46:57 UTC, ketmar wrote: On Thu, 26 Feb 2015 18:13:12 -0800, Jonathan M Davis via Digitalmars-d wrote: whereas creating a PR for dmd will sometimes put things in a position where Walter finally approves it (or rejects it) rather than simply discussing it and getting nowhere. oh, i see. i really enjoy multiple `alias this` now, it's a great merge! and that great new tuple syntax... i love it! ah, sorry, i was daydreaming. Didn't multiple alias this get merged? I wasn't even following it.
[Issue 12422] [REG2.055] Templated nested function is inferred as `pure` even if it calls impure functions
https://issues.dlang.org/show_bug.cgi?id=12422 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a326fcfd501514a41341f8e3a4901fe575145016 fix Issue 12422 - Templated nested function is inferred as `pure` even if it calls impure functions https://github.com/D-Programming-Language/dmd/commit/b00a79fae2560ee7b82c336bd9403f2d9071c22b Merge pull request #4441 from 9rnsr/fix12422 [REG2.055] Issue 12422 - Templated nested function is inferred as `pure` even if it calls impure functions --
[Issue 12422] [REG2.055] Templated nested function is inferred as `pure` even if it calls impure functions
https://issues.dlang.org/show_bug.cgi?id=12422 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 6810] Strange `tuple used as a type` error
https://issues.dlang.org/show_bug.cgi?id=6810 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/5e89c763b5f7e854f1a06c50aaa43340b1cb fix Issue 6810 - Strange `tuple used as a type` error https://github.com/D-Programming-Language/dmd/commit/6c5e3c378e5c8c23bf51ca94b967ff3e029f2f4f Merge pull request #4439 from 9rnsr/fix6810 Issue 6810 - Strange `tuple used as a type` error --
[Issue 6810] Strange `tuple used as a type` error
https://issues.dlang.org/show_bug.cgi?id=6810 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13064] Redundant `auto` storage class is allowed for functions
https://issues.dlang.org/show_bug.cgi?id=13064 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/2d99cd781acc0db602850a05453031df4b23f946 fix Issue 13064 - Redundant `auto` storage class is allowed for functions https://github.com/D-Programming-Language/dmd/commit/55587e23f159d247edb55f32e78c1f202347d993 Merge pull request #4442 from 9rnsr/fix13064 Issue 13064 - Redundant `auto` storage class is allowed for functions --
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On 2015-02-26 20:58, Walter Bright wrote: It was a generational gc, I described earlier how it used page faults instead of write barriers. I eventually removed the page fault system because it was faster without it. Instead you used? -- /Jacob Carlborg
Re: DIP74: Reference Counted Class Objects
On Thu, Feb 26, 2015 at 06:39:12PM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 2/26/15 6:21 PM, H. S. Teoh via Digitalmars-d wrote: On Thu, Feb 26, 2015 at 06:06:04PM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 2/26/15 5:59 PM, H. S. Teoh via Digitalmars-d wrote: On Thu, Feb 26, 2015 at 05:44:36PM -0800, Andrei Alexandrescu via Digitalmars-d wrote: [...] An interesting option to explore in the future would be rigging druntime to add opAddRef and opRelease to Object. [...] How would that work? Doesn't that immediately subject *all* classes to the restrictions set forth in DIP74? It does - but that might be fine with some applications. -- Andrei But putting it into druntime imposes it on *all* applications, because either opAddRef/opRelease are declared in Object, or they are not, and this decision is made long before the user writes his application. That's why I used rigging - meaning equip for special purpose. Hacking is clearer. Someone may decide to just add opAddRef/opRelease to Object for a system or application. Or make the addition subject to a versioning flag (and therefore have two druntime builds available). [...] Ahhh, I see what you mean now. That's an interesting idea... I suppose people like Manu could like to do something like this to get ARC by default, for example. T -- Do not reason with the unreasonable; you lose by definition.
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On 2015-02-26 21:45, Walter Bright wrote: If you want some fun, take any system and fill up the disk drive to just short of capacity. Now go about your work using the system. You'll experience all kinds of delightful, erratic behavior, because real world C code tends to ignore write failures and just carries on. It has happened to me quite often. It's usually no problem. Just (re)move some data an continue. -- /Jacob Carlborg
Re: DIP74: Reference Counted Class Objects
On 2015-02-26 22:50, Andrei Alexandrescu wrote: http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and discuss. To me this looks like ARC (Automated Reference Counting). I know that Walter has several complains about ARC, like he wrote in another thread [1]: RC has further performance and code bloat problems when used with exception handling Is that dealt with or is it something one just have to accepted when using reference counting? [1] http://forum.dlang.org/post/mcbejn$2tao$1...@digitalmars.com -- /Jacob Carlborg
[Issue 14225] [REG2.067a] GDB: error reading variable (string + dup)
https://issues.dlang.org/show_bug.cgi?id=14225 Martin Krejcirik m...@krej.cz changed: What|Removed |Added Component|DMD |druntime Summary|[REG2.067a] GDB: error |[REG2.067a] GDB: error |reading variable (string + |reading variable (string + |char[]) |dup) --- Comment #1 from Martin Krejcirik m...@krej.cz --- Introduced by https://github.com/D-Programming-Language/druntime/commit/5a5d1c5c4d9f27785422191178fc4e2876a0a097 --
Re: DIP74: Reference Counted Class Objects
On 2/26/15 2:17 PM, Brian Schott wrote: On Thursday, 26 February 2015 at 21:50:56 UTC, Andrei Alexandrescu wrote: http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and discuss. Thanks, Andrei This lowering assumes left-to-right evaluation of function parameters. -DIP 74 The following binary expressions are evaluated in an implementation-defined order: AssignExpression, function arguments - http://dlang.org/expression.html Yah, Walter mentioned these. We need to fix them. -- Andrei
Re: DIP74: Reference Counted Class Objects
On 2/26/15 2:39 PM, Johannes Pfau wrote: Looks very nice, some things to refine: Any attributes are allowed on these methods. * Should @safe and @trusted by disallowed as @safe code may not issue explicit calls to opAddRef/opRelease? * Probably also add a note here that the functions must be inverse and a note that they should be nothrow and/or final for performance. OK. I don't want to impose many limitations - let users explore possibilities. I added the recommendation. This DIP proposes @safe reference counted class objects (including exceptions) * Unfortunately the DIP doesn't talk about exceptions ;-) Will we simply make Throwable a RCO? Yes. considers that opRelease is the inverse of opAddRef, and therefore is at liberty to elide pairs of calls * Nice, but does that mean that reference-counted classes are now superior to reference counted structs? It would be nice if the compiler could also detect opRelease/opAddRef in structs. We could still require user code to call these manually in postblits etc but recognizing them would allow eliding pairs. That's already taken care of - this(this) and ~this() are considered complementary. Also a more general question: What are the most important memory management strategies and which are handled by DIP25+DIP74? * GC Of course supported * RC Supported with DIP74. I think this could also be considered as ARC. If not, what is missing from DIP74 compared to ARC? Unless something major we didn't think of is found with DIP25 and DIP74, it's not impossible we found the perfect shade. Not only we'll offer automatic reference counting, but we'll allow people do define types that are usable in @safe code that do that. * Scoped (useful for stack objects) Can 'return' be used to implement something which allocates a class on the stack and prevents escaping references? I guess a Scope struct allocating in place + a function returning a reference to the class with 'return' (+ alias this) would work? Yah, DIP74 can be directly used to make scope w = new Widget; work. But we'll address that in a distinct DIP in order to not bloat this one. * Owned Supported by the member variables lifetime = parent lifetime rule? * Unique ? * ? Let's see. Andrei
Re: LDC for iOS
On Thursday, 26 February 2015 at 19:26:07 UTC, Jacob Carlborg wrote: I could successfully compile the compiler and compile Hello World without any problems. I did not try running it on an a device. Thanks Jacob!
Re: A Refcounted Array Type
On 2015-02-26 21:07:26 +, Andrei Alexandrescu said:
On 2/26/15 12:54 PM, deadalnix wrote:
On Thursday, 26 February 2015 at 16:57:51 UTC, Andrei Alexandrescu wrote:
On 2/26/15 8:51 AM, Steven Schveighoffer wrote:
As talked about before, running dtors in the originating thread can
solve this problem.
Yah, that will solve the nonatomic reference counting. What do you
think about http://forum.dlang.org/thread/mcllre$1abs$1...@digitalmars.com?
Andrei
class BazingaException : Exception {
RefCount!Stuff reallyImportantStuff;
// ...
}
void main() {
auto t = new Thread({
RefCount!Stuff s = ...;
throw new BazingaException(s);
});
t.start();
t.join();
}
Could you please walk me through what the matter is here. Thanks. -- Andrei
The exception is thrown by t.join() in another thread, after the
originating thread died. Thus, obviously, it cannot be destructed in
the originating thread as stated above. But everyone already know that.
But the example doesn't make one problem quite clear: Unless the GC
destroys the exception in the thread join() was called, there can be a
race. That's because join() moves the exception to another thread, and
the thread that now owns the exception could make copies of that
reallyImportantStuff and access the counter beyond the exception's
lifetime. So it turns out that the GC heap needs call the exception's
destructor in the thread calling join() to avoid races.
Additionally, if the old thread has leftover objects still not yet
collected, they'll need to be destroyed in the thread calling join()
too. Otherwise you might get races when the exception is destroyed.
So you could solve all that by changing of ownership for things
originating from the worker thread to the thread that is calling
join(). Or if no one calls join(), then you can destroy objects
originating from the dead thread in any thread, as long as they are all
destroyed *in the same thread* (because objects originating from the
same thread might all points to the same thread-local reference counts).
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On Thursday, 26 February 2015 at 21:17:57 UTC, Benjamin Thaut wrote: Am 26.02.2015 um 20:58 schrieb Walter Bright: It was a generational gc, I described earlier how it used page faults instead of write barriers. I eventually removed the page fault system because it was faster without it. Page faults are inferrior to compiler generated write barriers. Because with a page fault startegy you pay for every write. Even if the write does not write a pointer. Compiler generated write barriers only apply to pointers written through another pointer. It is a tradeof. You can implement write barrier in the codegen. In which case you check them every time, but only for pointers. The check is cheap but creeping. You can implemented them using memory protection. In which case it is WAY more expensive and will trap all the write, but ONLY when needed (it can be turned on and off) and usually you trap once per page. Note that in D, you have union and all kind of crap like that, so what is writing a pointer is non obvious and so the tradeof is very different than it is in other languages.
Re: Is there such a thing?
On Thu, 26 Feb 2015 22:10:15 +, Taylor Hillegeist wrote: One of the listed uses for a unit was if the developer wanted to hide his ip but allow others to use the code. Does D have a way of doing this? you can compile static library and provide autogenerated .di file. compiler will strip out all unnecessary parts from it. signature.asc Description: PGP signature
Re: What am I doing wrong here - canFind with iota is not working
Hi John. Tks help with ldc - will look at that shortly. So Kingsly needs to use a predicate for canFind that returns true if the two values being compared are close enough to being the same given floating point quirks ? Ie I think people diagnosed the problem, but what is the solution... On Thursday, 26 February 2015 at 11:00:05 UTC, John Colvin wrote: On Thursday, 26 February 2015 at 10:55:43 UTC, Kingsley wrote: float oneDegree = (PI / 180.0); float first = -(oneDegree * 10.0); float second = (oneDegree * 10.0); float step = 0.01; float[] r = iota(first,second,step).array; writeln(r); float item = 0.174531; writeln(r.canFind(item)); // returns false for canFind - even though that float is in the array ??? Never check floating point numbers for equality, unless you've really thought about how the floating point arithmetic for this specific problem will go. Pretty much the only place it's useful to do is in unit tests for maths libraries.
Re: @trusted and return ref
On Thursday, 26 February 2015 at 10:15:07 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 25 February 2015 at 22:59:01 UTC, anonymous wrote: rule-breaking that's going on there. A public trusted_malloc would invite the un-initiated to shoot their feet. That's entirely social... Sure. A @trusted function that's not actually memory-safe is against the definition of @trusted. Breaking that rule on a public function is not acceptable. Breaking it locally is apparently ok as long as the surrounding entity (RCArray) is actually memory-safe in the end. I'm not trying to argue that this is good. Maybe the current system allows for a better way to solve such issues. If it doesn't, maybe the @safe/@trusted system needs an upgrade. [...] If you can inject new code that is not marked @trusted explicitly into already written code that is marked @trusted, then the trust type system is broken. The whole point of @trusted is to be able to call @system code. It doesn't matter if that code is injected or not. @safe prevents calling @system code. [...] It infers @safe, but it does not provide validation. Yup. RCArray is de-facto trusted, i.e. verified memory-safe by the programmer. It's not compiler verified safe, even though it ends up being labeled @safe.
Re: What am I doing wrong here - canFind with iota is not working
Laeeth Isharc:
Ie I think people diagnosed the problem, but what is the
solution...
A possible solution:
void main() @safe {
import std.stdio, std.range, std.algorithm, std.math;
immutable float oneDegree = (PI / 180.0f);
immutable float first = -(oneDegree * 10.0f);
immutable float second = (oneDegree * 10.0f);
immutable float step = 0.01f;
immutable float[] r = iota(first, second, step).array;
//r.writeln;
immutable float item = 0.174531f;
r.canFind!q{ feqrel(cast()a, cast()b) = 21 }(item).writeln;
}
Bye,
bearophile
Re: Opening temporary files for std.process.spawnProcess input/output
On Wednesday, 25 February 2015 at 19:09:16 UTC, Ali Çehreli wrote:
On 02/25/2015 05:56 AM, wobbles wrote:
Hi,
Any reason why the following wont work?
void main(string[] args)
{
auto pidIn = File.tmpfile();
auto pidOut = File.tmpfile();
auto pid = spawnProcess([ls, ./], pidIn, pidOut,
std.stdio.stdout, null, Config.newEnv);
if(wait(pid) == 0)
writefln(%s, pidOut.readln());
}
The pidOut.readln() throws this exception:
object.Exception@/usr/include/dmd/phobos/std/stdio.d(1377):
Attempt to
read from an unopened file.
I figured tmpfile() would be open for read/write by default?
Also, theres no way to pass in args to File.tmpfile() to make
them
read/write.
Any ideas?
It looks like the file is closed when spawnProcess is finished.
I don't know whether it is done by spawnProcess explicitly or
whether it is a behavior for temporary files.
How about using a pipe? The following works:
import std.stdio;
import std.process;
void main(string[] args)
{
auto pidIn = File.tmpfile();
auto pidOut = pipe();
auto pid = spawnProcess([ls, ./ ],
pidIn, pidOut.writeEnd,
std.stdio.stdout, null,
Config.newEnv);
if(wait(pid) == 0)
writeln(pidOut.readEnd.byLine);
}
Ali
This works, Thanks folks!
Re: Installing DMD From Zip
On 2/26/2015 10:06 PM, anonymous wrote: The pages are still there, they're just not linked from anywhere (except for the sitemap). I don't know what happened. On dmd (installation, flags, etc): http://dlang.org/dmd-linux.html http://dlang.org/dmd-windows.html http://dlang.org/dmd-osx.html http://dlang.org/dmd-freebsd.html Introduction to std.datetime: http://dlang.org/intro-to-datetime.html D Slices: http://dlang.org/d-array-article.html Thanks!
Re: @trusted and return ref
On 2/24/15 5:37 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
Since neither Andrei or Walter are able to say something sensible on
these issues when asked, I apparently need to learn something about the
consistency of C memory safety.
I'm happy to listen to anyone who can explain this to me:
1. My understanding is that @trusted is supposed to give memory safety
escapes by providing a context which reestablish a memory safety context
on return.
Yet in this thread
http://forum.dlang.org/thread/mcik3j$153g$1...@digitalmars.com it is stated
that this paradigm is an example of «careful use of @trusted»:
count = (() @trusted = cast(uint*) malloc(uint.sizeof))();
…arbitrary code…
(() @trusted = free(count))();
This isn't exactly what is happening.
First, malloc should be safe, in the same way new is safe. The fact that
@trusted is needed is somewhat incorrect in my opinion.
Where @trusted SHOULD be needed is for `free`.
Now, I disagree that using a @trusted delegate for the free is the right
thing to do. As soon as you free count, it is no longer safe, because
it's a dangling pointer.
I would say THIS is somewhat correct:
(() @trusted {free(count); count=null;})();
This takes something that is validly safe, and keeps the safety by
ensuring the pointer is no longer dangling.
However, we have an issue here. At any point inside the code, you could do:
oldcount = count;
And now, there is still potentially a dangling pointer somewhere. This
means every place count is used must be checked. In this case, all uses
of count have to be re-checked when the file is edited.
Because count leaks the memory details of the trusted call to free (In
other words, the fact that count, or any copy of it, can become a
dangling pointer), I believe every call in that type that deals with
count should be marked trusted.
This is a great example of why @trusted is mostly a convention thing,
and not an enforceable thing. And it's very difficult to get right.
There is no way to say compiler, count is tainted. Please error
whenever anyone uses count without marking that code as @trusted.
They way I see it, this is equivalent to typing a reinterpret_casting
malloc and free as memorysafe operations in isolation, basically
providing a malloc!int() and free() as memory safe functions. But why is
malloc and free not considered safe by default then? These @trusted
functions clearly cannot prevent leaks within their own context. You
would need a @trusted-only storage class on the receiving pointer to do
that and a @trusted move type.
If this is careful use of @trusted, then I don't see the point of having
@trusted at all. What is the purpose? What is it meant to cover? In
order for @trusted to make sense in this code segment (
http://dpaste.dzfl.pl/f3d854feede9 ) I would say that the whole class
will have to be marked @trusted. Is that possible?
I agree. I think it's possible, like this:
struct RCArray(E) {
@trusted:
But it doesn't help with mechanical checking -- @trusted is still
basically more dangerous @system code.
-Steve
Re: A Refcounted Array Type
On 2/26/15 8:51 AM, Steven Schveighoffer wrote: As talked about before, running dtors in the originating thread can solve this problem. Yah, that will solve the nonatomic reference counting. What do you think about http://forum.dlang.org/thread/mcllre$1abs$1...@digitalmars.com? Andrei
Re: What am I doing wrong here - canFind with iota is not working
Thanks. Rough version for Wiki here: http://wiki.dlang.org/Floating_Point_Gotchas It could be tidier, but I am not able to do so at moment. Feel free to change. On Thursday, 26 February 2015 at 14:04:17 UTC, John Colvin wrote: On Thursday, 26 February 2015 at 12:39:20 UTC, Laeeth Isharc wrote: Hi John. Tks help with ldc - will look at that shortly. So Kingsly needs to use a predicate for canFind that returns true if the two values being compared are close enough to being the same given floating point quirks ? Ie I think people diagnosed the problem, but what is the solution... My preference would be to find a way to construct the program such that it isn't needed. Failing that, std.math has feqrl and approxEqual for this task.
Re: DList.Range magically becomes empty.
On 2/26/15 11:07 AM, Tobias Pankrath wrote: On Thursday, 26 February 2015 at 15:57:22 UTC, Steven Schveighoffer wrote: On 2/25/15 4:58 AM, Ivan Timokhin wrote: Tobias Pankrath wrote: writefln(stack: %s, stack[]); //fine This call consumes all ranges stored in stack, so they're empty afterwards. This has to be a bug. stack[] should produce a range that can be iterated without destroying the data in the container. If it doesn't, it should be supported. -Steve Haven't looked into it, but I'd rather say that writefln (or formattedWrite, or what is used) should only take ranges per ref, if they cannot be copied and cannot be saved. OK, this is more complex than I thought. Both stack[] and list[] are providing copies. I mistakenly thought that because stack prints empty that the list has been emptied. It hasn't, just the ranges are emptied. Yes, I agree, it's writefln that should be fixed here. -Steve
Re: A Refcounted Array Type
On 2/24/15 3:34 PM, Walter Bright wrote: On 2/24/2015 6:56 AM, Steven Schveighoffer wrote: Actually, RCArray can never be allocated on GC, or you may corrupt memory. count may be non-null, and point at invalid memory when the dtor is called. Just set count to null after the delete. No, the GC may have already deallocated the memory count points at, and count is still non-null. This is why you can never refer to GC-allocated memory in dtors, if they can be called from the GC. Only safe way to do this is to C malloc/free the count. And yes, at that point, you need atomics. No, RCArray is not intended for shared access between threads. GC is what shares the access. For instance, if you have an RCArray in one object that is being collected, it will attempt to decrement count. However, that doesn't mean that another RCArray reference in the originating thread won't also be trying to adjust count. In reality, it's only shared between the GC-collection running thread and the originating thread. I was not talking at all about making RCArray shared-usable. As talked about before, running dtors in the originating thread can solve this problem. -Steve
Re: My Reference Safety System (DIP???)
On Thursday, 26 February 2015 at 16:40:27 UTC, Zach the Mystic
wrote:
int r; // declaration scopedepth(0)
void fun(int a /*scopedepth(0)*/) {
int b; // depth(1)
{
int c; // depth(2)
{
int d; // (3)
}
{
int e; // (3)
}
}
int f; // (1)
}
You have element of differing lifetime at scope depth 0 so far.
Sorry for the delay.
I made a mistake. Parameter `a` will have a *declaration* scope
of 1, just like int b above. It's *reference* scope will have
depth 0, with the mystery bit for the first parameter set.
That is, `a` would have such a reference scope is it were a
reference type... :-)
Re: My Reference Safety System (DIP???)
On Wednesday, 25 February 2015 at 18:08:55 UTC, deadalnix wrote:
On Wednesday, 25 February 2015 at 01:12:15 UTC, Zach the Mystic
wrote:
int r; // declaration scopedepth(0)
void fun(int a /*scopedepth(0)*/) {
int b; // depth(1)
{
int c; // depth(2)
{
int d; // (3)
}
{
int e; // (3)
}
}
int f; // (1)
}
You have element of differing lifetime at scope depth 0 so far.
Sorry for the delay.
I made a mistake. Parameter `a` will have a *declaration* scope
of 1, just like int b above. It's *reference* scope will have
depth 0, with the mystery bit for the first parameter set.
Principle 5: It's always un@safe to copy a declaration scope
from a higher scopedepth to a reference variable stored at
lower scopedepth. DIP69 tries to banish this type of thing
only in `scope` variables, but I'm not afraid to banish it in
all @safe code period:
void gun() @safe {
T* t; // t's declaration depth: 1
T u;
{
T* uu = u; // fine, this is normal
T tt;
t = tt; // t's reference depth: 2, error, un@safe
}
// now t is corrupted
}
Bingo. However, when you throw goto into the mix, weird thing
happens. The general idea is good but need refining.
I addressed this further down, in Principle 10. My proposed
solution has the compiler detecting the presence of code which
could both 1) be visited again (through a jump label or a loop)
and 2) is in a branching condition. In these cases it pushes any
statement which copies a reference onto a special stack. When the
branching condition finishes, it revisits the stack, reheating
the scopes in reverse order. If there is a way to defeat this
technique, it must be very convoluted, since the scopes do
nothing but accumulate possibilities. It may even be
mathematically impossible.
Principle 7: In this system, all scopes are *transitive*: any
reference type with double indirections inherits the scope of
the outermost reference. Think of it this way:
It is more complex than that, and this is where most proposals
fail short (including this one and DIP69). If you want to
disallow the assignment of a reference to something with a
short lifetime, you can't consider scope transitive when used
as a lvalue. You can, however, consider it transitive when used
as an rvalue.
The more general rule is that you want to consider the largest
possible lifetime of an lvalue, and the smallest possible one
for an rvalue.
When going through an indirection, that will differ, unless we
choose to tag all indirections, which is undesirable.
I'm unclear about what you're saying. Can you give an example in
code?
Principle 8: Any time a reference is copied, the reference
scope inherits the *maximum* of the two scope depths:
That makes control flow analysis easier, so I can buy this :)
Principle 8: We don't need to know! For all intents and
purposes, a reference parameter has infinite lifetime for the
duration of the function it is compiled in. Whenever we copy
any reference, we do a bitwise OR on *all* of the mystery
scopes. The new reference accumulates every scope it has ever
had access to, directly or indirectly.
That would allow to copy a parameter reference to a global,
which is dead unsafe.
Actually, it's not unsafe, so long as you have the parameter
attribute `noscope` (or possibly `static`) working for you:
void fun(T* a) {
static T* t;
*t = a; // this might be safe
}
The truth is, this *might* be safe. It's only unsafe if the
parameter `a` is located on the stack. From within the function,
the compiler can't possibly know this. But if it forces you to
mark `a` with `noscope` (or is allowed to infer the same), it
tells the caller all it needs to know about `a`. Simply put, it's
an error to pass a local to a `noscope` parameter. And it runs
all the way down: any parameter which it itself passed to a
`noscope` parameter must also be marked `noscope`. (Note: I'm
actually preferring the name `static` at this point, but using
`noscope` for consistency):
T* fun(noscope T* a) {
static T* t;
*t = a; // this might be safe
}
void tun(T* b) {
T c;
fun(c); // error, local
fun(b); // error, unless b also marked (or inferred) `noscope`
}
There is some goodness in there. Please address my comment and
tell me if I'm wrong, but I think you didn't covered all bases.
The only base I'm really worried about is the lvalue vs rvalue
base. Hopefully we can fix that!
Re: An exegesis of Walter's reference counted slice
On 2/24/15 3:03 PM, Andrei Alexandrescu wrote: On 2/24/15 11:55 AM, Steven Schveighoffer wrote: Note, you need to GC.addRange all the elements if the type has references, or else you cannot have GC pointers in the array. For example, an array of class references could potentially result in those references being collected before the array is gone. Ironically, if those elements are references, but are reference counted references, then you wouldn't need to addRange. An interesting problem... Could you please add a detailed issue about this? Thanks. -- Andrei I'm not sure what you mean by 'this'. As far as I can tell, it isn't a bug in GC but a bug in your dpaste code. -Steve
Re: My Reference Safety System (DIP???)
On Thursday, 26 February 2015 at 16:42:30 UTC, Zach the Mystic wrote: That is, `a` would have such a reference scope is it were a reference type... :-) s/is/if/ I seem to be making one more mistake for every mistake I correct.
Re: An exegesis of Walter's reference counted slice
On 2/26/15 8:44 AM, Steven Schveighoffer wrote: On 2/24/15 3:03 PM, Andrei Alexandrescu wrote: On 2/24/15 11:55 AM, Steven Schveighoffer wrote: Note, you need to GC.addRange all the elements if the type has references, or else you cannot have GC pointers in the array. For example, an array of class references could potentially result in those references being collected before the array is gone. Ironically, if those elements are references, but are reference counted references, then you wouldn't need to addRange. An interesting problem... Could you please add a detailed issue about this? Thanks. -- Andrei I'm not sure what you mean by 'this'. As far as I can tell, it isn't a bug in GC but a bug in your dpaste code. -Steve I'm referring to the interesting problem of adding addRange for some but not all types. -- Andrei
Re: static void arrays under garbage control?
On 2015-02-26 10:07, Steven Schveighoffer wrote:
Static data I believe is always scanned conservatively because no
type information is stored for it ever, even on allocation (i.e.
program startup).
ouh, the confusion goes on... are you saying that
{
// will be all scanned by GC for
// potential pointers into GC managed memory:
void[16] buffer0 = void;
ubyte[16] buffer1;
uint[4] buffer3;
// will not be scanned by GC for pointers:
void[] buffer4 = cast(void[])(new ubyte[16]);
uint[] buffer5 = cast(uint[])(new ubyte[16]);
}
Re: An exegesis of Walter's reference counted slice
On 2/26/15 11:56 AM, Andrei Alexandrescu wrote: On 2/26/15 8:44 AM, Steven Schveighoffer wrote: On 2/24/15 3:03 PM, Andrei Alexandrescu wrote: On 2/24/15 11:55 AM, Steven Schveighoffer wrote: Note, you need to GC.addRange all the elements if the type has references, or else you cannot have GC pointers in the array. For example, an array of class references could potentially result in those references being collected before the array is gone. Ironically, if those elements are references, but are reference counted references, then you wouldn't need to addRange. An interesting problem... Could you please add a detailed issue about this? Thanks. -- Andrei I'm not sure what you mean by 'this'. As far as I can tell, it isn't a bug in GC but a bug in your dpaste code. I'm referring to the interesting problem of adding addRange for some but not all types. -- Andrei OK, but I don't know where to add that :( RC isn't supported by D today. You mean add it to a DIP? Add it to the docs? I don't think it's mechanically checkable, BTW. If you have an array of pointers, each pointer may point at a GC-allocated block, or a C malloc-allocated block. I suppose at the time of setting an element, you can addRange if necessary. But the cost for that I think far outweighs the benefit of using RC. -Steve
Re: To GC or Not To GC in std.container.*
On Monday, 23 February 2015 at 21:33:35 UTC, Steven Schveighoffer wrote: It means that it can do that, and does do that in dcollections. std.container does not have all the code to do it, dcollections.RBTree has some extra calls that would probably help. However, the allocation is done in one spot so the code can easily use an allocator. Have anybody done any benchmarks on which allocators are suitable for which containers? I'm especially interested in optimizing RBTree because I want a fast Dikjstra implementation in D: http://rosettacode.org/wiki/Dijkstra%27s_algorithm#D
Re: Opening temporary files for std.process.spawnProcess input/output
On 2/25/15 2:09 PM, Ali Çehreli wrote: It looks like the file is closed when spawnProcess is finished. I don't know whether it is done by spawnProcess explicitly or whether it is a behavior for temporary files. I know the problem is solved, but I wanted to chime in with some explanation here: Yes, it's closed on purpose. Typically, when you open a file descriptor in order to have the child use it for stdin/stdout/stderr, you want to close the handle on the parent, since the parent isn't using it. Even with pipes, there are 2 ends. The child uses one and closes the other, and the parent uses one and closes the other. There is a way to disable this behavior, use Config.retainStdout. http://dlang.org/library/std/process/config.html The only time these aren't closed by default is if the default handles are used (you don't want to close e.g. stdout in the parent if you use it in the child). -Steve
Re: Why rbtree.length isn't const?
On 2/26/15 3:20 AM, drug wrote: Is it intended by some reason? No, it can be fixed. RBTree was not written to support const because D doesn't support tail-const ranges, which makes const really difficult to deal with. But length can definitely be const. Please submit an issue. http://issues.dlang.org -Steve
2nd London D Programmers Meetup - Robot Tank Battle Tournament
Hi, The second London D Programmers Meetup is now officially scheduled for Tuesday 24th March. As usual it's sponsored by Skills Matter and will be at their awesome training facility. This meetup will be all about an awesome robot battle tournament. Come along and bring your laptop and be prepared to build a tank robot that can destroy the opposition in our custom made 2D battle arena. I've used the very excellent DSFML library for the graphics so it's looks nice :) If we come up with a super tank we may start challenging other D meetup groups to a robot tank battle royale extravaganza!! So watch out!!! Here are the details - spread the word: http://www.meetup.com/London-D-Programmers/events/220610394/ thanks --Kingsley
Re: DList.Range magically becomes empty.
On 2/25/15 4:58 AM, Ivan Timokhin wrote: Tobias Pankrath wrote: writefln(stack: %s, stack[]); //fine This call consumes all ranges stored in stack, so they're empty afterwards. This has to be a bug. stack[] should produce a range that can be iterated without destroying the data in the container. If it doesn't, it should be supported. -Steve
Re: DlangIDE
On Friday, 6 February 2015 at 14:03:07 UTC, Vadim Lopatin wrote: Hello, I'm working on cross-platform D language IDE - DlangIDE. It's written in D using DlangUI based GUI. Project on GitHub: https://github.com/buggins/dlangide Recent changes: Package dependencies are now visible in workspace tree. When DUB project is being loaded, all DUB dependency packages are being loaded into workspace tree too. Now it's possible to use GoToDefinition and autocompletion using dependencies. Limitation: so far dependency list is being read from file dub.selections.json on project loading. If dub build was never executed, try run build or dub Upgrade Dependencies, and then reload workspace.
Re: static void arrays under garbage control?
On 2/25/15 8:15 PM, captaindet wrote: if i understand correctly, static arrays are exempt from GC scanning for memory pointers http://dlang.org/garbage.html : Pointers in D can be broadly divided into two categories: Those that point to garbage collected memory, and those that do not. Examples of the latter are pointers created by calls to C's malloc(), pointers received from C library routines, pointers to static data. but there is also a warning for void arrays http://dlang.org/arrays.html : The garbage collector will scan void[] arrays for pointers, since such an array may have been implicitly converted from an array of pointers or an array of elements that contain pointers. does this warning only apply to dynamic void[] arrays but not to static void[CTconstant] arrays? (because sometimes the docs also mean static arrays even if just type[] is written.) thanks! ps: this is for 32bit apps Somewhat missing in this disscusion is: the GC does not know what an array's type currently is, it only knows what it was when it was allocated. So for instance: ubyte[] arr = cast(ubyte[])(new void[100]); // scanned for pointers void[] arr = new ubyte[100]; // not scanned for pointers. In fact, the GC has no idea of type at all. It just knows about memory blocks, and whether those blocks are flagged as having pointers or not having pointers. The call to new is what tells the GC hm.. this is a type that may contain pointers, set that flag! Static data I believe is always scanned conservatively because no type information is stored for it ever, even on allocation (i.e. program startup). -Steve
[Issue 14226] New: invalid Runtime.traceHandler setup
https://issues.dlang.org/show_bug.cgi?id=14226 Issue ID: 14226 Summary: invalid Runtime.traceHandler setup Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: minor Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: ket...@ketmar.no-ip.org in module `core.runtime` at line 50 module constructor for setting up `Runtime.traceHandler` is declared as `static`, whereas tracehandler variable is `__gshared`. so custom trace handler will be reset on each new thread creation. i believe that module ctor must be `shared static` here. --
Re: What am I doing wrong here - canFind with iota is not working
On Thursday, 26 February 2015 at 12:39:20 UTC, Laeeth Isharc wrote: Hi John. Tks help with ldc - will look at that shortly. So Kingsly needs to use a predicate for canFind that returns true if the two values being compared are close enough to being the same given floating point quirks ? Ie I think people diagnosed the problem, but what is the solution... My preference would be to find a way to construct the program such that it isn't needed. Failing that, std.math has feqrl and approxEqual for this task.
Re: What am I doing wrong here - canFind with iota is not working
On Thursday, 26 February 2015 at 11:00:05 UTC, John Colvin wrote: On Thursday, 26 February 2015 at 10:55:43 UTC, Kingsley wrote: float oneDegree = (PI / 180.0); float first = -(oneDegree * 10.0); float second = (oneDegree * 10.0); float step = 0.01; float[] r = iota(first,second,step).array; writeln(r); float item = 0.174531; writeln(r.canFind(item)); // returns false for canFind - even though that float is in the array ??? Never check floating point numbers for equality, unless you've really thought about how the floating point arithmetic for this specific problem will go. Pretty much the only place it's useful to do is in unit tests for maths libraries. This is the classic reference on the topic: http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html but there are loads of other less rigorous explanations around the web. To cut a long story short: floating point maths is not the same as maths with real numbers. It's mostly roughly the same, sometimes catastrophically different and very, very rarely exactly the same.
Mister Math is wanted!
Hello all! Python's fsum is ready for D : https://github.com/D-Programming-Language/phobos/pull/2991 Destroy!
Re: Installing DMD From Zip
On Thursday, 26 February 2015 at 10:55:40 UTC, Jonathan M Davis wrote: I think that it was the same page, though I could be remembering wrong. Several articles are missing as well (e.g. the one on std.datetime and the one on arrays), so I don't know how careful they really were in updating the website. The pages are still there, they're just not linked from anywhere (except for the sitemap). I don't know what happened. On dmd (installation, flags, etc): http://dlang.org/dmd-linux.html http://dlang.org/dmd-windows.html http://dlang.org/dmd-osx.html http://dlang.org/dmd-freebsd.html Introduction to std.datetime: http://dlang.org/intro-to-datetime.html D Slices: http://dlang.org/d-array-article.html
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On Thursday, 26 February 2015 at 11:28:16 UTC, ponce wrote: That's the problem with future/promises, you spent your time explaining who waits for what instead of just writing what things do. There are many ways to do futures, but I don't think it is all that complicated for the end user in most cases. E.g. auto a = request_db1_async(); auto b = request_db2_async(); auto c = request_db3_async(); auto d = compute_stuff_async(); r = wait_for_all(a,b,c,d); if( has_error(r) ) return failure; No. If I can't open a file I'd better not create a File object in an invalid state. Invalid states defeats RAII. This is the attitude I don't like, because it means that you have to use pointers when you could just embed the file-handle. That leads to more allocations and more cache misses. So you can't re-enter that mutex as you asked, so I will grant you a scopedLock, but it is in an errored state so you'd better check that it is valid! A file can always enter an errored state. So can OpenGL. That doesn't mean you have to react immediately in all cases. When you mmap a file you write to the file indirectly without any function calls. The disk could die... but how do you detect that? You wait until you msync() and detect it late. It is more efficient.
Re: A Refcounted Array Type
On Thursday, 26 February 2015 at 16:51:30 UTC, Steven Schveighoffer wrote: As talked about before, running dtors in the originating thread can solve this problem. This probably implies forcibly destroying objects whose creating thread terminated.
Re: My Reference Safety System (DIP???)
On Wednesday, 25 February 2015 at 23:33:57 UTC, H. S. Teoh wrote: On Wed, Feb 25, 2015 at 09:26:31PM +, via Digitalmars-d wrote: [...] On Wednesday, 25 February 2015 at 01:12:15 UTC, Zach the Mystic wrote: Principle 3: Extra function and parameter attributes are the tradeoff for great memory safety. There is no other way to support both encapsulation of control flow (Principle 2) and the separate-compilation model (indispensable to D). Function signatures pay the price for this with their expanding size. I try to create the new attributes for the rare case, as opposed to the common one, so that they don't appear very often. IIRC H.S. Teoh suggested a change to the compilation model. I think he wants to expand the minimal compilation unit to a library or executable. In that case, inference for all kinds of attributes will be available in many more circumstances; explicit annotation would only be necessary for exported symbols. I don't remember making any such suggestion... I'm sorry then... I've pulled this from the back of my mind, and I'm sure something similar was actually suggested (not as a formal proposal, mind you). Maybe it was Martin Nowak, because he's working on DIP45 (export)? But better not to speculate, lest more innocent people get accused of proposing things ;-) the closest I can think of is the idea that attribute inference should always be done, and saved as part of the emitted object file(s), perhaps even in generated .di files that contain all inferred attributes. When importing some module, the compiler would read the inferred attributes from the saved information. Programmers won't even need to write any attributes except when they want to override the compiler's inference, but the code will automatically get the benefit of all inferred attributes. Library users would also benefit by having all inferred attributes available in the auto-generated .di files. This can be made to work regardless of what the minimal compilation unit is. Automatic inference also frees us from the concern that functions have too many attributes -- if the compiler will automatically infer most of them for us, we can freely add all sorts of attributes without worrying that it will become impractically verbose to write. Saving this info as part of the object file also lets the compiler take advantage of these extra attributes even when source code isn't available, or perform whole-program optmizations based on them. Yes, I fully agree with that. The one thing that's then missing is a way to disable automatic inference (for stable interfaces); `export` fits that mold.
Re: My Reference Safety System (DIP???)
On Wednesday, 25 February 2015 at 21:26:33 UTC, Marc Schütz wrote:
IIRC H.S. Teoh suggested a change to the compilation model. I
think he wants to expand the minimal compilation unit to a
library or executable. In that case, inference for all kinds of
attributes will be available in many more circumstances;
explicit annotation would only be necessary for exported
symbols.
You probably mean Dicebot:
http://forum.dlang.org/post/otejdbgnhmyvbyaxa...@forum.dlang.org
Anyway, it is a good idea to enable scope semantics implicitly
for all references involved in @safe code. As far as I
understand it, this is something you suggest, right? It will
eliminate annotations except in cases where a parameter is
returned, which - as you note - will probably be acceptable,
because it's already been suggested in DIP25.
Actually you could eliminate `return` parameters as well, I
think. If the compiler has the body of a function, which it
usually does, then there shouldn't be a need to mark *any* of the
covariant function or parameter attributes. I think it's the kind
of thing which should Just Work in all these cases.
Principle 4: Scopes. My system has its own notion of scopes.
They are compile time information, used by the compiler to
ensure safety. Every declaration which holds data at runtime
must have a scope, called its declaration scope. Every
reference type (defined below in Principle 6) will have an
additional scope called its reference scope. A scope
consists of a very short bit array, with a minimum of
approximately 16 bits and reasonable maximum of 32, let's say.
For this proposal I'm using 16, in order to emphasize this
system's memory efficiency. 32 bits would not change anything
fundamental, only allow the compiler to be a little more
precise about what's safe and what's not, which is not a big
deal since it conservatively defaults to @system when it
doesn't know.
This bitmask seems to be mostly an implementation detail.
I guess I'm trying to win over the people who might think the
system will cost too much memory or compilation time.
AFAIU, further below you're introducing some things that make
it visible to the user.
The only things I'm making visible to the user are things which
*must* appear in the function signature for the sake of the
separate compilation model. Everything else would be invisible,
except the occasional false positive, where something actually
safe is thought unsafe (the solution being to enclose the
statement in a @trusted black or lambda).
I'm not convinced this is a good idea; it looks complicated for
sure.
It's not that complicated. My main fear is that it's too simple!
Some of the logic may seem complicated, but the goal is to make
it possible to compile a function without having to visit any
other function. Everything is figured out in house.
I also think it is too coarse. Even variables declared at the
same lexical scope have different lifetimes, because they are
destroyed in reverse order of declaration. This is relevant if
they contain references and have destructors that access the
references; we need to make sure that no reference to a
destroyed variable can be kept in a variable whose destructor
hasn't yet run.
It might be too coarse. We could reserve a few more bits for
depth-constant declaration order. At the same, time, it doesn't
seem *that* urgent to me. But maybe I'm naive about this.
Everything is being destroyed anyway, so what's the real danger?
Principle 5: It's always un@safe to copy a declaration scope
from a higher scopedepth to a reference variable stored at
lower scopedepth. DIP69 tries to banish this type of thing
only in `scope` variables, but I'm not afraid to banish it in
all @safe code period:
For backwards compatibility reasons, it might be better to
restrict it to `scope` variables. But as all references in
@safe code should be implicitly `scope`, this would mostly have
the same effect.
I guess this is the Language versus Legacy issue. I think D's
strength is in it's language, not its huge legacy codebase.
Therefore, I find myself going with the #pleasebreakourcode
crowd, for the sake of extending D's lead where it shines. I'm
not sure all references in safe code need to be `scope` - that
would break a lot of code unto itself, right?
Principle 8: Any time a reference is copied, the reference
^^^
Principle 7 ?
scope inherits the *maximum* of the two scope depths:
T* gru() {
static T st; // decl depth(0)
T t; // decl depth(1)
T* tp = t; // ref depth(1)
tp = st; // ref depth STILL (1)
return tp; // error!
}
If you have ever loaded a reference with a local scope, it
retains that scope level permanently, ensuring the safety of
the reference.
Why is this rule necessary? Can you show an example what could
go wrong without it? I assume it's just there to ease
implementation (avoids the need for data flow analysis)?
You're right. It's only
Re: A Refcounted Array Type
On 2/26/15 11:57 AM, Andrei Alexandrescu wrote: On 2/26/15 8:51 AM, Steven Schveighoffer wrote: As talked about before, running dtors in the originating thread can solve this problem. Yah, that will solve the nonatomic reference counting. What do you think about http://forum.dlang.org/thread/mcllre$1abs$1...@digitalmars.com? I saw that, it sounds reasonable. I have to mull over what it means. I think possibly a better solution is to have a finalize function, similar to how tango does it, so the dtor is only called from destroy/delete, and the finalize method is called from the GC. -Steve
Re: A Refcounted Array Type
On 2/26/15 12:56 PM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: On Thursday, 26 February 2015 at 16:51:30 UTC, Steven Schveighoffer wrote: As talked about before, running dtors in the originating thread can solve this problem. This probably implies forcibly destroying objects whose creating thread terminated. However, this has to be done carefully. For instance, you have to run dtors on next allocation, or when thread terminates, because if you do it inside stop-the-world signal handler, you still potentially have a race. -Steve
Re: static void arrays under garbage control?
On 2/26/15 11:57 AM, captaindet wrote:
On 2015-02-26 10:07, Steven Schveighoffer wrote:
Static data I believe is always scanned conservatively because no
type information is stored for it ever, even on allocation (i.e.
program startup).
ouh, the confusion goes on... are you saying that
{
// will be all scanned by GC for
// potential pointers into GC managed memory:
void[16] buffer0 = void;
ubyte[16] buffer1;
uint[4] buffer3;
Yes, all 3 are stack based. This is not static data, which would be like
uint[4] at module level. Those are also treated as scannable, as the
entire stack of every thread is scanned.
// will not be scanned by GC for pointers:
void[] buffer4 = cast(void[])(new ubyte[16]);
uint[] buffer5 = cast(uint[])(new ubyte[16]);
Correct, since they are allocated as ubyte[]. uint[] also would not be
scanned.
-Steve
Re: A Refcounted Array Type
On 2/26/15 12:56 PM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: On Thursday, 26 February 2015 at 16:51:30 UTC, Steven Schveighoffer wrote: As talked about before, running dtors in the originating thread can solve this problem. This probably implies forcibly destroying objects whose creating thread terminated. I don't think so, those objects can just be destroyed by the GC-collection running thread. If the thread is no longer present, there can't be a race. -Steve
Re: Will D have a standard cross platform GUI toolkit?
Thanks to both answers. I hope there's more support for this kind of things too. I will post other questions soon :)
Re: static void arrays under garbage control?
On 02/26/2015 10:07 AM, Steven Schveighoffer wrote: // will not be scanned by GC for pointers: void[] buffer4 = cast(void[])(new ubyte[16]); uint[] buffer5 = cast(uint[])(new ubyte[16]); Correct, since they are allocated as ubyte[]. uint[] also would not be scanned. I've been under the impression that current GC being imprecise, even an unfortunate bit-pattern in an int would keep otherwise dead objects alive. Is that still true for a single int? And is 'new int[N]' better in this regard because it never keeps objects alive? Ali
[Issue 14227] Incorrect passed a delegate as argument with null value.
https://issues.dlang.org/show_bug.cgi?id=14227
--- Comment #1 from Alexey Poryadin alexey.porya...@gmail.com ---
Starting program: /work/research/test
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
Breakpoint 1, test.Class.set() (this=0x77ed8ff0, callback=..., b=1, a=1) at
/work/research/test.d:7
7writefln((callback !is null) %s, (callback !is null));
(gdb) print callback
$1 = {ctxptr = 0x0, funcptr = 0x3ff0}
(gdb)
---
This is debug output that I took.
--
Is there such a thing?
So, In languages like .net they have dll's that contain not only bytecode but also the necessary headers to make them usable in any .net language. I was curious if this kind of thing has ever been attempted for static libraries? basically some type of universal header + static library = Everything Needed to use in project file. of course they would be targeted for a certain platform but would be really easy to grab/use. And if the header could be agreed upon any compiled language could use the library which would be a huge benefit. Perhaps i'm incorrect in my assumptions. Let me know what you think about the idea?
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On 2/25/2015 8:51 PM, weaselcat wrote: Is this implying you've begun work on a compacting D collector, No. or are you relating to your Java experiences? Yes.
Re: [OT] HTML: div/iframe hybrid?
On 02/26/2015 03:30 AM, Kagamin wrote: AFAIK, div src=... syntax was proposed for this purpose (with fallback) in early editions of html5, don't know if it made it into the standard. Hmm, just looked that up, but all I found on that was one page that implies (sadly, with no sources referenced) it did not make it in: http://hannah.wf/why-dont-all-html-elements-have-a-src-attribute/ However, looks like what happened instead was iframe grew a seamless attribute, which frankly looks pretty damn sweet: http://benvinegar.github.io/seamless-talk/#/12 Still researching browser compatibility and adoption though. TL;DR: New in HTML5: iframe seamless src=url / is the answer (assuming it isn't still *too* new, not sure yet)
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On 2/25/2015 11:01 PM, Benjamin Thaut wrote: What you are describing is a compacting GC and not a generational GC. Please just describe in words how you would do a generational GC without write barriers. Because just as deadalnix wrote, the problem is tracking pointers within the old generation that point to the new generation. It was a generational gc, I described earlier how it used page faults instead of write barriers. I eventually removed the page fault system because it was faster without it.
3 dimension arrays
HI guys!!!
Have a problem with 3d array memory allocation in next code:
//
class NeuronNet(T, const uint layersNum)
{
T[] _inputs;
T[][layersNum - 2] _hidden;
T[] _outputs;
T[] _target;
//waights [col][row][dimension]
T[][][layersNum - 1] _waightsArray;
this(in uint[] nodesArr)
{
//values init
_inputs = new T[nodesArr[0]];
_outputs = new T[nodesArr[$-1]];
for(uint j = 0; j layersNum - 2; j++)
{
_hidden[][j] = new T[nodesArr[j + 1]];
}
//waights init
for(uint i = 0; i layersNum - 1; i++)
{
_waightsArray[][][i] = new T[][nodesArr[1+i]];
for(uint ii = 0; ii nodesArr[1+i]; ii++)
{
_waightsArray[][ii][i] = new T[nodesArr[i]];
}
}
}
}
//
debuger shows array range boundary error in line
_waightsArray[][ii][i] = new T[nodesArr[i]];
Help me please if any one knows
Re: Argumentation protocol [was: Mac Apps That Use Garbage Collection Must Move to ARC]
On 2/25/2015 11:05 PM, Russel Winder via Digitalmars-d wrote: Have you studied the G1 GC? Nope. Any data from the 1990 regarding Java, 1998 or so. I wrote D's GC some years later. and indeed any other programming language with a lifespan of 20+years, is suspect, to say the least. Also what is said above is not data, it is opinion. The day C++ compilers routinely generate write barriers is the day I believe they don't have runtime cost.
Will D have a serious dedicated well supported IDE like Visual Studio or Eclipse?
Hello, This question might have already been asked, but maybe new answers come up, with new updates. I a beginner with D, actually I have almost done nothing. I am using a Mac, and Xamarin Studio seem to be the best choice, but I am not even able to make it auto-complete the standard library. Does anybody know how to do it? My main question is: Will D have a serious dedicated well supported IDE like Visual Studio or Eclipse? Having a dedicated powerful IDE nowadays, in my opinion, is essential, because people don't like to type too much, and that could bring more people to program in D! Are there some open-source projects related to the creation of a D dedicated powerful IDE? Which are the other real serious alternatives? Thanks!
[Issue 14227] Incorrect passed a delegate as argument with null value.
https://issues.dlang.org/show_bug.cgi?id=14227 safety0ff.bugz safety0ff.b...@gmail.com changed: What|Removed |Added Keywords||wrong-code CC||safety0ff.b...@gmail.com --- Comment #2 from safety0ff.bugz safety0ff.b...@gmail.com --- This seems to be a heisenbug in the backend. It disappears when optimizations are enabled. Looking at the assembly, the compiler doesn't clear RDX for the first call to test.Class.set, but does for the second call, resulting in garbage in RDX for the first call. Still occurs with recent git version. --
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On Thursday, 26 February 2015 at 20:15:37 UTC, Walter Bright wrote: I don't really understand your point. Write barriers are emitted for code that is doing a write. That is exactly the point? When you don't write, you don't pay for write barriers. It is fairly straightforward that the argument that write barrier are expensive and undesirable does not follow for immutable heap.
Re: [OT] HTML: div/iframe hybrid?
On 02/26/2015 02:51 PM, Adam D. Ruppe wrote: I don't think it is a security hole, but websites typically do not get to set their viewport - the window size is under the user's control. (one of the few things they have left under the user's control!) So if you told a site to set its own size... it wouldn't really know what that is most the time. At least widths tend to be fluid and variable. Heights sometimes are set dynamically too. There's solutions to this - the containing page might set it to a width, then let the height be fluid. Yea, that's kinda what I had in mind anyway. All these embedded widget things are such a major thing now, and I totally get their appeal and value (want X feature on your site? Just copy/paste this snippet into your page REGARDLESS of your server's language/engine!) But so much of it is done with JS, which is totally unnecessary. Most such things can easily be no-JS iframes (and I guess some are), but one problem is stuff like disqus that needs to grow/expand vertically. Traditional iframe can't really handle that. Looks like HTML5 iframes, thanks to the seamless attribute, WILL be able to handle something like disqus just fine with NO js, but looks like seamless is still rather cutting edge and spotty compatibility despite having been a thing for several years already. Maybe it can be managed well enough with CSS tweakery though, for browsers that aren't ultra cutting edge. That's what most the JS solutions do and it works pretty well. But maybe that still feels too hacky for the standards committees, or is just messy to implement for the browser developers.
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On Thursday, 26 February 2015 at 19:58:56 UTC, Walter Bright wrote: On 2/25/2015 11:01 PM, Benjamin Thaut wrote: What you are describing is a compacting GC and not a generational GC. Please just describe in words how you would do a generational GC without write barriers. Because just as deadalnix wrote, the problem is tracking pointers within the old generation that point to the new generation. It was a generational gc, I described earlier how it used page faults instead of write barriers. I eventually removed the page fault system because it was faster without it. Page fault ARE write barrier.
Re: [OT] HTML: div/iframe hybrid?
I don't think it is a security hole, but websites typically do not get to set their viewport - the window size is under the user's control. (one of the few things they have left under the user's control!) So if you told a site to set its own size... it wouldn't really know what that is most the time. At least widths tend to be fluid and variable. Heights sometimes are set dynamically too. There's solutions to this - the containing page might set it to a width, then let the height be fluid. That's what most the JS solutions do and it works pretty well. But maybe that still feels too hacky for the standards committees, or is just messy to implement for the browser developers.
Re: Will D have a standard cross platform GUI toolkit?
On Thursday, 26 February 2015 at 18:20:12 UTC, Rinzler wrote: Hello, I was wondering if D will have a standard cross platform GUI toolkit. I think that any modern language should provide a cross-platform GUI toolkit. I know that there are some GUI toolkits, but are there cross-platform? Are there serious works? That is, will them always be supported and evolve along with the D programming language? I think that having bindings of a GUI toolkit for a programming languages can be useful, but they have to be well supported. Will QT support D programming language? I really love the Qt framework (except from the fact it's not open source, as far as I know), even though I have not used it a lot. I have to admit that I love D, even if I did not start programming with it. It seems it combines the most useful things of C++ and Java, which are my favourite programming languages. Maybe there are other questions already in the forum, since I am new, I don't know, but a new question, more up to date, can also be useful. Thanks! I can't believe no one has mentioned Dlangui https://github.com/buggins/dlangui.
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On 2/25/2015 9:01 PM, deadalnix wrote: On Thursday, 26 February 2015 at 04:11:42 UTC, Walter Bright wrote: On 2/25/2015 6:57 PM, deadalnix wrote: You seems to avoid the important part of my message : write barrier tend to be very cheap on immutable data. Because, as a matter of fact, you don't write immutable data (in fact you do to some extent, but the amount of write is minimal. There is no reason not to leverage this for D, and java comparison are irrelevant on the subject as java does not have the concept of immutability. The same way, we can use the fact that TL data are not supposed to refers to each others. Of course, you don't pay a write barrier cost when you don't write to data, whether it is immutable or not is irrelevant. It DOES matter as user tends to write way more mutable data than immutable ones. Pretending otherwise is ridiculous. I don't really understand your point. Write barriers are emitted for code that is doing a write. This doesn't happen for code that doesn't do writes. For example: x = 3: // write barrier emitted for write to x! y = x + 5; // no write barrier emitted for read of x! How would making x immutable make (x + 5) faster?
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On 2/25/2015 11:50 PM, Paulo Pinto wrote: Maybe it failed the goal of having C++ developers fully embrace .NET, but it achieved its goal of providing an easier way to integrate existing C++ code into .NET applications, instead of the P/Invoke dance. I wasn't referring to technical success. There is no doubt that multiple pointer types technically works. I was referring to acceptance by the community. Back in the old DOS days, there were multiple pointer types (near and far). Programmers put up with that because it was the only way, but they HATED HATED HATED it.
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On Thursday, 26 February 2015 at 12:06:53 UTC, Baz wrote: On Saturday, 21 February 2015 at 19:20:48 UTC, JN wrote: https://developer.apple.com/news/?id=02202015a Interesting... Apple is dropping GC in favor of automatic reference counting. What are the benefits of ARC over GC? Is it just about predictability of resource freeing? Would ARC make sense in D? Im not here to be liked so let's throw the bomb: http://www.codingwisdom.com/codingwisdom/2012/09/reference-counted-smart-pointers-are-for-retards.html The guy, despite of...well you know, is right, smart ptr are for beginner. The more the experience, the more you can manage memory by your own. Programmer that think they are so smart they handle everything are the very first to screw up because of lack of self awareness. Good, now that we established the author is the retard here, how seriously do we take his rant ?
Re: Will D have a standard cross platform GUI toolkit?
On Thursday, 26 February 2015 at 20:15:53 UTC, Zekereth wrote: On Thursday, 26 February 2015 at 18:20:12 UTC, Rinzler wrote: Hello, I was wondering if D will have a standard cross platform GUI toolkit. I think that any modern language should provide a cross-platform GUI toolkit. I know that there are some GUI toolkits, but are there cross-platform? Are there serious works? That is, will them always be supported and evolve along with the D programming language? I think that having bindings of a GUI toolkit for a programming languages can be useful, but they have to be well supported. Will QT support D programming language? I really love the Qt framework (except from the fact it's not open source, as far as I know), even though I have not used it a lot. I have to admit that I love D, even if I did not start programming with it. It seems it combines the most useful things of C++ and Java, which are my favourite programming languages. Maybe there are other questions already in the forum, since I am new, I don't know, but a new question, more up to date, can also be useful. Thanks! I can't believe no one has mentioned Dlangui https://github.com/buggins/dlangui. Is it stable? Do you think it will have future?
Re: Will D have a standard cross platform GUI toolkit?
On Thursday, 26 February 2015 at 18:20:12 UTC, Rinzler wrote: I was wondering if D will have a standard cross platform GUI toolkit. Maybe some day, but probably not because there's not enough agreement on which one to use or what it should do. There's a few different ones out there that people maintain themselves, but none are considered standard - you just pick the one that looks right to you. Among the options are: gtkd: https://github.com/gtkd-developers/GtkD tkd: https://github.com/nomad-software/tkd qtd (old): https://github.com/qtd-developers/qtd my simpledisplay.d and color.d if you just need the basic drawing https://github.com/adamdruppe/arsd/blob/master/simpledisplay.d https://github.com/adamdruppe/arsd/blob/master/color.d And I think there's a few others but I don't remember their names right now. You can also use C libraries like SDL from D. Will QT support D programming language? I doubt Nokia themselves will officially support D, but D is getting better and better C++ integration, so it shouldn't be long until it is possible for us to bind to the library. (It already is in some limited amount, but it isn't easy to use. There's also bindings to it through an intermediate layer, but they tend to be buggy and not well maintained (last I heard anyway) as well as kinda heavyweight.) So my answer to this is probably yes, but I wouldn't expect it to be ready for serious use for another year. Qt is open source btw.
Re: Invoking MAGO debugger
On Thursday, 26 February 2015 at 10:20:31 UTC, Vadim Lopatin wrote: Hello! I'm trying to integrate MAGO into DlangIDE. I can easy create instance of MAGO DebugEngine, but having problems with obtaining of IDebugPort which is needed for invoking of LaunchSuspended. It looks like to get IDebugPort, I need IDebugCoreServer2 instance. Does anybody know how to do it? Normally, it's being created by VisualStudio AFAIK. Best regards, Vadim I once remember pulling out my hair trying todo the same in order to get it to work with a monodevelop win32 debugger addon. It resulted in a writing new clr wrapper with a different exposed interface https://github.com/aBothe/MagoWrapper e.g. of how the debugee was was launched here: https://github.com/aBothe/MagoWrapper/blob/master/DebugEngine/MagoWrapper/NativeDebugger.cpp
Re: Will D have a standard cross platform GUI toolkit?
On Thursday, 26 February 2015 at 18:20:12 UTC, Rinzler wrote: Hello, I was wondering if D will have a standard cross platform GUI toolkit. I think that any modern language should provide a cross-platform GUI toolkit. I know that there are some GUI toolkits, but are there cross-platform? Are there serious works? That is, will them always be supported and evolve along with the D programming language? I think that having bindings of a GUI toolkit for a programming languages can be useful, but they have to be well supported. Will QT support D programming language? I really love the Qt framework (except from the fact it's not open source, as far as I know), even though I have not used it a lot. I have to admit that I love D, even if I did not start programming with it. It seems it combines the most useful things of C++ and Java, which are my favourite programming languages. Maybe there are other questions already in the forum, since I am new, I don't know, but a new question, more up to date, can also be useful. Thanks! You may want to check out DOtherSide, which is a set of bindings to QML: https://github.com/filcuc/DOtherSide
Re: Memory safety depends entirely on GC ?
Here's my best so far: http://forum.dlang.org/post/offurllmuxjewizxe...@forum.dlang.org On Tuesday, 24 February 2015 at 20:53:24 UTC, Walter Bright wrote: My criticisms of it centered around: 1. confusion about whether it was a storage class or a type qualifier. My system has neither. Instead, it just bans unsafe reference copying in @safe code. 2. I agree with Andrei that any annotation system can be made to work - but this one (as are most annotation systems) also struck me as wordy, tedious, and aesthetically unappealing. I just can't see myself throwing it up on a slide and trying to sell it to the audience as cool. 3. In line with (2), I want a system that relies much more on inference. We've made good progress with the existing annotations being inferred. Well you know I'm on board with this. The one penalty my system requires is two more parameter attributes, which I'm hoping can be alleviated by inference as much as possible. 4. I didn't see how one could, for example, have an array of pointers: int*[] pointers; and then fill that array with pointers of varying ownership annotations. 5. The (4) homogeneity requirement would mean that templated types would get new instantiations every time they are used with a different ownership. This could lead to massive code bloat. I deliberately designed my system to avoid all associations with type. No code bloat. 6. The 'return ref' scheme, which you have expressed distaste for, was one that required the fewest instances of the user having to add an annotation. It turned out that upgrading Phobos to this required only a handful of annotations. 7. 'return ref' makes memory safe ref counted types possible, finally, in D, without needing to upend the language or legacy code. And as the example I posted showed, they are straightforward to write. Only time and experience will tell if this will be successful, but it looks promising and I hope you'll be willing to give it a chance. I do give it a chance! See my proposal!
Re: LDC for iOS
On 2015-02-26 19:34, Dan Olson wrote: I think this all is in good enough shape that someone else should give it a try. Awesome work. I could successfully compile the compiler and compile Hello World without any problems. I did not try running it on an a device. -- /Jacob Carlborg
LDC for iOS
I think this all is in good enough shape that someone else should give it a try. https://github.com/smolt/ldc-iphone-dev This is an LDC development sandbox for iPhone iOS. It glues together various pieces needed to build an LDC cross compiler targeting iPhoneOS. It also includes a few samples to show how to get started. The compiler and libraries are in good enough shape to pass the druntime/phobos unittests with a few minor test failures (see project README.md). This means someone could, if so inclined, build their D library and use it in an iOS App. Currently based on LDC 0.15.1 (DMD v2.066.1) and LLVM 3.5.1. There are no prebuild binaries, so you have to do it yourself. Nobody has reported yet on trying to build beside me, so there may be potholes. Enjoy, Dan
Re: Will D have a standard cross platform GUI toolkit?
On 2015-02-26 19:20, Rinzler wrote: Hello, I was wondering if D will have a standard cross platform GUI toolkit. I think that any modern language should provide a cross-platform GUI toolkit. I know that there are some GUI toolkits, but are there cross-platform? Are there serious works? That is, will them always be supported and evolve along with the D programming language? I think that having bindings of a GUI toolkit for a programming languages can be useful, but they have to be well supported. Will QT support D programming language? I really love the Qt framework (except from the fact it's not open source, as far as I know), even though I have not used it a lot. I have to admit that I love D, even if I did not start programming with it. It seems it combines the most useful things of C++ and Java, which are my favourite programming languages. Since Java is one of your favorite languages I can recommend DWT [1], a port of SWT to D. It works for Windows and Linux, a port of OS X is being worked on. [1] https://github.com/d-widget-toolkit/dwt -- /Jacob Carlborg
[Issue 14227] New: Incorrect passed a delegate as argument with null value.
https://issues.dlang.org/show_bug.cgi?id=14227
Issue ID: 14227
Summary: Incorrect passed a delegate as argument with null
value.
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: alexey.porya...@gmail.com
import std.stdio;
class Class
{
void set(int a, double b, void delegate(int revents) callback)
{
writefln((callback !is null) %s, (callback !is null));
}
}
void main()
{
auto c = new Class;
c.set(1, 1, null); // prints: (callback !is null) true
c.set(1, 1, null); // prints: (callback !is null) false
}
-
Very strange. It dependent on previous argument number and types. For example
if they both has type int, it work correct.
DMD64 D Compiler v2.066.1
Linux desktop 3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 2015
x86_64 x86_64 x86_64 GNU/Linux
--
Will D have a standard cross platform GUI toolkit?
Hello, I was wondering if D will have a standard cross platform GUI toolkit. I think that any modern language should provide a cross-platform GUI toolkit. I know that there are some GUI toolkits, but are there cross-platform? Are there serious works? That is, will them always be supported and evolve along with the D programming language? I think that having bindings of a GUI toolkit for a programming languages can be useful, but they have to be well supported. Will QT support D programming language? I really love the Qt framework (except from the fact it's not open source, as far as I know), even though I have not used it a lot. I have to admit that I love D, even if I did not start programming with it. It seems it combines the most useful things of C++ and Java, which are my favourite programming languages. Maybe there are other questions already in the forum, since I am new, I don't know, but a new question, more up to date, can also be useful. Thanks!
Re: Will D have a standard cross platform GUI toolkit?
By the way, which, in your opinion, is the most performant and more stable?
Re: Will D have a standard cross platform GUI toolkit?
On Thursday, 26 February 2015 at 18:49:39 UTC, Rinzler wrote: By the way, which, in your opinion, is the most performant and more stable? I personally can't help you there, as I've never done any GUI programming in D. Maybe you can test a few of them out and write a report :o)
