Get all files imported by a D source file
Hi, I wonder if there's standardized way to gather which files are imported by a source file. I know I can run "dmd -v" and look for lines start with "import", but I don't know if this is the best way to do it.
Re: Performance issue with GC
On Wednesday, 7 September 2016 at 22:54:14 UTC, Basile B. wrote: On Wednesday, 7 September 2016 at 21:20:30 UTC, Yuxuan Shui wrote: I have a little data processing program which makes heavy use of associative arrays, and GC almost doubles the runtime of it (~2m with GC disabled -> ~4m). I just want to ask what's the best practice in this situation? Do I just use GC.disable and manually run GC.collect periodically? I'd say yes. Another option: https://github.com/economicmodeling/containers. The HashMap will give you a full control on the mem allocs. This is a really nice library! Thanks a lot.
Re: Templates problem
On Wednesday, 7 September 2016 at 21:41:20 UTC, data pulverizer wrote: Yes, but from a usability point of view this would be very poor - forcing the user to create a new variable each time they modified a table. I am aware that databases do this but it is hidden away. To be fair, you can still mutate values within the table. In this approach, it's only appending new columns (or inserting them or something) that requires a new variable. It shouldn't be an issue for adding rows, assuming the underlying table is made from slices. It might be possible to do this without creating a variable, but I haven't thought about it that carefully. Moreover, if you're working with slices, then it's a reference type. This means that the new variable is not a copy of the old. It shouldn't take up much space.
Re: Templates problem
On Wednesday, 7 September 2016 at 21:33:25 UTC, pineapple wrote: Fuck it, I took an hour to document the most significant modules. https://github.com/pineapplemachine/mach.d/tree/master/mach/range Looks like a step in the right direction!
Re: Performance issue with GC
On Wednesday, 7 September 2016 at 21:20:30 UTC, Yuxuan Shui wrote: I have a little data processing program which makes heavy use of associative arrays, and GC almost doubles the runtime of it (~2m with GC disabled -> ~4m). I just want to ask what's the best practice in this situation? Do I just use GC.disable and manually run GC.collect periodically? I'd say yes. Another option: https://github.com/economicmodeling/containers. The HashMap will give you a full control on the mem allocs.
Re: Templates problem
On Wednesday, 7 September 2016 at 22:11:05 UTC, data pulverizer wrote: On Wednesday, 7 September 2016 at 20:57:15 UTC, bachmeier wrote: I too come from the R world and I have been playing the game of flitting between R and C++; using C++ (through RCpp) to speed up slow things in R for some time and I have been looking for a better solution. What are you doing with Rcpp that you can't do with D? Sorry I'll correct myself again! Because R is a dynamic programming language, you could do things that you could not do in D, however they would be very inefficient. hyper-meta-programming takes this barrier away. I meant use a combination of R + D rather than R + C++. Any bottlenecks can be handled in D as easily as C++. However, if you want to go beyond what you can do with Rcpp, it's a different story.
Re: Templates problem
On Wednesday, 7 September 2016 at 20:57:15 UTC, bachmeier wrote: I too come from the R world and I have been playing the game of flitting between R and C++; using C++ (through RCpp) to speed up slow things in R for some time and I have been looking for a better solution. What are you doing with Rcpp that you can't do with D? Sorry I'll correct myself again! Because R is a dynamic programming language, you could do things that you could not do in D, however they would be very inefficient. hyper-meta-programming takes this barrier away.
Re: Templates problem
On Wednesday, 7 September 2016 at 21:25:30 UTC, jmh530 wrote: Consider a potential use case. You have an existing data frame and you want to add a column of data to it that has a different type than the existing frame. I imagine the function call would look something like: auto newFrame = oldFrame.addCol(newData); Yes, but from a usability point of view this would be very poor - forcing the user to create a new variable each time they modified a table. I am aware that databases do this but it is hidden away. ... I only wonder if you would lose performance if wanted something fully dynamic. A static approach is a good starting place. Yes you would, which is why I see the hyper-meta route as being the potential solution to this issue.
Re: Templates problem
On Wednesday, 7 September 2016 at 20:29:42 UTC, jmh530 wrote: Thanks for the reply. It looks like an interesting idea. You might consider adding this (or a modified version) to a read me in the range subfolder. Fuck it, I took an hour to document the most significant modules. https://github.com/pineapplemachine/mach.d/tree/master/mach/range
Re: Templates problem
On Wednesday, 7 September 2016 at 20:49:42 UTC, data pulverizer wrote: You're quite right that D doesn't need to change at all to implement something like pandas or dataframes in R, but I am thinking of how to got further. Very often in data science applications types will turn up that are required but are not currently configured for your table. The choice you have is to have to modify the code or as scala does give programmers the ability to write their own interface to the type so that the it can be stored in their DataFrame. I think part of the difficulty is that you're thinking in terms of everything being dynamic. If all your data is statically typed in the first place, then I don't see what the issue is. Consider a potential use case. You have an existing data frame and you want to add a column of data to it that has a different type than the existing frame. I imagine the function call would look something like: auto newFrame = oldFrame.addCol(newData); So you just need to ensure that the data frame struct or class has an addCol method that returns a new frame with the correct type when you add a column. I'm not familiar with Scala's data frames. The best solution is that the data table is able to cope with arbitrary number of types which can be done in Sparrow. D has support for an arbitrary number of types (tuple, variant, algebraic). It's just a matter of putting it together. Anyway, given that Sparrow is still in its early stages, if you actually want to get some work done, D might be a better fit. On Wednesday, 7 September 2016 at 20:52:26 UTC, data pulverizer wrote: p.s. it goes beyond just tables, ... having dynamic capability in a static compiled language really does take computing to a different place indeed. There are some dynamic capabilities in D, such as variant/algebraic and Adam Ruppe's jsvar. I only wonder if you would lose performance if wanted something fully dynamic. A static approach is a good starting place.
Performance issue with GC
I have a little data processing program which makes heavy use of associative arrays, and GC almost doubles the runtime of it (~2m with GC disabled -> ~4m). I just want to ask what's the best practice in this situation? Do I just use GC.disable and manually run GC.collect periodically?
Re: Templates problem
On Wednesday, 7 September 2016 at 21:07:20 UTC, data pulverizer wrote: Don't get me wrong, I still think Julia is a very cool language. My opinion is that we should have more languages. Let me correct myself ... I think that hyper-meta-programming as in Sparrow could certainly revolutionize computing. I think that a big deal.
Re: Templates problem
On Wednesday, 7 September 2016 at 21:01:59 UTC, deXtoRious wrote: That's just typical press nonsense, and even they quote Bezanson saying how Julia isn't at all suited to a whole host of applications. Julia certainly has (justifiable, imho, though only time will tell) ... Don't get me wrong, I still think Julia is a very cool language. My opinion is that we should have more languages.
Re: Templates problem
On Wednesday, 7 September 2016 at 20:57:03 UTC, data pulverizer wrote: On Wednesday, 7 September 2016 at 20:29:51 UTC, deXtoRious wrote: On Wednesday, 7 September 2016 at 19:19:23 UTC, data pulverizer wrote: The "One language to rule them all" motif of Julia has hit the rocks; one reason is because they now realize that their language is being held back because the compiler cannot infer certain types for example: http://www.johnmyleswhite.com/notebook/2015/11/28/why-julias-dataframes-are-still-slow/ As an avid user of Julia, I'm going to have to disagree very strongly with this statement. The language is progressing very nicely and while it doesn't aim to be the best choice for every programming task imaginable... Ahem (http://www.wired.com/2014/02/julia/), I'm not saying that the Julia founders approved that title, we all know how the press can inflate things, but there was a certain rhetoric that Julia was creating something super-special that would change everything. That's just typical press nonsense, and even they quote Bezanson saying how Julia isn't at all suited to a whole host of applications. Julia certainly has (justifiable, imho, though only time will tell) aspirations of being useful in certain areas of general computing, not just scientific code, but they are far from universal applicability, let alone optimality. If nothing else, it's an interesting example of thinking rather far outside the usual box of language design, one with demonstrable real world applications.
Re: Templates problem
On Wednesday, 7 September 2016 at 20:57:15 UTC, bachmeier wrote: What are you doing with Rcpp that you can't do with D? That's a very good point, there's nothing that R + C++ can do that is out of D's reach. But, I wander if we can go further
Re: Templates problem
On Wednesday, 7 September 2016 at 19:19:23 UTC, data pulverizer wrote: On Wednesday, 7 September 2016 at 15:04:38 UTC, jmh530 wrote: On Wednesday, 7 September 2016 at 11:37:44 UTC, Russel Winder wrote: I really don't see what's not working in this. Trying to get new D users from Python users is the main problem. I came to D from Python/R/Matlab. The biggest issue for me wasn't error messages so much as the lack of good libraries for a lot of things. Nevertheless, the longer I've been using D, the more I agree that there could be some improvements in D's error messages. Andre had posted about the Sparrow language a while back https://forum.dlang.org/thread/ne3265$uef$1...@digitalmars.com?page=1 He liked their use of concepts. I think at a minimum it would enable better error messages. I too come from the R world and I have been playing the game of flitting between R and C++; using C++ (through RCpp) to speed up slow things in R for some time and I have been looking for a better solution. What are you doing with Rcpp that you can't do with D?
Re: Templates problem
On Wednesday, 7 September 2016 at 20:29:51 UTC, deXtoRious wrote: On Wednesday, 7 September 2016 at 19:19:23 UTC, data pulverizer wrote: The "One language to rule them all" motif of Julia has hit the rocks; one reason is because they now realize that their language is being held back because the compiler cannot infer certain types for example: http://www.johnmyleswhite.com/notebook/2015/11/28/why-julias-dataframes-are-still-slow/ As an avid user of Julia, I'm going to have to disagree very strongly with this statement. The language is progressing very nicely and while it doesn't aim to be the best choice for every programming task imaginable... Ahem (http://www.wired.com/2014/02/julia/), I'm not saying that the Julia founders approved that title, we all know how the press can inflate things, but there was a certain rhetoric that Julia was creating something super-special that would change everything.
Re: Templates problem
On Wednesday, 7 September 2016 at 20:37:50 UTC, jmh530 wrote: On Wednesday, 7 September 2016 at 19:19:23 UTC, data pulverizer I don't see any reason why D can't implement pandas DataFrames without needing to change the language at all http://pandas.pydata.org/pandas-docs/stable/generated/pandas.DataFrame.html It's just a lot of work. The simplest I can think of is a struct containing a tuple that contains slices of equal length and an array of strings containing column names. You could have a specialization with a two-dimensional array (or ndslice). p.s. it goes beyond just tables, ... having dynamic capability in a static compiled language really does take computing to a different place indeed.
Re: Templates problem
On Wednesday, 7 September 2016 at 20:37:50 UTC, jmh530 wrote: On Wednesday, 7 September 2016 at 19:19:23 UTC, data pulverizer wrote: For some time I have been considering a problem to do with creating tables with unbounded types, one of the failed attempts is here: https://forum.dlang.org/thread/gdjaoxypicsxlfvzw...@forum.dlang.org?page=1 I then exchanged emails with Lucian, Sparrows creator and he very quickly and simply outlined the solution to the problem. Thereafter I read his PhD thesis - one of the most informative texts in computer science I have read and very well written. At the moment, there are lots of languages attempting to solve the dynamic-static loop, being able to have features inherent in dynamic programming languages, while keeping the safety and performance that comes with a static compiled programming language, and then doing so in a language that doesn't cause your brain to bleed. The "One language to rule them all" motif of Julia has hit the rocks; one reason is because they now realize that their language is being held back because the compiler cannot infer certain types for example: http://www.johnmyleswhite.com/notebook/2015/11/28/why-julias-dataframes-are-still-slow/ I don't see any reason why D can't implement pandas DataFrames without needing to change the language at all http://pandas.pydata.org/pandas-docs/stable/generated/pandas.DataFrame.html It's just a lot of work. The simplest I can think of is a struct containing a tuple that contains slices of equal length and an array of strings containing column names. You could have a specialization with a two-dimensional array (or ndslice). You're quite right that D doesn't need to change at all to implement something like pandas or dataframes in R, but I am thinking of how to got further. Very often in data science applications types will turn up that are required but are not currently configured for your table. The choice you have is to have to modify the code or as scala does give programmers the ability to write their own interface to the type so that the it can be stored in their DataFrame. The best solution is that the data table is able to cope with arbitrary number of types which can be done in Sparrow.
Re: Templates problem
On Wednesday, 7 September 2016 at 19:19:23 UTC, data pulverizer wrote: For some time I have been considering a problem to do with creating tables with unbounded types, one of the failed attempts is here: https://forum.dlang.org/thread/gdjaoxypicsxlfvzw...@forum.dlang.org?page=1 I then exchanged emails with Lucian, Sparrows creator and he very quickly and simply outlined the solution to the problem. Thereafter I read his PhD thesis - one of the most informative texts in computer science I have read and very well written. At the moment, there are lots of languages attempting to solve the dynamic-static loop, being able to have features inherent in dynamic programming languages, while keeping the safety and performance that comes with a static compiled programming language, and then doing so in a language that doesn't cause your brain to bleed. The "One language to rule them all" motif of Julia has hit the rocks; one reason is because they now realize that their language is being held back because the compiler cannot infer certain types for example: http://www.johnmyleswhite.com/notebook/2015/11/28/why-julias-dataframes-are-still-slow/ I don't see any reason why D can't implement pandas DataFrames without needing to change the language at all http://pandas.pydata.org/pandas-docs/stable/generated/pandas.DataFrame.html It's just a lot of work. The simplest I can think of is a struct containing a tuple that contains slices of equal length and an array of strings containing column names. You could have a specialization with a two-dimensional array (or ndslice).
Re: Templates problem
On Wednesday, 7 September 2016 at 19:19:23 UTC, data pulverizer wrote: The "One language to rule them all" motif of Julia has hit the rocks; one reason is because they now realize that their language is being held back because the compiler cannot infer certain types for example: http://www.johnmyleswhite.com/notebook/2015/11/28/why-julias-dataframes-are-still-slow/ As an avid user of Julia, I'm going to have to disagree very strongly with this statement. The language is progressing very nicely and while it doesn't aim to be the best choice for every programming task imaginable, it already does an excellent job of letting a scientific programmer such as myself do most of my workflow in a single language with remarkable performance. Furthermore, the article you linked pertains to a simple type inference issue, exposed by the design constraints of a particular library. While certain design patterns can and often do lead to Python-style Julia code with optimal performance, you can always get there by manually enforcing type stability at the cost of less pretty code. More to the general point of the discussion, I find that most scientifically minded users of Python already appreciate some of the inherent advantages of lower level statically typed languages and often rather write C/C++ code than descend into the likes of Cython. D has considerable advantages over C++ in conciseness and template facilities for achieving zero cost static polymorphism without descending into utter unreadability. Personally, I find myself still forced to write most of my non-Julia high performance code in C++ due to the available libraries and GPGPU support (especially CUDA), but in terms of language properties I'd much rather be writing D.
Re: Templates problem
On Wednesday, 7 September 2016 at 18:55:41 UTC, pineapple wrote:
So the first difference you're likely to notice is that it's
not as well documented. (Sorry. I'm a busy woman. I'll get
around to it.) I try to make up for it with copious unit tests,
which should provide a good example for how to use any given
module.
In terms of functionality, the single-biggest difference is
that unlike phobos I don't treat arrays or any other collection
directly as ranges; instead types may provide an `asrange`
property returning a range that enumerates their contents. This
architecture allows you to express HOFs as shown in that prior
post, not having to worry about whether it's safe to treat the
array itself as a range or whether you have to slice it.
Other significant differences include not requiring
bidirectional, slicing, random-access ranges to also be saving
("forward") ranges; (for the most part) supporting immutable
elements in ranges; and a more clearly defined interface for
what insertion and removal operations you may perform upon a
range and how they are expected to behave. There are a few
things phobos provides that I don't yet, but there's also a
handful of things implemented in mach.range that aren't in
phobos. (My personal favorite example of such is its small
suite of PRNG implementations.)
Thanks for the reply. It looks like an interesting idea. You
might consider adding this (or a modified version) to a read me
in the range subfolder.
Are you familiar with Chapel at all? The language allows the user
to specify a domain with an array, facilitating sparsity or
arrays distributed across different machines. For some reason I
was reminded of that when you say that asrange returns a range
that enumerates the contents.
Re: VisualD core.exception.RangeError@pipedmd(286): Range violation
On 07.09.2016 19:28, Rainer Schuetze wrote: On 06.09.2016 06:38, Tofu Ninja wrote: I get "core.exception.RangeError@pipedmd(286): Range violation" whenever I try to build from visual D. Is there any workaround for this? It was reported[1] almost 9 months ago, does not seem like it's going to be fixed anytime soon. Visual D is completely broken for me right now because of it. Only reason I use Visual D is because it's the only useable debugger on windows, now I can't even do that... Lost a day of work trying to fix this, starting to get really annoyed... [1] https://issues.dlang.org/show_bug.cgi?id=15606 Please provide a test case. Without it, there is little that can be done. I now remember having investigated that bug before: https://forum.dlang.org/post/nmkfnm$2f51$1...@digitalmars.com and I did find it happened for symbols of exact length 2048. I even had a fix for it, but can't find it in the log. I'll try to reconstruct what happened...
Re: Templates problem
On Wednesday, 7 September 2016 at 15:04:38 UTC, jmh530 wrote: On Wednesday, 7 September 2016 at 11:37:44 UTC, Russel Winder wrote: I really don't see what's not working in this. Trying to get new D users from Python users is the main problem. I came to D from Python/R/Matlab. The biggest issue for me wasn't error messages so much as the lack of good libraries for a lot of things. Nevertheless, the longer I've been using D, the more I agree that there could be some improvements in D's error messages. Andre had posted about the Sparrow language a while back https://forum.dlang.org/thread/ne3265$uef$1...@digitalmars.com?page=1 He liked their use of concepts. I think at a minimum it would enable better error messages. I too come from the R world and I have been playing the game of flitting between R and C++; using C++ (through RCpp) to speed up slow things in R for some time and I have been looking for a better solution. For some time I have been considering a problem to do with creating tables with unbounded types, one of the failed attempts is here: https://forum.dlang.org/thread/gdjaoxypicsxlfvzw...@forum.dlang.org?page=1 I then exchanged emails with Lucian, Sparrows creator and he very quickly and simply outlined the solution to the problem. Thereafter I read his PhD thesis - one of the most informative texts in computer science I have read and very well written. At the moment, there are lots of languages attempting to solve the dynamic-static loop, being able to have features inherent in dynamic programming languages, while keeping the safety and performance that comes with a static compiled programming language, and then doing so in a language that doesn't cause your brain to bleed. The "One language to rule them all" motif of Julia has hit the rocks; one reason is because they now realize that their language is being held back because the compiler cannot infer certain types for example: http://www.johnmyleswhite.com/notebook/2015/11/28/why-julias-dataframes-are-still-slow/ A language that can create arbitrary complex programs is the kind of thing that changes the world. I don't think D should be left out and should take Sparrow very seriously indeed.
Re: Templates problem
On Wednesday, 7 September 2016 at 18:22:39 UTC, jmh530 wrote:
On Wednesday, 7 September 2016 at 18:10:45 UTC, pineapple wrote:
You might want to check out the ranges package of the library
I'm working on.
https://github.com/pineapplemachine/mach.d/tree/master/mach/range
There's a lot of stuff there. Do you mind giving a TL;DR
version of what your range library does differently than phobos?
So the first difference you're likely to notice is that it's not
as well documented. (Sorry. I'm a busy woman. I'll get around to
it.) I try to make up for it with copious unit tests, which
should provide a good example for how to use any given module.
In terms of functionality, the single-biggest difference is that
unlike phobos I don't treat arrays or any other collection
directly as ranges; instead types may provide an `asrange`
property returning a range that enumerates their contents. This
architecture allows you to express HOFs as shown in that prior
post, not having to worry about whether it's safe to treat the
array itself as a range or whether you have to slice it.
Other significant differences include not requiring
bidirectional, slicing, random-access ranges to also be saving
("forward") ranges; (for the most part) supporting immutable
elements in ranges; and a more clearly defined interface for what
insertion and removal operations you may perform upon a range and
how they are expected to behave. There are a few things phobos
provides that I don't yet, but there's also a handful of things
implemented in mach.range that aren't in phobos. (My personal
favorite example of such is its small suite of PRNG
implementations.)
Also: I just pushed the fix.
Re: Templates problem
On Wednesday, 7 September 2016 at 18:10:45 UTC, pineapple wrote: You might want to check out the ranges package of the library I'm working on. https://github.com/pineapplemachine/mach.d/tree/master/mach/range There's a lot of stuff there. Do you mind giving a TL;DR version of what your range library does differently than phobos?
Re: Templates problem
On Tuesday, 6 September 2016 at 14:38:54 UTC, Russel Winder wrote:
and I have no idea just now why it is complaining, nor what to
do to fix it.
You might want to check out the ranges package of the library I'm
working on.
https://github.com/pineapplemachine/mach.d/tree/master/mach/range
This topic motivated me to see if my map function worked with
static arrays. Turns out that somehow I'd neglected to include a
unit test, and it in fact failed.
Once I've had a chance to commit the couple-line fix, probably in
a couple hours, this will be a valid program:
import mach.range : map;
import std.stdio : writeln;
void main(){
const(const(int)[3]) array = [1, 2, 3];
auto mapped = array.map!(e => e + 1);
mapped.front.writeln; // 2
mapped[0].writeln; // 2
// etc.
}
Re: Unicode function name? ∩
On Wednesday, 7 September 2016 at 07:39:53 UTC, Jesper Tholstrup wrote: On Tuesday, 6 September 2016 at 20:26:01 UTC, Illuminati wrote: Ok, continue your game I see you are quite involved with it. For what it's worth I was actually trying to learn something. I apologize if I contributed to sidetracking the discussion. Well, I tried to tell you that you are hung up on the meaning of meaningless things and you said that it was all my personal opinion. Either it is or isn't but simply stating it proves nothing. It's up for you to decide if what I have said is worth pursuing for yourself or not. But surely you would agree that if you believe something has inherent meaning but it actually doesn't that you are creating a whole world of grief for yourself and others? Hence, it is utmost importance to know? All I will say is "Don't confuse the map with the territory". The territory exists without the map, but not vice versa.
Re: VisualD core.exception.RangeError@pipedmd(286): Range violation
On 06.09.2016 06:38, Tofu Ninja wrote: I get "core.exception.RangeError@pipedmd(286): Range violation" whenever I try to build from visual D. Is there any workaround for this? It was reported[1] almost 9 months ago, does not seem like it's going to be fixed anytime soon. Visual D is completely broken for me right now because of it. Only reason I use Visual D is because it's the only useable debugger on windows, now I can't even do that... Lost a day of work trying to fix this, starting to get really annoyed... [1] https://issues.dlang.org/show_bug.cgi?id=15606 Please provide a test case. Without it, there is little that can be done.
forwarding build type to dependencies with dub
Is it possible to forward the build type to the dependencies of a dub project? For example, if I build my project with dub build -b unittest is it possible to make dub build the dependencies of my project also with the unittest build type? Even better would be a way to specify for which dependencies this should happen. This would be useful for using dunit (http://code.dlang.org/packages/dunit). When built with the unittest build type, it replaces the default unittest handler to give nicer output about which unittests failed and why etc. If I simply add dunit as a dependency to my project and build my project as described above, dunit is not built with the unittest build type and thus the unittest handler is not replaced and I got the usual assertion error output for failing unittests. I tried removing the version(unittest) from the part of dunit, which replaces the handler, but it always outputs some text, even if no unittests are being run (if we don't compile with -unittest). Of course I do not want this ouput when not testing and especially not in release code...
Re: Templates problem
On Wednesday, 7 September 2016 at 11:37:44 UTC, Russel Winder wrote: The real problem though is the terrifying error message. I am having a hard time finding a way of pitching them to Pythonistas. Do they use single assignment a lot?
Re: Templates problem
On Wednesday, 7 September 2016 at 11:37:44 UTC, Russel Winder wrote: I really don't see what's not working in this. Trying to get new D users from Python users is the main problem. I came to D from Python/R/Matlab. The biggest issue for me wasn't error messages so much as the lack of good libraries for a lot of things. Nevertheless, the longer I've been using D, the more I agree that there could be some improvements in D's error messages. Andre had posted about the Sparrow language a while back https://forum.dlang.org/thread/ne3265$uef$1...@digitalmars.com?page=1 He liked their use of concepts. I think at a minimum it would enable better error messages.
Re: Templates problem
On Wednesday, 7 September 2016 at 11:37:44 UTC, Russel Winder wrote: I'd prefer immutable, but const sometimes has to do. The idea is to find out how to enforce single assignment in D. Everything depends on what you mean by "single assignment". If you mean "I can't use opAssign", then const is definitely too strong. In this case, you can write a simple type wrapper that disables opAssign, while providing all other functionalities. If you mean "Methods do not mutate objects; instead, they return new objects, mutated", the issue is deeper. In fact, input ranges and output ranges cannot (by definition) fulfill this requirement. Other ranges (forward, bidirectional, random) can fulfill this requirement, but it's very expensive, as it requires a new copy of every range every time you want to popFront or popBack. The same goes for every other type with mutable methods. If you really want this behaviour, you can easily write (again) a type wrapper that forwards every const method call while intercepting every mutable method call and applying it to a new copy that is returned. But I think it will severely hurt performance and readability.
Re: Templates problem
On Wednesday, 7 September 2016 at 11:33:08 UTC, Russel Winder wrote: C++, error messages sorry, i loled hard.
Re: Templates problem
On Wed, 2016-09-07 at 09:04 +, Lodovico Giaretta via Digitalmars-d- learn wrote: > […] > You have your const fixed-length array. You slice it and you > obtain a const range to feed map. Now map will not return you an > array. Because most of the time you don't need it. It will return > you a range that lazily computes its elements on demand. No > memory allocation at all. You can do a foreach on that range. If > you need to access those elements more than once, instead of > recomputing each of them every time it is accessed, you can store > the results of the map. You simply have to use .array on the map > result. This will allocate memory and give you an array with your > results. Otherwise, no allocation at all. That result array can > be const, if you want. If you need to access your elements only > once, there's no need to have an array. The problem for me had been that ranges are mutable or useless since they are single use destructive things. So yes trying to add immutable or const to it is breaking the range model. The real problem though is the terrifying error message. I am having a hard time finding a way of pitching them to Pythonistas. > I really don't see what's not working in this. Trying to get new D users from Python users is the main problem. > And by the way, there's no need to put const on everything. An > optimizing compiler is often able to infer things, especially for > stack allocated local variables. I'd prefer immutable, but const sometimes has to do. The idea is to find out how to enforce single assignment in D. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Templates problem
On Wed, 2016-09-07 at 09:03 +, ketmar via Digitalmars-d-learn wrote: > […] > > alas, no jokes here. within the current D sytnax there is simply > no way to make that error less cryptic. :-( Well that will be the end of any traction for D then. C++, Java, Groovy, etc. error messages prove that error reporting is something you get right or you have no users that are not working under Stockholm Syndrome. > even pointing at the failed constraint is fairly hard with > current DMDFE code (that's why nobody did it yet), and show > custom error for that is nearly impossible. we can't write "catch > all" template with static assert, 'cause it catches everything, > which is not desirable. > > i myself didn't found even acceptable solution for this mess. > sure, at least pointing to failed constraint is something we > should have, but in your case it is of little help, actually. > > probably adding `map` overload which accepts static arrays and > does `static assert(0, "please use slice for static arrays");` > may help in this case. I think bearophile suggested adding amap many moons ago. I suspect this will never happen due to array(map(…)) which is fine. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Templates problem
On Wed, 2016-09-07 at 20:32 +1200, rikki cattermole via Digitalmars-d-
learn wrote:
>
[…]
> Ok, I have it mostly compiling.
>
> void run_mean() {}
> void run_mode() {}
> void run_stdDev() {}
For my code the functions have to be declared within the main function
rather than being at module level. But this turns out to be a non-
issue.
> void main() {
> import std.datetime;
> import std.algorithm : map;
> import std.conv;
> import std.array;
I am still not a fan of this import all symbols approach, like the map
import, I would do the same for the other modules' functions used.
> const results = benchmark!(run_mean, run_mode, run_stdDev)(1);
> const times = map!((TickDuration t) { return
> (to!Duration(t)).total!"seconds"; })(results[]);
It turns out my problem was here. See below.
> import std.stdio;
> foreach(v; times) {
> writeln(v);
> }
> }
>
> However times really can't be const. Since times is an input range
> which
> gets modified as part of the iterations.
Indeed. I keep forgetting that ranges are use once mutable entities,
and there is no option. s/const/auto/ solves the problem, but the more
likely general solution is to retain the const and reify the array. But
it depends on usage, obviously.
> So what exactly do you want times to be? If you want an array .array
> from std.algorithm it which can be const. Either way there is
> something
> I'm missing as to why const is so important here.
In this case it isn't as you can't use a constant range. The problem I
am having is when I cannot use const or better immutable. I'm a single
assignment sort of person, but D ranges break all that orthodoxy.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: Templates problem
On Wed, 2016-09-07 at 08:42 +, Kagamin via Digitalmars-d-learn wrote: > https://dpaste.dzfl.pl/0b436b240e3c But now try adding the writeln function. Then you get the errors. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Templates problem
On Wednesday, 7 September 2016 at 08:19:39 UTC, Russel Winder wrote: On Tue, 2016-09-06 at 14:50 +, Lodovico Giaretta via Digitalmars-d- learn wrote: […] From a quick look, it looks like `results` is a `const(TickDuration[3])`, that is a fixed-length array. And fixed-length arrays aren't ranges. If you explicitly slice them, they become dynamic arrays, which are ranges. So the solution is to call `map` with `results[]` instead of `results`. So trying with results[] leads to: run_checks.d(21): Error: mutable method std.algorithm.iteration.MapResult!(function (TickDuration t) => to(t).total(), const(TickDuration)[]).MapResult.opIndex is not callable using a const object run_checks.d(21): Error: mutable method std.algorithm.iteration.MapResult!(function (TickDuration t) => to(t).total(), const(TickDuration)[]).MapResult.opIndex is not callable using a const object run_checks.d(21): Error: mutable method std.algorithm.iteration.MapResult!(function (TickDuration t) => to(t).total(), const(TickDuration)[]).MapResult.opIndex is not callable using a const object yes, the message is repeated three times, for unknown reason. Possibly because the compiler is fairly certain I am not going to believe it. So the upshot of this is that I can't work with const data, which is dreadful in these days of single assignment being the way of doing things. So what is the way of constructing a range from a const array? If it involves copying then D is doomed. And yes I am under stress as I am trying to pitch D to Python people next week. You have your const fixed-length array. You slice it and you obtain a const range to feed map. Now map will not return you an array. Because most of the time you don't need it. It will return you a range that lazily computes its elements on demand. No memory allocation at all. You can do a foreach on that range. If you need to access those elements more than once, instead of recomputing each of them every time it is accessed, you can store the results of the map. You simply have to use .array on the map result. This will allocate memory and give you an array with your results. Otherwise, no allocation at all. That result array can be const, if you want. If you need to access your elements only once, there's no need to have an array. I really don't see what's not working in this. And by the way, there's no need to put const on everything. An optimizing compiler is often able to infer things, especially for stack allocated local variables.
Re: Templates problem
On Wednesday, 7 September 2016 at 08:30:51 UTC, Russel Winder wrote: On Tue, 2016-09-06 at 14:53 +, ketmar via Digitalmars-d-learn wrote: […] exactly. static arrays doesn't have `popFront`, hence `isInputRange` fails. yet there is no way to tell that to user, so one should just learn what those cryptic error messages really means. I shall assume a ;-) at the end of that. alas, no jokes here. within the current D sytnax there is simply no way to make that error less cryptic. :-( even pointing at the failed constraint is fairly hard with current DMDFE code (that's why nobody did it yet), and show custom error for that is nearly impossible. we can't write "catch all" template with static assert, 'cause it catches everything, which is not desirable. i myself didn't found even acceptable solution for this mess. sure, at least pointing to failed constraint is something we should have, but in your case it is of little help, actually. probably adding `map` overload which accepts static arrays and does `static assert(0, "please use slice for static arrays");` may help in this case.
Re: UFCS not working with alias
On Wednesday, 7 September 2016 at 08:35:26 UTC, rikki cattermole wrote: On 07/09/2016 8:26 PM, Andre Pany wrote: [...] People have tried, this is the behavior as designed. The workaround is simple, don't use UFCS. I won't repeat the explanation or reasoning here, plenty of posts on it ;) Thanks, this answer my question. Kind regards André
Re: Templates problem
https://dpaste.dzfl.pl/0b436b240e3c
Re: UFCS not working with alias
On 07/09/2016 8:26 PM, Andre Pany wrote:
On Wednesday, 7 September 2016 at 08:08:34 UTC, rikki cattermole wrote:
On 07/09/2016 8:06 PM, Andre Pany wrote:
Should I open an enhancement request?
No.
It works outside of the function (part of lookup rules).
I simplified my example too much. Yes in the example above I can move
the alias
outside the main function. Here is a more complex example.
As I use the input parameter args in the alias, I cannot move the alias
outside
the main function.
import std.algorithm;
bool fulfillsKeyPredicate(string s, string t) {return true;}
void main(string[] args)
{
alias keyPredicateFilter = filter!(e =>
e.fulfillsKeyPredicate(args[0]));
string[] arr;
keyPredicateFilter(arr);
arr.keyPredicateFilter;
}
Is there a workaround? Or is still a valid scenario to change the lookup
rules?
People have tried, this is the behavior as designed.
The workaround is simple, don't use UFCS.
I won't repeat the explanation or reasoning here, plenty of posts on it ;)
Re: Templates problem
On 07/09/2016 2:38 AM, Russel Winder via Digitalmars-d-learn wrote:
The code fragment:
const results = benchmark!(run_mean, run_mode, run_stdDev)(1);
const times = map!((TickDuration t) { return
(to!Duration(t)).total!"seconds"; })(results);
seems entirely reasonable to me. However rdmd 20160627 begs to differ:
run_checks.d(20): Error: template std.algorithm.iteration.map!(function
(TickDuration t) => to(t).total()).map cannot deduce function from argument
types !()(const(TickDuration[3])), candidates are:
/usr/include/dmd/phobos/std/algorithm/iteration.d(450):
std.algorithm.iteration.map!(function (TickDuration t) =>
to(t).total()).map(Range)(Range r) if (isInputRange!(Unqual!Range))
Failed: ["dmd", "-v", "-o-", "run_checks.d", "-I."]
and I have no idea just now why it is complaining, nor what to do to
fix it.
Ok, I have it mostly compiling.
void run_mean() {}
void run_mode() {}
void run_stdDev() {}
void main() {
import std.datetime;
import std.algorithm : map;
import std.conv;
import std.array;
const results = benchmark!(run_mean, run_mode, run_stdDev)(1);
const times = map!((TickDuration t) { return
(to!Duration(t)).total!"seconds"; })(results[]);
import std.stdio;
foreach(v; times) {
writeln(v);
}
}
However times really can't be const. Since times is an input range which
gets modified as part of the iterations.
So what exactly do you want times to be? If you want an array .array
from std.algorithm it which can be const. Either way there is something
I'm missing as to why const is so important here.
Re: Templates problem
On Tue, 2016-09-06 at 14:53 +, ketmar via Digitalmars-d-learn wrote: > […] > exactly. static arrays doesn't have `popFront`, hence > `isInputRange` fails. yet there is no way to tell that to user, > so one should just learn what those cryptic error messages really > means. I shall assume a ;-) at the end of that. In trying to pitch D to Pythonistas, having to deal with error messages of this sort is the fastest route to "F@@@ that I'll just use Python", with D consigned to the dustbin. Either that or it will make it very easy to pitch Chapel to Pythonistas. Which I shall also be trying to do as well – the idea is to wean Pythonistas off hacking Python to achieve computational speed, get them into a polyglot approach. The issue here is having to compete against NumPy and Numba for performance computation, and Matplotlib for data visualisation. C, C++, Rust, Go will not cut it as competition in performance computation. D and Chapel (and X10 and Fortran but I am avoiding them) can. Sort of. The issue is that Python and Matplotlib should be seen as the partners rather than competition for D and Chapel. Arcane error messages from D compilers, are the fastest turn offs imaginable for people coming new to a language. > or just get used to always slice arrays, it's cheap. ;-) Except that it seems you cannot create a range from a const array by slicing. If the algorithms cannot operate on const arrays then the algorithms have a problem. If the algorithms have a problem, the language has a problem. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: UFCS not working with alias
On Wednesday, 7 September 2016 at 08:08:34 UTC, rikki cattermole
wrote:
On 07/09/2016 8:06 PM, Andre Pany wrote:
Should I open an enhancement request?
No.
It works outside of the function (part of lookup rules).
I simplified my example too much. Yes in the example above I can
move the alias
outside the main function. Here is a more complex example.
As I use the input parameter args in the alias, I cannot move the
alias outside
the main function.
import std.algorithm;
bool fulfillsKeyPredicate(string s, string t) {return true;}
void main(string[] args)
{
alias keyPredicateFilter = filter!(e =>
e.fulfillsKeyPredicate(args[0]));
string[] arr;
keyPredicateFilter(arr);
arr.keyPredicateFilter;
}
Is there a workaround? Or is still a valid scenario to change the
lookup rules?
Kind regards
André
Re: Templates problem
On Tue, 2016-09-06 at 14:50 +, Lodovico Giaretta via Digitalmars-d- learn wrote: > […] > From a quick look, it looks like `results` is a > `const(TickDuration[3])`, that is a fixed-length array. And > fixed-length arrays aren't ranges. If you explicitly slice them, > they become dynamic arrays, which are ranges. > > So the solution is to call `map` with `results[]` instead of > `results`. So trying with results[] leads to: run_checks.d(21): Error: mutable method std.algorithm.iteration.MapResult!(function (TickDuration t) => to(t).total(), const(TickDuration)[]).MapResult.opIndex is not callable using a const object run_checks.d(21): Error: mutable method std.algorithm.iteration.MapResult!(function (TickDuration t) => to(t).total(), const(TickDuration)[]).MapResult.opIndex is not callable using a const object run_checks.d(21): Error: mutable method std.algorithm.iteration.MapResult!(function (TickDuration t) => to(t).total(), const(TickDuration)[]).MapResult.opIndex is not callable using a const object yes, the message is repeated three times, for unknown reason. Possibly because the compiler is fairly certain I am not going to believe it. So the upshot of this is that I can't work with const data, which is dreadful in these days of single assignment being the way of doing things. So what is the way of constructing a range from a const array? If it involves copying then D is doomed. And yes I am under stress as I am trying to pitch D to Python people next week. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: UFCS not working with alias
On 07/09/2016 8:06 PM, Andre Pany wrote: Should I open an enhancement request? No. It works outside of the function (part of lookup rules).
UFCS not working with alias
Hi,
I just noticed ufcs does not work with alias. Is this limitation
needed?
void foo(int a) {}
void main()
{
alias bar = foo;
3.foo();
3.bar();
}
Last line fails with "no property 'bar' for type int.
Should I open an enhancement request?
Kind regards
André
Re: Unicode function name? ∩
On Tuesday, 6 September 2016 at 20:26:01 UTC, Illuminati wrote: Ok, continue your game I see you are quite involved with it. For what it's worth I was actually trying to learn something. I apologize if I contributed to sidetracking the discussion.
