Re: AI Challenge - Ants
Ola. Well, my A* algorithm is already working very nicely - and imo there isn't any problem-specific optimization left to implement other than the data structures holding the nodes themselves. So the question is only whether it would pay off to switch to D* instead. Second, I'm aiming for the #1 spot :D. I have a lot of strategy in mind that I haven't seen implemented by anyone else yet and I think a TOP 10 spot should definitely be possible. Minimizing the impact of the path-finding on computing requirements is thus certainly a priority. /Max On 10/29/2011 9:26 PM, Lishaak Bystroushaak wrote: Hi. I don't think, that you have to use some advanced strategies and path finding. I'm currently 261 with this simple code: http://pastebin.com/1Nsb81rj With hill defense and ant grouping, you could be imho easilly in first 100 without A* :) 2011/10/29 Sean Kellys...@invisibleduck.org: If you want to cheat, there have been books published on ant colony optimization. I'm sure the related papers could be dug up. Sent from my iPhone On Oct 29, 2011, at 3:12 AM, Max Wolterawishform...@gmail.com wrote: On 10/25/2011 1:44 PM, Trass3r wrote: I'm working on a bot in D. I'm currently done implementing the A* algorithm for path finding Dump A*, D* Lite ftw ;) Hellooo. Correct me if I'm wrong, but in A*, I can just find a path, store it (let's say as a string) and find a new one if it's blocked for some reason. As far as I could see from what I've read about Lifelong A*, D*, Focused D* and D* Lite, I would have to store all nodes used in the algorithm - so, as opposed to A*, I have to conserve the state of the entire search algorithm throughout ticks, for each ant. Is the environment in this AI challenge really noisy enough to warrant this? Obviously, if the path needs to be re-planned almost every tick, D* Lite seems like a better choice to me. But if you have 100+ ants, that would be a lot of allocated heap memory, wouldn't it? I really don't have a clue how the processing vs allocating should be weighed here performance-wise. /Max
Re: Xinok Sort Update
Hey there.
Thanks for your good work.
I decided to test your xinok sort in my implementation of the A*
algorithm; since the list of open nodes will always be partially sorted,
it should give better performance than the phobos sort.
/Max
On 10/30/2011 12:19 AM, Xinok wrote:
On 10/29/2011 5:53 PM, Timon Gehr wrote:
Looks good =). Thank you. How does this implementation of your algorithm
compare to the the unstable sort that is currently in Phobos,
performance wise?
I posted some benchmarks here. These benchmarks used the specialized
code for arrays. There would likely be a larger gap when using ranges.
https://sourceforge.net/p/xinoksort/blog/2011/10/another-update--benchmarks/
One comment:
while(temp is null){
try temp.length = len;
catch(Exception err){ // Reduce memory usage and try again
len /= 2;
if(len = 8) continue;
else throw err;
}
}
temp.length = len cannot throw an Exception.
I think you are trying to catch an OutOfMemoryError here?
Yes I was. What should I do/use instead?
Re: Xinok Sort Update
On 10/30/2011 09:52 AM, Max Wolter wrote: Hey there. Thanks for your good work. I decided to test your xinok sort in my implementation of the A* algorithm; since the list of open nodes will always be partially sorted, it should give better performance than the phobos sort. /Max You might want to consider using a heap to maintain the list of open nodes instead.
Re: AI Challenge - Ants
On 10/30/11 3:43 AM, Max Wolter wrote: Ola. Well, my A* algorithm is already working very nicely - and imo there isn't any problem-specific optimization left to implement other than the data structures holding the nodes themselves. A* is fairly specific but if the implementation is generic enough (e.g. parameterized on the node type and the heuristic use) I think it would have a place in Phobos. Andrei
Re: dmd 1.071 and 2.056 release
On 10/27/11 5:16 AM, Vladimir Panteleev wrote: On Wed, 26 Oct 2011 21:34:35 +0300, Walter Bright newshou...@digitalmars.com wrote: 100 bugs fixed! I'm only saddened that my std.socket cleanup pull request[1] wasn't merged, despite being ready for merging for over a month of inactivity. That's a few more months for my open-source network code not building with a stock DMD. Oh well, I guess I'll move the new std.socket to my network library if it comes to that. [1]: https://github.com/D-Programming-Language/phobos/pull/260 Let's make sure we review and pull that in soon. Andrei
Re: dmd 1.071 and 2.056 release
On 10/26/11 4:25 PM, Jonathan M Davis wrote: On Wednesday, October 26, 2011 14:20 Nick Sabalausky wrote: http://www.d-programming-language.org/phobos/std_string.html Have the docs just not been updated yet, or did I do something wrong in the doc comments for my std.string changes? It's Andrei that manages the site, whereas Walter does the dmd release, and it's been less than 3 hours since the release, so I expect that Andrei hasn't had the chance to update the site yet. - Jonathan M Davis Site updated. Andrei
Re: Xinok Sort Update
On 10/29/2011 1:13 PM, Xinok wrote: I recently put some time into updating my implementation of xinok sort for D. Major changes include support for random-access ranges and custom predicates (ab). You can download the new version here: http://sourceforge.net/projects/xinoksort/files/D%202.0/2011-10-29/xinoksort.d/download I'm working on adapting the code to work at compile time. I found out about the variable, __ctfe, so I can bypass the try / catch statement. But it can't be used in a compile-time specific manner, such as in a static if. The implementation for ranges works just fine at compile time, but the implementation for arrays doesn't (it makes heavy use of pointers). I'm not sure how I could rewrite it to use only ranges at compile time.
std.regex wins with 11 votes
I wish to congratulate Dmitry Olshansky for not only having his project selected for GSoC, but inclusion into Phobos. Absolutely no one had objection to this proposal and it received 11 yes votes, myself included. Dmitry, please merge in the latest master branch and submit a pull request so that we can have this great addition in the next release!
Re: Argument of template as method of the object (How to replace the macros)
Kagamin wrote: try val.get!(_WRAPPED_TYPE) Oh, yes, it will works. Big thanks. I just started my practice with D, and yet don't accustomed to its way, but it is great. Thank you again!
Re: NULL indicator in Variant
On Sat, 29 Oct 2011 17:42:54 -0400, Robert Jacques wrote:
Variant var = 1;
var.mark = true;
if(var.mark) {
// Do DB NULL stuff
} else {
// Do DB value stuff
}
But how is that different from this:
Variant var = 1;
var.nullify;
if(var.isNull) {
// Do DB NULL stuff
} else {
// Do DB value stuff
}
or this:
auto var = Variant.NULL!int;
if(var.hasValue) {
// Do DB NULL stuff
} else {
// Do DB value stuff
}
or this:
auto var = typeid(int);
if(auto type = var.peek!TypeInfo) {
// Do DB NULL stuff
} else {
// Do DB value stuff
}
?
I don't care about adding functionality X; you can already build a
null-able DB type on top of Variant (see above, or use Nullable!Vairant,
etc). I care about making variant (or Algebraic) _into_ a null-able DB
type. So that it composes integrates well with the rest of our
code-bases.
It is not essential, but it would make a database interface using
variants easier to code and to use. Probably we should just forget the
idea.
Steve
Databases and their ilk are a pretty big and important use case. So I
think cleanly supporting them is necessary. That said, there are lots of
alternatives available.
Robert,
I guess I was reacting to your worry about the std.typecons Nullable!T,
and Steve S's objection to 'muddying' Variant by including specifically
database oriented stuff. A simple mark seemed more general purpose and
possibly more acceptable.
From your examples, I like
Variant var = 1;
var.nullify;
if(var.isNull) {
// Do DB NULL stuff
} else {
// Do DB value stuff
}
As long as when it is nullified I can still use var.type and get int.
I take it that in the case of this example hasValue() would signify that
the Variant was 'raw' - we don't really have uninitialized in D.
Steve
Re: core.cpuid
Andrew Wiley wiley.andre...@gmail.com wrote in message news:mailman.591.1319951129.24802.digitalmar...@puremagic.com... On Sat, Oct 29, 2011 at 10:55 PM, Chante udontspa...@never.will.u wrote: Manu turkey...@gmail.com wrote in message news:mailman.586.1319935753.24802.digitalmar...@puremagic.com... What's the deal with core.cpuid? I think they just want the mainstream (sheeple/followers/believers/90210_ers/younsters, etc.). If you don't fit into their petri-dish and aren't cog to add to their self-aggrandizement, they won't let you log in anymore. There are a few things like this around, and if you look far enough back, it's quite simple why things like this happened. Originally, when D was new, DMD essentially was the definition of D, x86 was the only real architecture around, with x86_64 starting to come into play. Now we have more compilers, and x86/64 isn't looking quite like the monopoly it used to be, so this interface will probably need to change. There's no conspiracy here, it's just what worked back in the day, and either it's unused or unimportant such that no one has tried to update it thus far. Since this is in core, it's mostly Sean's territory, but I'm sure he'd welcome ideas. I didn't call you anything.
Ranges, Performance, and opApply
As it stands right now, ranges are quite inefficient. Phobos is designed with an emphasis on ranges, including in performance-sensitive code such as std.algorithm. No matter how optimized the range is, it will always be slower than the equivalent opApply function (and, as far as I can tell, offers no benefit for just iteration). The fastest way of iterating over anything currently, is foreach over an array. It beats even for(size_t i 0 to length-1) by a decent bit. The lowest level range for all ranges is almost always an array (that is, if you have a range using a range ... using a range, it is likely that the last range is an array or uses an array). By implementing an opApply for these ranges, that calls opApply on the wrapped range or wrapped array (or other), you can basically double the performance cost of iterating (for many iterations over a small body). It is not possible to make the compiler-generated opApply make this optimization, as it does not know what the underlying data for the range is. Creating an opApply can be done on a per-range basis for ranges that are used in performance-sensitive code (such as countUntil). If the manual opApply foreach's over the input range, and the input range has a similar manual opApply, there are fair performance benefits. If the underlying range does not have a manual opApply, there will still be some performance benefits, and does not break code in any way. If all ranges being used have opApply and the last range is an array, then performance benefits are very significant. As an example, I made a test of 5 different ways of implementing std.algorithm.filter, and two tests of another filter on top of the output from the first one, one with a manual opApply, and one without. Basically, a manual opApply was over twice as fast. The code and results can be found at http://pastie.org/2781723. Ultimately, nothing is as fast as just doing a foreach yourself, but that's to be expected. It can be however, be easily made that the difference is not as extreme as it currently is. So, should Phobos ranges attempt to have a manual opApply where feasibly being used in performance sensitive code?
Re: GSoC Mentor Summit Observations and D Marketing
At the gsoc I was using something like this: a better (simplified) C++: - close to C but not 100% backward compatible, either it compiles or it gives an error - easy to link C, partially possible to use C++ libs (no template instantiation) - single inheritance + interfaces (and contracts) - garbage collection (possible to avoid with some effort) - better templates (template language close to normal D, constraints), CTFE and mixing - auto/foreach - delegates - immutable/const/pure if the discussions goes in that direction and going more in depth in the things that did strike the listener. I was also surprised about how many already heard something about D, I got even some questions about D1/D2 tango/phobos. My answers were something along these lines: - D2 toolchain becoming now robust enough to be chosen for new projects (with gdc finally also 64 bits) - D1 simpler, but misses some nice features of D2, not all D2 features are perfect, but the proposal is compelling - it was difficult for the community to improve the lib druntime - tango, personally I think it is the better library for D1 (I was contributing to it), unfortunately not compatible with phobos. D2 runtime, and no tango yet, but if/when it comes likely it will use druntime. Fawzi
Re: template specialization for arrays
On 10/30/2011 01:34 AM, J Arrizza wrote:
Thank you Timon, I very much appreciate your (and others) help.
I will look all this up in the online docs and the book.
There is still some very odd things in how these fit together. For
example, if I comment out the last 3 function templates, I get all
simpleparms, which is expected.
But if I add in the fourth, I get a compilation error saying the call to
abc(arr2) is ambiguous. So even though the first one specifies U =
void and size_t N = 0, and the fourth specifies something very
different, there is ambiguity between them.
Adding in the third resolves the ambiguity between the first and fourth.
John
I cannot reproduce that behaviour. If I comment out the second and the
third, I get 3 simpleparms and 1 static array
On Sat, Oct 29, 2011 at 4:02 PM, Timon Gehr timon.g...@gmx.ch
mailto:timon.g...@gmx.ch wrote:
This works:
void abc(T, U=void, size_t N=0) (T parm1) {
writeln(simpleparm: , parm1);
}
void abc(T: string) (T parm1) {
writeln(string : , parm1);
}
void abc(T:U[], U) (T parm1) if (isDynamicArray!T) {
writeln(dynamic array : , parm1);
}
void abc(T:U[N], U, size_t N) (T parm1) {
writeln(static array : , parm1);
}
void main(string[] args) {
abc(1);
abc(str);
int[] arr = [1, 2];
abc(arr);
int[2] arr2 =[3, 4];
abc(arr2);
}
Whoops, just noticed that I accidentally left the if(isDynamicArray!T)
in there. That is not necessary, if the pattern matches it will always
evaluate to true.
void abc(T, U=void, size_t N=0) (T parm1) {
writeln(simpleparm: , parm1);
}
//void abc(T: string) (T parm1) {
//writeln(string : , parm1);
//}
//void abc(T:U[], U) (T parm1){ // no constraint necessary
//writeln(dynamic array : , parm1);
//}
void abc(T:U[N], U, size_t N) (T parm1) {
writeln(static array : , parm1);
}
void main(string[] args) {
abc(1); // simpleparm
abc(str); // simpleparm
int[] arr = [1, 2];
abc(arr);// simpleparm
int[2] arr2 =[3, 4];
abc(arr2); // static array
}
What compiler version are you using?
Re: template specialization for arrays
You should use either std.traits.isXxx systematically, or patterns
systematically, but not both at the same time. Personally I prefer isXxx
because they foster simple logic to decide what overloads should apply.
Also, when posting, you may want to include complete short programs so
others can try them quickly.
Andrei, I thought I had posted the entire program. Here it is again using
only traits as you recommend:
import std.stdio;
import std.traits;
void abc(T) (T parm1)
if (isNarrowString!T || (!isStaticArray!T !isDynamicArray!T))
{
writeln(simpleparm: , parm1);
}
void abc(T) (T parm1)
if (!isNarrowString!T (isDynamicArray!T || isStaticArray!T) )
{
writeln(array : , parm1);
}
void main(string[] args)
{
writeln(v4);
abc(1);
abc(str);
int[] arr = [1, 2];
abc(arr);
int[2] arr2 = [3, 4];
abc(arr2);
}
And it does work, here's the output:
simpleparm: 1
simpleparm: str
array : [1, 2]
array : [3, 4]
Note my original intent was to differentiate between arrays and non-arrays
only (lumping strings into non-array).
As for using only patterns, I can't get the compiler to disambiguate
between non-arrays and arrays:
import std.stdio;
import std.traits;
void abc(T, U = void, size_t N = 0) (T parm1) //line 3
{
writeln(simpleparm: , parm1);
}
void abc(T: U[N], U = char, size_t N) (T parm1)
{
writeln(string : , parm1);
}
void abc(T) (T parm1)
{
writeln(dynamic array : , parm1);
}
void abc(T: U[N], U, size_t N) (T parm1) //line 15
{
writeln(static array : , parm1);
}
void main(string[] args)
{
writeln(v4);
abc(1);
abc(str);
int[] arr = [1, 2];
abc(arr);
int[2] arr2 = [3, 4];
abc(arr2);//line 27
}
Here's the compiler error:
dtest.d(27): Error: template dtest.abc(T,U = void,ulong N = 0) abc(T,U =
void,ulong N = 0) matches more than one template declaration,
dtest.d(3):abc(T,U = void,ulong N = 0) and dtest.d(15):abc(T : U[N],U,ulong
N)
Re: template specialization for arrays
On Sun, Oct 30, 2011 at 3:13 AM, Timon Gehr timon.g...@gmx.ch wrote: What compiler version are you using? $ dmd -v DMD64 D Compiler v2.055
Re: Compiler patch for runtime reflection
On 2011-10-29 22:11, Adam Wilson wrote: WPF isn't the native GUI, it just comes with skins that emulate the look of the native GUI. The native GUI in Windows is called Win32 GDI (Graphices Device Interface). WPF is built on top of DirectX which is analagous to OpenGL and is primarily used for games. DirectX completely bypasses the GDI and communicates directly with the hardware. It's primary claim to fame is that it is fast, but it's not as compatible, whereas GDI is compatible with everything that implements VESA (which is everything since the early 90's), but it's slow. We don't have to argue about this but it sounds like WPF is a new native GUI, especially if it bypasses GDI. Ok, so I apologize for generalizing there. It turns out that WPF is really bad at drawing round shapes, and the default skins (which the exception of the Windows 2000 skin) rely heavily on rounded corners. We replaced the default skin with one that used square corners and had fewer Measure and Arrange stages (where WPF figures out where to place the controls) which are equally expensive. WPF has virtual lists as well, and we do use it, which also helped contribute to our speed gains, but it is not enabled by default. My complaint is that the working with WPF requires a non-trivial amount of esoteric experience with it to make it work well. With DWT you only pass an additional flag when creating the table, if I recall correctly. I am looking to create an open-source implementation of a GUI framework that is 'lookless', i.e. it's underlying implementation has no dependencies on how it looks and the look can be changed to however the designer wants it to look without having to worry about code. WPF and JavaFX are the only two frameworks that are examples of how this might work. I absolutely agree that relying on something else is probably not the best idea, because for better or worse you end up inheriting their design choices, which may or may not work for your project. Since I am windows guy, the reference implementation is going to be DirectX. First I just have to create Direct2D bindings for D... What's wrong with using the lowest level of the drawing operations available on a given OS. On Mac OS X it would be Quartz which is has been hardware accelerated since a very long time. On Linux it would probably be Cairo and on Windows you could use the lowest level of WPF. Why reinvent the wheel again? If you want to roll your own drawing operations anyway why not have the reference implementation in OpenGL, it's available on basically all platforms including Windows. OpenGL bindings and other things like SDL and FreeType: http://dsource.org/projects/derelict DirectX bindings and bindings in general: http://dsource.org/projects/bindings This is not my strongest side, but wouldn't you need native windows to draw your widgets on? And another goal of the framework beyond platform independence is language independence. I have to admit that one of the big draws for me of D was the C++ ABI and COM compatibility of D while having a MUCH more modern capability set. However, it's still lacking in a few key areas for my project, and runtime reflection is one of them... Just for the record, the interface to C++ is very limited. -- /Jacob Carlborg
Re: template specialization for arrays
On 10/30/11 5:16 AM, J Arrizza wrote:
You should use either std.traits.isXxx systematically, or
patterns systematically, but not both at the same time.
Personally I prefer isXxx because they foster simple logic to
decide what overloads should apply.
Also, when posting, you may want to include complete short programs
so others can try them quickly.
Andrei, I thought I had posted the entire program. Here it is again
using only traits as you recommend:
import std.stdio;
import std.traits;
void abc(T) (T parm1)
if (isNarrowString!T || (!isStaticArray!T !isDynamicArray!T))
{
writeln(simpleparm: , parm1);
}
void abc(T) (T parm1)
if (!isNarrowString!T (isDynamicArray!T || isStaticArray!T) )
{
writeln(array : , parm1);
}
void main(string[] args)
{
writeln(v4);
abc(1);
abc(str);
int[] arr = [1, 2];
abc(arr);
int[2] arr2 = [3, 4];
abc(arr2);
}
Thanks, sorry for having missed that.
The code as above is canonical. I think restricted templates are the way
to go for most code. Pattern matching on types is rather arcane and
should be let to a few advanced uses (such as implementing traits
themselves).
Andrei
Re: Ranges, Performance, and opApply
On 10/30/11 3:02 AM, Kapps wrote: As it stands right now, ranges are quite inefficient. Phobos is designed with an emphasis on ranges, including in performance-sensitive code such as std.algorithm. No matter how optimized the range is, it will always be slower than the equivalent opApply function (and, as far as I can tell, offers no benefit for just iteration). The test is flawed in a subtle way and no conclusion can be drawn from it. The test filters a checkerboard distribution (one element satisfies/the next doesn't satisfy the filter). As such, the loop on lines 26-29 will always test exactly two times to take one step. In contrast, the loop at lines 75-81 is integrated and only makes the minimum amount of tests. Calling the delegate is expensive, but there are only half as many calls and the saved tests compensate for that. I believe there is nothing inherent in the design of ranges that makes them generally less efficient than various alternatives. Yes, there will be the corner cases where internal iteration will be better, but overall I don't think they form a large fraction of all cases. Andrei
Re: template specialization for arrays
On Sun, Oct 30, 2011 at 7:36 AM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
The code as above is canonical. I think restricted templates are the way
to go for most code.
Yes, they are much simpler to use.
I went back to traits.d to see how isDynamicArray and isStaticArray were
built mostly to figure out the patterns used for them. I found a couple
more isArray!T and isSomeString which simplify and generalize the code
just a little more:
import std.stdio;
import std.traits;
void abc(T) (T parm1)
if (isSomeString!T || !isArray!T)
{
writeln(simpleparm: , parm1);
}
void abc(T) (T parm1)
if (!isSomeString!T isArray!T)
{
writeln(array : , parm1);
}
void main(string[] args)
{
writeln(v4);
abc(1);
abc(str);
int[] arr = [1, 2];
abc(arr);
int[2] arr2 = [3, 4];
abc(arr2);
}
Another one that looked promising is isIterable() for the array.
All of this begs the question, where do I find the latest doc? Since these
are not showing up in the online doc but are clearly in traits.d.
http://d-programming-language.org/traits.html
Thanks again for your help,
John
Re: Ranges, Performance, and opApply
On Sun, 30 Oct 2011 15:42:36 +0100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 10/30/11 3:02 AM, Kapps wrote: As it stands right now, ranges are quite inefficient. Phobos is designed with an emphasis on ranges, including in performance-sensitive code such as std.algorithm. No matter how optimized the range is, it will always be slower than the equivalent opApply function (and, as far as I can tell, offers no benefit for just iteration). The test is flawed in a subtle way and no conclusion can be drawn from it. The test filters a checkerboard distribution (one element satisfies/the next doesn't satisfy the filter). As such, the loop on lines 26-29 will always test exactly two times to take one step. In contrast, the loop at lines 75-81 is integrated and only makes the minimum amount of tests. Calling the delegate is expensive, but there are only half as many calls and the saved tests compensate for that. No it does not. In fact the opApply version does ONE additional check at loop start, which doesn't matter for 2.5M iterations. I believe there is nothing inherent in the design of ranges that makes them generally less efficient than various alternatives. Yes, there will be the corner cases where internal iteration will be better, but overall I don't think they form a large fraction of all cases. Andrei The test still doesn't measure anything but spurious effects of different inline decisions. I get a ~10% hit for range foreach over opApply. When looping without predicate than popFront is inlined and the result is a ~10% hit for opApply. As the opApply body can never be inlined it is a worse choice in general. martin
Re: core.cpuid
On 30-10-2011 06:05, Andrew Wiley wrote: On Sat, Oct 29, 2011 at 10:55 PM, Chante udontspa...@never.will.u wrote: Manu turkey...@gmail.com mailto:turkey...@gmail.com wrote in message news:mailman.586.1319935753.24802.digitalmar...@puremagic.com... What's the deal with core.cpuid? I think they just want the mainstream (sheeple/followers/believers/90210_ers/younsters, etc.). If you don't fit into their petri-dish and aren't cog to add to their self-aggrandizement, they won't let you log in anymore. There are a few things like this around, and if you look far enough back, it's quite simple why things like this happened. Originally, when D was new, DMD essentially was the definition of D, x86 was the only real architecture around, with x86_64 starting to come into play. Now we have more compilers, and x86/64 isn't looking quite like the monopoly it used to be, so this interface will probably need to change. There's no conspiracy here, it's just what worked back in the day, and either it's unused or unimportant such that no one has tried to update it thus far. Since this is in core, it's mostly Sean's territory, but I'm sure he'd welcome ideas. I actually do use core.cpuid and find it very useful. I think what we need to do is have separate modules for the various architectures, and then have some central wrapper module that wraps the common stuff that most archs share (i.e. are we using 64-bit pointers?, etc...). We still need to keep the modules with more arch-specific checks public, because someone might actually need to use that information (in my case, I need it to decide which instructions I can emit in my JIT compiler). Speaking of all this, we really need to standardize version identifiers for !x86 architectures in the web site... - Alex
Re: Review of Jesse Phillips's CSV Parser
Thank you for the response, only one more follow-up question. Records Record Don't these look easy to confuse? And funny if we didn't have type inference. Records records = csvText(str); foreach(Record record; records) ... Anyone want to complain about this suggestion? Record is private and can only be obtained from Records (is that appropriate phrasing?).
Re: Review of Jesse Phillips's CSV Parser
On Sun, 30 Oct 2011 17:02:26 +, Jesse Phillips wrote: Thank you for the response, only one more follow-up question. Records Record If it's any consolation, I'm suffering from similar questions to myself in my naming of structs and methods for my database interface experiments. Since it is rather a short step from a generic 'CSV' interface to a database interface, you may be determining the terminology that I should use. I should really divert for a day and look at what you have done. It would be interesting to see if I could write a similar interface over your stuff. But there's so much to do! Steve
Re: template specialization for arrays
On Sunday, October 30, 2011 08:41:47 J Arrizza wrote: All of this begs the question, where do I find the latest doc? Since these are not showing up in the online doc but are clearly in traits.d. http://d-programming-language.org/traits.html That page is talking about __traits (which is built into the compiler), not std.traits. For std.traits, you want http://www.d-programming-language.org/phobos/std_traits.html Depending on what you're doing, you may need both, but generally all you need is std.traits unless you're getting fancy. - Jonathan M Davis
Re: [std.database]
Just a quick progress report. Since it was clear that my original ideas for a MySQL D interface were not going to make it into Phobos at least because of license issues, I have been investigating the use of the published MySQL client/server protocol (this was expressly removed from GPL, if it could ever have belonged there in the first place, some time ago.) The results are encouraging, and I am pretty well back to the point I had reached using the C API, but now without files derived from GPL material, linking to a library, and mimicry of the C API methods. In the course of going over the whole thing again, and with a knowledge now of how the MySQL client/server relationship works, I think I may have improved the interface, even in its present experimental form. Steve
Re: Review of Jesse Phillips's CSV Parser
On 10/30/2011 10:02 AM, Jesse Phillips wrote: Thank you for the response, only one more follow-up question. Records Record Don't these look easy to confuse? And funny if we didn't have type inference. Records records = csvText(str); foreach(Record record; records) ... Anyone want to complain about this suggestion? Record is private and can only be obtained from Records (is that appropriate phrasing?). I started using that convention in dmd, i.e. Objects is an array of Object, and after I got used to it I like it fine.
The D players
I'm probably slightly crazy, but I have this urge to associate the digitalmars.D group with some well known group of leaders. Now I'd guess that still the best-known bunch would still be the allied leaders from WW2. So I guess that whether he likes it or not, I have to cast Walter as Churchill - it was he who took on the burden in the first place. But the others. Who is Roosevelt, who Eisenhower, Montgomery, Patton and so on? And most provocatively, who is Stalin? A little relaxation - let's hear your views. Steve
Re: Software architecture support in D.
have you seen this? https://github.com/itiu/zeromq-connector On 25/10/2011 11:18, Gor Gyolchanyan wrote: yeah. 0MQ is the ultimate concurrency tool. I just love it. But i mean a D-solution, rather then a C-solution port. D's rich modeling power allows those concepts to be implemented in a whole new and incredibly flexible and easy-to-use way. On Tue, Oct 25, 2011 at 2:14 PM, simendsjosimend...@gmail.com wrote: On 25.10.2011 12:07, Gor Gyolchanyan wrote: * Message passing (event-driven programming). std.concurrency and zeromq (missing a good wrapper). libev or libevent would be nice too.
Re: Ranges, Performance, and opApply
On 10/30/11 11:45 AM, Martin Nowak wrote: On Sun, 30 Oct 2011 15:42:36 +0100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 10/30/11 3:02 AM, Kapps wrote: As it stands right now, ranges are quite inefficient. Phobos is designed with an emphasis on ranges, including in performance-sensitive code such as std.algorithm. No matter how optimized the range is, it will always be slower than the equivalent opApply function (and, as far as I can tell, offers no benefit for just iteration). The test is flawed in a subtle way and no conclusion can be drawn from it. The test filters a checkerboard distribution (one element satisfies/the next doesn't satisfy the filter). As such, the loop on lines 26-29 will always test exactly two times to take one step. In contrast, the loop at lines 75-81 is integrated and only makes the minimum amount of tests. Calling the delegate is expensive, but there are only half as many calls and the saved tests compensate for that. No it does not. Indeed you're right. In the quiescent state both implementations call the support functions the same number of times. Thanks. In fact the opApply version does ONE additional check at loop start, which doesn't matter for 2.5M iterations. I believe there is nothing inherent in the design of ranges that makes them generally less efficient than various alternatives. Yes, there will be the corner cases where internal iteration will be better, but overall I don't think they form a large fraction of all cases. Andrei The test still doesn't measure anything but spurious effects of different inline decisions. I get a ~10% hit for range foreach over opApply. When looping without predicate than popFront is inlined and the result is a ~10% hit for opApply. As the opApply body can never be inlined it is a worse choice in general. That was my intuition too. Andrei
Re: The D players
On 10/30/11 1:18 PM, Steve Teale wrote: I'm probably slightly crazy, but I have this urge to associate the digitalmars.D group with some well known group of leaders. Now I'd guess that still the best-known bunch would still be the allied leaders from WW2. So I guess that whether he likes it or not, I have to cast Walter as Churchill - it was he who took on the burden in the first place. But the others. Who is Roosevelt, who Eisenhower, Montgomery, Patton and so on? And most provocatively, who is Stalin? Pliz pliz don't give me Stalin. Andrei
Re: Review of Jesse Phillips's CSV Parser
On 10/29/2011 10:03 PM, Walter Bright wrote: I want to press Andrei to write up a doc on What's a Range As a D1 user planning to migrate, this would be very appreciated.
Re: Ranges, Performance, and opApply
On 10/30/2011 3:09 PM, Andrei Alexandrescu wrote: As the opApply body can never be inlined it is a worse choice in general. That was my intuition too. Andrei Just for future reference, LDC **DOES** sometimes inline opApply bodies.
Re: Ranges, Performance, and opApply
On Sun, 30 Oct 2011 20:23:59 +0100, dsimcha dsim...@yahoo.com wrote: On 10/30/2011 3:09 PM, Andrei Alexandrescu wrote: As the opApply body can never be inlined it is a worse choice in general. That was my intuition too. Andrei Just for future reference, LDC **DOES** sometimes inline opApply bodies. Right it should have been 'is mostly not inlined'.
Re: The D players
On 10/30/2011 07:18 PM, Steve Teale wrote: I'm probably slightly crazy, but I have this urge to associate the digitalmars.D group with some well known group of leaders. Now I'd guess that still the best-known bunch would still be the allied leaders from WW2. So I guess that whether he likes it or not, I have to cast W. as Churchill - it was he who took on the burden in the first place. But the others. Who is Roosevelt, who Eisenhower, Montgomery, Patton and so on? And most provocatively, who is Stalin? A little relaxation - let's hear your views. Steve 2012First integration of the D programming language into several Linux distributions 2013Libraries such as gtkd, qtd, derelict now have their packages in the distro. 2014The language enters the top 10 in the Tiobe entry. From this point forward major companies start thinking of D as an option. Facebook starts using D. 2016D programming language second edition by Andrei Alexandrescu 2018ISO standardisation of the D programming language. 2020Department of defence impressed about the D programming language 2020First Terminator programmed with the D programming language. 2022Software was programmed so well that it becomes self aware. World war begins. 2023John Connor asks W. to find a weakness in the code. W. finds a bug in phobos and fixes it, making all Terminators impenetrable to software attacks. John Connor goes wtf. W. goes I've got to think about my reputation as a programmer 2024The machines take over the world. W. is Miles Dyson of Cyberdyne Systems.
Re: The D players
On 10/30/2011 12:13 PM, Andrei Alexandrescu wrote: On 10/30/11 1:18 PM, Steve Teale wrote: But the others. Who is Roosevelt, who Eisenhower, Montgomery, Patton and so on? And most provocatively, who is Stalin? Pliz pliz don't give me Stalin. You can be Ioseb Besarionis dze Jughashvili, if you like!
The Posix version identifier: D2 only?
Hi, I noticed in version.dd, the Posix version identifier is marked as D 2.0 only. Is this actually still the case? - Alex
Re: The D players
On Sun, 30 Oct 2011 20:18:55 +0200, Steve Teale steve.te...@britseyeview.com wrote: I'm probably slightly crazy, but I have this urge to associate the digitalmars.D group with some well known group of leaders. Now I'd guess that still the best-known bunch would still be the allied leaders from WW2. So I guess that whether he likes it or not, I have to cast Walter as Churchill - it was he who took on the burden in the first place. But the others. Who is Roosevelt, who Eisenhower, Montgomery, Patton and so on? And most provocatively, who is Stalin? A little relaxation - let's hear your views. Steve I'd love to take that role, with the sole reason he was a Russian. If the earth is still in one piece we owe it to them (not just ww2 but ever since). FYI, i am not a Russian.
Disallow arrays as pointers
I have translated C code similar to:
something foo(int n) {
int *array = malloc(n * sizeof(int));
int i;
for (...) {
for (i = 0; i n; i++, array++) {
*array = ...;
*array = ...;
}
...
}
Into D2 code similar to:
something foo(int n) {
auto array = new int[n];
size_t index;
foreach (...) {
foreach (i; 0 .. n) {
array[index] = ...;
*array = ...;
index++;
}
...
}
Do you see the bug I have found during the debugging?
I think the D2 compiler has to catch this bug:
*array = ...;
D arrays aren't pointers. Letting the compiler see them as pointers is
bug-prone, not tidy, and doesn't help D newbies understand how D represents its
arrays.
My bug report:
http://d.puremagic.com/issues/show_bug.cgi?id=3990
Some very good comments about this topic:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=135391
Bye,
bearophile
Re: CTFE Bug?!
On Sun, 30 Oct 2011 03:39:57 +0300, Mehrdad wfunct...@hotmail.com wrote:
I tried converting some C code I found on the internet to D.
Reduced version:
import std.stdio;
static double[1][] f()
{
auto array = new double[1][2];
array[0][0] = 1;
return array;
}
void main()
{
const result = f();
pragma(msg, result); // [[1],[1]]
writeln(result); // [[1], [nan]]
}
I don't know what's going on here.
--
Best regards,
Vladimirmailto:vladi...@thecybershadow.net
Re: Disallow arrays as pointers
On Sunday, October 30, 2011 17:29:36 bearophile wrote:
I have translated C code similar to:
something foo(int n) {
int *array = malloc(n * sizeof(int));
int i;
for (...) {
for (i = 0; i n; i++, array++) {
*array = ...;
*array = ...;
}
...
}
Into D2 code similar to:
something foo(int n) {
auto array = new int[n];
size_t index;
foreach (...) {
foreach (i; 0 .. n) {
array[index] = ...;
*array = ...;
index++;
}
...
}
Do you see the bug I have found during the debugging?
I think the D2 compiler has to catch this bug:
*array = ...;
D arrays aren't pointers. Letting the compiler see them as pointers is
bug-prone, not tidy, and doesn't help D newbies understand how D represents
its arrays.
My bug report:
http://d.puremagic.com/issues/show_bug.cgi?id=3990
Some very good comments about this topic:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Dar
ticle_id=135391
Arrays in D implicitly convert to their ptr property, so they essentially
_are_ pointers in that sense. Now, personally, I think that it would be a good
idea for them _not_ to implicitly convert, forcing you to explicitly use the
ptr property, since you really shouldn't be treating arrays as pointers in D
code. It's primarily when interacting with C code that you need to do that
sort of thing, and the ptr property deals with it just fine.
However, I don't think that you're going to find a general consensus that the
implicit conversion is bad, and changing it now would likely break a lot of
code. So, while I do think that it would be a good change, I really don't
think that it's going to happen at this point.
- Jonathan M Davis
Re: Disallow arrays as pointers
I didn't know that would compile. Anyway, if one really wants to treat arrays like pointers he can do: *array.ptr
Re: CTFE Bug?!
Vladimir Panteleev: Reduced version: Nice reduction, it looks fit for Bugzilla. Bye, bearophile
Re: Disallow arrays as pointers
On Sunday, October 30, 2011 18:10:06 bearophile wrote: Jonathan M Davis: However, I don't think that you're going to find a general consensus that the implicit conversion is bad, I'll keep count how many are against this idea. and changing it now would likely break a lot of code. How much code is broken by this? It's bad D code that's easy to fix adding a .ptr, or using -d (deprecated) to compile the code. I think that it will primarily affect strings (though in many such cases toStringz or toUTFz should generally be used), but from what I understand, it's quite common for D programmers interacting with C code to just pass arrays to C functions without using the ptr property. - Jonathan M Davis
Re: Disallow arrays as pointers
Jonathan M Davis: from what I understand, it's quite common for D programmers interacting with C code to just pass arrays to C functions without using the ptr property. That code works with an implicit conversion that saves the typing of 4 more chars, while introducing something that is negative for both newbie D programmers and more trained ones. .ptr was introduced in D to avoid this. In general I find it curious that D design tries to avoid some mistakes of the C design, and to disallow some bug-prone features of C, like some implicit type conversions. But then, it seems that D doesn't take a lot of care to avoid bug-prone features that it has introduced, that were not present in C (like the one discussed here, like lax management of strings that represent operators of operator overloading, etc.) Thank you for your answers, bye, bearophile
Re: Disallow arrays as pointers
On 10/31/2011 12:03 AM, bearophile wrote: Jonathan M Davis: from what I understand, it's quite common for D programmers interacting with C code to just pass arrays to C functions without using the ptr property. That code works with an implicit conversion that saves the typing of 4 more chars, while introducing something that is negative for both newbie D programmers and more trained ones. .ptr was introduced in D to avoid this. In general I find it curious that D design tries to avoid some mistakes of the C design, and to disallow some bug-prone features of C, like some implicit type conversions. But then, it seems that D doesn't take a lot of care to avoid bug-prone features that it has introduced, that were not present in C (like the one discussed here, like lax management of strings that represent operators of operator overloading, etc.) I have never had a bug because of arrays implicitly converting to pointers. I'd sometimes even like e.g. ++array to mean array=array[1..$]. A lot of C's carefully designed syntactic elegance is lost when going from pointers/iterators to arrays and ranges. But why is *array not bounds checked in non-release mode? I think it should be. The lax management of strings is not a bug-prone feature. (in the sense that it would be likely to produce erroneous code because of subtle typing mistakes.) Sure, if the implementer of the aggregate using operator overloading does not handle invalid sequences, it can be exploited to gain access to private members and/or implementation details. That does not happen by accident. I don't think Phobos helps enough to make correct handling easy, maybe some simple isOpBinary(string), isOpUnary(string), etc. templates would be worth adding.
Re: Disallow arrays as pointers
Timon Gehr: I have never had a bug because of arrays implicitly converting to pointers. Good. A lot of C's carefully designed syntactic elegance is lost when going from pointers/iterators to arrays and ranges. You see that D design tries hard to avoid the need to use pointers as much as possible, because pointers are bug prone, give less readable code, and they are not needed in most cases (you use something a bit higher level, like arrays or references). Some people say that C language is as elegant as a katana sword, but I have to say that most times you want to keep it in its sheath :-) But why is *array not bounds checked in non-release mode? I think it should be. In D there are arrays, and there are pointers. Arrays are bound-checked, pointers aren't. So when you use arrays as pointers, or when you use somearray.ptr[x] you have lost array bounds. Adding a third intermediate type is not a good idea, it increases language and implementation complexity for a practice that is meant as discouraged since the introduction of the ptr field. Bye, bearophile
Re: an old topic (pun intended)
On 10/29/2011 8:26 PM, bearophile wrote: The only reason to have an 'out(result)' form is to declare that we intend to use the magic 'result' symbol in the post-condition testing. This is not true. Currently 'result' has nothing magic, it's just a variable name, you are free to change it: Ah. I did not know that. Thanks for the info. I think the thing to do is to just declare 'out' as we currently do [or 'scope(out)' as I am proposing], and treat the 'result' symbol magically in the post-condition code whether or not it is pre-declared -- that is, have the compiler find it and interpret it as the magic returned-value. In some rare situations magic is acceptable, but it's dangerous, and in most situations it's better to avoid it.Unless result becomes a keyword (so you can't assign something to it by mistake), then the current syntax with out(someConstVariableName) seems better. Ah, again. 'Result' *is* magic in Eiffel (in all functions). I assumed that it was equivalently magic in D (in the post-condition context only), and named that way *because* of the Eiffel usage. You learn something every day. The notion that you can name exactly zero symbols or exactly one symbol in the 'out()' argument list, and if you name exactly one symbol then it gets (a copy of?) the returned value from the function which you can then use in your post-condition test strikes me as slightly more flexible at the cost of becoming slightly less obvious, and equally magical either way. But that's just my opinion, and I don't feel strongly about it. -- Davidson
static try?
I've written this piece of code a fair number of times:
static if (is(typeof(foo( { foo(); }
else { bar(); }
When the expression inside the condition (i.e. the call to foo()) gets
complicated, you get lots of code duplication and things become harder
to read.
So I'm thinking, why not just introduce a 'static try'?
Something like:
static try
{
foo();
}
catch // (string ex) // perhaps let them know what the error is?
{
bar();
}
It's a clean and immensely readable improvement IMO, and it doesn't
introduce any new keywords or any breaking changes to anything.
How's the idea?
Re: GSoC Mentor Summit Observations and D Marketing
On 10/24/2011 11:19 PM, Walter Bright wrote: The 3 keys come next. It has to be more than two, and less than 4. I've been toying with: 1. control 2. multi-paradigm 3. robustness (Yes, I've been reading a book on this!) Whatever you do, drop #2. multi-paradigm is a common buzzword that makes people's eyes glaze over.
Re: Compiler patch for runtime reflection
On 10/30/2011 4:03 AM, Jacob Carlborg wrote: On 2011-10-29 22:11, Adam Wilson wrote: WPF isn't the native GUI, it just comes with skins that emulate the look of the native GUI. The native GUI in Windows is called Win32 GDI (Graphices Device Interface). WPF is built on top of DirectX which is analagous to OpenGL and is primarily used for games. DirectX completely bypasses the GDI and communicates directly with the hardware. It's primary claim to fame is that it is fast, but it's not as compatible, whereas GDI is compatible with everything that implements VESA (which is everything since the early 90's), but it's slow. We don't have to argue about this but it sounds like WPF is a new native GUI, especially if it bypasses GDI. That's not the issue. The nativeness isn't regarding GDI vs. DirectX, but it's regarding the _windowing_ framework itself (which is separate from, although related to, the graphics framework). _Native_ windows use the _system_ window classes (e.g. SysListView32) to display themselves to the user. WPF (which uses DirectX) and GTK (which uses GDI) and most frameworks, on the other hand, don't -- rather, they try to /look/ like native windows by creating custom windows and intercepting all of the drawing operations. And, of course, they fail. This is indeed hard to notice on XP, but it's blindingly obvious on Windows Vista and later, because, for example, the buttons no longer feel native, even though they might look native -- e.g. the way they fade or get depressed (the timeout, the fade colors, etc.), the way they get focused, etc. is completely out of sync with the rest of the system's looks. Since native controls use GDI internally, they obviously can't be drawn with DirectX. But the key point is that the inverse is not true -- if something uses GDI (e.g. GTK), that doesn't mean it's native. So no, WPF is not native in any way, and neither is GTK -- the only native frameworks are those that use the built-in windowing classes, which include MFC, ATL, SWT, and (I /think/) Qt. Most other frameworks don't do this.
Re: Disallow arrays as pointers
Timon Gehr: A lot of C's carefully designed syntactic elegance is lost when going from pointers/iterators to arrays and ranges. I think that a large part of that C syntactic elegance is an illusion. From my experience, I want my code to look very simple to read and clean every time this is possible. I want it to be easy to port to other languages, because I have do it often enough. C code that uses lot of pointers is often bug-prone, messy and hard to safely translate to other languages. There are situation where pointers are necessary or are better than the alternatives, or they give the needed flexibility, so I prefer a language with pointers, but in a well designed language those situations are not common, and I think raw pointers should be avoided when they are not needed. I have debugged enough C code to be rather sure of this. Good luck with your pointers. Bye, bearophile
Re: The D players
On 10/30/2011 11:18 AM, Steve Teale wrote: who is Stalin? One pointer bug is a tragedy. A million pointer bugs is a statistic. - Joseph Ceelin. Are you laboring under the impression that I can compile this code of yours? I can't even open the file. - Franklin D. Rubysvelt Now I want you to remember that no programmer ever made an app work by following best practices. He made it work by making the other poor dumb programmer work his ass off. - George S. Phppon The inherent vice of static typing is the unequal sharing of bugs; the inherent virtue of dynamic typing is the equal sharing of crashes. - Winston C#arphill
Re: The D players
On 10/30/2011 09:00 PM, Walter Bright wrote: On 10/30/2011 11:18 AM, Steve Teale wrote: who is Stalin? One pointer bug is a tragedy. A million pointer bugs is a statistic. - Joseph Ceelin. Are you laboring under the impression that I can compile this code of yours? I can't even open the file. - Franklin D. Rubysvelt Now I want you to remember that no programmer ever made an app work by following best practices. He made it work by making the other poor dumb programmer work his ass off. - George S. Phppon The inherent vice of static typing is the unequal sharing of bugs; the inherent virtue of dynamic typing is the equal sharing of crashes. - Winston C#arphill Nice :-D
[beginner] Why nothing is printed to stdout ?
Hi,
Can someone give me a clue on why nothing is printed to stdout ?
I wish a list of files with their size.
code:
//
import std.stdio;
import std.file;
void main(string[] args)
{
foreach (DirEntry e; dirEntries(., SpanMode.shallow))
{
writeln(e.name, \t, e.size);
}
}
//
Build with (dmd2):
dmd -w test.d
std.container ranges
Hello there.
I seem to be having problems wrapping my head around how to use the
ranges in the context of containers in phobos. Specifically, I can't
seem to figure out how to remove an element from a linked list.
foreach(cell; organism)
{
if(cell.x == x cell.y == y)
{
organism.stableLinearRemove(cell);
break;
}
}
mind.d(123): Error: function
std.container.SList!(Cell).SList.linearRemove (Range r) is not callable
using argument types (Cell)
mind.d(123): Error: cannot implicitly convert expression (cell) of type
cell.Cell to Take!(Range)
I somehow get the feeling such a basic operation should just...work?
/Max
Re: [beginner] Why nothing is printed to stdout ?
On 30.10.2011 11:00, Frédéric Galusik wrote:
Hi,
Can someone give me a clue on why nothing is printed to stdout ?
I wish a list of files with their size.
code:
//
import std.stdio;
import std.file;
void main(string[] args)
{
foreach (DirEntry e; dirEntries(., SpanMode.shallow))
{
writeln(e.name, \t, e.size);
}
}
//
Build with (dmd2):
dmd -w test.d
Works for me on 2.055 and 2.056 on windows. What compiler and OS are you
using?
c:\tempdmd -w test.d
c:\temptest|more
.\.a.d.un~ 5326
.\.asciidoc_user-guide.txt.un~ 942
(...)
Re: [beginner] Why nothing is printed to stdout ?
Le Sun, 30 Oct 2011 12:17:24 +0100, simendsjo a écrit : Works for me on 2.055 and 2.056 on windows. What compiler and OS are you using? c:\tempdmd -w test.d c:\temptest|more .\.a.d.un~ 5326 .\.asciidoc_user-guide.txt.un~ 942 (...) Tested with dmd 2.055 and now 2.056 on Linux ++
Re: [beginner] Why nothing is printed to stdout ?
On Sun, 30 Oct 2011 10:00:21 +, Frédéric Galusik wrote:
Hi,
Can someone give me a clue on why nothing is printed to stdout ?
I wish a list of files with their size.
code:
//
import std.stdio;
import std.file;
void main(string[] args)
{
foreach (DirEntry e; dirEntries(., SpanMode.shallow))
{
writeln(e.name, \t, e.size);
}
}
//
Build with (dmd2):
dmd -w test.d
works for me, dmd 2.054 linux.
Re: std.container ranges
On Sunday, October 30, 2011 11:38:30 Max Wolter wrote:
Hello there.
I seem to be having problems wrapping my head around how to use the
ranges in the context of containers in phobos. Specifically, I can't
seem to figure out how to remove an element from a linked list.
foreach(cell; organism)
{
if(cell.x == x cell.y == y)
{
organism.stableLinearRemove(cell);
break;
}
}
mind.d(123): Error: function
std.container.SList!(Cell).SList.linearRemove (Range r) is not callable
using argument types (Cell)
mind.d(123): Error: cannot implicitly convert expression (cell) of type
cell.Cell to Take!(Range)
I somehow get the feeling such a basic operation should just...work?
linearRemove (and stableLinearRemove) takes a _range_ not a value. cell is an
element in the list, not a range over the list. The range that it takes must
be either of type SList.Range or Take!(SList.Range). You get that range by
slicing an SList. Take!(SList.Range) is for the case where you want only a
portion of the beginning of a range rather than the whole range. Your example
actually has a really simple solution:
auto found = find!((a){return a.x == x a.y == y;})(organism[]);
organism.stableLinearRemove(take(found, 1));
It finds the element in the list that you're looking for, and then it passes a
range with that one element to stableLinearRemove so that it'll remove it.
- Jonathan M Davis
Re: template expressions in C++ to an equivalent in D
I was thinking about porting http://eigen.tuxfamily.org/index.php in D. Don't we have a LinAlg library now thx to that GSoC project? I'm currently on SFML2 but it goes quite fast (thanks to Trass3r for porting SFML to D2 so a big part of the job is done). You're welcome.
Re: std.container ranges
On 10/30/2011 6:45 PM, Jonathan M Davis wrote:
On Sunday, October 30, 2011 11:38:30 Max Wolter wrote:
Hello there.
I seem to be having problems wrapping my head around how to use the
ranges in the context of containers in phobos. Specifically, I can't
seem to figure out how to remove an element from a linked list.
foreach(cell; organism)
{
if(cell.x == x cell.y == y)
{
organism.stableLinearRemove(cell);
break;
}
}
mind.d(123): Error: function
std.container.SList!(Cell).SList.linearRemove (Range r) is not callable
using argument types (Cell)
mind.d(123): Error: cannot implicitly convert expression (cell) of type
cell.Cell to Take!(Range)
I somehow get the feeling such a basic operation should just...work?
linearRemove (and stableLinearRemove) takes a _range_ not a value. cell is an
element in the list, not a range over the list. The range that it takes must
be either of type SList.Range or Take!(SList.Range). You get that range by
slicing an SList. Take!(SList.Range) is for the case where you want only a
portion of the beginning of a range rather than the whole range. Your example
actually has a really simple solution:
auto found = find!((a){return a.x == x a.y == y;})(organism[]);
organism.stableLinearRemove(take(found, 1));
It finds the element in the list that you're looking for, and then it passes a
range with that one element to stableLinearRemove so that it'll remove it.
- Jonathan M Davis
Hello there.
Thank you very much for the explanation.
However, while I really liked the concept of ranges in Andrei's book and
a lot of it seems intuitive and faster than using iterators, I can't
shake the feeling that in this case, it's just unnecessarily convoluted.
Maybe it's just the fact that the container library is still very basic,
but I don't think I should go through such a complicated procedure to
remove an known element from a list. It's just not a very simple or
intuitive solution, which is something I came to love D for thus far.
/Max
Re: std.container ranges
On Sunday, October 30, 2011 20:53:02 Max Wolter wrote:
Hello there.
Thank you very much for the explanation.
However, while I really liked the concept of ranges in Andrei's book and
a lot of it seems intuitive and faster than using iterators, I can't
shake the feeling that in this case, it's just unnecessarily convoluted.
Maybe it's just the fact that the container library is still very basic,
but I don't think I should go through such a complicated procedure to
remove an known element from a list. It's just not a very simple or
intuitive solution, which is something I came to love D for thus far.
You would be doing exactly the same thing in C++ except that it would be with
an iterator rather than a range. You would use find to find the iterator to the
element that you wanted and then you'd pass that to the list's erase function.
It is only more complicated in D in that you get a range which _starts_ with
the element that you want (essentially, you get the iterator to that element
plus the end iterator for the list), so if you want to remove only the first
element, you take it from the front of the range. Other than that, it's the
same as in C++. You can't remove an element from a list in C++ by giving that
element to the list anymore than you can in D. In both cases, you need an
iterator or a range.
So, in comparison to C++, there's no significant difference. Now, Java does
have
a remove function which will take an element and remove the first occurence of
that element from a list, and we could theoretically add one, but why? It
would just be duplicating the functionality that find already gives. Java
doesn't use iterators the way the C++ does, and it doesn't have ranges, so it
_can't_ have a find function the way that C++ and D do, but D can. And in some
cases, find can do it more efficiently than your loop could have.
I grant you that if you're not used to using find like this in C++ (and far,
far too many C++ programmers use loops instead of find - in part because pre-
C++11, there were no lambdas and any time you need a custom comparison
function, it's a pain to get one), then it's not immediately intuitive, but
it's far more flexible and powerful than removing elements by giving the
element to a remove function on the list. And if you really want to use a
loop, then you still can. You just can't use foreach.
for(auto r = organism[]; !r.empty; r.popFront())
{
if(r.front.x == x r.front.y == y)
{
organism.stableLinearRemove(take(r, 1));
break;
}
}
but that's a lot more verbose than simply using find, and as I said, in at
least some cases, find can be more efficient than simply looping, since it's
optimized for finding elements.
- Jonathan M Davis
Re: [beginner] Why nothing is printed to stdout ?
Frédéric Galusik fr...@salixosnospam.org wrote in message
news:j8j77l$pfv$1...@digitalmars.com...
Hi,
Can someone give me a clue on why nothing is printed to stdout ?
I wish a list of files with their size.
code:
//
import std.stdio;
import std.file;
void main(string[] args)
{
foreach (DirEntry e; dirEntries(., SpanMode.shallow))
{
writeln(e.name, \t, e.size);
}
}
//
Build with (dmd2):
dmd -w test.d
My aplogies it you already know this, It's not my intention to be
patronizing: You did run the resulting executable, right ( ./test )? And
there are files in the dir its beng run from?
Re: [beginner] Why nothing is printed to stdout ?
Nick Sabalausky a@a.a wrote in message
news:j8kd11$25v1$1...@digitalmars.com...
Frédéric Galusik fr...@salixosnospam.org wrote in message
news:j8j77l$pfv$1...@digitalmars.com...
Hi,
Can someone give me a clue on why nothing is printed to stdout ?
I wish a list of files with their size.
code:
//
import std.stdio;
import std.file;
void main(string[] args)
{
foreach (DirEntry e; dirEntries(., SpanMode.shallow))
{
writeln(e.name, \t, e.size);
}
}
//
Build with (dmd2):
dmd -w test.d
My aplogies it you already know this, It's not my intention to be
patronizing: You did run the resulting executable, right ( ./test )? And
there are files in the dir its beng run from?
And you did run it in a DOS window or from a batch file with a PAUSE to
allow you to read the output ;-)
Re: [beginner] Why nothing is printed to stdout ?
On 30.10.2011 14:00, Frédéric Galusik wrote:
Hi,
Can someone give me a clue on why nothing is printed to stdout ?
I wish a list of files with their size.
code:
//
import std.stdio;
import std.file;
void main(string[] args)
{
foreach (DirEntry e; dirEntries(., SpanMode.shallow))
{
writeln(e.name, \t, e.size);
}
}
//
Build with (dmd2):
dmd -w test.d
I might be way off on this.
Yet this silly stuff used to catch me all the time when switching from
windows to *nixes, back and forth:
sh$: compile something to 'test'
sh$: test
no output - WTF? Ahem, it just called that command line tool named test...
sh$: ./test
wow, now something happens ;)
--
Dmitry Olshansky
Re: std.container ranges
On Monday, October 31, 2011 12:11:45 Mike Parker wrote: On 10/31/2011 5:28 AM, Jonathan M Davis wrote: So, in comparison to C++, there's no significant difference. Now, Java does have a remove function which will take an element and remove the first occurence of that element from a list, and we could theoretically add one, but why? IMO, it's much more intuitive to say list.remove(item). It's the first thing a lot of people expect coming from a Java background, that's for sure. The first time I tried to use SList, being unfamiliar with ranges as I was, it took a while to figure out what I needed to do. IIRC, I had to post here to ask. The problem is that you really have to understand ranges and the Phobos functions that manipulate them before you can begin to use containers. I think that's wrong. Ideally, containers should be usable without having to know about find and Take and whatever else. This isn't the first time this question has come up in the NG and I've got a feeling it won't be the last. At the very least it would be nice to see something in the documentation tying std.algorithm and std.range together with std.container. Something to point the way for those to whom it isn't obvious. I definitely agree that the documentation should be improved to at least give the basic example of using find with linearRemove. Adding something similar to C++'s remove_if which removes all elements which match a predicate could also be useful, but I don't at all agree that there should be a function which takes an element and removes the first element which is equal to it. find allows you to do that just fine, and such a remove function would simply be duplicating its functionality. As for understanding ranges, it's definitely true that there needs to be more documentation and/or articles on them so that the concept can better communicated. That's a definite flaw in the current documentation. But there's a lot in Phobos which you're just not going to be able to use if you don't understand ranges, and the library would definitely be worse if it used them less, since they're such a powerful concept, so I think that the problem is the lack of communication on ranges, not the fact that ranges are used so heavily in Phobos. - Jonathan M Davis
[Issue 6213] MixinIdentifier is not work
http://d.puremagic.com/issues/show_bug.cgi?id=6213 Haruki Shigemori rayerd@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Haruki Shigemori rayerd@gmail.com 2011-10-30 00:21:13 PDT --- Fixed by dmd 2.056. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3757] The overload and override issue of const/immutable member functions -2nd-
http://d.puremagic.com/issues/show_bug.cgi?id=3757 Haruki Shigemori rayerd@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6863] New: Can upcast to Base from cosnt(Derived)
http://d.puremagic.com/issues/show_bug.cgi?id=6863
Summary: Can upcast to Base from cosnt(Derived)
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P1
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rayerd@gmail.com
--- Comment #0 from Haruki Shigemori rayerd@gmail.com 2011-10-30 00:38:10
PDT ---
// dmd 2.56
class Base {}
class Derived : Base {}
void main()
{
Base x = new const(Derived); // accepts-invalid
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6863] Can upcast to Base from const(Derived)
http://d.puremagic.com/issues/show_bug.cgi?id=6863 Haruki Shigemori rayerd@gmail.com changed: What|Removed |Added Summary|Can upcast to Base from |Can upcast to Base from |cosnt(Derived) |const(Derived) --- Comment #1 from Haruki Shigemori rayerd@gmail.com 2011-10-30 00:46:40 PDT --- Fixed a summary typo. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6864] New: Const conversion should precedence over the shared one
http://d.puremagic.com/issues/show_bug.cgi?id=6864
Summary: Const conversion should precedence over the shared one
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2011-10-30 06:49:25 PDT ---
BasicTypes can convert shared from/to non-shared with copy, but the shared
conversion priority should be lower than const conversions.
This means that following code should pass the assertions.
int fn( const int n) { return 1; }
int fn(shared int n) { return 2; }
inout(int) fw(inout int s) { return 1; }
inout(int) fw(shared inout int s) { return 2; }
int n;
assert(fn(n) == 1);
assert(fw(n) == 1);
shared int sn;
assert(fn(sn) == 2);
assert(fw(sn) == 2);
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6865] New: inout matching removes shared qualifier
http://d.puremagic.com/issues/show_bug.cgi?id=6865
Summary: inout matching removes shared qualifier
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: wrong-code
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2011-10-30 06:57:19 PDT ---
shared(inout(int)) foo(shared(inout(int)) n){ return n; }
void main()
{
shared(const(int)) n;
static assert(is(typeof(foo(n)) == shared(const(int;
// test.d(6): Error: static assert
//(is(const(int) == shared(const(int is false
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6866] New: ICE(mtype.c): alias this and inout matching
http://d.puremagic.com/issues/show_bug.cgi?id=6866
Summary: ICE(mtype.c): alias this and inout matching
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2011-10-30 07:00:44 PDT ---
struct S
{
const(char)[] val;
alias val this;
}
inout(char)[] foo(inout(char)[] s) { return s; }
void main()
{
S s;
static assert(is(typeof(foo(s)) == const(char)[]));
// Assertion failure: 'targ' on line 2029 in file 'mtype.c'
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6864] Const conversion should precedence over the shared one
http://d.puremagic.com/issues/show_bug.cgi?id=6864 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||patch --- Comment #1 from Kenji Hara k.hara...@gmail.com 2011-10-30 07:52:33 PDT --- https://github.com/D-Programming-Language/dmd/pull/481 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6865] inout matching removes shared qualifier
http://d.puremagic.com/issues/show_bug.cgi?id=6865 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||patch --- Comment #1 from Kenji Hara k.hara...@gmail.com 2011-10-30 07:52:45 PDT --- https://github.com/D-Programming-Language/dmd/pull/481 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6866] ICE(mtype.c): alias this and inout matching
http://d.puremagic.com/issues/show_bug.cgi?id=6866 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords|rejects-valid |ice-on-valid-code, patch --- Comment #1 from Kenji Hara k.hara...@gmail.com 2011-10-30 07:53:23 PDT --- https://github.com/D-Programming-Language/dmd/pull/481 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6867] New: inout and nested foreach loops
http://d.puremagic.com/issues/show_bug.cgi?id=6867
Summary: inout and nested foreach loops
Product: D
Version: D2
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: siegelords_ab...@yahoo.com
--- Comment #0 from siegelords_ab...@yahoo.com 2011-10-30 11:21:41 PDT ---
DMD version: 2.056
inout(char)[] test(inout(char)[] a)
{
foreach(dchar d; a) // No error if 'dchar' is removed
{
foreach(c; a) // line 5
{
}
}
return [];
}
test.d(5): Error: variable test.test.__foreachbody3.__aggr4 inout variables can
only be declared inside inout functions
test.d(5): Error: variable test.test.__foreachbody3.c inout variables can only
be declared inside inout functions
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6867] inout and nested foreach loops
http://d.puremagic.com/issues/show_bug.cgi?id=6867 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||patch, rejects-valid --- Comment #1 from Kenji Hara k.hara...@gmail.com 2011-10-30 12:32:43 PDT --- https://github.com/D-Programming-Language/dmd/pull/481 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6868] New: IsExp + incorrect static array type = error
http://d.puremagic.com/issues/show_bug.cgi?id=6868
Summary: IsExp + incorrect static array type = error
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2011-10-30 14:16:42 PDT ---
Code:
@property bool empty(T)(in T[] a) @safe pure nothrow
{
return !a.length;
}
void main()
{
alias int[] Range;
static if (is(char[1 + Range.empty])) // Line 9
enum bool isInfinite = true;
char[0] s; // need
}
Output:
test.d(9): Error: Integer constant expression expected instead of cast(uint)(1
+ cast(int)empty((__error)))
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6868] IsExp + incorrect static array type = error
http://d.puremagic.com/issues/show_bug.cgi?id=6868
--- Comment #1 from Kenji Hara k.hara...@gmail.com 2011-10-30 14:23:36 PDT ---
Original code:
import std.range;
void main()
{
pragma(msg, isInfinite!(int[]));
char[0] s; // need
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6868] IsExp + incorrect static array type = error
http://d.puremagic.com/issues/show_bug.cgi?id=6868 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||patch Severity|normal |major --- Comment #2 from Kenji Hara k.hara...@gmail.com 2011-10-30 15:04:37 PDT --- https://github.com/D-Programming-Language/dmd/pull/482 And change importance: normal - major In my opinion, this issue is important, because std.range.isInfinite is used frequently. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
