Re: ow Integers Should Work
On 2011-Dec-05 18:30:54+00:00, bearophile wrote: Manu: but I don't believe I'm alone.. the rest of the gamedev community will find D soon enough if the language gets it right... I think games are one of the most important short-term purposes of D, despite I think D was not explicitly designed to write games. I played a game, where experience counter was int32, it wasn't meant to overflow during normal play, but it allowed console commands, which could be a lot of fun, so I made xp overflow to negative values, it didn't make any trouble, just in the case it used checked arithmetic, it would crash, not so much fun.
Re: Java > Scala
On 2011-12-06 20:14, Adam Wilson wrote: My goal for the project is what you would term non-native in that it does not make use of the OS widgets; however the plan is to provide native looking skins for the widgets. I'd like to design something that interfaces with the machine at a lower level than widgets. On Windows I am targeting Direct2D, on Linux, OpenGL is the best candidate, and on OSX, well OpenGL might work but OSX has a lot of options to explore, and I don't have access to a Mac. On Mac OS X you don't have many choices on that level, basically only OpenGL. There's Quartz but that is a higher level than OpenGL (I think). (Anybody know how to get OSX working on VirtualBox?) You're only allowed to install Mac OS X virtually on a physical Mac. For a version below 10.7 you are only allowed to use Mac OS X Server. You are allowed to install the client version virtually of 10.7 or higher. But that still needs to be install on a physical Mac. That said, I read that VMware Fusion 4.1 allows to install client versions of 10.5 and 10.6 because of a mistake made by VMware (don't know if that allows to install on a physical PC). Another alternative is to install Mac OS X on a physical PC anyway (virtually or native). How to do that is quite simple and easy to find by searching at google or similar. Note that you're not allowed to do any of this according to the Apple's licenses. I'm just saying it's possible. -- /Jacob Carlborg
Is D associative array thread safe, and will it relocate memory when add or delete a value?
Is D associative array thread safe, and will it relocate memory when add or delete a value? Where I can find the implemention.
Re: Is D associative array thread safe, and will it relocate memory when add or delete a value?
On 2011-12-07 08:59, raojm wrote: > Is D associative array thread safe, and will it relocate memory when > add or delete a value? > > Where I can find the implemention. You should be able to find the implementation somewhere in druntime: https://github.com/D-Programming-Language/druntime -- /Jacob Carlborg
Re: Is D associative array thread safe, and will it relocate memory when add or delete a value?
On Wed, 07 Dec 2011 08:59:32 +0100, raojm wrote: Is D associative array thread safe, and will it relocate memory when add or delete a value? Where I can find the implemention. No it's not, and yes it has to relocate memory. It's working as a hashtable not a binary tree, so all pointers will be invalidated by adding/removing. https://github.com/D-Programming-Language/druntime/blob/master/src/rt/aaA.d
Re: The current status of D?
On 12/07/2011 08:35 AM, Kagamin wrote:
int z = 0;
int foo(int x, int y) { return x + y; }
int bar(int x) { z++; return x * x + z; }
int baz(int x) { z--; return 2 * x + z; }
int main() {
int w = foo(bar(5), baz(3));
return w;
}
See also:
http://en.wikipedia.org/wiki/Sequence_point
I think ',' in parameter lists are already sequence points.
They aren't, but a function call is a sequence point, so bar is
guaranteed to be called before baz.
?
If bar is guaranteed to be called before baz, then the ',' is associated
with a sequence point. You are right that there is a sequence point
before a function call, but that only guarantees that bar and baz are
called before foo, and says nothing about the evaluation order of bar
and baz (note that function calls are sequence points in C/C++, but the
order of argument evaluation is unspecified).
Re: The current status of D?
On 06.12.2011 09:37, bearophile wrote: Don: Right. But it's hard to come up with high-priority language issues these days. The old ones have been fixed..< There are several things that I'd like to see fixed/improved in D still. Yes, of course. But most of the showstoppers are done. Not so long ago there were major features in the spec or in TDPL that weren't implemented at all - contracts, @safe, pure, inout, TDPL operator overloading, almost nothing worked in CTFE, Phobos didn't compile on 64 bits, ...
Re: DDMD
Andrej Mitrovic Wrote: > This is much harder than I expected it to be.. > > It's problematic because everything has to be hand-ported. And things > aren't so obvious, as DDMD introduces some of its own helper > functions. > > I think to really port this properly I would need to know the ins and > outs of the compiler (or at least its front-end). Otherwise I could > end up blindly converting C code to D without paying too much > attention on what it does. > > Yikes! Sorry guys, I think I'll have to pass on this project for now. > Maybe in a few months I'll check it out again, but not now. I hate > chickening out, but I'd do more damage than good if I blindly > translated this to D. Sowwy! :/ thanks! Call ddmd resurrection ! thanks all ! dolive ºô»½Ëû¸´»î
Re: Looking forward to the resurrection ddmd
Daniel Murphy Wrote: > "Nick Sabalausky" wrote in message > news:j4gflo$1c59$1...@digitalmars.com... > > I'm wondering if maybe the problem is that it needs a different approach. > > I suspect a big part of the reason it's stagnated is because it's > > difficult to update to new versions of DMD. > > > > I think what's needed is an approach where changes from DMD to DDMD are > > minimal. Plus a "staged" approach to maximize DDMD's usefulness while it's > > under development. This is what I have in mind: > > I actually had some success with a similar approach in the past, converting > parts of the lexer to D (before I got sidetracked fixing dmd bugs). For > this to be viable, D needs to be able to call normal C++ functions, C++ > non-virtual member functions (including constructors), and access data > members of C++ classes. > > How about Progress at ? Look forward to ddmd early resurrection ! thanks all ! dolive
Re: Is D associative array thread safe, and will it relocate memory when add or delete a value?
On Wednesday, December 07, 2011 09:10:16 Martin Nowak wrote: > On Wed, 07 Dec 2011 08:59:32 +0100, raojm wrote: > > Is D associative array thread safe, and will it relocate memory when > > add or delete a value? > > > > Where I can find the implemention. > > No it's not, and yes it has to relocate memory. > It's working as a hashtable not a binary tree, so all > pointers will be invalidated by adding/removing. > https://github.com/D-Programming-Language/druntime/blob/master/src/rt/aaA.d Yeah. AFAIK, it's impossible to have a hash table which doesn't risk reallocating something when adding a value to it, unless you limit how many elements it can hold or somesuch, which would make it considerably less useful. Typically, when a hash table gets full enough, it rehashes itself, which definitely involves allocating more memory, and possible reallocating a large portion of what it's already allocated. So, there's no way that an AA can avoid the risk of reallocating when elements are added to it, pretty much regardless of its implementation. It's an attribute of the data structure. But since adding to a hash table obviously isn't going to be atomic, there's no way that it's going to be thread-safe regardless. It would have to have to be using a mutex internally or be synchronized, and there's no way that the built-in AA is going to do that. It would harm efficiency in the general case for a special case. If you're using a shared AA and want to ensure thread- safety, you're going to have to use mutexes or synchronized blocks or whatnot to ensure that only one thread is using it at a time. - Jonathan M Davis
Re: The current status of D?
On Wednesday, December 07, 2011 09:16:48 Don wrote: > On 06.12.2011 09:37, bearophile wrote: > > Don: > >> Right. But it's hard to come up with high-priority language issues > >> these days. The old ones have been fixed..<> > > There are several things that I'd like to see fixed/improved in D still. > > Yes, of course. But most of the showstoppers are done. > Not so long ago there were major features in the spec or in TDPL that > weren't implemented at all - contracts, @safe, pure, inout, TDPL > operator overloading, almost nothing worked in CTFE, Phobos didn't > compile on 64 bits, ... Where does the compiler stand with multiple alias thises (as TDPL describes). AFAIK, it still doesn't support them at all. That would be a major feature from TDPL which hasn't be implemented. But yes, a lot of work has been done, and we're much closer to having everything fully implemented. - Jonathan M Davis
Re: ow Integers Should Work
Don Wrote: > On 07.12.2011 05:11, bcs wrote: > > On 12/05/2011 11:20 PM, Don wrote: > >> On 06.12.2011 05:21, bcs wrote: > >>> On 12/05/2011 08:37 AM, Don wrote: > On 05.12.2011 14:31, bearophile wrote: > > Found through Reddit, two blog posts about how integers should behave > > in system languages (with hardware support): > > > > http://blog.regehr.org/archives/641 > > http://blog.regehr.org/archives/642 > > > > Bye, > > bearophile > > Not very convincing, since he proposes a change to existing > architectures, and seems completely unaware of the overflow flag. > >>> > >>> I think he's looking at it form the language theory standpoint. As such, > >>> architectures has nothing to do with it (the architectures to be > >>> targeted has yet to be defined at that point)and getting access to the > >>> overflow flag would require exposing it natively in the language. > >> > >> It's not that he hasn't specified an architecture. It's a proposal which > >> does not work on _any_ existing architectures! > >> It's pure fantasy. > > > > Well you can do it on x86. The fact the it doesn't provied hardware > > traps is irrelevant. You might need to add a lot of branches but you can > > get the semantics he is asking for. > > > > That said, there is another interesting (but independent) question of > > can it be done efficiently? You might have a very good question there, > > but that isn't the question regehr is considering. > > > >> > >> And he talks about NaN, when he means infinity. Floating point overflow > >> never results in a NaN. > > > > You have a point there. > > > >> He doesn't seem to know anything about > >> saturating integer arithmetic, which exists in hardware (even x86 > >> machines have supported a couple of operations since 1996). > >> > >> Useless. > > > > Again, he's not interested in the hardware implementation, he's only > > interested in the defined semantics of the language, the things you can > > count on regardless of that instruction set you are using. The fact the > > x86 has saturating integer operations is moot because C doesn't have a > > type the end up using them. > > He's talking about system languages. A system language has to have a > close relationship to the architecture. Ada is a systems language and if I am not mistaken allows for the type of rules he is describing. C# is also used as systems language in the Singularity project (Sing# + Bartok) and also has some of the strict rules he advocates. I am pretty sure that there are quite a few systems languages that have more precise rules regarding integer overflow.
Re: The current status of D?
http://en.wikipedia.org/wiki/Sequence_point I think ',' in parameter lists are already sequence points. They aren't, but a function call is a sequence point, so bar is guaranteed to be called before baz. ? If bar is guaranteed to be called before baz, then the ',' is associated with a sequence point. You are right that there is a sequence point before a function call, but that only guarantees that bar and baz are called before foo, and says nothing about the evaluation order of bar and baz (note that function calls are sequence points in C/C++, but the order of argument evaluation is unspecified). Well, if sequence points don't go in a sequence, that would mean a total mess. Order of argument evaluation is usually unspecified because arguments are usually simple values and thus don't contain sequence points.
Re: SCons support for D
On Tue, 06 Dec 2011 18:14:25 + Russel Winder wrote: > SCons is a Python-based build tool to replace Make and much of the > Autotools functionality. It has D support as part of the core. This > support is though in need of development. > > The new Mercurial/BitBucket infrastructure for developing SCons > (replacing the old Subversion/Tigris set up) is now in place, a new > release 2.1.0 has been declared and everything is open for business > leading to a 2.2.0 release. > > I got my changes to support DMD 2 into this release :-) > > However, support for GDC, LDC, etc. is almost certainly still sadly > lacking, and indeed the support for DMD almost certainly needs a > severe refactoring and most likely a rewrite. > > Rather than people having to work on a clone of SCons in order to work > on the tool, I have created a separate Mercurial repository > (https://bitbucket.org/russel/scons_dmd_new) as a development version > of just the tool. When a new version of this separate tool is > declared I create a pull request for the SCons mainline to get the > new version in the next version of SCons. > > Is anyone else other than me interested in using SCons as a build tool > with D code? If there is, perhaps we can collaborate in some way to > progress SCons support for all the various realizations of D? > I think the build tool question is in need of the same level of high level design and support that Steve Teale is working on for std.database/std.sql. It seems there is SCons support (python), CMake, Orbit (Ruby), DSSS (D1 only?), xfbuild, dake, rdmd options - I've added preliminary D support to premake. Would it be a good idea to thrash out the arguments for/against a particular tool, and build/support just one? The community doesn't seem big enough to be so fragmented. Java has Ant, Scala has sbt - surely D should have a canonical build tool? -- Andrew Gough M: 0408 596 656 and...@goughy.org signature.asc Description: PGP signature
Re: SCons support for D
On Wed, 2011-12-07 at 20:27 +1100, Andrew Gough wrote: [...] > I think the build tool question is in need of the same level of high > level design and support that Steve Teale is working on for > std.database/std.sql. I am not sure I quite get that, sorry. > It seems there is SCons support (python), CMake, Orbit (Ruby), DSSS > (D1 only?), xfbuild, dake, rdmd options - I've added preliminary D > support to premake. As far as I am aware the C, C++, Fortran communities use Make, Autotools, SCons, CMake or Waf. I suspect they have never heard of DSSS, xfbuild, dake or rdmd ;-) > Would it be a good idea to thrash out the arguments for/against a > particular tool, and build/support just one? The community doesn't > seem big enough to be so fragmented. Java has Ant, Scala has sbt - > surely D should have a canonical build tool? I use SCons for much of my builds of LaTeX, C, C++, Fortran, Haskell, D, OCaml, etc. It works nicely for multi-target, multi-platform builds. I use Waf for "ship the source, compile on installation" FOSS projects. I have given up on Autotools. CMake's language is dreadful so I only use that if necessary. Java has Gradle, Maven, Gant, and Ant. Using Ant for builds is like using assembly language to create GUI applications -- possible but not recommended. Scala has sbt because the Scala community couldn't abide the multi-languages approach, everything has to be Scala. Clojure has a similar philosophy and hence Leiningen. Sure D can use D as the build specification language and follow the inward looking Scala and Clojure approaches of creating a new tool for build. But that is just trying to create a closed system. Is this closed approach really what the D community wants to do -- is following the Scala and Clojure philosophy desirable? The advantage of Gradle and Maven as build tools for JVM based systems is that you can write multi-lingual systems and build them. Java, Scala, Groovy, JRuby, Clojure -- all can be used in a single system. sbt has problems with this since it assumes all source is Scala (more or less). The Java community is rapidly giving up its "Java is all you need" attitude and is looking positively at the polyglot approach. D sits in a context of C, C++, Fortran (possible others?) which means something like SCons, Waf and CMake which has support for all these already baked in seems like a "less work" way forward. So the strategy is one of: Do we work with a build framework that exists and already allows serious build using D; or do we start from scratch with a new build framework that no-one can use till something is ready? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: ow Integers Should Work
Kagamin: >I played a game, where experience counter was int32, it wasn't meant to >overflow during normal play, but it allowed console commands, which could be a >lot of fun, so I made xp overflow to negative values, it didn't make any >trouble, just in the case it used checked arithmetic, it would crash, not so >much fun.< If that game is written in C/C++ then those languages don't define what happens when you add 1 to the max signed integer. This means crashing the game in that case is OK according to the specs of those languages. And even if that experience counter is an unsigned integer, that in C/C++ has to wrap to zero, how many signed or unsigned 32 bit integers there are in a game? A lot. I presume that for most of them a silent wrap to the minimum integer doesn't lead to a fun game. As it usually happens in complex systems, there are far more ways for that system to not work than to work. In most cases implicit modular arithmetic doesn't lead to smooth error behaviours. Bye, bearophile
Re: ow Integers Should Work
Manu: > but making standard ints compromise basic hardware implementation just won't > fly.< Ada language does those things, and it's used to fly planes :-) So maybe it will fly. Today some online games are managing real money of the players. You don't want to use raw integers to manage those important numbers :-) Bye, bearophile
Re: SCons support for D
On Wed, 07 Dec 2011 09:54:08 + Russel Winder wrote: > On Wed, 2011-12-07 at 20:27 +1100, Andrew Gough wrote: > [...] > > I think the build tool question is in need of the same level of high > > level design and support that Steve Teale is working on for > > std.database/std.sql. > > I am not sure I quite get that, sorry. I'm suggesting that the current multi-pronged approach to providing a workable build system is hampered by the multitude of directions and could benefit from some initial discussion, consensus and design. > > > It seems there is SCons support (python), CMake, Orbit (Ruby), DSSS > > (D1 only?), xfbuild, dake, rdmd options - I've added preliminary D > > support to premake. > > As far as I am aware the C, C++, Fortran communities use Make, > Autotools, SCons, CMake or Waf. I suspect they have never heard of > DSSS, xfbuild, dake or rdmd ;-) I agree that it would be good to use a tool with support for multiple languages & platforms. I was trying to point out that the multitude of options is potentially harmful. > > > Would it be a good idea to thrash out the arguments for/against a > > particular tool, and build/support just one? The community doesn't > > seem big enough to be so fragmented. Java has Ant, Scala has sbt - > > surely D should have a canonical build tool? > > I use SCons for much of my builds of LaTeX, C, C++, Fortran, Haskell, > D, OCaml, etc. It works nicely for multi-target, multi-platform > builds. I use Waf for "ship the source, compile on installation" > FOSS projects. I have given up on Autotools. CMake's language is > dreadful so I only use that if necessary. > > Java has Gradle, Maven, Gant, and Ant. Using Ant for builds is like > using assembly language to create GUI applications -- possible but not > recommended. > Simple Ant scripts are easy, but XML is a very bad choice for a build system IMO > Scala has sbt because the Scala community couldn't abide the > multi-languages approach, everything has to be Scala. Clojure has a > similar philosophy and hence Leiningen. > > Sure D can use D as the build specification language and follow the > inward looking Scala and Clojure approaches of creating a new tool for > build. But that is just trying to create a closed system. Is this > closed approach really what the D community wants to do -- is > following the Scala and Clojure philosophy desirable? > Not really what I was suggesting - I was hoping to discuss consolidating effort around a small set of tools, rather than the current state. > The advantage of Gradle and Maven as build tools for JVM based systems > is that you can write multi-lingual systems and build them. Java, > Scala, Groovy, JRuby, Clojure -- all can be used in a single system. > sbt has problems with this since it assumes all source is Scala (more > or less). The Java community is rapidly giving up its "Java is all > you need" attitude and is looking positively at the polyglot approach. > > D sits in a context of C, C++, Fortran (possible others?) which means > something like SCons, Waf and CMake which has support for all these > already baked in seems like a "less work" way forward. > > So the strategy is one of: > > Do we work with a build framework that exists and already allows > serious build using D; or > Possibly. > do we start from scratch with a new build framework that no-one can > use till something is ready? > Possibly (if necessary) I thought it important to have a discussion first to determine the requirements and use cases, and concentrate effort rather than disperse it. -- Andrew Gough M: 0408 596 656 and...@goughy.org signature.asc Description: PGP signature
Re: ow Integers Should Work
On 12/07/2011 11:46 AM, bearophile wrote: Manu: but making standard ints compromise basic hardware implementation just won't fly.< Ada language does those things, and it's used to fly planes :-) So maybe it will fly. Maybe. Ada in action: http://www.youtube.com/watch?v=kYUrqdUyEpI Today some online games are managing real money of the players. You don't want to use raw integers to manage those important numbers :-) Therefore, don't do that.
Re: The current status of D?
On 07-12-2011 09:16, Don wrote: On 06.12.2011 09:37, bearophile wrote: Don: Right. But it's hard to come up with high-priority language issues these days. The old ones have been fixed..< There are several things that I'd like to see fixed/improved in D still. Yes, of course. But most of the showstoppers are done. Not so long ago there were major features in the spec or in TDPL that weren't implemented at all - contracts, @safe, pure, inout, TDPL operator overloading, almost nothing worked in CTFE, Phobos didn't compile on 64 bits, ... Speaking of contracts, what are the plans for: * Supporting contracts in interfaces - sometimes the compiler will not allow this, claiming that a method body must be present (other times it Just Works) * this pointer adjustment in interface contracts - using other interface members in an interface contract currently crashes because the this pointer isn't adjusted correctly * Supporting pre-state (AKA 'old') * Supporting contracts specific to exceptional function exit ? These are all rather essential to have usable contract programming, probably most significantly the interface ones. - Alex
Re: ow Integers Should Work
On 12/07/2011 11:41 AM, bearophile wrote: [...] As it usually happens in complex systems, there are far more ways for that system to not work than to work. [...] Maybe we should exclusively study the ways for for the system to work, as that seems to be less complex.
Re: Haxe (From: Java > Scala -> new thread: GUI for D)
Am 06.12.2011 18:00, schrieb Nick Sabalausky: > "Adrian" wrote in message > news:jbkkpf$cut$1...@digitalmars.com... >> Am 05.12.2011 18:56, schrieb Nick Sabalausky: >> >>> CGI. The only problem now is that that would rule out the possibility of >>> sharing code between both server and client - Which is *NOT* something I >>> want to give up... >>> >> >> That is exactly my point. HaXe' s ability to share the same code on >> client and server side is one of it's killer features. > > Absolutely! > >>> : >>> >>> So to that end, you mentioned Java and C# targets are coming to Haxe? >>> Well, >>> so is D... :) >>> >>> HaxeD: http://www.dsource.org/projects/haxed >>> >> >> interesting - the last time I looked, I thought the project is abandoned. >> > > Nah, I'm pretty hell-bent on getting this working[1]. It's just that > sometimes real-world gets in the way. But I plan to use this for my main > real-world project, so that's helping keep the priority up. > > [1] ...Unless I could get Dax (ie, D -> Haxe) working before finishing > HaxeD, which I would have preferred, but that's definitely not going to > happen: I've decided to put Dax on indefinite hold b/c it's a *much* more > difficult problem: partly because D's features are more-or-less a superset > of Haxe's, and partly b/c Dax is currently based on DDMD which has proven to > be an unsustainable approach to accessing DMD from D. > > IMHO haXe->D is more interesting than D->haXe. [OT] As a side point from a not yet D developer, but someone who looks at the language with great interest, but also someone with a commercial responsibility: I am missing big projects developed in D and the most logic project would be the compiler itself! I know this has been discussed a million times before, but... >>> >>> Why did I write the whole thing from scratch in D as a separate tool, >>> instead of just adding D support to the official Haxe codebase? Ehh, >>> possibly-questionable reasons: >>> >>> 1. Because I looked at Haxe's source and decided I didn't feel like >>> figuring >>> out OCaml before getting started :/ >>> >> >> yes OCaml is another beast. My idea was to take the source of Hugh >> Sandersons C++ target and adopt it to D. For me, D is a much more >> logical target for haXe, because many of the language features fit >> better together. The problem I see with your solution is, that haXe >> evolves very fast and a D target written in OCaml would benefit from >> this, whereas a target written in D is always behind. >> > > Yea, that is definitely the downside of my approach. OTOH, Haxe still > doesn't evolve as fast as, say, D. And I'm optimistic that once I have it > 100% working, updates shouldn't be too difficult. Most of the changes in > each Haxe release are either in the std lib, neko-related, or bug-fixes, > none of which would be applicable to HaxeD (as far as the std lib, HaxeD > will have a copy of the std lib that may add some "#if d" directives where > applicable, and those would need to get merged wih each Haxe release, but > that shouldn't be too hard). > The pro of this approach would be, that there is a second haXe implementation, even if it is bound only to D. The downside would be, that there is the risk of incompatibilities of the compilers, leading to 2 different dialects, which would force the users of both, only to use the subset of the languages. I have this situation on the object pascal side with freepascal and Delphi, which are very the same but still different. If you code for both, you can't use new language features (and "new" means sometimes many years) Reading your second post, I feel that the risk for the haXe language is real: > There is another upside to my approach, though: It gives me the ability to > add optional features without Cannasse's approval. Sometimes he can > be...(how can I say this diplomatically?)...a bit stubborn in refusing to > even consider or discuss reasonable requests. He seems to like his "Denied > Because I Said So" stamp . Couple off the top of my head examples: Yes it is sometimes frustrating when the leaders of certain development (like the Canasses, Brights, Alexandrescus etc.) seem to be stubborn in some cases. But I think otherwise we wouldn't have such nice developments like D or haXe and many others - they have to be! But the decision for a second haXe compiler shouldn't be driven by such feelings, even if I agree that: > var dyn:Dynamic = "foo"; > var i:Int; // Statically-typed **INTEGER**!! > i = dyn; should be compiled as: i = cast(dyn, Int); but it could be handled like that by the runtime as well. Dynamic languages like JS don't do it, but a D target could - even if implemented in OCaml. IMHO a way to avoid dynamics at all (at least reduce the need), would be much better! And here is haXe going in the right way with its macros. Most of the need for dynamics comes from accessing data from foreign sources like databases. If the structure of these
Re: SCons support for D
On 2011-12-07 10:27, Andrew Gough wrote: On Tue, 06 Dec 2011 18:14:25 + Russel Winder wrote: SCons is a Python-based build tool to replace Make and much of the Autotools functionality. It has D support as part of the core. This support is though in need of development. The new Mercurial/BitBucket infrastructure for developing SCons (replacing the old Subversion/Tigris set up) is now in place, a new release 2.1.0 has been declared and everything is open for business leading to a 2.2.0 release. I got my changes to support DMD 2 into this release :-) However, support for GDC, LDC, etc. is almost certainly still sadly lacking, and indeed the support for DMD almost certainly needs a severe refactoring and most likely a rewrite. Rather than people having to work on a clone of SCons in order to work on the tool, I have created a separate Mercurial repository (https://bitbucket.org/russel/scons_dmd_new) as a development version of just the tool. When a new version of this separate tool is declared I create a pull request for the SCons mainline to get the new version in the next version of SCons. Is anyone else other than me interested in using SCons as a build tool with D code? If there is, perhaps we can collaborate in some way to progress SCons support for all the various realizations of D? I think the build tool question is in need of the same level of high level design and support that Steve Teale is working on for std.database/std.sql. It seems there is SCons support (python), CMake, Orbit (Ruby), DSSS (D1 only?), xfbuild, dake, rdmd options - I've added preliminary D support to premake. Orbit is a package manager and not a build tool. -- /Jacob Carlborg
Re: SCons support for D
On 2011-12-07 10:54, Russel Winder wrote: On Wed, 2011-12-07 at 20:27 +1100, Andrew Gough wrote: [...] I think the build tool question is in need of the same level of high level design and support that Steve Teale is working on for std.database/std.sql. I am not sure I quite get that, sorry. It seems there is SCons support (python), CMake, Orbit (Ruby), DSSS (D1 only?), xfbuild, dake, rdmd options - I've added preliminary D support to premake. As far as I am aware the C, C++, Fortran communities use Make, Autotools, SCons, CMake or Waf. I suspect they have never heard of DSSS, xfbuild, dake or rdmd ;-) Would it be a good idea to thrash out the arguments for/against a particular tool, and build/support just one? The community doesn't seem big enough to be so fragmented. Java has Ant, Scala has sbt - surely D should have a canonical build tool? I use SCons for much of my builds of LaTeX, C, C++, Fortran, Haskell, D, OCaml, etc. It works nicely for multi-target, multi-platform builds. I use Waf for "ship the source, compile on installation" FOSS projects. I have given up on Autotools. CMake's language is dreadful so I only use that if necessary. Java has Gradle, Maven, Gant, and Ant. Using Ant for builds is like using assembly language to create GUI applications -- possible but not recommended. Scala has sbt because the Scala community couldn't abide the multi-languages approach, everything has to be Scala. Clojure has a similar philosophy and hence Leiningen. Sure D can use D as the build specification language and follow the inward looking Scala and Clojure approaches of creating a new tool for build. But that is just trying to create a closed system. Is this closed approach really what the D community wants to do -- is following the Scala and Clojure philosophy desirable? The advantage of Gradle and Maven as build tools for JVM based systems is that you can write multi-lingual systems and build them. Java, Scala, Groovy, JRuby, Clojure -- all can be used in a single system. sbt has problems with this since it assumes all source is Scala (more or less). The Java community is rapidly giving up its "Java is all you need" attitude and is looking positively at the polyglot approach. D sits in a context of C, C++, Fortran (possible others?) which means something like SCons, Waf and CMake which has support for all these already baked in seems like a "less work" way forward. So the strategy is one of: Do we work with a build framework that exists and already allows serious build using D; or do we start from scratch with a new build framework that no-one can use till something is ready? What I see as the advantage of a new build system is that it can be developed specifically for D which could make the tool very easy to use. Example: $ tool build main.d That's all that should be needed to build an executable. You could have the same in a build script: // buildfile main.d $ tool build For a library it should be similar: $ tool build foo Where "foo" is a directory. I don't know if that's possible to have in a build tool not specifically developed for D. -- /Jacob Carlborg
Re: Is D associative array thread safe, and will it relocate memory when add or delete a value?
On Wed, 07 Dec 2011 04:00:34 -0500, Jonathan M Davis wrote: On Wednesday, December 07, 2011 09:10:16 Martin Nowak wrote: On Wed, 07 Dec 2011 08:59:32 +0100, raojm wrote: > Is D associative array thread safe, and will it relocate memory when > add or delete a value? > > Where I can find the implemention. No it's not, and yes it has to relocate memory. It's working as a hashtable not a binary tree, so all pointers will be invalidated by adding/removing. https://github.com/D-Programming-Language/druntime/blob/master/src/rt/aaA.d Yeah. AFAIK, it's impossible to have a hash table which doesn't risk reallocating something when adding a value to it, unless you limit how many elements it can hold or somesuch, which would make it considerably less useful. Typically, when a hash table gets full enough, it rehashes itself, which definitely involves allocating more memory, and possible reallocating a large portion of what it's already allocated. So, there's no way that an AA can avoid the risk of reallocating when elements are added to it, pretty much regardless of its implementation. It's an attribute of the data structure. dcollections' HashMap does not invalidate cursors when adding data, even when a rehash is done. The rehash routine specifically is written to make this possible. However, it does invalidate ranges. Note that for any hash implementation, the only thing that needs to be reallocated is the bucket array. In many implementations, this is not where the data is stored. -Steve
Re: SCons support for D
On Wed, 2011-12-07 at 22:00 +1100, Andrew Gough wrote: [...] > I'm suggesting that the current multi-pronged approach to providing a > workable build system is hampered by the multitude of directions and > could benefit from some initial discussion, consensus and design. OK. It is a valid point, effort is being diluted. On the other hand various people prefer different systems, so I am not sure there is any constructive point in dictating the "one true build system". If there were one that gained a majority support votes then it could concentrate available effort. [...] > I agree that it would be good to use a tool with support for multiple > languages & platforms. I was trying to point out that the multitude of > options is potentially harmful. Or an opportunity? D is trying to supplant C, C++, Fortran and Python. D should therefore be buildable with the same tools that people use with these languages in order to provide the lowest possible barrier to entry to D of C, C++, Fortran and Python programmers. Not having to change build system but simply to add to their current build system makes transition easier. [...] > Simple Ant scripts are easy, but XML is a very bad choice for a build > system IMO XML was an interesting choice originally, but has been perverted beyond sanity in the Ant context. This is why I wrote Gant -- use all the Ant tasks but not from the XML interpreter but from Groovy scripts. The idea cannot have been all bad as it inspired Hans Dockter to create Gradle, and the Apache folk forked Gant to create the Groovy frontend to Ant. [...] > > Not really what I was suggesting - I was hoping to discuss > consolidating effort around a small set of tools, rather than the > current state. I fully appreciate the idea is to focus effort so as to avoid dilution. With the effort available it is a good idea. I am just not convinced creating new tools from scratch is the right approach. [...] > > Do we work with a build framework that exists and already allows > > serious build using D; or > > Possibly. > > > do we start from scratch with a new build framework that no-one can > > use till something is ready? > > Possibly (if necessary) > > I thought it important to have a discussion first to determine the > requirements and use cases, and concentrate effort rather than > disperse it. Having a full and frank exchange of views is an excellent move. As long as everyone stays friends! Having watched what happened with Gant, Gradle, Buildr, sbt, Leiningen, Rake, Bake, Rant, Ant, Maven, make, Cmake, Autotools, etc. I fear the overall effect of a "focused on D" build tool, whether build from scratch or over another framework. Specialist per language build tools lead to a ghettoization. Even 5 mins looking at the Rake, sbt and Leiningen situations make this abundantly clear. Which is sad as there are many good things about all of them. If there effort to start from scratch with D to create the replacement for Make, CMake, Autotools, as a general build framework, that is a different issue. But this is a big undertaking requiring DAGs, C scanners, C++ scanners, Fortran scanners, LaTeX scanners, etc., not to mention tool finders and toolchain builders. My current prejudice is that SCons, Waf and CMake already have almost all of this stuff already in place, so it is an incremental step to make sure they work well with D (*). (*) Though due to various bits of history, the project lead of Waf has declared me persona non grata, so I cannot actually contribute to Waf and its D support :-(( -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: SCons support for D
On Wed, 2011-12-07 at 14:38 +0100, Jacob Carlborg wrote: [...] > What I see as the advantage of a new build system is that it can be > developed specifically for D which could make the tool very easy to use. > Example: > > $ tool build main.d Go has gone to the extreme with this, they have a project structure which is mandated. This makes build completely convention driven so there are no build specifications at all, their build tool can deduce all the data needed to complete a build. This is the logical extension of the "convention over configuration" approach developed by Maven and Gradle to such great effect. > That's all that should be needed to build an executable. You could have > the same in a build script: > > // buildfile > main.d Too much data ;-) > $ tool build > > For a library it should be similar: > > $ tool build foo > > Where "foo" is a directory. I don't know if that's possible to have in a > build tool not specifically developed for D. I still worry about a language specific tool. Language plugins to general tools make far more sense to me. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
On garbage collection
http://www.infoq.com/presentations/Understanding-Java-Garbage-Collection This is java focussed, but I think this is still very interesting for D people. So I'm sharing it here.
Re: Haxe (From: Java > Scala -> new thread: GUI for D)
Adrian Wrote: > [OT] As a side point from a not yet D developer, but someone who looks > at the language with great interest, but also someone with a commercial > responsibility: I am missing big projects developed in D and the most > logic project would be the compiler itself! I know this has been > discussed a million times before, but... How big is big? My app is up to about 75,000 lines of D2 (including my D libs), which isn't gigantic but it does a lot of things and needs to be ready for use and changes almost every day.
Re: SCons support for D
On Wed, 07 Dec 2011 14:38:04 +0100 Jacob Carlborg wrote: > What I see as the advantage of a new build system is that it can be > developed specifically for D which could make the tool very easy to > use. Example: > > $ tool build main.d > > That's all that should be needed to build an executable. You could > have the same in a build script: > > // buildfile > main.d > > $ tool build > > For a library it should be similar: > > $ tool build foo > > Where "foo" is a directory. I don't know if that's possible to have > in a build tool not specifically developed for D. Hmm...isn0t it too simplistic? For our project, we have need to e.g. buil lib from the included sources of 3rd party C library, then use SWIG to provide D bindings for it, then build D libs using those bindings and only then buil D executable. That's why we're targetting CMake/CPack and want to help Jens to push D support upstream(the only problem is we're a bit short on time atm.) Sincerely, Gour -- As the ignorant perform their duties with attachment to results, the learned may similarly act, but without attachment, for the sake of leading people on the right path. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: SCons support for D
On 2011-12-07 15:03, Russel Winder wrote: Having watched what happened with Gant, Gradle, Buildr, sbt, Leiningen, Rake, Bake, Rant, Ant, Maven, make, Cmake, Autotools, etc. I fear the overall effect of a "focused on D" build tool, whether build from scratch or over another framework. Specialist per language build tools lead to a ghettoization. Even 5 mins looking at the Rake, sbt and Leiningen situations make this abundantly clear. Which is sad as there are many good things about all of them. Rake isn't targeted to a single language. It's just as make but with a different syntax for the script files. If you take a look at the official tutorial you can see that they use C in the examples. -- /Jacob Carlborg
Re: SCons support for D
On 2011-12-07 15:06, Russel Winder wrote: On Wed, 2011-12-07 at 14:38 +0100, Jacob Carlborg wrote: [...] What I see as the advantage of a new build system is that it can be developed specifically for D which could make the tool very easy to use. Example: $ tool build main.d Go has gone to the extreme with this, they have a project structure which is mandated. This makes build completely convention driven so there are no build specifications at all, their build tool can deduce all the data needed to complete a build. There are still cases when special flags are needed and how is the library dependencies resolved? This is the logical extension of the "convention over configuration" approach developed by Maven and Gradle to such great effect. I think that makes sense. It should be the default but it should still be possible to use a custom project structure. That's all that should be needed to build an executable. You could have the same in a build script: // buildfile main.d Too much data ;-) Hehe. It's the same amount of data, just moved from the command line into a build script. The comment was to make it clear it was in a build script. $ tool build For a library it should be similar: $ tool build foo Where "foo" is a directory. I don't know if that's possible to have in a build tool not specifically developed for D. I still worry about a language specific tool. Language plugins to general tools make far more sense to me. Well, can the above be simplicity be achieved if an existing tool is used? -- /Jacob Carlborg
Re: SCons support for D
On 2011-12-07 15:15, Gour wrote: On Wed, 07 Dec 2011 14:38:04 +0100 Jacob Carlborg wrote: What I see as the advantage of a new build system is that it can be developed specifically for D which could make the tool very easy to use. Example: $ tool build main.d That's all that should be needed to build an executable. You could have the same in a build script: // buildfile main.d $ tool build For a library it should be similar: $ tool build foo Where "foo" is a directory. I don't know if that's possible to have in a build tool not specifically developed for D. Hmm...isn0t it too simplistic? For our project, we have need to e.g. buil lib from the included sources of 3rd party C library, then use SWIG to provide D bindings for it, then build D libs using those bindings and only then buil D executable. That's why we're targetting CMake/CPack and want to help Jens to push D support upstream(the only problem is we're a bit short on time atm.) Sincerely, Gour Of course it should be possible to build more complex projects and have more options in the build script. But for simple projects nothing more should be needed. The above would be the minimum to actually build something. For an executable that doesn't have any dependencies (except for the standard library) noting more should be needed. -- /Jacob Carlborg
Re: Haxe (From: Java > Scala -> new thread: GUI for D)
"Adrian" wrote in message news:jbnmoo$2seg$1...@digitalmars.com... > > The downside would be, that there is the risk of incompatibilities of > the compilers, leading to 2 different dialects, which would force the > users of both, only to use the subset of the languages. I have this > situation on the object pascal side with freepascal and Delphi, which > are very the same but still different. If you code for both, you can't > use new language features (and "new" means sometimes many years) > That's true, but FWIW, I do intend to place a very strong emphasis on compatablity with the official Haxe. (It even accepts Haxe's command line params to the extent possible, and I plan to support .hxml files.) As far as any deliberate deviations (such as #105), such things will be purely optional. Anything else is to be considered a bug in HaxeD.
Re: std.json dynamic initialization of JSONValue
Am 06.12.2011 22:30, schrieb Kai Meyer:
I posted this on D.learn, but got no responses. I'm hoping it's because
I'm asking the wrong crowd.
I'm finding std.json extremely well written, with one glaring exception.
I can't seem to figure out how to do this:
JSONValue root = JSONValue(null, JSON_TYPE.OBJECT);
root.object["first_object"] = JSONValue(null, JSON_TYPE.OBJECT);
root.object["first_string"] = JSONValue("first_string", JSON_TYPE.STRING);
which would decode to:
{"first_object":{},"first_string":"first_string"}
What I end up having to do is:
JSONValue root;
root.type = JSON_TYPE.OBJECT;
root.object["first_object"] = JSONValue();
root.object["first_object"].type = JSON_TYPE.OBJECT;
root.object["first_string"] = JSON_Value();
root.object["first_string"].type = JSON_TYPE.STRING;
root.object["first_string"].str = "first_string";
That just feels like I'm doing it wrong. Is there a way to dynamically
initialize a JSONValue struct? If I try to intialize the JSONValue
object with anything other than simply null, or empty string, I either
get a compile error or a segfault at run-time.
root.object["first_object"] = JSONValue(null, JSON_TYPE.OBJECT);
compile error:
Error: overlapping initialization for integer
root.object["first_string"] = JSONValue("first_string");
run-time segfault.
Any ideas?
That's the reason why I use libdjson (well the bug with dmd 2.053 made
me switch, but I didn't switch back):
https://256.makerslocal.org/wiki/Libdjson
Re: SCons support for D
Jacob Carlborg Wrote: > On 2011-12-07 15:06, Russel Winder wrote: > > On Wed, 2011-12-07 at 14:38 +0100, Jacob Carlborg wrote: > > [...] > >> What I see as the advantage of a new build system is that it can be > >> developed specifically for D which could make the tool very easy to use. > >> Example: > >> > >> $ tool build main.d > > > > Go has gone to the extreme with this, they have a project structure > > which is mandated. This makes build completely convention driven so > > there are no build specifications at all, their build tool can deduce > > all the data needed to complete a build. > > There are still cases when special flags are needed and how is the > library dependencies resolved? There are still makefiles required. You just need to include the standard definitions Makefile (application, package) and define a few standard variables that describe your project. There are also some conventions regarding to which processor and operating system your Go files refer to. More information here: http://golang.org/doc/code.html
Re: Is D associative array thread safe, and will it relocate memory when add or delete a value?
On Wed, 07 Dec 2011 14:51:49 +0100, Steven Schveighoffer wrote: On Wed, 07 Dec 2011 04:00:34 -0500, Jonathan M Davis wrote: On Wednesday, December 07, 2011 09:10:16 Martin Nowak wrote: On Wed, 07 Dec 2011 08:59:32 +0100, raojm wrote: > Is D associative array thread safe, and will it relocate memory when > add or delete a value? > > Where I can find the implemention. No it's not, and yes it has to relocate memory. It's working as a hashtable not a binary tree, so all pointers will be invalidated by adding/removing. https://github.com/D-Programming-Language/druntime/blob/master/src/rt/aaA.d On a second thought that was wrong, D's AA do allocate one node per value, so pointers to the values won't get invalidated. But simple optimizations as adding a freelist would break this. Depending on your application you should either lock access or have a look at implementing a lock-free map. Yeah. AFAIK, it's impossible to have a hash table which doesn't risk reallocating something when adding a value to it, unless you limit how many elements it can hold or somesuch, which would make it considerably less useful. Typically, when a hash table gets full enough, it rehashes itself, which definitely involves allocating more memory, and possible reallocating a large portion of what it's already allocated. So, there's no way that an AA can avoid the risk of reallocating when elements are added to it, pretty much regardless of its implementation. It's an attribute of the data structure. dcollections' HashMap does not invalidate cursors when adding data, even when a rehash is done. The rehash routine specifically is written to make this possible. However, it does invalidate ranges. Note that for any hash implementation, the only thing that needs to be reallocated is the bucket array. In many implementations, this is not where the data is stored. -Steve
Comma operator = broken design
Hi,
Consider this code:
if (condition)
foo();
else
bar(),
baz();
Notice the comma in the bar call. This will actually compile. Why?
Because the program is really interpreted as:
if (condition)
{
foo();
}
else
{
bar();
baz();
}
This is, honestly, ridiculous. On most European keyboard layouts, comma
is on the same key as semicolon. This means that a typo such as the
above can lead to an incorrect (but compiling) program easily, rather
than a compile-time error.
I really do not see the value in allowing such syntax in the first
place. I've been told that one argument was that generated code might
use it, but I have no idea why it would be needed. Furthermore, this
operator makes it very hard to introduce Python-style tuples in the
language.
Why is this operator still kept around?
- Alex
Comma operator = broken design
It could be moved to use either the section character or one of the application-specific unicode points reserved for internal use by whatever an application wants. This would eliminate confusing typing and, if using this for generated code, the generator can easily reference it by unicode ID when constructing the strings.
Hazard pointers needed with GC ?
I implemented a lock-free doubly linked list some time ago.
I omitted the use of hazard lists because flagging the lowest
bit would still make a valid pointer into the list node.
Afterwards I found that http://www.d-programming-language.org/garbage.html
explicitly states:
p = cast(void*)(cast(int)p | 1); // error: undefined behavior
Is this really needed? Guess the current GC would work properly.
Also if a list node were
Node(T)
{
ubyte[2] data;
T t;
}
Than both a pointer to data[0] as well as one to data[1] are valid
and effectively hold the node.
martin
On garbage collection
On 2011-Dec-07 14:13:11+00:00, deadalnix wrote: http://www.infoq.com/presentations/Understanding-Java-Garbage-Collection This is java focussed, but I think this is still very interesting for D people. So I'm sharing it here. Thanks for the link - I've just finished watching the presentation. It is very educational.
Re: is d-runtime non-gc safe?
On 12/5/2011 3:22 PM, Norbert Nemec wrote: On 05.12.2011 21:40, Tobias Pankrath wrote: Right - thanks for the hint! That would leave the following rules for real-time audio code in D: [snip] What's about message passing? Is message passing hard real time ready? The issue actually came up for me a few weeks ago. In principle, all you need are non-blocking queues to send messages to, from or even between RT threads. With the atomic operations in D, such a queue is fairly straightforward to implement. Unfortunately, I could not find any OS support for non-blocking message passing. More specifically, there does not seem to be any way to wake a sleeping thread by sending a message from a RT thread. The only option is periodically querying the message queue. Not optimal, but probably sufficient for most purposes. In windows land you would use MsgWaitForMultipleObject on the sleepy thread and wake it up with a kernel object of some kind (an Event most likely)
Re: Hazard pointers needed with GC ?
Le 07/12/2011 18:02, Martin Nowak a écrit :
I implemented a lock-free doubly linked list some time ago.
I omitted the use of hazard lists because flagging the lowest
bit would still make a valid pointer into the list node.
Afterwards I found that
http://www.d-programming-language.org/garbage.html explicitly states:
p = cast(void*)(cast(int)p | 1); // error: undefined behavior
Is this really needed? Guess the current GC would work properly.
Also if a list node were
Node(T)
{
ubyte[2] data;
T t;
}
Than both a pointer to data[0] as well as one to data[1] are valid
and effectively hold the node.
martin
When doing so, you should anyway have a local pointer to that data. So
it will not be collected until you release that local pointer, when the
flagged one is already removed.
Flagged pointer is a temporary state. It is usefull because falgging can
be done as an atomic operation. But the flagged pointer is not here to
stay. It is here to mention to others thread that an ongoing operation
is concurently running.
Re: Comma operator = broken design
On Wed, 07 Dec 2011 11:49:33 -0500, Alex Rønne Petersen
wrote:
Hi,
Consider this code:
if (condition)
foo();
else
bar(),
baz();
Notice the comma in the bar call. This will actually compile. Why?
Because the program is really interpreted as:
if (condition)
{
foo();
}
else
{
bar();
baz();
}
This is, honestly, ridiculous. On most European keyboard layouts, comma
is on the same key as semicolon. This means that a typo such as the
above can lead to an incorrect (but compiling) program easily, rather
than a compile-time error.
I really do not see the value in allowing such syntax in the first
place. I've been told that one argument was that generated code might
use it, but I have no idea why it would be needed. Furthermore, this
operator makes it very hard to introduce Python-style tuples in the
language.
Why is this operator still kept around?
Take your pick:
1) So that legacy B/C/C++/D1/etc code can be trivially ported to D1/D2.
2) The comma operator is heavily used in regular old for loops.
3) It is frequently used internally by the compiler to effect syntactic
lowerings. A decent portion of D's syntax is not transformed directly to
instructions; instead it is converted to simpler code which is in turn
processed. Technically the compiler doesn't need ',' in the language to do this.
4) D has a policy of 'If C/C++ code compiles in D without error, it must have
the same syntactic meaning as in C.' So even if we remove the comma operator,
we might not get comma-style tuples. (I don't know if anyone has looked at this
issue in depth)
5) The comma and semicolon are on different keys on US style keyboards.
6) It is trivial to change your keyboard layout (I've hotkeyed Greek for fast
math symbols)
7) We are trying to stabilize the language, so massive code-breaks are frowned
upon.
Personally, I think real tuples outweigh the comma-operator, but real tuples
don't necessarily need the ',' (we could use '..' or something else instead)
and removing comma-expressions isn't without its problems.
P.S. I was going to suggest testing/looking into issue 4, but a quick test in D
suggests that there are valid ',' and '(,)' style expressions in C/C++ that
would remain valid in D with comma-tuples.
Re: Comma operator = broken design
Alex Rønne Petersen Wrote: > I really do not see the value in allowing such syntax in the first > place. I've been told that one argument was that generated code might > use it, but I have no idea why it would be needed. Aside from the compiler's implementation, one possible use is something I ended up doing in Javascript recently. I have a thing that takes an attribute and pastes it into a code string to check it. given validate="this.value.length > 3" it writes: if(!(this.value.length > 3)) return false; // failed validation since the given string is inside an if statement, you can't put a semicolon in there. So, if you have a check more complex than returning a boolean and want to stuff it all in that string (so functions are out), the comma lets you do it: validate="do something, true" This is pretty ugly style that I think I've only ever done in D inside a for loop... but the point is sometimes something comes up, and it's nice to have another option available, even if it is ugly.
Re: SCons support for D
On Wed, 2011-12-07 at 14:38 +0100, Jacob Carlborg wrote: [...] > Example: > > $ tool build main.d > > That's all that should be needed to build an executable. You could have > the same in a build script: > > // buildfile > main.d > > $ tool build Currently with SCons, you type: $ scons and the default activity occurs. With the SConstruct file: Program ( "main.d" ) the result is the construction of the executable, ready for execution. If there is to be a D specific build tool then I would suggest that there has to be even less work than using SCons for it to be appealing. So my current "straw man" use case would be that there is no configuration file at all just a naming convention and a default target so that: $ tool infers the project structure and compiles the executable -- i.e. something along the lines of what Go is doing since it eschewed Make as the standard build tool. > For a library it should be similar: > > $ tool build foo > > Where "foo" is a directory. I don't know if that's possible to have in a > build tool not specifically developed for D. With SCons you specify the list of object files that comprise the archive or the shared object depending on whether it is a static library or a shared library. The list is generally constructed programmatically, so for example, something akin to: contributors = Glob ( '*.d' ) Library ( 'flob' , contributors ) SharedLibrary ( 'flob' , contributors ) I am sure a convention could make this such that no specification would be needed. If we could come up with a executable and library project convention it could be encoded in the SCons dmd tool so it can improve and continue to act as a straw man against which arguments can be made. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Comma operator = broken design
"Adam Ruppe" wrote in message news:jbo8rr$rhh$1...@digitalmars.com... > Alex Rønne Petersen Wrote: >> I really do not see the value in allowing such syntax in the first >> place. I've been told that one argument was that generated code might >> use it, but I have no idea why it would be needed. > > > Aside from the compiler's implementation, one possible use > is something I ended up doing in Javascript recently. > > I have a thing that takes an attribute and pastes it into a code > string to check it. > > given validate="this.value.length > 3" > > it writes: > > if(!(this.value.length > 3)) > return false; // failed validation > > since the given string is inside an if statement, you can't put > a semicolon in there. > > > So, if you have a check more complex than returning a boolean > and want to stuff it all in that string (so functions are out), the > comma lets you do it: > > validate="do something, true" > > > > This is pretty ugly style that I think I've only ever done in D inside > a for loop... but the point is sometimes something comes up, and > it's nice to have another option available, even if it is ugly. Don't know about JS, but D can solve the same problem with anon delegates, which is less obscure anyway.
Re: Comma operator = broken design
"Robert Jacques" wrote in message news:op.v54q04vd26s...@sandford.myhome.westell.com... > On Wed, 07 Dec 2011 11:49:33 -0500, Alex Rønne Petersen > wrote: >> >> Why is this operator still kept around? > > Take your pick: > 1) So that legacy B/C/C++/D1/etc code can be trivially ported to D1/D2. That's a pretty weak counter-argument: A. I'd think a lot of C/C++ code can't be trivially ported to D anyway. B. "B", seriously? ;) C. Being able to link to C/C++ makes it less likely to need to port C/C++ code anyway. D. Outside of for loops (special-case-able), comma operator is rarely used in C/C++/D. E. Even among actual uses of the comma operator, I think it'd be rare (if even possible) to have a use of it that isn't trivially convertable to non-comma. > 2) The comma operator is heavily used in regular old for loops. That can be special cased. > 3) It is frequently used internally by the compiler to effect syntactic > lowerings. A decent portion of D's syntax is not transformed directly to > instructions; instead it is converted to simpler code which is in turn > processed. Technically the compiler doesn't need ',' in the language to do > this. Like you're saying, it can exist in the compiler's internal AST without having to exist in the parser. > 4) D has a policy of 'If C/C++ code compiles in D without error, it must > have the same syntactic meaning as in C.' So even if we remove the comma > operator, we might not get comma-style tuples. (I don't know if anyone has > looked at this issue in depth) Meh, I still think it would be better to allow such situations on occasion and just provide a "--c-lint" switch to warn (or error) on any such code. Porting C/C++ to D is a much smaller use case than writing/maintaining D. I don't think it's a good idea to hamper the langauge for the sake of such an edge case when it's just as possible to simply handle that scenario with a special tool/switch. But I guess I'm outvoted by Walter on that :( > 5) The comma and semicolon are on different keys on US style keyboards. > 6) It is trivial to change your keyboard layout (I've hotkeyed Greek for > fast math symbols) Those are very weak counter-arguments. > 7) We are trying to stabilize the language, so massive code-breaks are > frowned upon. > Poo ;( > Personally, I think real tuples outweigh the comma-operator, but real > tuples don't necessarily need the ',' (we could use '..' or something else > instead) and removing comma-expressions isn't without its problems. > > P.S. I was going to suggest testing/looking into issue 4, but a quick test > in D suggests that there are valid ',' and '(,)' style expressions in > C/C++ that would remain valid in D with comma-tuples.
Re: ow Integers Should Work
On 12/7/2011 2:46 AM, bearophile wrote: Today some online games are managing real money of the players. You don't want to use raw integers to manage those important numbers :-) Banks have been using computer programs to handle money forever, so has every piece of accounting software. I.e. it's a well understood and solved issue. It'd be very foolish for online game developers to try to reinvent this. And frankly, we'd also be foolish to try and reinvent it without consulting with someone who does financial software professionally.
Re: SCons support for D
Andrew Gough wrote: > On Tue, 06 Dec 2011 18:14:25 + > Russel Winder wrote: > > > SCons is a Python-based build tool to replace Make and much of the > > Autotools functionality. It has D support as part of the core. This > > support is though in need of development. > > > > The new Mercurial/BitBucket infrastructure for developing SCons > > (replacing the old Subversion/Tigris set up) is now in place, a new > > release 2.1.0 has been declared and everything is open for business > > leading to a 2.2.0 release. > > > > I got my changes to support DMD 2 into this release :-) > > > > However, support for GDC, LDC, etc. is almost certainly still sadly > > lacking, and indeed the support for DMD almost certainly needs a > > severe refactoring and most likely a rewrite. > > > > Rather than people having to work on a clone of SCons in order to work > > on the tool, I have created a separate Mercurial repository > > (https://bitbucket.org/russel/scons_dmd_new) as a development version > > of just the tool. When a new version of this separate tool is > > declared I create a pull request for the SCons mainline to get the > > new version in the next version of SCons. > > > > Is anyone else other than me interested in using SCons as a build tool > > with D code? If there is, perhaps we can collaborate in some way to > > progress SCons support for all the various realizations of D? > > > > I think the build tool question is in need of the same level of high > level design and support that Steve Teale is working on for > std.database/std.sql. > > It seems there is SCons support (python), CMake, Orbit (Ruby), DSSS > (D1 only?), xfbuild, dake, rdmd options - I've added preliminary D > support to premake. Where do I find your changes for premake? > Would it be a good idea to thrash out the arguments for/against a > particular tool, and build/support just one? The community doesn't > seem big enough to be so fragmented. Java has Ant, Scala has sbt - > surely D should have a canonical build tool? I'm unsure whether D needs its own configuration/build tool. It definitely needs a package manager. For building there are different options but usually it's make. Most people (at least for sure on Unix variants) are using it. I think Scons does both building and configuring. Just want to say that you can have different tools for these jobs or single one. Jacob's build tool looks good but I wonder what are the major improvements over e.g. make (portability is an issue with make; maybe simplicity). For configuring there are some options and so far none of them is preferred by a majority. Different people weigh different aspects differently. But it seems people are moving away from configure scripts. As Russell already said, several build/configuration tools are used and there is no clear winner in general. So I think it's very nice that you have added support for D to premake. So we then have SCons (build and configuration), CMake (configuration and several build tools via generators), rdmd (can generate dependencies for Makefile), Jacob as a build tool and there are several others specifically for D and premake. I'm not sure about the state of each of these. But SCons and CMake work with dmd (both do configuration). premake is also configuration. Regarding build tools I wonder how important they are. make works fairly well. Jens
Re: Hazard pointers needed with GC ?
On Wed, 07 Dec 2011 18:28:59 +0100, deadalnix wrote:
Le 07/12/2011 18:02, Martin Nowak a écrit :
I implemented a lock-free doubly linked list some time ago.
I omitted the use of hazard lists because flagging the lowest
bit would still make a valid pointer into the list node.
Afterwards I found that
http://www.d-programming-language.org/garbage.html explicitly states:
p = cast(void*)(cast(int)p | 1); // error: undefined behavior
Is this really needed? Guess the current GC would work properly.
Also if a list node were
Node(T)
{
ubyte[2] data;
T t;
}
Than both a pointer to data[0] as well as one to data[1] are valid
and effectively hold the node.
martin
When doing so, you should anyway have a local pointer to that data. So
it will not be collected until you release that local pointer, when the
flagged one is already removed.
That's exactly what a hazard pointer is used for.
Now the question is if the flagged pointer still points to
valid memory in the same object (union aliased), there should
be no need for thread local hazard pointers.
Flagged pointer is a temporary state. It is usefull because falgging can
be done as an atomic operation. But the flagged pointer is not here to
stay. It is here to mention to others thread that an ongoing operation
is concurently running.
Re: SCons support for D
premake supports D? I was planning to add D support to premake myself, but that's wonderful news. I'll add support for VisualD if it is not already done. GDC is also important. Great news! :) On 7 December 2011 21:56, Jens Mueller wrote: > Andrew Gough wrote: > > On Tue, 06 Dec 2011 18:14:25 + > > Russel Winder wrote: > > > > > SCons is a Python-based build tool to replace Make and much of the > > > Autotools functionality. It has D support as part of the core. This > > > support is though in need of development. > > > > > > The new Mercurial/BitBucket infrastructure for developing SCons > > > (replacing the old Subversion/Tigris set up) is now in place, a new > > > release 2.1.0 has been declared and everything is open for business > > > leading to a 2.2.0 release. > > > > > > I got my changes to support DMD 2 into this release :-) > > > > > > However, support for GDC, LDC, etc. is almost certainly still sadly > > > lacking, and indeed the support for DMD almost certainly needs a > > > severe refactoring and most likely a rewrite. > > > > > > Rather than people having to work on a clone of SCons in order to work > > > on the tool, I have created a separate Mercurial repository > > > (https://bitbucket.org/russel/scons_dmd_new) as a development version > > > of just the tool. When a new version of this separate tool is > > > declared I create a pull request for the SCons mainline to get the > > > new version in the next version of SCons. > > > > > > Is anyone else other than me interested in using SCons as a build tool > > > with D code? If there is, perhaps we can collaborate in some way to > > > progress SCons support for all the various realizations of D? > > > > > > > I think the build tool question is in need of the same level of high > > level design and support that Steve Teale is working on for > > std.database/std.sql. > > > > It seems there is SCons support (python), CMake, Orbit (Ruby), DSSS > > (D1 only?), xfbuild, dake, rdmd options - I've added preliminary D > > support to premake. > > Where do I find your changes for premake? > > > Would it be a good idea to thrash out the arguments for/against a > > particular tool, and build/support just one? The community doesn't > > seem big enough to be so fragmented. Java has Ant, Scala has sbt - > > surely D should have a canonical build tool? > > I'm unsure whether D needs its own configuration/build tool. It > definitely needs a package manager. > > For building there are different options but usually it's make. Most > people (at least for sure on Unix variants) are using it. I think Scons > does both building and configuring. Just want to say that you can have > different tools for these jobs or single one. > Jacob's build tool looks good but I wonder what are the major > improvements over e.g. make (portability is an issue with make; maybe > simplicity). > > For configuring there are some options and so far none of them is > preferred by a majority. Different people weigh different aspects > differently. But it seems people are moving away from configure scripts. > > As Russell already said, several build/configuration tools are used and > there is no clear winner in general. So I think it's very nice that you > have added support for D to premake. So we then have SCons (build and > configuration), CMake (configuration and several build tools via > generators), rdmd (can generate dependencies for Makefile), Jacob as a > build tool and there are several others specifically for D and premake. > > I'm not sure about the state of each of these. But SCons and CMake work > with dmd (both do configuration). premake is also configuration. > Regarding build tools I wonder how important they are. make works fairly > well. > > Jens >
Overloading doesn't work like described in "The D programming language"
Hi!
On pages 145 and 146 (§ 5.5.1) of "The D programming language" there is
an example with overloading a function with uint, long, and a
parameterized type. I tried to reproduce that using a similar example:
module main;
import std.stdio;
void overloadme(uint number)
{
writeln("This is overloadme with uint.");
}
void overloadme(long number)
{
writeln("This is overloadme with long.");
}
void overloadme(T)(T number)
{
writeln("Generic overloadme called.");
}
int main(string[] argv)
{
overloadme(25);
overloadme("Bla");
writeln("\nFinished");
readln();
return 0;
}
However, if I try to compile that code, the compiler yields an error in
line 15:
Error: template main.overloadme(T) conflicts with function
main.overloadme at main.d(5)
In the book it says that "non-generic functions are generally preferred
to generic functions, even when the non-generic function need an
implicit conversion". But in my case that doesn't work.
Can anyone explain me what's going on here? Is the example in the book
wrong or did I misinterpret something?
Best regards
Michael
Re: Overloading doesn't work like described in "The D programming language"
On Wednesday, December 07, 2011 22:35:04 Michael Kremser wrote:
> Hi!
>
> On pages 145 and 146 (§ 5.5.1) of "The D programming language" there is
> an example with overloading a function with uint, long, and a
> parameterized type. I tried to reproduce that using a similar example:
>
>
> module main;
>
> import std.stdio;
>
> void overloadme(uint number)
> {
> writeln("This is overloadme with uint.");
> }
>
> void overloadme(long number)
> {
> writeln("This is overloadme with long.");
> }
>
> void overloadme(T)(T number)
> {
> writeln("Generic overloadme called.");
> }
>
> int main(string[] argv)
> {
> overloadme(25);
> overloadme("Bla");
>
> writeln("\nFinished");
> readln();
> return 0;
> }
>
>
> However, if I try to compile that code, the compiler yields an error in
> line 15:
>
> Error: template main.overloadme(T) conflicts with function
> main.overloadme at main.d(5)
>
> In the book it says that "non-generic functions are generally preferred
> to generic functions, even when the non-generic function need an
> implicit conversion". But in my case that doesn't work.
>
> Can anyone explain me what's going on here? Is the example in the book
> wrong or did I misinterpret something?
Currently, you cannot overload templated functions with non-templated ones. It
should be fixed at some point, but it hasn't been yet. There's a bug report on
it: http://d.puremagic.com/issues/show_bug.cgi?id=2972
The workaround is to templatize the non-templated functions with an empty
template parameter list. e.g.
void overloadme(uint number)
becomes
void overloadme()(uint number)
- Jonathan M Davis
Re: Overloading doesn't work like described in "The D programming language"
On Wed, 07 Dec 2011 16:35:04 -0500, Michael Kremser
wrote:
Hi!
On pages 145 and 146 (§ 5.5.1) of "The D programming language" there is
an example with overloading a function with uint, long, and a
parameterized type. I tried to reproduce that using a similar example:
module main;
import std.stdio;
void overloadme(uint number)
{
writeln("This is overloadme with uint.");
}
void overloadme(long number)
{
writeln("This is overloadme with long.");
}
void overloadme(T)(T number)
{
writeln("Generic overloadme called.");
}
int main(string[] argv)
{
overloadme(25);
overloadme("Bla");
writeln("\nFinished");
readln();
return 0;
}
However, if I try to compile that code, the compiler yields an error in
line 15:
Error: template main.overloadme(T) conflicts with function
main.overloadme at main.d(5)
In the book it says that "non-generic functions are generally preferred
to generic functions, even when the non-generic function need an
implicit conversion". But in my case that doesn't work.
Can anyone explain me what's going on here? Is the example in the book
wrong or did I misinterpret something?
The compiler has not implemented overloads with templates yet.
Looks like there isn't a bug on it yet...
-Steve
Re: SCons support for D
On Wed, 7 Dec 2011 22:39:34 +0200 Manu wrote: > premake supports D? I was planning to add D support to premake > myself, but that's wonderful news. I'll add support for VisualD if it > is not already done. Didn't hear about premake before...how does it compare with e.g. Cmake? Anything like Cpack available for it? Sincerely, Gour -- As the ignorant perform their duties with attachment to results, the learned may similarly act, but without attachment, for the sake of leading people on the right path. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: Comma operator = broken design
On 12/07/2011 07:02 PM, Nick Sabalausky wrote: "Adam Ruppe" wrote in message news:jbo8rr$rhh$1...@digitalmars.com... Alex Rønne Petersen Wrote: I really do not see the value in allowing such syntax in the first place. I've been told that one argument was that generated code might use it, but I have no idea why it would be needed. Aside from the compiler's implementation, one possible use is something I ended up doing in Javascript recently. I have a thing that takes an attribute and pastes it into a code string to check it. given validate="this.value.length> 3" it writes: if(!(this.value.length> 3)) return false; // failed validation since the given string is inside an if statement, you can't put a semicolon in there. So, if you have a check more complex than returning a boolean and want to stuff it all in that string (so functions are out), the comma lets you do it: validate="do something, true" This is pretty ugly style that I think I've only ever done in D inside a for loop... but the point is sometimes something comes up, and it's nice to have another option available, even if it is ugly. Don't know about JS, but D can solve the same problem with anon delegates, which is less obscure anyway. I think Don said that DMD cannot currently inline any delegates. Imho the spec should even *require* inlining in the special case that such a delegate is immediately executed. (even for debug builds).
Re: Hazard pointers needed with GC ?
On 12/07/2011 06:02 PM, Martin Nowak wrote:
I implemented a lock-free doubly linked list some time ago.
I omitted the use of hazard lists because flagging the lowest
bit would still make a valid pointer into the list node.
Afterwards I found that
http://www.d-programming-language.org/garbage.html explicitly states:
p = cast(void*)(cast(int)p | 1); // error: undefined behavior
Is this really needed? Guess the current GC would work properly.
Also if a list node were
Node(T)
{
ubyte[2] data;
T t;
}
Than both a pointer to data[0] as well as one to data[1] are valid
and effectively hold the node.
martin
TDPL suggests that using that kind of pointer flagging is sane. Maybe
you can file a bug against the specification.
What would you do...
Hey peoples, So this might be a bit off topic... but I'm trying to think about the best way to write a small program in the most D-ish way possible (just to make sure I'm giving myself the most realistic experience with the language), and I wanted to get some thoughts. I don't know which way to go on this. I know what I'd do in various other languages, but I'm curious to hear the communities opinion. I think part of the problem is that D's networking libraries are pretty incomplete... but here it is anyway. I basically just want to write a trivial echo server which may have hundreds of thousands of connections split into small groups, and whenever data is received from a member in any group, it is basically echoed to the others in that group. Sounds super simple... My instinct is to have a listener on the main thread, and spawn a thread per group, each blocking on a select().. I think the questions is around thread safety and group management (managing the connection list for each group), and how to interrupt a blocking select() when a new connection has entered the group... "The D way" to solve these questions is a mystery to me. I just feel like I'm writing C code, manually managing thread safety, timeout logic. I feel like D offers some fundamental features that should make solving this problem a whole lot simpler that I must be completely missing... So, in a few sentences... simple problem, what would you do?
Re: Hazard pointers needed with GC ?
On 12/7/2011 9:02 AM, Martin Nowak wrote:
I implemented a lock-free doubly linked list some time ago.
I omitted the use of hazard lists because flagging the lowest
bit would still make a valid pointer into the list node.
Afterwards I found that http://www.d-programming-language.org/garbage.html
explicitly states:
p = cast(void*)(cast(int)p | 1); // error: undefined behavior
Is this really needed? Guess the current GC would work properly.
Also if a list node were
Node(T)
{
ubyte[2] data;
T t;
}
Than both a pointer to data[0] as well as one to data[1] are valid
and effectively hold the node.
If the GC runs a collection cycle while the pointer has that bit set, and
setting the bit causes it to point past the allocated data, then it will not
regard that data as being in use and will delete it.
An easy way to make it work right is to make sure that or'ing in the bit will
not cause the pointer to point past the object.
Re: SCons support for D
Gour wrote: > On Wed, 7 Dec 2011 22:39:34 +0200 > Manu wrote: > > > premake supports D? I was planning to add D support to premake > > myself, but that's wonderful news. I'll add support for VisualD if it > > is not already done. > > Didn't hear about premake before...how does it compare with e.g. Cmake? The nice thing about premake is that it is build using Lua. So you have a full language at your disposal. CMake's configuration language is not that nice or at least it takes time to get used to it. premake only concerns itself with configuring. Which I think is nice. But it has nothing similar to CMake's find_package last time I checked. > Anything like Cpack available for it? As far as I know no. Jens
Re: rt_finalize WTFs?
On Dec 4, 2011, at 5:46 PM, dsimcha wrote:
> I'm at my traditional passtime of trying to speed up D's garbage collector
> again, and I've stumbled on the fact that rt_finalize is taking up a
> ridiculous share of the time (~30% of total runtime) on a benchmark where
> huge numbers of classes **that don't have destructors** are being created and
> collected. Here's the code to this function, from lifetime.d:
>
> extern (C) void rt_finalize(void* p, bool det = true)
> {
>debug(PRINTF) printf("rt_finalize(p = %p)\n", p);
>
>if (p) // not necessary if called from gc
>{
>ClassInfo** pc = cast(ClassInfo**)p;
>
>if (*pc)
>{
>ClassInfo c = **pc;
>byte[]w = c.init;
>
>try
>{
>if (det || collectHandler is null ||
> collectHandler(cast(Object)p))
>{
>do
>{
>if (c.destructor)
>{
>fp_t fp = cast(fp_t)c.destructor;
>(*fp)(cast(Object)p); // call destructor
>}
>c = c.base;
>} while (c);
>}
>if ((cast(void**)p)[1]) // if monitor is not null
>_d_monitordelete(cast(Object)p, det);
>(cast(byte*) p)[0 .. w.length] = w[]; // WTF?
>}
>catch (Throwable e)
>{
>onFinalizeError(**pc, e);
>}
>finally // WTF?
>{
>*pc = null; // zero vptr
>}
>}
>}
> }
>
> Getting rid of the stuff I've marked with //WTF? comments (namely the finally
> block and the re-initializing of the memory occupied by the finalized object)
> speeds things up by ~15% on the benchmark in question. Why do we care what
> state the blob of memory is left in after we finalize it? I can kind of see
> that we want to clear things if delete/clear was called manually and we want
> to leave the object in a state that doesn't look valid. However, this has
> significant performance costs and IIRC is already done in clear() and delete
> is supposed to be deprecated. Furthermore, I'd like to get rid of the
> finally block entirely, since I assume its presence and the effect on the
> generated code is causing the slowdown, not the body, which just assigns a
> pointer.
Now that having multiple in-flight exceptions is actually legal, we can
probably just throw out the try/catch entirely. The try/catch and call to
onFinalizeError is a holdover from when it was effectively illegal to throw
from a finalizer.
Re: Comma operator = broken design
On Wednesday, December 07, 2011 23:10:53 Timon Gehr wrote: > On 12/07/2011 07:02 PM, Nick Sabalausky wrote: > > "Adam Ruppe" wrote in message > > news:jbo8rr$rhh$1...@digitalmars.com... > > > >> Alex Rønne Petersen Wrote: > >>> I really do not see the value in allowing such syntax in the first > >>> place. I've been told that one argument was that generated code > >>> might > >>> use it, but I have no idea why it would be needed. > >> > >> Aside from the compiler's implementation, one possible use > >> is something I ended up doing in Javascript recently. > >> > >> I have a thing that takes an attribute and pastes it into a code > >> string to check it. > >> > >> given validate="this.value.length> 3" > >> > >> it writes: > >> > >> if(!(this.value.length> 3)) > >> > >> return false; // failed validation > >> > >> since the given string is inside an if statement, you can't put > >> a semicolon in there. > >> > >> > >> So, if you have a check more complex than returning a boolean > >> and want to stuff it all in that string (so functions are out), the > >> comma lets you do it: > >> > >> validate="do something, true" > >> > >> > >> > >> This is pretty ugly style that I think I've only ever done in D inside > >> a for loop... but the point is sometimes something comes up, and > >> it's nice to have another option available, even if it is ugly. > > > > Don't know about JS, but D can solve the same problem with anon > > delegates, which is less obscure anyway. > > I think Don said that DMD cannot currently inline any delegates. Imho > the spec should even *require* inlining in the special case that such a > delegate is immediately executed. (even for debug builds). lazy doesn't get inlined for the same reason (since it's essentially using a delegate), and that potentially has some nasty implications for performance with regards to stuff like enforce. In the recent thread on std.regex's performance, while enforce was definitely not at the top of the list of functions in the profiler (listed descending by running time), it was definitely a decent portion of the running time of the program. The cost of enforce should be comparable to the cost of assert, but with the issues of inlining lazy and delegates, it definitely isn't that efficient. These sorts of things need to be inlinable. - Jonathan M Davis
Re: Hazard pointers needed with GC ?
On Wed, 07 Dec 2011 23:23:26 +0100, Walter Bright
wrote:
On 12/7/2011 9:02 AM, Martin Nowak wrote:
I implemented a lock-free doubly linked list some time ago.
I omitted the use of hazard lists because flagging the lowest
bit would still make a valid pointer into the list node.
Afterwards I found that
http://www.d-programming-language.org/garbage.html
explicitly states:
p = cast(void*)(cast(int)p | 1); // error: undefined behavior
Is this really needed? Guess the current GC would work properly.
Also if a list node were
Node(T)
{
ubyte[2] data;
T t;
}
Than both a pointer to data[0] as well as one to data[1] are valid
and effectively hold the node.
If the GC runs a collection cycle while the pointer has that bit set,
and setting the bit causes it to point past the allocated data, then it
will not regard that data as being in use and will delete it.
An easy way to make it work right is to make sure that or'ing in the bit
will not cause the pointer to point past the object.
Nice, this really simplifies lock-free data structures.
Re: Comma operator = broken design
On Wed, 07 Dec 2011 13:19:31 -0500, Nick Sabalausky wrote: "Robert Jacques" wrote in message news:op.v54q04vd26s...@sandford.myhome.westell.com... On Wed, 07 Dec 2011 11:49:33 -0500, Alex Rønne Petersen wrote: Why is this operator still kept around? Take your pick: 1) So that legacy B/C/C++/D1/etc code can be trivially ported to D1/D2. That's a pretty weak counter-argument: A. I'd think a lot of C/C++ code can't be trivially ported to D anyway. That statement implies that there is a lot of code that can be trivially ported to D. B. "B", seriously? ;) Yes, the poster was (in part) asking about where the comma operator came from. C did a lot of stupid things to be portable with B and we have all inherited that legacy. C. Being able to link to C/C++ makes it less likely to need to port C/C++ code anyway. Sure, for code that's in reasonably complete libraries that full fill your use cases and are supported by someone else. That's not always the case. D. Outside of for loops (special-case-able), comma operator is rarely used in C/C++/D. Special casing is a big and dangerous hammer. Generally, it introduces extra work for the compiler and cognitive load for the programmer. Now, we have used special casing to detect common errors to great effect, but these don't add cognitive load to the programmer. E. Even among actual uses of the comma operator, I think it'd be rare (if even possible) to have a use of it that isn't trivially convertable to non-comma. True, but that still implies extra work on the part of the programmer. 2) The comma operator is heavily used in regular old for loops. That can be special cased. Ahem. So are you suggesting that (a,b) means a tuple everywhere but in a for loop, where it is used to separate two statements? 5) The comma and semicolon are on different keys on US style keyboards. 6) It is trivial to change your keyboard layout (I've hotkeyed Greek for fast math symbols) Those are very weak counter-arguments. I don't disagree, but the poster's original argument was (essentially) that EU keyboards put ; and , on the same key, so it was easy to mistype between the two. I was just suggesting that maybe the poster might want to fix their keyboard before trying to 'fix' the language.
expression templates vs D arrays
I've been reading about the use of expression templates in this blitz page, which provides arrays implemented by c++ templates. They have some convenient features, such as array initialization with auto-incrementing array index values in the expressions and applying a cast operator to an entire array within an expression. Do D built-in array operations and initialization include these type of features, or would you need to create some similar D template implementation to guarantee the efficient expression evaluation and similar initialization features? http://www.oonumerics.org/blitz/docs/blitz_3.html#SEC80
Re: ow Integers Should Work
On 12/06/2011 11:50 PM, Don wrote: He's talking about system languages. A system language has to have a close relationship to the architecture. By contrast, if you don't care about performance, it's easy -- just use BigInts for everything. Problem solved. Looks like I have to put it more bluntly: I don't think he knows what he's talking about. (On this particular topic). I know exactly what you have been saying I just think you are wrong, not because I don't think you knows what you are talking about but because I think you are evaluating his conclusion based on a different criteria than he is. More specifically, I think we are dealing with a differing order of priories for system languages. Mine would put safety (i.e. NO undefined behaviour) over performance. I think he is going the same way. Personally, if I could only have one, I think I'd (first) go with defining overflow semantics rather than trapping but I'm not sure which is more useful in a systems context. Can we at least agree that if you are only going to have one signed integer semantic, that undefined overflow is the worst possible choice?
Re: Comma operator = broken design
On 12/07/2011 08:49 AM, Alex Rønne Petersen wrote: I really do not see the value in allowing such syntax in the first place. I've been told that one argument was that generated code might use it, but I have no idea why it would be needed. Furthermore, this operator makes it very hard to introduce Python-style tuples in the language. IIRC the generated code argument was actually made with regards to the compiler doing internal rewriting of the AST. If I'm remembering correctly, this make it even weaker as, at that point, there is no reason that the form of the AST need match the syntax.
Re: SCons support for D
On Wed, 7 Dec 2011 23:31:10 +0100 Jens Mueller wrote: > The nice thing about premake is that it is build using Lua. So you > have a full language at your disposal. Heh, that much I could see quickly...Something like Scons/Waf... > CMake's configuration language is not that nice or at least it takes > time to get used to it. Well, although it's considered ugly by many, it can build stuff like KDE which means: good-enough, right? > premake only concerns itself with configuring. Which I think is nice. > But it has nothing similar to CMake's find_package last time I > checked. OK. I'll take a look, but Cmake seems to be really robust and supports *many* platforms. > > Anything like Cpack available for it? > > As far as I know no. Thanks...I still have to finish some web-stuff, then I'm going to tackle cmaked2...Asked on the mailing list about more details, but no reply...I'm not sure about testing suite which cmaked2 is supposed to pass. Sincerely, Gour -- Bewildered by the modes of material nature, the ignorant fully engage themselves in material activities and become attached. But the wise should not unsettle them, although these duties are inferior due to the performers' lack of knowledge. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: expression templates vs D arrays
On Wed, 07 Dec 2011 23:27:41 -0500, Jay Norwood wrote: I've been reading about the use of expression templates in this blitz page, which provides arrays implemented by c++ templates. They have some convenient features, such as array initialization with auto-incrementing array index values in the expressions and applying a cast operator to an entire array within an expression. Do D built-in array operations and initialization include these type of features, or would you need to create some similar D template implementation to guarantee the efficient expression evaluation and similar initialization features? http://www.oonumerics.org/blitz/docs/blitz_3.html#SEC80 Built-in? No, not everything. But std.range, std.array and std.algorithm have a lot of the convenience features you're looking for. Actual D array operations, i.e. x[] = y[] + z[] * b;, are more efficient than expression templates. Currently, what you can do in an array op is somewhat limited, but generalization, i.e. x[] = sin(iota(0,x.length)[]) + y[] is on Don's todo list.
Re: SCons support for D
On 2011-12-07 16:49, Paulo Pinto wrote: Jacob Carlborg Wrote: On 2011-12-07 15:06, Russel Winder wrote: On Wed, 2011-12-07 at 14:38 +0100, Jacob Carlborg wrote: [...] What I see as the advantage of a new build system is that it can be developed specifically for D which could make the tool very easy to use. Example: $ tool build main.d Go has gone to the extreme with this, they have a project structure which is mandated. This makes build completely convention driven so there are no build specifications at all, their build tool can deduce all the data needed to complete a build. There are still cases when special flags are needed and how is the library dependencies resolved? There are still makefiles required. You just need to include the standard definitions Makefile (application, package) and define a few standard variables that describe your project. There are also some conventions regarding to which processor and operating system your Go files refer to. More information here: http://golang.org/doc/code.html I see. -- /Jacob Carlborg
Re: SCons support for D
On 2011-12-07 19:02, Russel Winder wrote: On Wed, 2011-12-07 at 14:38 +0100, Jacob Carlborg wrote: [...] Example: $ tool build main.d That's all that should be needed to build an executable. You could have the same in a build script: // buildfile main.d $ tool build Currently with SCons, you type: $ scons and the default activity occurs. With the SConstruct file: Program ( "main.d" ) the result is the construction of the executable, ready for execution. Ok, sounds good. But I'm not sure if I like that you just have to invoke "scons" without any action or flag. In the tools I've written lately it will out put the usage information if you just invoke "tool". I'm not sure what I like best. If there is to be a D specific build tool then I would suggest that there has to be even less work than using SCons for it to be appealing. So my current "straw man" use case would be that there is no configuration file at all just a naming convention and a default target so that: $ tool infers the project structure and compiles the executable -- i.e. something along the lines of what Go is doing since it eschewed Make as the standard build tool. That should be doable. For a library it should be similar: $ tool build foo Where "foo" is a directory. I don't know if that's possible to have in a build tool not specifically developed for D. With SCons you specify the list of object files that comprise the archive or the shared object depending on whether it is a static library or a shared library. The list is generally constructed programmatically, so for example, something akin to: contributors = Glob ( '*.d' ) Library ( 'flob' , contributors ) SharedLibrary ( 'flob' , contributors ) That's quite could but a bit unnecessary for the simplest cases. Just specifying a folder should be enough. I am sure a convention could make this such that no specification would be needed. If we could come up with a executable and library project convention it could be encoded in the SCons dmd tool so it can improve and continue to act as a straw man against which arguments can be made. I think that should be doable, perhaps something like this: project |-- src |-- main.d // executable target |-- project // library target Or: project |-- src |-- project |-- main.d "project" would be a library target if "main.d" doesn't exist. Otherwise "main.d" will be an executable target. After a build: project |-- bin // executable is placed here |-- lib // libraries are placed here |-- imports // imports are placed here I'm not entirely sure where I want to place "main.d". -- /Jacob Carlborg
Re: SCons support for D
On 2011-12-07 20:56, Jens Mueller wrote: I'm unsure whether D needs its own configuration/build tool. It definitely needs a package manager. For building there are different options but usually it's make. Most people (at least for sure on Unix variants) are using it. I think Scons does both building and configuring. Just want to say that you can have different tools for these jobs or single one. Jacob's build tool looks good but I wonder what are the major improvements over e.g. make (portability is an issue with make; maybe simplicity). Makefiles are a horrible thing of this world. For configuring there are some options and so far none of them is preferred by a majority. Different people weigh different aspects differently. But it seems people are moving away from configure scripts. As Russell already said, several build/configuration tools are used and there is no clear winner in general. So I think it's very nice that you have added support for D to premake. So we then have SCons (build and configuration), CMake (configuration and several build tools via generators), rdmd (can generate dependencies for Makefile), Jacob as a build tool and there are several others specifically for D and premake. I'm not sure about the state of each of these. But SCons and CMake work with dmd (both do configuration). premake is also configuration. Regarding build tools I wonder how important they are. make works fairly well. Jens I want a simple portable build tool. DSSS was/is a good tool, but it's not maintained anymore. It had some problems but I like it in general. -- /Jacob Carlborg
Re: expression templates vs D arrays
On 12/7/2011 11:11 PM, Robert Jacques wrote: On Wed, 07 Dec 2011 23:27:41 -0500, Jay Norwood wrote: I've been reading about the use of expression templates in this blitz page, which provides arrays implemented by c++ templates. They have some convenient features, such as array initialization with auto-incrementing array index values in the expressions and applying a cast operator to an entire array within an expression. Do D built-in array operations and initialization include these type of features, or would you need to create some similar D template implementation to guarantee the efficient expression evaluation and similar initialization features? http://www.oonumerics.org/blitz/docs/blitz_3.html#SEC80 Built-in? No, not everything. But std.range, std.array and std.algorithm have a lot of the convenience features you're looking for. Actual D array operations, i.e. x[] = y[] + z[] * b;, are more efficient than expression templates. Currently, what you can do in an array op is somewhat limited, but generalization, i.e. x[] = sin(iota(0,x.length)[]) + y[] is on Don's todo list. I'll add that you can do expression templates in D, but there's no point to them.
