Re: Who here actually uses D?
On Mon, 03 Jan 2011 06:53:36 +0100, Nick Sabalausky wrote: "Patrick Kreft" wrote in message news:op.vopbqgqzq2m...@zeus-pc.belkin... On Sun, 02 Jan 2011 19:28:07 +0100, Nick Sabalausky wrote: Yea, my three primary critera for a GUI lib are: - Multiplatform - Native controls - Works on D2 Qt has self-drawn control, which could hold an native handler, if needed. But they are different from native control. Qt has a compile-time setting to disable that and just use native controls like it always used to do. And since Qt added the self-drawing primarily just to decrease some redraw flicker, I suspect its self-drawing might not be too bad. Sry there is no argument in your post. You can enbale an native handler to the control in three ways. Look for Qt Documentation. As i said qt controls haven't the look and behavior like native controls such as control created by winapi, mfc or winforms.
Re: Who here actually uses D?
On Sat, 01 Jan 2011 22:22:35 +, Robert Clipsham wrote: > Having seen a post by Peter Alexander (in Re: D for game development), > mentioning some of the issues he's hit I thought I'd post this. I've > been in his shoes (every other time I use D it seems), and feel I should > ask - who here uses D, and to what extent? > > I'm mostly interested in those of you with 1000 Line plus projects in D, > as that's when I've found I start hitting issues. > > Just to clarify, for those D purists among you... I'm not trolling, just > curious (I wouldn't normally have asked, but now I know I'm not paranoid > and the only one having problems, I thought I'd ask). I've been using D almost every day for the past 3 1/2 years as a part of my doctoral work, as well as for hobby programming. The programs I've written at work have mostly been rather small ones, each of which typically performs a very specific calculation. But since there weren't many preexisting numerics libraries for D, I've had to write quite a few numerical algorithms myself -- some from scratch, some ported from old FORTRAN code found on Netlib. This has led to the SciD project, which is now almost 28,000 lines. SciD is a combined hobby and professional project in that I add stuff when I need it for work, but the rest (probably the largest part) I've done on my spare time. In my experience, D's bugginess is often very exaggerated. Some people on this forum give the impression that D actively prevents them from doing what they need to do! Granted, I do run into bugs at times, some of them pretty annoying, but only once (I think) have I run into one that didn't have a simple workaround, or which couldn't simply be ignored for the time being. And the few annoyances I face with D are insignificant compared to the major PITA of using C/C++ (which is what I used for numerics before D) or Java (which I used for non-numerical programming before D). Yes, most of the time I write numerical code, so there are parts of D and Phobos that I seldom use, and therefore there are lots of bugs I never run into. However, comments from other non-pessimistic D users such as Adam R. tell me that the above is true in general. -Lars
Re: Hooking the GC?
%u wrote: Hi, Is there any way to add a hook to the garbage collector in D, so that I can be immediately notified (for example) when an object is created? (I'm aware that this could cause infinite recursion/deadlock if I try to allocate memory, but that's all right, I'm fine with that.) You're gonna have to add such functionality to the GC by yourself, I'm afraid. Shouldn't be too hard though, depending on what sort of info you require from the hook. -- Simen
Re: Moving to D
On Sun, 02 Jan 2011 20:34:40 +0200, bioinfornatics wrote: they are a D2 port for tango. It is not done. take source here: git clone git://supraverse.net/tango.git The job is almost done. everyone can do this job. Take a D2 compiler build and fix error How many people are working on this port? How many people will be interested in using it, considering that a direct port won't use many of D2's features (why not just use D1)? Will this port be around in 1 year? 5 years? Will it have the same kind of momentum as the original D1 version, with as many developers working on it, fixing bugs etc.? Will the API always stay in sync with the developments in the original D1 version? What about all the existing documentation, tutorials, even book(s)? Sorry, having more options is a good thing, but I think there is a lot more to a real "Tango for D2" than just someone fixing the code so it compiles and works. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: std.unittests for (final?) review
On Mon, 03 Jan 2011 06:44:50 +0200, Jonathan M Davis wrote: So, please have a look at the code. Just one thing: wouldn't these functions also be useful in contract programming (invariants etc.)? Perhaps they should just be added to std.exception? -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: std.unittests for (final?) review
Jonathan M Davis: > While improvements can be > made to how unit tests work in D, I believe that that should be addressed by > actually making those improvements to the core language as opposed to using a > module in Phobos to change things. You shouldn't _need_ std.unittests to > write > unit testing code. I think it's wrong to design a built-in unit test system able to do most of the things a real unit test system is expected to work, because it's a lot of stuff and because 10-15 years from now the best design for an unit test system may be different, and there are different ways to create tests. So I prefer the built-in unit test features to allow the creation of a good standard library unit test system based on the built-in one, working as an extension. In little programs you are free to use the built-in one. What basic unit testing features do you think are better to become built-in? (Unit test names?) Bye, bearophile
Re: Hooking the GC?
On Mon, 03 Jan 2011 05:34:55 +0200, %u wrote: Is there any way to add a hook to the garbage collector in D, so that I can be immediately notified (for example) when an object is created? FWIW, Diamond ( http://github.com/CyberShadow/Diamond ) hooks various GC functions, but it's an ugly hack that breaks with multi-threaded programs (and the module is D1 and x86-only). A better run-time solution (not involving modifying Phobos/druntime) would need a instruction-length disassembler. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: std.unittests for (final?) review
On Monday 03 January 2011 01:38:29 Vladimir Panteleev wrote: > On Mon, 03 Jan 2011 06:44:50 +0200, Jonathan M Davis > > wrote: > > So, please have a look at the code. > > Just one thing: wouldn't these functions also be useful in contract > programming (invariants etc.)? Perhaps they should just be added to > std.exception? Well, they're written with unit tests in mind rather than contracts. Unit tests and contracts have similar but different purposes. I wouldn't really want to conflate the two. Also, it's std.exception now rather than std.contracts specifically because it doesn't really relate to contracts, so even if you did want to use unit testing functions in contracts, I'm not sure that std.exception is the right place to put such functions anyway. As it stands, the entire module is in a version(unittest) block, so the functions can't be used outside of unit tests. If a lot of people really thought that unit testing functions would be useful and reasonable to use inside of contracts, then it would make some sense for the unit testing functions to no longer be in a version(unittest) block. But personally, I'd be a bit worried to see more than simple assertions inside of contracts. Contracts should be efficient, since they're going to be run while the code is running normally, whereas unit tests don't have to worry about efficiency quite as much. I believe that the functions that I have are efficient, but I can easily see functions intended to aid in unit testing being totally inappropriate in a contract due to efficiency concerns. And of course, a number of the unit testing functions just don't make sense in contracts regardless - like assertExThrown. Howevr, regardless of whether the functions are deemed reasonable for use in contracts, I do think that having a module of functions designed specifically for use in unit tests is of definite value, and regardless of the current size of the module, it's quite possible that it could become fairly large at some point if enough useful unit testing functions are devised. Merging that in with std.exception seems ill-advised to me. Not to mention, it's a lot more obvious that you're dealing with functions intended to aid in unit tests when the module is named std.unittests than if those functions are lumped in with the stuff in std.exception. - Jonathan M Davis
Re: Advocacy (Was: Who here actually uses D?)
On 11-01-02 03:35 AM, Walter Bright wrote: bearophile wrote: But D is not currently the best fit to write a kernel Based on what? Currently the issues I see with D in kernel land is a fat runtime and type system. Although you can reduce the runtime requirements, you end up losing alot of features and might as well be writing in C at that point anyway. I don't think D as a language is a bad fit for a kernel (conceptually I think I'd be a great fit for a kernel). I think the bigger issues are the current state of the D+druntime implementations that are problematic.
Re: std.unittests for (final?) review
Jonathan M Davis Wrote: > But personally, I'd be a bit worried to see more than simple assertions > inside of > contracts. I agree. And I hope to see Phobos contracts as soon as possible free of enforce() and similar exceptions. It's not just a matter of performance. Otherwise enforce() risks becoming a permanent workaround for a missing but necessary feature. A way to solve the problem DMD has to use a Phobos library compiled in not-release mode when you don't use the -release switch. Bye, bearophile
Re: std.unittests for (final?) review
bearophile wrote: > Jonathan M Davis: > > > While improvements can be > > made to how unit tests work in D, I believe that that should be addressed > > by > > actually making those improvements to the core language as opposed to using > > a > > module in Phobos to change things. You shouldn't _need_ std.unittests to > > write > > unit testing code. > > I think it's wrong to design a built-in unit test system able to do most of > the things a real unit test system is expected to work, because it's a lot of > stuff and because 10-15 years from now the best design for an unit test > system may be different, and there are different ways to create tests. So I > prefer the built-in unit test features to allow the creation of a good > standard library unit test system based on the built-in one, working as an > extension. In little programs you are free to use the built-in one. I agree with bearophile. Unit testing can be implemented on top of the language and shouldn't be put into it. Somehow I have the feeling that too often one tries to extend the language even though the feature could be implemented in a library. I like the basic built-in support for unit testing in D but more advanced testing should be implemented in a module ideally leading to something like GoogleTest for D. I think unittest.d does a good step into that direction. More will be needed, if there is consensus. Jens
Re: std.unittests for (final?) review
Jens Mueller: > I agree with bearophile. Unit testing can be implemented on top of the > language and shouldn't be put into it. This is not what I have said. I was talking about option IV I have explained here: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=107997 This means I accept the built-in unit test system, but I think it's wrong to make it do everything you want from an unit test system. So the built-in one has to give the basic features (like giving a name to each unit test) that are later used by the library-defined unit test system. Bye, bearophile
Re: std.unittests for (final?) review
On Monday 03 January 2011 01:50:48 bearophile wrote: > Jonathan M Davis: > > While improvements can be > > made to how unit tests work in D, I believe that that should be addressed > > by actually making those improvements to the core language as opposed to > > using a module in Phobos to change things. You shouldn't _need_ > > std.unittests to write unit testing code. > > I think it's wrong to design a built-in unit test system able to do most of > the things a real unit test system is expected to work, because it's a lot > of stuff and because 10-15 years from now the best design for an unit test > system may be different, and there are different ways to create tests. So > I prefer the built-in unit test features to allow the creation of a good > standard library unit test system based on the built-in one, working as an > extension. In little programs you are free to use the built-in one. > > What basic unit testing features do you think are better to become > built-in? (Unit test names?) The main items that I can think of are unit test names and what happens when a unittest block fails. We can't currently name unit tests, and while it's planned that every unittest block will run even if others in the module fail, at present, if one unittest block in a module runs, none of the other unittest blocks in the module run. Other changes that some people have expressed interest in are things like having it printed when a test passes, and those should not be in the language or druntime itself. That's going to either have to be in helper functions that are run inside of unittest blocks or it's going to need to be possible to run unittest blocks externally somehow (like would be necessary if you wanted to run them in an IDE) and then whatever program runs them can choose to print test successes. But printing test successes goes against how D's unit testing framework is designed and IMHO would be very bad - particularly when the tests run before main rather than in a separate program. What I was essentially trying to say was that I'm not trying to fundamentally change how unit testing in D functions, and I don't think that it really should be changed. Some improvements can be made, but I don't think that that's the job of Phobos. Such changes either need to be made in the language/druntime, or they need to be made in a some sort of external tool which runs D's unit tests differently. All that std.unittests is trying to do is to expand on what D's unit tests already do, not fundamentally alter how they work. - Jonathan M Davis
Re: std.unittests for (final?) review
Jonathan M Davis wrote: > On Monday 03 January 2011 01:38:29 Vladimir Panteleev wrote: > > On Mon, 03 Jan 2011 06:44:50 +0200, Jonathan M Davis > > > > wrote: > > > So, please have a look at the code. > > > > Just one thing: wouldn't these functions also be useful in contract > > programming (invariants etc.)? Perhaps they should just be added to > > std.exception? > > Well, they're written with unit tests in mind rather than contracts. Unit > tests > and contracts have similar but different purposes. I wouldn't really want to > conflate the two. Also, it's std.exception now rather than std.contracts > specifically because it doesn't really relate to contracts, so even if you > did > want to use unit testing functions in contracts, I'm not sure that > std.exception > is the right place to put such functions anyway. > > As it stands, the entire module is in a version(unittest) block, so the > functions can't be used outside of unit tests. > > If a lot of people really thought that unit testing functions would be useful > and reasonable to use inside of contracts, then it would make some sense for > the > unit testing functions to no longer be in a version(unittest) block. But > personally, I'd be a bit worried to see more than simple assertions inside of > contracts. Contracts should be efficient, since they're going to be run while > the > code is running normally, whereas unit tests don't have to worry about > efficiency > quite as much. I believe that the functions that I have are efficient, but I > can > easily see functions intended to aid in unit testing being totally > inappropriate > in a contract due to efficiency concerns. And of course, a number of the unit > testing functions just don't make sense in contracts regardless - like > assertExThrown. What do you mean by "running normally"? I think since they are compiled away with -release they are not run normally. > Howevr, regardless of whether the functions are deemed reasonable for use in > contracts, I do think that having a module of functions designed specifically > for > use in unit tests is of definite value, and regardless of the current size of > the > module, it's quite possible that it could become fairly large at some point > if > enough useful unit testing functions are devised. Merging that in with > std.exception seems ill-advised to me. Not to mention, it's a lot more > obvious > that you're dealing with functions intended to aid in unit tests when the > module > is named std.unittests than if those functions are lumped in with the stuff > in > std.exception. I think you're right. It definitely should stay in it's own module. I do it as follows: Build with -release -noboundscheck and no -unittest to get the production version. I.e. all contracts, asserts, boundschecks, and unittests go away. Further I have a build with -unittest which is for testing. Now I can use Jonathan's assertions with better error messages even in contracts. Jens
Re: Less commas
Brad Roberts: > I haven't read the paper, probably should, There are papers about Coccinelle, but the PDF I have linked is just a pack of few slides :-) > but is it counting found, fixed, introduced? Each of those are different data > points. The section in the slides says "Finding and fixing !x&y bugs using Coccinelle", and at the end it says "Over 450 patches created using Coccinelle accepted into Linux", so I think it's talking about bugs fixed. > Also of interest would be > any indicator of total bug counts during that same period. We're talking > about > a LONG period of time here (5-6 years) and a rather large code base that does > a > lot of low level bit manipulations. Surely the total count of Linux bugs in those years is very high, so the percentage of !x&y bugs is very low. On the other hand to catch higher level bugs you need a very refined type system, that doesn't seem to go well with the current D Zen. I don't have such numbers, but I think it's not too much hard to find how many bugs have being fixed in that time in Linux. The bug trackers are online. Bye, bearophile
D without a GC (Was: Advocacy (Was: Who here actually uses D?))
On Sun, 02 Jan 2011 21:57:50 +0200, Walter Bright wrote: Sure, but D has *optional* gc. If you want to, you can use D as simply a "better C" and it will compile to the same code as C does. The usual comeback to that is that Phobos depends on the GC, so a great part of the standard library was unusable without memory leaks. I think this is an interesting problem, and solving it could both prove that D *is* practically usable for nontrivial tasks without a GC, and provide a solution for those who can't or don't want to use a GC (you may have noticed how many upvotes the stackoverflow comment about people just not wanting to use a GC got). How much of D can you really use without Phobos? I imagine there'd be no problem in using it as a better C, but there isn't much appeal to that, compared to C++/STL/Boost. A practical No-GC D solution would probably have to include a standard library that works without a GC. Some ideas: * A while ago, it was suggested that there be a version(NO_GC) or something like that, and the standard library could be modified to work differently depending on that version flag. It's probably not practically possible, though, because some functions would not make sense in a GC-less context (lack of GC would require changing their signature/documentation), and the code would quickly become a jungle. * Forking Phobos into a new standard library based on STL-like RAII/refcount constructs (std::string, std::vector) instead of built-in arrays, etc. ** The biggest problem with the above idea is that we're back to typing long type names instead of having the luxury of built-in dynamic arrays/AAs. There could be a language mode (controlled by a compiler switch) which maps the syntax for built-in arrays/AAs to RAII/refcounting library types. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: std.unittests for (final?) review
Jonathan M Davis: > Other changes that some people have expressed interest in are things like > having > it printed when a test passes, and those should not be in the language or > druntime itself. That's going to either have to be in helper functions that > are > run inside of unittest blocks or it's going to need to be possible to run > unittest blocks externally somehow Few hooks may help. Built-in unit tests may call few things that are usually empty (the calls may contain a string with the unit test name, and other data). A unit test library is then free to fill those with code that shows statistics, prints, GUIs, etc. Bye, bearophile
Re: std.unittests for (final?) review
bearophile wrote: > Jens Mueller: > > > I agree with bearophile. Unit testing can be implemented on top of the > > language and shouldn't be put into it. > > This is not what I have said. I was talking about option IV I have explained > here: > http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=107997 > > This means I accept the built-in unit test system, but I think it's wrong to > make it do everything you want from an unit test system. So the built-in one > has to give the basic features (like giving a name to each unit test) that > are later used by the library-defined unit test system. I mean the same. "I like the basic built-in support for unit testing in D but more advanced testing should be implemented in a module ideally leading to something like GoogleTest for D." Advanced features should be implemented on top of the built-in one. Specifically they should not be put into the core language. Sorry for my bad wording. Jens
Re: std.unittests for (final?) review
bearophile wrote: > Jens Mueller: > > > I agree with bearophile. Unit testing can be implemented on top of the > > language and shouldn't be put into it. > > This is not what I have said. I was talking about option IV I have explained > here: > http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=107997 Not sure but is this compatible with your option IV: Built advanced unit testing capabilities on top of the existing ones in a module. You want to add hooks. If you just need them because right now some things cannot be implemented (e.g. because a unit test has no name) then we perfectly agree. There might be things in the current built-in unit testing that prevent implementing some advanced feature on top of them. That needs to be done. Jens
Re: std.unittests for (final?) review
On Monday 03 January 2011 02:39:59 Jens Mueller wrote: > Jonathan M Davis wrote: > > On Monday 03 January 2011 01:38:29 Vladimir Panteleev wrote: > > > On Mon, 03 Jan 2011 06:44:50 +0200, Jonathan M Davis > > > > > > > > > wrote: > > > > So, please have a look at the code. > > > > > > Just one thing: wouldn't these functions also be useful in contract > > > programming (invariants etc.)? Perhaps they should just be added to > > > std.exception? > > > > Well, they're written with unit tests in mind rather than contracts. Unit > > tests and contracts have similar but different purposes. I wouldn't > > really want to conflate the two. Also, it's std.exception now rather > > than std.contracts specifically because it doesn't really relate to > > contracts, so even if you did want to use unit testing functions in > > contracts, I'm not sure that std.exception is the right place to put > > such functions anyway. > > > > As it stands, the entire module is in a version(unittest) block, so the > > functions can't be used outside of unit tests. > > > > If a lot of people really thought that unit testing functions would be > > useful and reasonable to use inside of contracts, then it would make > > some sense for the unit testing functions to no longer be in a > > version(unittest) block. But personally, I'd be a bit worried to see > > more than simple assertions inside of contracts. Contracts should be > > efficient, since they're going to be run while the code is running > > normally, whereas unit tests don't have to worry about efficiency quite > > as much. I believe that the functions that I have are efficient, but I > > can easily see functions intended to aid in unit testing being totally > > inappropriate in a contract due to efficiency concerns. And of course, a > > number of the unit testing functions just don't make sense in contracts > > regardless - like assertExThrown. > > What do you mean by "running normally"? I think since they are compiled > away with -release they are not run normally. I mean when the program is running. If you're running a debug version of your program (which is perfectly normal and common), the contracts are going to run. They're _supposed_ to run while the program is running. That's the point. Naturally, you compile them out for release, but contracts need to be written in way that the program works just fine with them compiled in. Unit tests, on the other hand, don't run while the program is running. They're run once when the program starts up (assuming that -unittest was used), and then they're done. You don't want them to be super slow, but they're not getting called multiple times or running while the program is, so they don't have to be as efficient. - Jonathan M Davis
Re: D without a GC
Vladimir Panteleev: > The usual comeback to that is that Phobos depends on the GC, so a great > part of the standard library was unusable without memory leaks. It's not just Phobos, D is designed to work with a GC (see the recent deprecation of "delete"), some features are designed to work with a GC. Memory management is not a solved problem, it's an open problem still. There is no silver bullet. So my suggestion is to face the situation with a practical point of view and try to attack the problem from all sides at the same time: - Put in Phobos some simple systems to manage memory manually better, like memory pools and a hyerarchical memory manager. - Put in Phobos some (sealed?) collections that manage their own memory, useful when you need a collection of data that contain no GC-managed references, like a double[3]. - Keep using in Phobos the idea used often in Tango of offering an optional way to avoid GC allocations. This helps a lot. - Make the D GC a little more precise: http://d.puremagic.com/issues/show_bug.cgi?id=3463 - Add to DMD a compilation switch to list all places where a closure is created: http://d.puremagic.com/issues/show_bug.cgi?id=5070 - Add to DMD a compilation switch to turn into syntax errors all situations where the GC is silently used (so [1,2]~[3] becomes a syntax error, etc). (Maybe there is a bug report for this too, I don't know the number). - Something like @noheap: http://d.puremagic.com/issues/show_bug.cgi?id=5219 - Add Variable Length Arrays to D, they are much safer than alloca() and avoid some dynamic array heap allocations, reducing pressure on the GC: http://d.puremagic.com/issues/show_bug.cgi?id=5348 - Plan to replace the current GC with a good generational one (and years later with something like G1), because if you have a better GC you have less desire to manage memory manually. Bye, bearophile
Re: std.unittests for (final?) review
> On Monday 03 January 2011 02:39:59 Jens Mueller wrote: > > Jonathan M Davis wrote: > > > > What do you mean by "running normally"? I think since they are compiled > > away with -release they are not run normally. > > I mean when the program is running. If you're running a debug version of your > program (which is perfectly normal and common), the contracts are going to > run. > They're _supposed_ to run while the program is running. That's the point. > Naturally, you compile them out for release, but contracts need to be written > in > way that the program works just fine with them compiled in. I see. You're right. If one uses unittest.d in contracts than they won't work in all builds, namely the build with no -release and no -unittest. Jens
Re: Nimrod language
> - I like the idea of AST macros, they are powerful, A nice example of macro usage: http://lambda-the-ultimate.org/classic/message6437.html Bye, bearophile
Re: Advocacy (Was: Who here actually uses D?)
Travis Boucher wrote: Currently the issues I see with D in kernel land is a fat runtime and type system. Although you can reduce the runtime requirements, you end up losing alot of features and might as well be writing in C at that point anyway. If you're doing kernel dev, you'll most likely write your own runtime anyway. That's what one does with C.
Re: D without a GC
[snip] - Add Variable Length Arrays to D, they are much safer than alloca() and avoid some dynamic array heap allocations, reducing pressure on the GC: http://d.puremagic.com/issues/show_bug.cgi?id=5348 As stated in this proposal they are quite useless, e.g. they are easily implemented via mixin with alloca. Plus, what's the benefit in throwing exception on alloca failure, how you suppose the user to handle this stackoverflow exception? I would have expected a better design to provide an optional parameter to fallback to GC or something ( like malloc(...) + scope(exit) free(...); ) and that's indicates a library solution, of course. -- Dmitry Olshansky
Re: David Simcha's std.parallelism
On Sun, 02 Jan 2011 11:00:36 -0600, Andrei Alexandrescu wrote:
> On 1/2/11 10:39 AM, dsimcha wrote:
>> On 1/1/2011 6:07 PM, Andrei Alexandrescu wrote:
>>> I think David Simcha's library is close to reviewable form. Code:
>>>
>>> http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/
std_parallelism.d
>>>
>>>
>>>
>>> Documentation:
>>>
>>> http://cis.jhu.edu/~dsimcha/d/phobos/std_parallelism.html
>>>
>>> Here are a few comments:
>>>
>>> * parallel is templated on range, but not on operation. Does this
>>> affect speed for brief operations (such as the one given in the
>>> example, squares[i] = i * i)? I wonder if using an alias wouldn't be
>>> more appropriate. Some performance numbers would be very useful in any
>>> case.
>>
>> Will benchmark, though the issue here is that I like the foreach syntax
>> and this can't be done with templates as you describe. Also, IIRC (I'll
>> do the benchmark at some point to be sure) for such examples memory
>> bandwidth is limiting, so the delegate call doesn't matter anyhow.
>
> I think anyone who wants to run something in parallel is motivated
> primarily by increasing efficiency, so focusing on aesthetics would be
> secondary and unsatisfactory for your target audience.
I've already been using David's parallelism library for quite a while,
and parallel foreach is my favourite part of it! I often have programs
that look like this:
foreach (point; grid) { point.doExpensiveComputation(); }
With David's library I just rewrite this into
foreach (point; parallel(grid)) { ... }
Wow! Typing 10 characters just gave me a 3-4 times speedup (assuming
quad core).
So yeah, if using an alias parameter gives significant performance
benefits for cheap operations (such as the squares example), by all
means, add that. But I don't think parallel foreach should be dropped in
any case.
-Lars
Re: D without a GC
Dmitry Olshansky: > As stated in this proposal they are quite useless, e.g. they are easily > implemented via mixin with alloca. Thank you for your comments. Here I have added some answers to your comments: http://d.puremagic.com/issues/show_bug.cgi?id=5348 Bye, bearophile
Re: Moving to D
> How many people are working on this port? How many people will be interested > in using it, considering that a direct port won't use many of D2's features > (why not just use D1)? Will this port be around in 1 year? 5 years? Will it > have the same kind of momentum as the original D1 version, with as many > developers working on it, fixing bugs etc.? Will the API always stay in sync > with the developments in the original D1 version? What about all the > existing documentation, tutorials, even book(s)? There aren't a lot of additions to D1 Tango nowadays, partly because people seems to have other things to do, partly because most of it works pretty nice already. That said, I think the D2-version of Tango will be a one-time fork. Regarding how many people are working on the D2-fork, I think it's quite few (AFAICT only Marenz). The general consensus in Tango have been to wait on D2 to be "finalized" before investing effort into porting. > Sorry, having more options is a good thing, but I think there is a lot more > to a real "Tango for D2" than just someone fixing the code so it compiles > and works. Agreed, but it doesn't all have to happen at day1. Just being able to port Tango-apps over to D2 with minimal fuzz would is valuable in itself. Anyways, IMHO I think one of the most important advances in D2, is the separation of runtime from system-library, such that Phobos and Tango can co-exist more easily, reducing fragmentation.
Re: std.unittests for (final?) review
On Sun, 02 Jan 2011 20:44:50 -0800, Jonathan M Davis wrote:
> Okay. As some of you are aware, I created a module with unit testing
> functions when I wrote std.datetime, and it really helped with writing
> the unit tests for std.datetime. It has been at least somewhat reviewed
> here previously, and that has definitely improved it. However, it has
> not yet been decided whether it's going to go into Phobos along with
> std.datetime. I'd like it to, but it hasn't been voted on, and I'm not
> sure that it's been reviewed as heavily as it should be. So, I'm posting
> the most up-to-date version in the hopes of getting any necessary
> changes found and made so that it can be voted on. Andrei has yet to
> weigh in on std.unittests at all, so I don't know if we're actually
> going to get a vote on it, but I'm presenting it for (final?) review so
> that it can be voted in if that's what he wants to do.
>
> The code: http://is.gd/jZEVl
>
>
> Both the source file and the ddoc hmtl file are included. And unlike
> std.datetime, it's actually straightforward enough that it makes sense
> for your average program to actually look at it.
>
> To be clear, this module has 2 purposes:
>
> 1. Improve error messages on test failure. A good example of this is
> assertEqual, which prints out both of the values being compared so that
> you don't have to add a print statement (or run a debugger) and rerun
> the test to see what the actual values were.
>
> 2. Reduce boiler-plate code in unit tests. A good example of this is
> assertExThrown. Testing whether a function call actually throws an
> exception like it's supposed to becomes a single line of code instead of
> being around 10 lines.
>
> This module does _not_ attempt to change how unit testing in D
> fundamentally works. It does not print out on success. It doesn't make
> it so that a unittest block continues after a failure occurs in that
> block. All of the assertXXX functions throw an AssertError upon failure
> - just like assert does, but the message in the AssertError is far more
> informative. While improvements can be made to how unit tests work in D,
> I believe that that should be addressed by actually making those
> improvements to the core language as opposed to using a module in Phobos
> to change things. You shouldn't _need_ std.unittests to write unit
> testing code.
>
> std.unittests is intended to help you write more informative unit test
> code and save you from writing some of the boilerplate code in unit
> tests, but it is _not_ intended to fundamentally alter how unit tests in
> D function.
>
> So, please have a look at the code. I've made changes according to
> previous suggestions, and I think that the result is quite a bit better
> than my original proposal. If all goes well, perhaps Andrei will put it
> up for vote soon, and we can actually have it in Phobos.
>
> - Jonathan M Davis
Sorry for not commenting on earlier iterations of this module. For the
most part, I think it looks pretty good, and I also think it will be
useful. Often, I find myself writing stuff like
assert (someVar == someVal,
text("Wrong value for someVar: ", someVar));
and assertEqual() will be nice to have for those cases. :) I just have
some minor comments.
1. I think assertExThrown() and assertExNotThrown() should be named
assertThrown() and assertNotThrown(), because they can intercept any
subclass of Throwable, not just Exception, and because you rarely throw
anything else, so it seems redundant.
2. I think the name getMsg() is too non-specific. I'd prefer if it was
renamed to throwableMsg(), thrownMsg(), or something similar. The
function should also be moved upwards a bit so its documentation follows
that of the assert*Thrown() functions. Then, the various functions will
be nicely grouped in the documentation -- all the exception handling
tests come first, followed by the value tests.
-Lars
Re: Less commas
2011/1/2 Peter Alexander : > That really surprises me that it's a common bug. Isn't it obvious that ! has > higher precedence than &? Or have I totally misunderstood the cause of the > bug? Assembler is "obvious". People don't always get that right either. The purpose of a higher-level language IMO, is to make it easier for the developer to express his/her intentions, and pitfalls like this should be avoided. IMHO, the most important job of a high-level language is to encourage good programming practices. There's a reason why people aren't seriously using Brainfuck. It's not because it's not turing-complete, it's because it's simply difficult to get right. There's also a reason why "object oriented" languages were invented. It's not because you can't do object-oriented code in C, it's because object orientation in an object-oriented language is easier and more readable. Programming languages is all about encouraging preferred models.
Re: streaming redux
On Sat, 01 Jan 2011 10:59:47 -0500, so wrote: This can be significantly shortened: write((&i)[0..1]); Wow, i didn't know that! Could you point me to doc, please? Thanks. http://www.digitalmars.com/d/2.0/arrays.html#implicit-conversions -Steve
Re: std.unittests for (final?) review
On 2011-01-03 05:04:28 -0500, Jonathan M Davis said:
If a lot of people really thought that unit testing functions would be useful
and reasonable to use inside of contracts, then it would make some
sense for the
unit testing functions to no longer be in a version(unittest) block. But
personally, I'd be a bit worried to see more than simple assertions inside of
contracts. Contracts should be efficient, since they're going to be run
while the
code is running normally, whereas unit tests don't have to worry about
efficiency
quite as much. I believe that the functions that I have are efficient,
but I can
easily see functions intended to aid in unit testing being totally
inappropriate
in a contract due to efficiency concerns. And of course, a number of the unit
testing functions just don't make sense in contracts regardless - like
assertExThrown.
This makes me think of an issue. In contracts, asserts use a different
implementation so they can work with inheritance. I believe in unit
tests too the compiler use a different implementation too for asserts
which gives more control to the runtime over what to do when a test
fails (remember previous behaviour where asserts in unit tests were
simply printing a message without aborting?). Assertions inside a
function and inside a contract and inside a unittest block being
different things makes me rather hesitant when I see a function
designed to be used as a special assert in a unit test...
So given the choice between these two forms:
unittest { assertExThrown!Exception(test); }
unittest { assert(exThrown!Exception(test)); }
I'd choose the second just to be sure the right assertion handler is used.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: Advocacy (Was: Who here actually uses D?)
Walter: > I'm afraid that's baloney, as I pointed out in the other thread. What you have said was about application code. It's not true for kernel code, where you need strict control on what, how, and if the compiler performs certain optimizations. > I think that is a serious misinterpretation of the complaint. The complaint > was > actually that the high level abstractions that one can choose to use in C++ > can > be impenetrable in what they do. In D, if you want low level control, write > low > level code. It's that simple. This is true for C++ too. But he doesn't want high level abstractions in kernel code. So he has not much use for C++ and D too. But he wants more static analysis. > Typed assembler is a waste of effort in a language like D, as you only need a > few drops of assembler here and there. This talk says: http://www.linuxjournal.com/article/7272 >The problem is that being the kernel has to do a lot of things that break >typechecking. Which you see more in the kernel than in a lot of other >programs. You end up having a lot of inline assembly which is obviously >completely opaque.< In the Nucleus of the experimental operating system Verve I have seen a good amount of assembly code. They are able to use so much assembly because it's not normal assembly, it's typed its assertions are often verified statically. So it's not completely opaque. In the D runtime I have counted 2100 lines of asm just for the array operations implementation, (that's unfinished still). asm code is uncommon in application programs, but it's clearly more than few drops. > Those languages are failures at what they propose to do; they need years and > perhaps decades to fulfill that. C#4 has contracts too, as a library: http://research.microsoft.com/en-us/projects/contracts/ But this page says something interesting: http://msdn.microsoft.com/en-us/devlabs/dd491992.aspx >Code Contracts Premium Edition: This version installs only if you have one of >the following: Visual Studio 2008 Team System, Visual Studio 2010 Premium >Edition, or Visual Studio 2010 Ultimate Edition. It includes the static >checker in addition to all of the features in the Code Contracts Standard >Edition.< It means that if today you have better versions of Visual Studio, then you have a static checker for contracts. I have not used them yet, I will try to try them. As you see Microsoft is pushing some of its research in the Real World today. And regardless the usefulness of Verve today, they contain some quite interesting ideas. I'm not just an engineer, I like ideas too. Shutting the brain closed is stupid. Bye, bearophile
Re: Advocacy (Was: Who here actually uses D?)
"Code Contracts Premium Edition" That's just hillarious. What's next, will the customers be forced to buy a dozen pointers in a bundle? If you try using more than 10 pointers in your app you'll get a pop-up saying you're can't do that in the trial version, upgrade now!. LOL!
Re: Moving to D
Agreed, but it doesn't all have to happen at day1. Just being able to port Tango-apps over to D2 with minimal fuzz would is valuable in itself. Anyways, IMHO I think one of the most important advances in D2, is the separation of runtime from system-library, such that Phobos and Tango can co-exist more easily, reducing fragmentation. So true.
Re: Advocacy (Was: Who here actually uses D?)
"Limited offer: Increase your stack size, for only 49.99$!"
Re: Who here actually uses D?
On Sat, 01 Jan 2011 17:22:35 -0500, Robert Clipsham wrote: Having seen a post by Peter Alexander (in Re: D for game development), mentioning some of the issues he's hit I thought I'd post this. I've been in his shoes (every other time I use D it seems), and feel I should ask - who here uses D, and to what extent? I'm mostly interested in those of you with 1000 Line plus projects in D, as that's when I've found I start hitting issues. Just to clarify, for those D purists among you... I'm not trolling, just curious (I wouldn't normally have asked, but now I know I'm not paranoid and the only one having problems, I thought I'd ask). At my previous job, I used D1/Tango to implement a network client to allow remote execution of programs. It was probably on the order of 5KLOC. Other than that, I wrote dcollections which is a fair size, but not really an 'end' product. However, it is D2. In my new job, I'm doing all web development (php+mysql) so, I have very little opportunity to use D professionally recently. As far as bugs hit, I found quite a few while creating the unit tests for dcollections. My experience with the bugs has been that you are playing sort of a game of roulette -- you could hit a bug that's annoying but has a workaround, or you could hit a blocker. Hitting a blocker is horrible, because you basically are stuck in your tracks, and you are depending on someone else to fix the bug to get you going. There was a time where dcollections was stalled for probably close to a year, if not more, because of a bizarre interface bug: http://d.puremagic.com/issues/show_bug.cgi?id=2061 Those are the bugs that can piss you off to the point of abandoning D. -Steve
Re: std.unittests for (final?) review
On 1/3/11, Jonathan M Davis wrote:
> Other changes that some people have expressed interest in are things like
> having
> it printed when a test passes, and those should not be in the language or
> druntime itself.
Isn't this already done in Phobos?:
unittest
{
debug(std_algorithm) scope(success)
writeln("unittest @", __FILE__, ":", __LINE__, " done.");
}
--
Re: std.unittests for (final?) review
Also, you know you get my vote. :)
Re: Advocacy (Was: Who here actually uses D?)
On 03.01.2011 16:19, Andrej Mitrovic wrote: "Limited offer: Increase your stack size, for only 49.99$!" LOL, BTW vendors should also like it: reselling already sold hardware to developers :) -- Dmitry Olshansky
Re: property-like data members
On Mon, 03 Jan 2011 00:55:47 -0500 "Robert Jacques" wrote: > On Sun, 02 Jan 2011 05:29:48 -0500, spir wrote: > > Hello, > > > > Using properties allows travesting a method call into direct data > > access. What if the underlying member actually is plain data? Would it > > be possible to provide a real data member where the language expects a > > property (for instance as range empty & front properties)? > > Yes, see the Uniform access principle > (http://en.wikipedia.org/wiki/Uniform_access_principle). (Though UAP > hasn't been discussed much on the newsgroup) Thank you, Robert for the pointer. Actually, I know this principle a bit; but would it be hard to implement it for d: * maybe for properties only, * if the data member is marked as (pseudo)property ? (The latter condition to give a hint to the compiler that member name & type coincidence are intended.) Genis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: property-like data members
On Sun, 02 Jan 2011 05:29:48 -0500, spir wrote:
Hello,
Using properties allows travesting a method call into direct data
access. What if the underlying member actually is plain data? Would it
be possible to provide a real data member where the language expects a
property (for instance as range empty & front properties)?
Yes, just use a data member:
struct MyRange {
int front;
bool empty;
void popFront();
}
A property is actually supposed to work just like a field.
There is no need for new syntax.
-Steve
Re: Hooking the GC?
On Sun, 02 Jan 2011 22:34:55 -0500, %u wrote: Hi, Is there any way to add a hook to the garbage collector in D, so that I can be immediately notified (for example) when an object is created? (I'm aware that this could cause infinite recursion/deadlock if I try to allocate memory, but that's all right, I'm fine with that.) Thank you! If you want to hook the GC, you probably have to add your own code to the GC. Start with _d_newclass in druntime's src/rt/lifetime.d -Steve
Re: std.unittests for (final?) review
On Monday 03 January 2011 05:26:14 Andrej Mitrovic wrote:
> On 1/3/11, Jonathan M Davis wrote:
> > Other changes that some people have expressed interest in are things like
> > having
> > it printed when a test passes, and those should not be in the language or
> > druntime itself.
>
> Isn't this already done in Phobos?:
>
> unittest
> {
> debug(std_algorithm) scope(success)
> writeln("unittest @", __FILE__, ":", __LINE__, " done.");
> }
>
> --
I think that it's fine if someone wants to make their unittest blocks print out
on success, but that doesn't work in the general case with the unit tests
running before main. And if you made it so that they _did_ print success, then
what would the people who only want the failures do? With the current scheme,
you can make it print if you want to, but it's not forced on you. And honestly,
aside from creating a simple string mixin which does what Phobos is doing in
your example, I don't how you could really have helper functions for that.
However, maybe adding a function which returns an appropriate string to mixin
to
print successes like Phobos is there would be of some value in std.unittests.
Regardless, printing test successes is definitely example of where named unit
tests would be nice. And being able to name unittest blocks is definitely a
change that would have to be made in the language. Of course, what I _really_
want named unit tests for is so that the stack traces have recognizable names
in
them for unittest blocks.
In any case, it's perfectly possible to do as Phobos does above and have extra
code in your unittest blocks which prints upon success.
- Jonathan M Davis
Re: D without a GC
== Quote from bearophile (bearophileh...@lycos.com)'s article
> Dmitry Olshansky:
> > As stated in this proposal they are quite useless, e.g. they are easily
> > implemented via mixin with alloca.
> Thank you for your comments. Here I have added some answers to your comments:
> http://d.puremagic.com/issues/show_bug.cgi?id=5348
> Bye,
> bearophile
Some thoughts to your proposal:
> void bar(int len) {
> Foo* ptr = cast(Foo*)alloca(len * Foo.sizeof);
> if (ptr == null)
> throw new Exception("alloca failed");
> Foo[] arr = ptr[0 .. len];
> foreach (ref item; arr)
> item = Foo.init;
>
> // some code here
> writeln(arr);
>
> foreach (ref item; arr)
> item.__dtor();
> }
1) Why call the dtors manually? Forgive me if I'm wrong, but iirc, alloca will
free the memory when the stack exits from the current frame level. :)
2) The GCC implementation is roughly equivalent to this:
{
size_t len;
void * saved_stack;
int[len] * arr.2;
int arr[len] [value-expr: *arr.2];
saved_stack = __builtin_stack_save ();
try
{
arr.2 = (int[len] *) __builtin_alloca (len * 4);
}
finally
{
__builtin_stack_restore (saved_stack);
}
}
And any interaction with the VLA is done within the try block.
Being a very biased person, in an imaginary D implementation I'd favour some
similar sort of behaviour. :o)
Re: std.unittests for (final?) review
We can always resort to hacks!
module namedUnittest;
import std.stdio;
import std.string;
void main()
{
}
unittest // Foo
{
scope(failure)
{
writefln("Unittest '%s' Failed: ",
split(split(import(.stringof[7..$] ~ ".d"),
"\r\n")[__LINE__-5..__LINE__-4][0])[2]);
}
assert(0 == 1, "0 != 1");
}
..what..? Why are you looking at me like that? :p
Re: std.unittests for (final?) review
P.S. that will only work with windows newlines, and fail without the -J switch. Hehe.
Re: D without a GC
2011/1/3 Iain Buclaw :
> == Quote from bearophile (bearophileh...@lycos.com)'s article
>> Dmitry Olshansky:
>> > As stated in this proposal they are quite useless, e.g. they are easily
>> > implemented via mixin with alloca.
>> Thank you for your comments. Here I have added some answers to your comments:
>> http://d.puremagic.com/issues/show_bug.cgi?id=5348
>> Bye,
>> bearophile
>
> Some thoughts to your proposal:
>
>> void bar(int len) {
>> Foo* ptr = cast(Foo*)alloca(len * Foo.sizeof);
>> if (ptr == null)
>> throw new Exception("alloca failed");
>> Foo[] arr = ptr[0 .. len];
>> foreach (ref item; arr)
>> item = Foo.init;
>>
>> // some code here
>> writeln(arr);
>>
>> foreach (ref item; arr)
>> item.__dtor();
>> }
>
> 1) Why call the dtors manually? Forgive me if I'm wrong, but iirc, alloca will
> free the memory when the stack exits from the current frame level. :)
The dtor doesn't free memory, it allows the class to perform cleanup
on destruction, such as close():ing any native FD:s etc.
Actually, AFAICT, the above code should also after "item=Foo.init"
call item.__ctor(), to allow the constructor to run.
IMHO, stdlibs should provide wrappers for this type of functionality.
An application-writer should not have to know the intricate details of
__ctor and __dtor as opposed to memory-mangement etc. A template
"stackAllocate!(T)" would be nice.
Re: const - Best practices
On 1/3/11 12:06 AM, Peter Alexander wrote: [quoting an older post of mine] As an aside, I know what it takes to define lazily computed state to work with const, but Walter is at the bottom of a 5000 TeV potential hole that spells like "this is like C++ mutable and C++ mutable is incorrect, therefore I will not process any information henceforth". So I am unable to even start explaining that to him. Besides, assuming Walter is convinced of the correctness of the feature, it's unclear whether it will pull its weight. It will complicate the language, and the benefits, while there, are rather subtle. I am glad to announce that now Walter and me see eye to eye in the matter of lazily computable state. We also have a path to get there, but it's a fair amount of work. Andrei
Re: std.unittests for (final?) review
On 1/3/11 3:38 AM, Vladimir Panteleev wrote: On Mon, 03 Jan 2011 06:44:50 +0200, Jonathan M Davis wrote: So, please have a look at the code. Just one thing: wouldn't these functions also be useful in contract programming (invariants etc.)? Perhaps they should just be added to std.exception? In fact (without looking at std.unittest) I think it should be grouped with a simple benchmark facility. That's what the homonym frameworks in Google's and Facebook's code base do. Does anyone want to be the review manager? Refer to http://www.boost.org/community/reviews.html. Also, everybody please follow the guidelines in that document for submitting your comments. Let's collect comments and votes until February 7, when a decision will be made about inclusion into Phobos. Andrei
Re: property-like data members
On Mon, 03 Jan 2011 08:34:42 -0500
"Steven Schveighoffer" wrote:
> Yes, just use a data member:
>
> struct MyRange {
> int front;
> bool empty;
> void popFront();
> }
>
> A property is actually supposed to work just like a field.
>
> There is no need for new syntax.
Hum, does not work by me (else I would not have posted ;-)
The compiler rejects the code complaining for missing opApply (which I
interpret as meaning it does not recognize a range in such an interface).
indeed, it works if manually implement iteration like for instance:
while (! coll.empty) {
auto element = coll.front;
use(element);
coll.popFront();
}
But then there no property in play (I mean the compiler does not expect a
property set implementing a range).
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: std.unittests for (final?) review
On Monday 03 January 2011 06:43:24 Andrei Alexandrescu wrote: > On 1/3/11 3:38 AM, Vladimir Panteleev wrote: > > On Mon, 03 Jan 2011 06:44:50 +0200, Jonathan M Davis > > > > wrote: > >> So, please have a look at the code. > > > > Just one thing: wouldn't these functions also be useful in contract > > programming (invariants etc.)? Perhaps they should just be added to > > std.exception? > > In fact (without looking at std.unittest) I think it should be grouped > with a simple benchmark facility. That's what the homonym frameworks in > Google's and Facebook's code base do. I'm afraid that I don't see what unit test helper functions have to do with benchmarking. And I don't believe that we have a benchmarking module at the moment regardless, so if you want to do that, we'd need to create one. The only benchmarking stuff that I'm aware of is the bencharking stuff in std.datetime that SHOO did, which isn't all that much code. I would have thought that unit test helper functions would merit their own module, particularly when I don't see what they have to do with benchmarks. - Jonathan M Davis
Re: std.unittests for (final?) review
On 1/3/11 9:02 AM, Jonathan M Davis wrote: On Monday 03 January 2011 06:43:24 Andrei Alexandrescu wrote: On 1/3/11 3:38 AM, Vladimir Panteleev wrote: On Mon, 03 Jan 2011 06:44:50 +0200, Jonathan M Davis wrote: So, please have a look at the code. Just one thing: wouldn't these functions also be useful in contract programming (invariants etc.)? Perhaps they should just be added to std.exception? In fact (without looking at std.unittest) I think it should be grouped with a simple benchmark facility. That's what the homonym frameworks in Google's and Facebook's code base do. I'm afraid that I don't see what unit test helper functions have to do with benchmarking. They both help the decision: "Is this module good to go?" At work we almost always put benchmarks in the same file as the unit tests, and run them together (subject to a --benchmark flag because benchmarks tend to take a fair amount of time). I find that very natural, although I should add that the unittest and benchmark libraries are nominally distinct. And I don't believe that we have a benchmarking module at the moment regardless, so if you want to do that, we'd need to create one. The only benchmarking stuff that I'm aware of is the bencharking stuff in std.datetime that SHOO did, which isn't all that much code. I would have thought that unit test helper functions would merit their own module, particularly when I don't see what they have to do with benchmarks. Adding basic support for benchmarking shouldn't be difficult and does not entail a lot of code, but I understand it if you're not all that motivated to work on that. Andrei
Re: std.unittests for (final?) review
On Monday 03 January 2011 07:17:56 Andrei Alexandrescu wrote: > On 1/3/11 9:02 AM, Jonathan M Davis wrote: > > On Monday 03 January 2011 06:43:24 Andrei Alexandrescu wrote: > >> On 1/3/11 3:38 AM, Vladimir Panteleev wrote: > >>> On Mon, 03 Jan 2011 06:44:50 +0200, Jonathan M Davis > >>> > >>> wrote: > So, please have a look at the code. > >>> > >>> Just one thing: wouldn't these functions also be useful in contract > >>> programming (invariants etc.)? Perhaps they should just be added to > >>> std.exception? > >> > >> In fact (without looking at std.unittest) I think it should be grouped > >> with a simple benchmark facility. That's what the homonym frameworks in > >> Google's and Facebook's code base do. > > > > I'm afraid that I don't see what unit test helper functions have to do > > with benchmarking. > > They both help the decision: "Is this module good to go?" At work we > almost always put benchmarks in the same file as the unit tests, and run > them together (subject to a --benchmark flag because benchmarks tend to > take a fair amount of time). I find that very natural, although I should > add that the unittest and benchmark libraries are nominally distinct. > > > And I don't believe that we have a benchmarking module at the > > moment regardless, so if you want to do that, we'd need to create one. > > The only benchmarking stuff that I'm aware of is the bencharking stuff > > in std.datetime that SHOO did, which isn't all that much code. I would > > have thought that unit test helper functions would merit their own > > module, particularly when I don't see what they have to do with > > benchmarks. > > Adding basic support for benchmarking shouldn't be difficult and does > not entail a lot of code, but I understand it if you're not all that > motivated to work on that. I'm by no means against it, but I wouldn't have a clue what to even do for benchmarking code. I've never used a benchmarking library or done much more than the occasional ad-hoc benchmarks, so I'm not at all familiar with what would be typically done for benchmarking in a library. I'm really not the person to implement such functionality. And I'm busy enough with other stuff at the moment, that I'm not in a hurry to spend time trying to figure out the best benchmarking functionality for Phobos. It could be that it's very straightforward, but using something similar to SHOO's stopwatch to time code is about as far as my experience goes. - Jonathan M Davis
Re: property-like data members
On Mon, 03 Jan 2011 09:56:30 -0500, spir wrote:
On Mon, 03 Jan 2011 08:34:42 -0500
"Steven Schveighoffer" wrote:
Yes, just use a data member:
struct MyRange {
int front;
bool empty;
void popFront();
}
A property is actually supposed to work just like a field.
There is no need for new syntax.
Hum, does not work by me (else I would not have posted ;-)
The compiler rejects the code complaining for missing opApply (which I
interpret as meaning it does not recognize a range in such an
interface). indeed, it works if manually implement iteration like for
instance:
while (! coll.empty) {
auto element = coll.front;
use(element);
coll.popFront();
}
But then there no property in play (I mean the compiler does not expect
a property set implementing a range).
That's a bug. isInputRange!S returns true.
There's nothing in the spec that says foreach requires those elements to
be functions. In fact, empty *does* work as a normal field, i.e. this
struct is foreachable:
struct S
{
@property int front() {return 0;}
bool empty;
void popFront() {empty = true;}
}
Filed:
http://d.puremagic.com/issues/show_bug.cgi?id=5403
-Steve
Re: std.unittests for (final?) review
> >>In fact (without looking at std.unittest) I think it should be grouped
> >>with a simple benchmark facility. That's what the homonym frameworks in
> >>Google's and Facebook's code base do.
> >
> >I'm afraid that I don't see what unit test helper functions have to do with
> >benchmarking.
>
> They both help the decision: "Is this module good to go?" At work we
> almost always put benchmarks in the same file as the unit tests, and
> run them together (subject to a --benchmark flag because benchmarks
> tend to take a fair amount of time). I find that very natural,
> although I should add that the unittest and benchmark libraries are
> nominally distinct.
How do you do it? I had similar thoughts. When I do testing I also want
to add some performance tests. In D I thought about having
version(performance) (maybe better version(benchmark)) inside a unittest
{} to assess performance. This way compiling with -unittest
-version=performance will execute the benchmarking code.
> >And I don't believe that we have a benchmarking module at the
> >moment regardless, so if you want to do that, we'd need to create one. The
> >only
> >benchmarking stuff that I'm aware of is the bencharking stuff in
> >std.datetime that
> >SHOO did, which isn't all that much code. I would have thought that unit test
> >helper functions would merit their own module, particularly when I don't see
> >what they have to do with benchmarks.
>
> Adding basic support for benchmarking shouldn't be difficult and
> does not entail a lot of code, but I understand it if you're not all
> that motivated to work on that.
What do you think is needed for basic support? I found std.perf and used
it but I think it's deprecated. But std.datetime will do it as well (I
haven't looked at it though).
Jens
Re: Nimrod language
"bearophile" wrote >> - I like the idea of AST macros, they are powerful, > > A nice example of macro usage: > http://lambda-the-ultimate.org/classic/message6437.html > > Bye, > bearophile > D can also do some https://github.com/AlexYD/DPP/blob/master/bin/Debug/test.d
Re: property-like data members
On Mon, 03 Jan 2011 10:27:17 -0500
"Steven Schveighoffer" wrote:
> On Mon, 03 Jan 2011 09:56:30 -0500, spir wrote:
>
> > On Mon, 03 Jan 2011 08:34:42 -0500
> > "Steven Schveighoffer" wrote:
> >
> >> Yes, just use a data member:
> >>
> >> struct MyRange {
> >> int front;
> >> bool empty;
> >> void popFront();
> >> }
> >>
> >> A property is actually supposed to work just like a field.
> >>
> >> There is no need for new syntax.
> >
> > Hum, does not work by me (else I would not have posted ;-)
> > The compiler rejects the code complaining for missing opApply (which I
> > interpret as meaning it does not recognize a range in such an
> > interface). indeed, it works if manually implement iteration like for
> > instance:
> > while (! coll.empty) {
> > auto element = coll.front;
> > use(element);
> > coll.popFront();
> > }
> > But then there no property in play (I mean the compiler does not expect
> > a property set implementing a range).
>
> That's a bug. isInputRange!S returns true.
>
> There's nothing in the spec that says foreach requires those elements to
> be functions. In fact, empty *does* work as a normal field, i.e. this
> struct is foreachable:
>
> struct S
> {
> @property int front() {return 0;}
> bool empty;
> void popFront() {empty = true;}
> }
>
> Filed:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=5403
>
> -Steve
All right. great that we can do that (provide a plain data member where a
property is expected).
denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: Who here actually uses D?
"Patrick Kreft" wrote in message news:op.vop6g7wgq2m...@zeus-pc.belkin... > On Mon, 03 Jan 2011 06:53:36 +0100, Nick Sabalausky wrote: > >> "Patrick Kreft" wrote in message >> news:op.vopbqgqzq2m...@zeus-pc.belkin... >>> On Sun, 02 Jan 2011 19:28:07 +0100, Nick Sabalausky wrote: >>> Yea, my three primary critera for a GUI lib are: - Multiplatform - Native controls - Works on D2 >>> >>> >>> Qt has self-drawn control, which could hold an native handler, if >>> needed. >>> But they are different from native control. >> >> Qt has a compile-time setting to disable that and just use native >> controls >> like it always used to do. And since Qt added the self-drawing primarily >> just to decrease some redraw flicker, I suspect its self-drawing might >> not >> be too bad. >> > > Sry there is no argument in your post. > > You can enbale an native handler to the control in three ways. Look for Qt > Documentation. > As i said qt controls haven't the look and behavior like native controls > such as control created by winapi, mfc or winforms. There seems to be a lot of conflicting information about Qt then. I read a post from one of the Qt devs that said basically what I said above. So I guess at this point I haven't a clue what to make of Qt. Oh well, anyone know if wx is coming to D2?
Re: Who here actually uses D?
"Lars T. Kyllingstad" wrote in message news:ifs496$tg...@digitalmars.com... > > And the few annoyances I face with D are insignificant > compared to the major PITA of using C/C++ [...] or Java [...]. > That's exactly my experience with D: Sure, there are a few hiccups, but dealing with hiccups is FAR better than dealing with a language (like C/C++/Java) that just sucks to begin with.
Re: Who here actually uses D?
"Nick Sabalausky" wrote in message news:ifsvc4$3l...@digitalmars.com... > "Lars T. Kyllingstad" wrote in message > news:ifs496$tg...@digitalmars.com... >> >> And the few annoyances I face with D are insignificant >> compared to the major PITA of using C/C++ [...] or Java [...]. >> > > That's exactly my experience with D: Sure, there are a few hiccups, but > dealing with hiccups is FAR better than dealing with a language (like > C/C++/Java) that just sucks to begin with. > For instance, DMD's bugs get fixed or at least worked around, but C++ will likely never get a real module system, strong typing (as opposed to the "*cough* 'strong typing' *cough*" it has now), or non-PITA metaprogramming.
Re: Who here actually uses D?
On 03/01/11 16:53, Nick Sabalausky wrote: There seems to be a lot of conflicting information about Qt then. I read a post from one of the Qt devs that said basically what I said above. So I guess at this point I haven't a clue what to make of Qt. Oh well, anyone know if wx is coming to D2? Having used both Qt and QtD on (Windows|Linux|OS X), I can say it looks native on all platforms (who cares if it actually is, it looks and feels it). I've never used QtD with D2, when I used it with D1/Tango it was pretty much fully functional GUI wise. No idea about wx/D2, sorry. -- Robert http://octarineparrot.com/
Re: Who here actually uses D?
I can report that QtD seems to work for D2 now. kilckverbot issued a CTFE fix that was problematic for many examples that I've tried yesterday. I am trying out all of the examples right now (a few examples are using Tango and will have to be cloned and modified for Phobos), so far they're compiling and running fine. You will need cmake installed, fetch the repo from https://bitbucket.org/qtd/repo/issues?status=new&status=open, follow the instructions here http://www.dsource.org/projects/qtd/wiki/BuildWindows, download Qt, and might have to patch dmd with http://www.dsource.org/projects/qtd/wiki/DmdPatch. I did the patching manually since the patch was made for an older dmd release (It's just a dozen lines of code, so it's easy). After that just add the path to the import libs, copy the DLLs and build the examples. Nick, if you want to give it a shot but have trouble setting it up properly let me know and I'll help out.
Re: Who here actually uses D?
Nick Sabalausky wrote: Oh well, anyone know if wx is coming to D2? What does this mean ? If wxWidgets is being ported to D2 ? Or if you can use wxWidgets from D2, if so: yes you can. Or at least you could, back with DMD 2.049 (or whatever) But what should be done is to regenerate it with SWIG/etc. Even if wxD "works" with D2 and wx3 too, it's still a port from wx.NET and wxWidgets 2.6.4 API - and 5 years old now. --anders
Re: Who here actually uses D?
Robert Clipsham Wrote: > Having seen a post by Peter Alexander (in Re: D for game development), > mentioning some of the issues he's hit I thought I'd post this. I've > been in his shoes (every other time I use D it seems), and feel I should > ask - who here uses D, and to what extent? > > I'm mostly interested in those of you with 1000 Line plus projects in D, > as that's when I've found I start hitting issues. > > Just to clarify, for those D purists among you... I'm not trolling, just > curious (I wouldn't normally have asked, but now I know I'm not paranoid > and the only one having problems, I thought I'd ask). We used D in a college project. It's a Wolfenstein 3D clone (simple ray caster engine, untextured floor and ceil, our own software renderer, uses SDL) written in D1 by 7 persons. Thanks to fast compile speed we were able to use TDD heavily. The game is about 105 kLOC and the unittest suite 280 kLOC with documents. We were impressed how tight code was possible to write in D (FPS games can have millions lines of code) and how unittests were integrated in the language. We would not have been able to implement anything as complex in C++ or Java in only 3 months. Maybe a tic tac toe or tetris. My role was porting Java/C++ type coding style of other members in more like D as the repository master. They quickly learned more advanced idioms. We encountered one forward reference bug, but it disappeared when restructuring program. No other bugs were found in D and we updated the compiler in 1-7 days when a new came.
Re: Who here actually uses D?
"Andrej Mitrovic" wrote in message news:mailman.397.1294077039.4748.digitalmar...@puremagic.com... >I can report that QtD seems to work for D2 now. kilckverbot issued a > CTFE fix that was problematic for many examples that I've tried > yesterday. I am trying out all of the examples right now (a few > examples are using Tango and will have to be cloned and modified for > Phobos), so far they're compiling and running fine. > > You will need cmake installed, fetch the repo from > https://bitbucket.org/qtd/repo/issues?status=new&status=open, follow > the instructions here > http://www.dsource.org/projects/qtd/wiki/BuildWindows, download Qt, > and might have to patch dmd with > http://www.dsource.org/projects/qtd/wiki/DmdPatch. I did the patching > manually since the patch was made for an older dmd release (It's just > a dozen lines of code, so it's easy). > > After that just add the path to the import libs, copy the DLLs and > build the examples. Nick, if you want to give it a shot but have > trouble setting it up properly let me know and I'll help out. Cool, thanks. I'm not sure when I'll actually have a chance, but I definitely want to try that.
Re: Who here actually uses D?
"Robert Clipsham" wrote in message news:ift0mt$60...@digitalmars.com... > On 03/01/11 16:53, Nick Sabalausky wrote: >> There seems to be a lot of conflicting information about Qt then. I read >> a >> post from one of the Qt devs that said basically what I said above. So I >> guess at this point I haven't a clue what to make of Qt. Oh well, anyone >> know if wx is coming to D2? > > Having used both Qt and QtD on (Windows|Linux|OS X), I can say it looks > native on all platforms (who cares if it actually is, it looks and feels > it). > The typical problem with things that look native but aren't technically native is that there's almost inevitably things that don't work right. For instance, they may ignore the system color scheme, they may fail to work with tools that inspect/manipulate other app's controls, they may not behave correctly outside of the most common use-cases, they may ignore system-wide skin settings (such things do, and should, exist for Windows), and I've even seen ones that actually go and emulate the wrong system style (For instance, Chrome/Iron's dialog windows look like Aero...but I'm on XP, and if I were on Win7 I'd be using the Classic theme anyway. Very very sloppy). If it turns out that Qt's self-drawn controls doesn't have any of those issues, then I agree there's no problem at all. I'd also be incredibly impressed.
Re: Who here actually uses D?
"Anders F Björklund" wrote in message news:ift31b$al...@digitalmars.com... > Nick Sabalausky wrote: >> Oh well, anyone know if wx is coming to D2? > > What does this mean ? If wxWidgets is being ported to D2 ? > > Or if you can use wxWidgets from D2, if so: yes you can. > Or at least you could, back with DMD 2.049 (or whatever) > > But what should be done is to regenerate it with SWIG/etc. > > Even if wxD "works" with D2 and wx3 too, it's still a port > from wx.NET and wxWidgets 2.6.4 API - and 5 years old now. > Ahh, I was under the impression there were currently no wd bindings for D2, just D1. Am I correct in my understanding that wx is cross-platform and uses native controls? Also, as I haven't followed this real closely, what's the current state of SWIG for D? Fully-usable?
Re: Who here actually uses D?
"Nick Sabalausky" wrote in message news:ift425$cf...@digitalmars.com... > "Anders F Björklund" wrote in message > news:ift31b$al...@digitalmars.com... >> Nick Sabalausky wrote: >>> Oh well, anyone know if wx is coming to D2? >> >> What does this mean ? If wxWidgets is being ported to D2 ? >> >> Or if you can use wxWidgets from D2, if so: yes you can. >> Or at least you could, back with DMD 2.049 (or whatever) >> >> But what should be done is to regenerate it with SWIG/etc. >> >> Even if wxD "works" with D2 and wx3 too, it's still a port >> from wx.NET and wxWidgets 2.6.4 API - and 5 years old now. >> > > Ahh, I was under the impression there were currently no wd bindings for > D2, just D1. Am I correct in my understanding that wx is cross-platform > and uses native controls? > > Also, as I haven't followed this real closely, what's the current state of > SWIG for D? Fully-usable? > s/wd/wx/
Re: Who here actually uses D?
"Jean Crystof" wrote in message news:ift3aj$b9...@digitalmars.com... > Robert Clipsham Wrote: > >> Having seen a post by Peter Alexander (in Re: D for game development), >> mentioning some of the issues he's hit I thought I'd post this. I've >> been in his shoes (every other time I use D it seems), and feel I should >> ask - who here uses D, and to what extent? >> >> I'm mostly interested in those of you with 1000 Line plus projects in D, >> as that's when I've found I start hitting issues. >> >> Just to clarify, for those D purists among you... I'm not trolling, just >> curious (I wouldn't normally have asked, but now I know I'm not paranoid >> and the only one having problems, I thought I'd ask). > > We used D in a college project. It's a Wolfenstein 3D clone (simple ray > caster engine, untextured floor and ceil, our own software renderer, uses > SDL) written in D1 by 7 persons. Thanks to fast compile speed we were able > to use TDD heavily. The game is about 105 kLOC and the unittest suite 280 > kLOC with documents. We were impressed how tight code was possible to > write in D (FPS games can have millions lines of code) and how unittests > were integrated in the language. We would not have been able to implement > anything as complex in C++ or Java in only 3 months. Maybe a tic tac toe > or tetris. My role was porting Java/C++ type coding style of other members > in more like D as the repository master. They quickly learned more > advanced idioms. > > We encountered one forward reference bug, but it disappeared when > restructuring program. No other bugs were found in D and we updated the > compiler in 1-7 days when a new came. Cool. I find raycasters very nostalgic. Out of curiosity, was there any book or reference that you used for the raycasting algorithm, or did you just work out the math and implement? There are a least a couple old DOS-based raycasting book I read cover-to-cover back in the day. Although I've never actually implemented anything other than a Mode7-style floor.
Re: Who here actually uses D?
Nick Sabalausky wrote: What does this mean ? If wxWidgets is being ported to D2 ? Or if you can use wxWidgets from D2, if so: yes you can. Or at least you could, back with DMD 2.049 (or whatever) But what should be done is to regenerate it with SWIG/etc. Even if wxD "works" with D2 and wx3 too, it's still a port from wx.NET and wxWidgets 2.6.4 API - and 5 years old now. Ahh, I was under the impression there were currently no wd bindings for D2, just D1. Am I correct in my understanding that wx is cross-platform and uses native controls? You are correct. Where native means Win32/Win64 or GTK+ or Carbon/Cocoa. There's even a Qt4 port coming next to the GTK+, and an old limited X11. wxD uses wx.NET as a base, where wxHaskell uses wxEiffel, but same idea. Drew some images and stuff on http://wxd.sourceforge.net/ to explain it. Also, as I haven't followed this real closely, what's the current state of SWIG for D? Fully-usable? No idea. But I saw that just like GCC it comes with Go language support. Just saying that the "correct" approach is to generate it from the C++ ? The current export "C" code is generated by a mix of Perl and monkeys... See http://xkcd.com/224/ for some related information on how that works. --anders
Re: Who here actually uses D?
On 03/01/11 18:15, Nick Sabalausky wrote: The typical problem with things that look native but aren't technically native is that there's almost inevitably things that don't work right. For instance, they may ignore the system color scheme, they may fail to work with tools that inspect/manipulate other app's controls, they may not behave correctly outside of the most common use-cases, they may ignore system-wide skin settings (such things do, and should, exist for Windows), and I've even seen ones that actually go and emulate the wrong system style (For instance, Chrome/Iron's dialog windows look like Aero...but I'm on XP, and if I were on Win7 I'd be using the Classic theme anyway. Very very sloppy). If it turns out that Qt's self-drawn controls doesn't have any of those issues, then I agree there's no problem at all. I'd also be incredibly impressed. I've not seen any such issues on Windows/Linux/OS X, could be others though *shrugg*. I'm pretty sure Qt uses the native API as a backend anyway, I remember reading an article about them transitioning from carbon to cocoa on OS X (the native APIs) on their blog at some point, I'd be surprised if they didn't do the same for Windows. -- Robert http://octarineparrot.com/
Re: Please comment on http://d-programming-language.org/
On 12/31/10 1:51 PM, Matthias Pleh wrote: BTW: > Am 2010-09-02 14:46, schrieb retard: >> We need a more professional looking SVG version of the D man then! ... there is already a SVG logo for the D-man since 5 years, but obviousily it get not adopted :/ http://w148.de/~mmartin/d/logo.html Looks good. May I use it on d-programming-language.org? Andrei This should be answered by Marcel Martin. (I will send a copy of this email to the email-address on the website) I've found this image through this website: http://dlogo.chinese-blog.org/ greets Matthias For now I snatched it for TDPL's errata page: http://erdani.com/tdpl/errata/ Andrei
Re: Who here actually uses D?
On 2011-01-02 05:13, Nick Sabalausky wrote: "Robert Clipsham" wrote in message news:ifo9jd$1kt...@digitalmars.com... Having seen a post by Peter Alexander (in Re: D for game development), mentioning some of the issues he's hit I thought I'd post this. I've been in his shoes (every other time I use D it seems), and feel I should ask - who here uses D, and to what extent? I'm mostly interested in those of you with 1000 Line plus projects in D, as that's when I've found I start hitting issues. Just to clarify, for those D purists among you... I'm not trolling, just curious (I wouldn't normally have asked, but now I know I'm not paranoid and the only one having problems, I thought I'd ask). For a number a years, I've been using D for almost anything where I feel I really have a choice. I have been doing a lot of web work in Haxe (PHP and Flash), but it's my intent to migrate over to D. The two main things holding me back on that are the lack of a real comprehensive web-oriented library/framework that's comparable to Haxe's Igniter (or Python's Django), and the inability to compile D code down to PHP or Flash so I won't have to worry about any servers that I might not be about to do custom CGI on (this issue I intend to remedy with my still-embryonic Dax: www.dsource.org/projects/dax -- Speaking of which, what's happened to DDMD? The main guys behind it haven't had made any updates in quite awhile. Just got busy with other things?). I've switched from D1/Tango to D2/Phobos fairly recently, and I haven't really had too much trouble with bugs or incomplete implementations, probably due in big part to not using too much of the more cutting-edge stuff. There have been some pains from bugs or unimplemented stuff, but it's always been far better than using a language that's mediocre to begin with. I have been avoiding doing GUI work because I'm not quite sure how far along QtD is, and the other D GUI libs aren't really suitable for me various reasons. I've may have asked this before but how what about DWT? I see now that you've switch to D2 but when you used D1. -- /Jacob Carlborg
Re: Who here actually uses D?
On 2011-01-02 22:13, Don wrote: Here is the priority list: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#DMDCompilerStability And here's my personal list of top-priority bugs: -- Showstoppers -- 4854 Regression(2.047, Mac 10.5 only) writefln Segmentation fault if no globals I would hope that someone could comment on my patch for that issue. -- /Jacob Carlborg
Re: Who here actually uses D?
Oh damn wrong video
Re: Who here actually uses D?
On Mon, 03 Jan 2011 19:36:05 +0100, Robert Clipsham wrote: On 03/01/11 18:15, Nick Sabalausky wrote: The typical problem with things that look native but aren't technically native is that there's almost inevitably things that don't work right. For instance, they may ignore the system color scheme, they may fail to work with tools that inspect/manipulate other app's controls, they may not behave correctly outside of the most common use-cases, they may ignore system-wide skin settings (such things do, and should, exist for Windows), and I've even seen ones that actually go and emulate the wrong system style (For instance, Chrome/Iron's dialog windows look like Aero...but I'm on XP, and if I were on Win7 I'd be using the Classic theme anyway. Very very sloppy). If it turns out that Qt's self-drawn controls doesn't have any of those issues, then I agree there's no problem at all. I'd also be incredibly impressed. I've not seen any such issues on Windows/Linux/OS X, could be others though *shrugg*. I'm pretty sure Qt uses the native API as a backend anyway, I remember reading an article about them transitioning from carbon to cocoa on OS X (the native APIs) on their blog at some point, I'd be surprised if they didn't do the same for Windows. Look: http://labs.qt.nokia.com/2007/08/09/qt-invaded-by-aliens-the-end-of-all-flicker/ Qt doesn't build up a virtual api beside from winapi. Yes qt have to use system api, but they want the small amount of them. Because they have to ask the system how is your state, and i want you to do that and that. There are always some control they have native handler - i believe it is shown in the video. Like the MenuBar Qt Menubar in Windows feels like a Windows Menubar and on a Mac i believe it would feel like an Mac Menubar. But there are some components in Qt which are better than the native one like Qt Calendar it is beauty and have more function as the windows one- I want exchange them xd
Re: D without a GC (Was: Advocacy (Was: Who here actually uses D?))
Vladimir Panteleev wrote: How much of D can you really use without Phobos? I imagine there'd be no problem in using it as a better C, but there isn't much appeal to that, I don't agree there's not much appeal to that. D has quite a bit that makes C-style code much easier and more robust, such as the module system. C doesn't even have thread local storage! compared to C++/STL/Boost. A practical No-GC D solution would probably have to include a standard library that works without a GC. D can use the minimal library used by C in kernel dev.
Re: Advocacy (Was: Who here actually uses D?)
bearophile wrote: It means that if today you have better versions of Visual Studio, then you have a static checker for contracts. I have not used them yet, I will try to try them. As you see Microsoft is pushing some of its research in the Real World today. And as I pointed out to you, their contract support is *fundamentally* broken. Furthermore, their static checker for contracts only works in *trivial* cases, as I also showed to you. This is not a technology that is ready for real world use. And regardless the usefulness of Verve today, they contain some quite interesting ideas. I'm not just an engineer, I like ideas too. Shutting the brain closed is stupid. Interesting ideas is not the same thing as usable/better for kernel dev. Interesting ideas are a dime a dozen. Getting them to work in a professionally useful tool is an entirely different matter.
Re: streaming redux
On Mon, 03 Jan 2011 14:58:22 +0200, Steven Schveighoffer wrote: On Sat, 01 Jan 2011 10:59:47 -0500, so wrote: This can be significantly shortened: write((&i)[0..1]); Wow, i didn't know that! Could you point me to doc, please? Thanks. http://www.digitalmars.com/d/2.0/arrays.html#implicit-conversions -Steve Thanks. I know those 3, but they don't have much to do with your example, or most likely i didn't get it... -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: streaming redux
On Mon, 03 Jan 2011 15:15:27 -0500, so wrote:
On Mon, 03 Jan 2011 14:58:22 +0200, Steven Schveighoffer
wrote:
On Sat, 01 Jan 2011 10:59:47 -0500, so wrote:
This can be significantly shortened:
write((&i)[0..1]);
Wow, i didn't know that!
Could you point me to doc, please?
Thanks.
http://www.digitalmars.com/d/2.0/arrays.html#implicit-conversions
-Steve
Thanks.
I know those 3, but they don't have much to do with your example, or
most likely i didn't get it...
type of (&i)[0..1] is int[]. int[] is implicitly convertable to void[]
per those rules, so there is no need to cast.
The original post implying that void[] would make things more difficult
stated that with write taking a (void[]) argument instead of (void *,
size_t length) you would have to write put like this:
void put(int i) {
void *tmp = cast(void*)(&i);
void[] arr = tmp[0..int.sizeof];
write(arr);
}
But you do not need to do this, all you need is what I wrote (which is
actually simpler I think than the void*, size_t function).
That was my point. If there is something else you are looking for, maybe
you can ask a different question?
-Steve
Re: std.unittests for (final?) review
Jens Mueller wrote: Unit testing can be implemented on top of the language and shouldn't be put into it. Somehow I have the feeling that too often one tries to extend the language even though the feature could be implemented in a library. On the other hand, the built-in D unit test ability has been a huge success. A unit test facility that is not used is worthless, no matter how capable it is. The advantage of it being simple and built-in is it gets used, and I think there's strong evidence that this is true for D.
Re: streaming redux
type of (&i)[0..1] is int[] I see what the topic is all about. The trouble is this syntax. You say it is int[], but i couldn't find anything in D reference that explains this. Sorry if i am overlooking something. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Who here actually uses D?
Nick Sabalausky wrote: > "Robert Clipsham" wrote in message > news:ift0mt$60...@digitalmars.com... >> On 03/01/11 16:53, Nick Sabalausky wrote: >>> There seems to be a lot of conflicting information about Qt then. I read >>> a >>> post from one of the Qt devs that said basically what I said above. So I >>> guess at this point I haven't a clue what to make of Qt. Oh well, anyone >>> know if wx is coming to D2? >> >> Having used both Qt and QtD on (Windows|Linux|OS X), I can say it looks >> native on all platforms (who cares if it actually is, it looks and feels >> it). >> > > The typical problem with things that look native but aren't technically > native is that there's almost inevitably things that don't work right. For > instance, they may ignore the system color scheme, they may fail to work > with tools that inspect/manipulate other app's controls, they may not > behave correctly outside of the most common use-cases, they may ignore > system-wide skin settings (such things do, and should, exist for Windows), > and I've even seen ones that actually go and emulate the wrong system > style (For instance, Chrome/Iron's dialog windows look like Aero...but I'm > on XP, and if I were on Win7 I'd be using the Classic theme anyway. Very > very sloppy). > > If it turns out that Qt's self-drawn controls doesn't have any of those > issues, then I agree there's no problem at all. I'd also be incredibly > impressed. Qt uses the native theme managers on mac osx and windows for styling. I haven't tried it but Qt apps should be able to cope with custom color schemes, unless of course the developer has overridden that. Perhaps some animations / effects are different, but colors should be fine.
Queue Performance, etc. (was "Thread Failed To Start")
My streamlined version of the inter-thread queue tester is more reliable (though it still freezes sometimes. I am trying to isolate it and will post if I do). But running the resulting comparison has led to some observations: 1. As I noted earlier, the lockfree linked-list based queues are the fastest by a large margin (over a synchronized array-based or linked-list based queue and message passing). 2. That gap closes some (to more like 2x or 3x faster) if the size of the messages increases, but the lockfree are still the fastest. 3. I love D. I was running on OSX, copied the files to my Windows machine and they compiled and ran fine. So awesome. 3a. My windows machine is, I think, 2 x 2.4 GHz Quad Core Xeon and my mac is 2 x 2.8 Quad Core GHz Xeon. The inter-thread queues run 2 or 3x faster on OSX. I will try linux boxes later this week. 3b. Are "systime()" and "Thread.sleep()" portable? The timing on the windows is weird. The sleep between packet sending seems too short and some of the timings seem way off. If that is a portability issue, I may revise 3a. 4. I tried receive vs. receiveOnly in the message passing (MP) version and it made no difference to the latency characteristics. 5. MP has a much larger minimum latency (avg of fastest 1% of packets around 8us vs 0 to 1 for the others). Adam
Re: D without a GC (Was: Advocacy (Was: Who here actually uses D?))
On Mon, 03 Jan 2011 21:41:37 +0200, Walter Bright wrote: Vladimir Panteleev wrote: How much of D can you really use without Phobos? I imagine there'd be no problem in using it as a better C, but there isn't much appeal to that, I don't agree there's not much appeal to that. D has quite a bit that makes C-style code much easier and more robust, such as the module system. C doesn't even have thread local storage! You took my line out of context :) Of course D is better than C and can be used as a better C, but I was making the comparison to C++/STL/Boost. Well, it depends on which features you're after - if you're Linus Torvalds and hate abstractions, D minus Phobos would indeed be a better deal than C++/STL/Boost :) -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Who here actually uses D?
Am 02.01.2011 05:00, schrieb Walter Bright: Caligo wrote: You don't get it! If only one back-end was used then there wouldn't be three different groups working on three different projects that try to accomplish the same thing. Back when there was only one D compiler, people complained there was only one. They needed more to feel comfortable using it. Now that there are three, the complaints switch 180 degrees. It's just different (kinds of) people complaining ;-) I guess most people (and especially people who have to decide whether to use D in a major project) appreciate the availability of multiple compilers.
Re: streaming redux
On Mon, 03 Jan 2011 15:33:10 -0500, so wrote: type of (&i)[0..1] is int[] I see what the topic is all about. The trouble is this syntax. You say it is int[], but i couldn't find anything in D reference that explains this. Sorry if i am overlooking something. Oh that: http://www.digitalmars.com/d/2.0/arrays.html#slicing quoted from there: Slicing is not only handy for referring to parts of other arrays, but for converting pointers into bounds-checked arrays: int* p; int[] b = p[0..8]; The type of &i is int*, so there you go. -Steve
Re: std.unittests for (final?) review
Walter Bright wrote: > Jens Mueller wrote: > >Unit testing can be implemented on top of the > >language and shouldn't be put into it. Somehow I have the feeling that > >too often one tries to extend the language even though the feature could > >be implemented in a library. > > On the other hand, the built-in D unit test ability has been a huge success. > > A unit test facility that is not used is worthless, no matter how > capable it is. The advantage of it being simple and built-in is it > gets used, and I think there's strong evidence that this is true for > D. Yes. I do not disagree. I like having unittest in the language. Extending the basic built-in unit testing support should not be done inside the language, if it can be done conveniently as a library. And the built-in unit testing is very helpful and necessary. But it should be possible to build extended testing frameworks (as there are in Java, C++, etc.) on top of these. Sorry. My very first sentence was very misleading. I wanted to say that further/advanced unit testing shouldn't be put into the language. We all agree on that, don't we? Maybe we can get a discussion what features are considered useful in a testing framework library and what needs to be changed in the built-in testing to make such a library happen. Jens
Re: std.unittests for (final?) review
On 1/3/11, Walter Bright wrote: > The advantage of it being simple and built-in is it gets used, and I think > there's strong evidence that this is true for D. > Yup. I often read about C++ programmers who don't bother with unittests because it's a drag to use them. And people keep coming up with new "simpler" unittest C++ libraries all the time. Offtopic (sry): On the other hand, D could do the same for the build process. Bringing RDMD's abilities to DMD would simplify the build process for many people.
Re: streaming redux
On Mon, 03 Jan 2011 23:02:20 +0200, Steven Schveighoffer wrote: On Mon, 03 Jan 2011 15:33:10 -0500, so wrote: type of (&i)[0..1] is int[] I see what the topic is all about. The trouble is this syntax. You say it is int[], but i couldn't find anything in D reference that explains this. Sorry if i am overlooking something. Oh that: http://www.digitalmars.com/d/2.0/arrays.html#slicing quoted from there: Slicing is not only handy for referring to parts of other arrays, but for converting pointers into bounds-checked arrays: int* p; int[] b = p[0..8]; The type of &i is int*, so there you go. -Steve Thanks a ton! Another small but very important feature. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Less commas
Am 02.01.2011 22:21, schrieb Manfred_Nowak: Walter Bright wrote: disallowing (!x&y) expressions While `!x&y' may be replaced by `y&!x', for `!x&&y' an isomorphic change is not possible. -manfred (!x) && y may actually be desired, (!x) & y most probably not, so !x&y should be forbidden and !x&&y should not.
Re: Who here actually uses D?
Daniel Gibson wrote: It's just different (kinds of) people complaining ;-) I guess most people (and especially people who have to decide whether to use D in a major project) appreciate the availability of multiple compilers. I think multiple compilers is a very good thing for D.
Re: streaming redux
Am 31.12.2010 15:43, schrieb Steven Schveighoffer:
On Fri, 31 Dec 2010 03:28:12 -0500, Daniel Gibson
wrote:
Am 30.12.2010 23:17, schrieb Andrei Alexandrescu:
On 12/30/10 3:59 PM, Dmitry Olshansky wrote:
On 28.12.2010 16:08, Daniel Gibson wrote:
[snip]
## UnbufferedInputTransport:
I'd like "void readFully(ubyte[] buffer)" which reads buffer.length
bytes or throws an exception if that is not possible
This would also fix busy-waiting (it'd block until buffer.length bytes
are available).
Also "size_t read(void* buffer, size_t length)" (and the same for
readFully()) would be nice, so one can read from the stream to buffers
of arbitrary type without too much casting. Is probably especially
handy when used with (data from) extern(C) functions and such.
Also, for convenience: "ubyte[] read(size_t length)" (does something
like "return read(new ubyte[length]);"
and "ubyte[] readFully(size_t length)"
This, I guess, would be provided by free functions in the same module,
there is no point in requiring to implement them inside the stream
itself.
## UnbufferedOutputTransport:
I'd like "void write(void *buffer, size_t length)" - for the same
reason as read(void* buffer, size_t length).
Ditto
What's wrong with void[]?
Andrei
For example:
void put(int i) {
write(&i, int.sizeof);
}
is shorter and easier than
void put(int i) {
void *tmp = cast(void*)(&i);
void[] arr = tmp[0..int.sizeof];
write(arr);
}
This can be significantly shortened:
write((&i)[0..1]);
Remember, all arrays implicitly cast to void[], which is why you use it
for input parameters.
-Steve
This is indeed a very cool trick :-)
Re: D without a GC (Was: Advocacy (Was: Who here actually uses D?))
Vladimir Panteleev wrote: You took my line out of context :) Of course D is better than C and can be used as a better C, but I was making the comparison to C++/STL/Boost. Well, it depends on which features you're after - if you're Linus Torvalds and hate abstractions, D minus Phobos would indeed be a better deal than C++/STL/Boost :) I should also point out that anyone who has the chops to build a kernel can certainly build a customized D runtime.
Re: Who here actually uses D?
"Jacob Carlborg" wrote in message news:ift7ig$j1...@digitalmars.com... > On 2011-01-02 05:13, Nick Sabalausky wrote: >> "Robert Clipsham" wrote in message >> news:ifo9jd$1kt...@digitalmars.com... >>> Having seen a post by Peter Alexander (in Re: D for game development), >>> mentioning some of the issues he's hit I thought I'd post this. I've >>> been >>> in his shoes (every other time I use D it seems), and feel I should >>> ask - >>> who here uses D, and to what extent? >>> >>> I'm mostly interested in those of you with 1000 Line plus projects in D, >>> as that's when I've found I start hitting issues. >>> >>> Just to clarify, for those D purists among you... I'm not trolling, just >>> curious (I wouldn't normally have asked, but now I know I'm not paranoid >>> and the only one having problems, I thought I'd ask). >>> >> >> For a number a years, I've been using D for almost anything where I feel >> I >> really have a choice. >> >> I have been doing a lot of web work in Haxe (PHP and Flash), but it's my >> intent to migrate over to D. The two main things holding me back on that >> are >> the lack of a real comprehensive web-oriented library/framework that's >> comparable to Haxe's Igniter (or Python's Django), and the inability to >> compile D code down to PHP or Flash so I won't have to worry about any >> servers that I might not be about to do custom CGI on (this issue I >> intend >> to remedy with my still-embryonic Dax: www.dsource.org/projects/dax -- >> Speaking of which, what's happened to DDMD? The main guys behind it >> haven't >> had made any updates in quite awhile. Just got busy with other things?). >> >> I've switched from D1/Tango to D2/Phobos fairly recently, and I haven't >> really had too much trouble with bugs or incomplete implementations, >> probably due in big part to not using too much of the more cutting-edge >> stuff. There have been some pains from bugs or unimplemented stuff, but >> it's >> always been far better than using a language that's mediocre to begin >> with. >> >> I have been avoiding doing GUI work because I'm not quite sure how far >> along >> QtD is, and the other D GUI libs aren't really suitable for me various >> reasons. > > I've may have asked this before but how what about DWT? I see now that > you've switch to D2 but when you used D1. > I looked into it at one point when I was using D1. It seemed promising but at the time there were still some bugs or something (don't remember exactly) that needed to be worked out (and I was busy with other things anyway). I'm sure that's probably all fixed by now though.
Re: Who here actually uses D?
On 03/01/11 21:39, Walter Bright wrote: I think multiple compilers is a very good thing for D. I agree, when I hit a bug in one it's nice to be able to use another before resorting to compiler hacking instead of working on my own code, it's working out far nicer for me! Shame I'm currently at a point where none of the compilers want to make my app act the same at runtime (this only seems happens at a certain point in the evening, perhaps I should only code earlier/later in the day ;p)... -- Robert http://octarineparrot.com/
Dynamic D
Over the weekend, I attacked opDispatch again and found some old
Variant bugs were killed. I talked about that in the Who uses D
thread.
Today, I couldn't resist revisiting a dynamic kind of object, and
made some decent progress on it.
http://arsdnet.net/dcode/dynamic.d
(You can compile that; there's a main() at the bottom of that file)
It isn't quite done - still needs op overloading, and probably better
errors, but it basically works.
It works sort of like a Javascript object.
Features:
opDispatch and assignment functions:
Dynamic obj;
// assign from various types
obj = 10;
obj = "string";
obj.a = 10; // assign properties from simple types naturally
// can set complex types with one compromise: the () after the
// property tells it you want opAssign instead of property opDispatch
obj.a() = { writefln("hello, world"); }
// part two of the compromise - to call it with zero args, use call:
obj.a.call();
// delegte with arguments works too
obj.a() = delegate void(string a) { writeln(a); };
// Calling with arguments works normally
obj.a("some arguments", 30);
Those are just the basics. What about calling a D function? You
need to convert them back to regular types:
string mystring = obj.a.as!string; // as forwards to Variant.coerce
// to emulate weak typing
Basic types are great, but what about more advanced types? So far,
I've implemented interfaces:
interface Cool {
void a();
}
void takesACool(Cool thing) { thing.a(); }
takesACool(obj.as!Cool); // it creates a temporary class implementing
// the interface by forwarding all its methods to the dynamic obj
I can make it work with structs too but haven't written that yet.
I want to add some kind of Javascript like prototype inheritance too.
I just thought it was getting kinda cool so I'd share it :)
Re: Who here actually uses D?
On Mon, Jan 3, 2011 at 12:18 PM, Nick Sabalausky wrote: > > Also, as I haven't followed this real closely, what's the current state of > SWIG for D? Fully-usable? > > > It's usable (but not without a little bit of work in writing the .i files.) Take a look at the thing I've been working on in my free time (with SWIG): http://irrlichtd.codeplex.com/
Re: Who here actually uses D?
Robert Clipsham wrote: Shame I'm currently at a point where none of the compilers want to make my app act the same at runtime (this only seems happens at a certain point in the evening, perhaps I should only code earlier/later in the day ;p)... I learned long ago not to attempt to write code past a certain level of tiredness. If I do, I always have to completely throw that work away and start over.
